Docker, konteneryzacja aplikacji, mikroserwisy to nie jest tylko pozamykanie jakiś małych części aplikacji w oddzielne kontenery i zdeploy-owanie ich na jakaś chmurę w celu jej uruchomienia. Sam docker to dużo bardziej skomplikowane narzędzie niż mogłoby się wydawać. Za jego pomocą możemy tworzyć całe ekosystemy zawierające wirtualne sieci, usługi typu service discovery a nawet (od niedawna) za pomocą orchiestrator-a, skalować naszą aplikację. W dzisiejszym poście chciałbym poświęcić kilka słów wirtualnym sieciom i w kilku słowach słowach opisać ich zarządzanie (przy użyciu API docker-a).
Najpierw szybkie pytanie - czy czytałeś moje wcześniejsze materiały dotyczące Dockera? Nie? No weeeź przeczytaj. Ładnie proszę... Tak serio, jeżeli miałeś już styczność z Dockerem to czytaj ten wpis śmiało. W przypadku twojego pierwszego kontaktu dobrze by było byś zapoznał się najpierw z podstawami:
Do czego to służy?
Docker network jest potężnym narzędziem, którego wielu developerów używa nieświadomie. Wszystko przez takie przyrządy jak docker compose, który ma już w sobie wbudowaną obsługę wirtualnych sieci prywatnych. Dlatego przed przejściem do niego chciałbym opisać w jaki sposób można zarządzać siecią.
Zaczynając, w globalnym obiekcie docker-a mamy cały namespace poleceń służących do tworzenia, edycji, usuwania treści etc. Wszystkie te polecenia znajdują się w namespace "docker network".
Pierwszym poleceniem, które chciałbym wam przedstawić jest "docker network ls". Wypisuje na ekranie terminala wszystkie sieci, które stworzyliśmy jak i wszystkie, które są wbudowane out of the box.
Jak widzicie na załączonym obrazku, out of the box otrzymujemy trzy wbudowane sieci:
- bridge - pomiędzy maszyną a kontenerem znajduje się sieć wirtualna, która pozwala nam na filtrowanie ruchu np. po portach
- host - kontener jest podłączony bezpośrednio do sieci w której znajduje się maszyna na której został uruchomiony
- none - wycinamy całkowicie interfejs sieciowy z naszego kontenera
Defaultowo, jak będziemy tworzyli nową sieć, zostanie ona stworzona na podstawie sieci bridge. Zastanawiając się jaki rodzaj sieci stworzyć pamiętajcie, że im mniejszy dostęp do kontenera z zewnątrz tym jest on bezpieczniejszy. Niestety nie jest rozsądne stworzyć wszystkich kontenerów w typie "none" bo nie będą miały szansy porozumieć się ze sobą :( smutne ale prawdziwe). Polecam korzystać z sieci bridge, która zapewnia że z kontenerem będziemy mogli porozumieć się tylko po jasno sprecyzowanych portach, co w przeciwieństwie do sieci "host" jest nieco wolniejsze, acz bezpieczniejsze.
Tworzenie sieci
Skoro już opisałem trzy podstawowe sieci, które już są dostępne od samej instalacji docker-a, możemy przejść do zdefiniowania własnej. Do tego zadania wystarczy jedna komenda "docker network create {nazwa sieci}". Po jek wykonaniu otrzymamy w terminalu identyfikator nowo powstałej sieci.
Teraz, wykonując komendę "docker network ls", otrzymamy listę czterech dostępnych sieci
Nowa sieć powstała na podstawie sieci "bridge". Uruchamiając kontener wewnątrz to konieczne będzie jasne definiowanie portów.
Uruchomienie kontenera w sieci
Aby uruchomić kontener, w sieci stworzonej przez nas, do komendy "docker container run" dodajemy atrybut --network z nazwą naszej sieci. Przykład:
$ docker container run --name my_nginx --network my_virtual_network nginx
Oczywiście trzeba pamiętać, że w przypadku komunikacji z nowo uruchomionym kontenerem konieczne jest wykorzystanie atrybut -p aby otworzyć porty.
Po uruchomieniu kontenera możemy wykorzystać komendę "docker netowrk inspect my_virtual_netowrk" aby zobaczyć wszystkie informację o sieci. Jedną ciekawszych rzeczy, jakie możemy wyczytać z json-a, którego otrzymaliśmy w odpowiedzi, jest pełna lista kontenerów uruchomionych w sieci. Pozwala nam to wyczytać, w jakiej podsieci IP zostały one uruchomione, jakiego typu jest ta sieć etc.
System DNS
Dzięki temu, że w sieci są przetrzymywane informacje o wszystkich uruchomionych kontenerach, otrzymujemy coś w rodzaju systemu DNS. Co to dla nas oznacza? A to, że zamiast identyfikować kontenery po ich adresach IP (na przykład adres 172.18.100.100 wysyła żądania na adres 172.18.100.101) mamy możliwość zidentyfikować je za pomocą naszej, zdefiniowanej nazwy. Cały proces komunikacji się upraszcza i nie musimy polegać na czymś tak zmiennym jak lokalne IP.
Cały ten system stoi u podstaw jeszcze bardziej rozbudowanego narzędzia, którym jest docker-compose. Chcąc dowiedzieć się więcej na jego temat odwiedzajcie mój blog w przyszłości. Nie omieszkam poświęcić o nim kilku słów w nadchodzących postach :)
Podsumowanie
Tak to nastała ta część post-a, której już 70% ludzi nie czyta :) Dzisiaj przedstawiłem wam podstawy konceptu wirtualnych sieci w dockerze. Jak zwykle mam nadzieje że miło wam się to czytało i że wiedza zawarta w tym poście się wam przyda.
A Teraz pozostało mi życzyć wam miłego dnia.
I do następnego
Cześć