OpenStack – część 2 – Tworzenie instancji oraz sieci

Zakładam, że posiadamy już OpenStacka (wersja queens) zainstalowanego w systemie CentOS 7.

Obrazy systemów

Przed utworzeniem instancji należy dodać obraz systemu. Domyślnie mamy do dyspozycji jeden obraz z systemem CirrOS. My jednak załadujemy własny obraz. Możemy to zrobić na dwa sposoby. Pierwszy to pobranie obrazu ISO i samodzielna instalacja systemu, a drugi to użycie obrazu przygotowanego specjalnie dla OpenStacka. Lista dystrubucji które udostępniają obrazy dla OpenStacka znajduje się tutaj. Skorzystamy z najnowszego obrazu Debiana (link do pobrania).

Po pobraniu obrazu wchodzimy na stronę zarządzania obrazami „Project -> Compute -> Images” i klikamy na przycisk „Create Image”.

 

Wpisujemy nazwę, wybieramy plik z obrazem oraz format „QCOW2 – QEMU Emulator” i naciskamy „Create Image”.

Po chwili do listy obrazów zostanie dodany nowy obraz.

Sieci

W tym momencie powinniśmy utworzyć instancję, ale każda instancja do działania wymaga sieci. OpenStack domyślnie tworzy jedną sieć o nazwie „public”, której użycie powinno nam zagwarantować nadanie adresu naszej instancji przez DHCP oraz dostęp do sieci Internet, ale… z jakiegoś powodu to nie działa. Instancje nie otrzymują adresów.

Problem udało mi się rozwiązać dodając własną sieć.

Przechodzimy do „Project -> Network -> Networks” i klikamy na „Create Network”. Uzupełniamy nazwę sieci („prod”), klikamy „Next” i uzupełniamy nazwę podsieci oraz „Network Address” np. „20.0.0.0/24”, następnie „Next” oraz „Create”.

Teraz musimy podłączyć naszą sieć do Internetu. Podczas instalacji tworzona jest sieć publiczna o nazwie „public” oraz router o nazwie „rourter1”. Te dwa elementy zapewniają nam łączność ze światem zewnętrznym.

Najłatwiej byłoby dodać naszą sieć do domyślnego routera („router1”), ale ta operacja powoduje, że nie da się przypisywać zewnętrznych adresów IP do naszych instancji. Co ciekawe, da się to zrobić przy pomocy narzędzi konsolowych. Problem można ominąć tworząc własny router i ustawiając jego domyślną bramę na router publiczny („router1”).

Wchodzimy w „Project -> Network -> Routers” i klikamy na „Create Router”. Uzupełniamy nazwę i ponownie na „Create Router”. Wchodzimy w szczegóły naszego routera i klikamy w „Add Interface”. W „Subnet” wybieramy naszą sieć („prod”) i naciskamy „Submit”. Następnie klikamy w „Set Gateway”, w „External Network” wybieramy sieć „public” i klikamy „Submit”.

Od teraz wszystkie instancje w naszej sieci („prod”) będą miały dostęp do Internetu.

Instancje

Przechodzimy do „Project -> Compute -> Instances” i klikamy na „Launch Instance”. Uzupełniamy „Instance Name” w zakładce „Details”, wybieramy obraz w zakładce „Source” oraz nowo utworzoną sieć („prod”) w zakładce „Networks”. Następnie tworzymy klucz w zakładce „Key Pair”, pobieramy klucz prywatny i zapisujemy go w pliku. Będziemy go używali do łączenia się z naszą instancją przez SSH. Naciskamy „Launch Instance”.

Możemy kilknąć w naszą instancję, a następnie w zakładkę „Log”, aby zobaczyć co się dzieje. Aby zobaczyć pełny log możemy kliknąć na „View Full Log”. Interesuje nas tabela z interfejsami sieciowymi (szukamy ciągu znaków „Net device info”). Zobaczymy w niej, że interfejs „eth0” utrzymał adres (np. „20.0.0.9”).

Możemy teraz wejść w „Project -> Network -> Network Topology”, aby zobaczyć jak wygląda struktura naszej sieci.

Niestety, nie może się połączyć z instacją, ponieważ dostęp do instancji jest zablokowany (port 22) oraz instancja nie posiada zewnętrzengo adresu IP.

Security groups

Przechodzimy do „Admin -> Network -> Security Groups”. Przy grupie „default” klikamy na „Manage Rules” i „Add Rule”. W nowym oknie w „Rule” wybieramy „SSH” i naciskamy „Add”. W celach testowych możemy również dodać reguły zezwalające na ICMP dzięki czemu będziemy mogli pingować nasze instancje. Dodajemy regułę „All ICMP” dwa razy. Za pierwszym razem w „Direction” wybierami „Ingres”, a za drugim „Engress”.

Zewnętrze adresy IP

OpenStack powinien utworzyć w naszym systemie interfejs „br-ex”, który służy do komunikacji pomiędzy naszymi instancjami, a światem zewnętrznym. Jego obecność możemy sprawdzić poleceniem „ip addr”.

5: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN qlen 1000
    link/ether 66:7e:ac:bc:aa:44 brd ff:ff:ff:ff:ff:ff
    inet 172.24.4.1/24 scope global br-ex
       valid_lft forever preferred_lft forever
    inet6 fe80::647e:acff:febc:aa44/64 scope link
       valid_lft forever preferred_lft forever

Jak widzimy interfejs posiada adres 172.24.4.1/24. Nasze instancje będą otrzymywać adresy właśnie z tego zakresu.

Wracamy do listy instancji. Rozwijamy menu obok instancji i wybieramy „Assiociate Floating IP”. W nowym oknie naciskamy na „+” obok pustej listy IP. W kolejnym oknie naciskamy tylkoe „Allocate IP” i wracamy do poprzedniego okna. W „IP Adress” będzie nowo dodany adres IP, a w „Port to be associated” powinien zostać automatycznie wybrany interfejs sieciowy naszej instancji. Klikamy „Assiocate”.

Po odświeżeniu listy instancji zobaczymy, że adres IP został przypisany. Sprawdzamy poleceniem „ping”:

[root@localhost ~(keystone_admin)]# ping 172.24.4.9
PING 172.24.4.9 (172.24.4.9) 56(84) bytes of data.
64 bytes from 172.24.4.9: icmp_seq=1 ttl=63 time=0.348 ms
64 bytes from 172.24.4.9: icmp_seq=2 ttl=63 time=0.299 ms
64 bytes from 172.24.4.9: icmp_seq=3 ttl=63 time=0.269 ms

Oraz polecniem „nmap” czy port 22 jest odblokowany:

[root@localhost ~(keystone_admin)]# nmap 172.24.4.9

Starting Nmap 6.40 ( http://nmap.org ) at 2018-04-01 21:47 CEST
Nmap scan report for 172.24.4.9
Host is up (0.00041s latency).
Not shown: 999 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh
MAC Address: FA:16:3E:E9:B3:01 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 4.71 seconds

Teraz możemy połączyć się z instancją przy pomocy SSH:

[root@localhost ~(keystone_admin)]# ssh -i ~/.ssh/prod.key debian@172.24.4.9
The authenticity of host '172.24.4.9 (172.24.4.9)' can't be established.
ECDSA key fingerprint is SHA256:TubIgAQfXsIEN8xEtENFFl7MRlyc5vLeS36G++h/jxc.
ECDSA key fingerprint is MD5:47:2d:38:ee:b5:c0:11:99:08:83:14:7f:eb:b2:da:38.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.24.4.9' (ECDSA) to the list of known hosts.
Linux prod 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Apr  1 20:03:33 2018 from 172.24.4.1
debian@prod:~$

Domyślnie moja instancja nie posiadała skonfigurowanych adresów DNS w pliku /etc/resolv.conf. Po dodaniu serwerów DNS:

debian@prod:~$ ping google.pl
PING google.pl (216.58.215.67) 56(84) bytes of data.
64 bytes from waw02s16-in-f3.1e100.net (216.58.215.67): icmp_seq=1 ttl=52 time=18.9 ms
64 bytes from waw02s16-in-f3.1e100.net (216.58.215.67): icmp_seq=2 ttl=52 time=19.8 ms
64 bytes from waw02s16-in-f3.1e100.net (216.58.215.67): icmp_seq=3 ttl=52 time=18.1 ms

Niestety ta operacja nie jest trwała i DNS-y są kasowane po każdym restarcie instancji, nie wiem jeszcze w jaki sposób zachować konfigurację DNS-ów lub gdzie w OpenStacku należy je skonfigurować.

Ten wpis został opublikowany w kategorii CentOS, OpenStack. Dodaj zakładkę do bezpośredniego odnośnika.