Читать книгу Docker w praktyce - Ian Miell - Страница 21
Оглавление2. Zrozumieć Dockera: wewnątrz maszynowni
Niniejszy rozdział dotyczy:
architektury Dockera,
śledzenia na hoście wewnętrznych elementów Dockera,
korzystania z Docker Hub do znajdowania i pobierania obrazów,
konfigurowania własnego rejestru Dockera,
łączenia kontenerów ze sobą.
Poznanie architektury Dockera jest kluczem do jego pełniejszego zrozumienia. W tym rozdziale dokonamy przeglądu głównych komponentów Dockera na maszynie i w sieci, a także zaznajomimy się z kilkoma technikami, które rozwiną to zrozumienie.
W tym procesie poznamy kilka ciekawych sztuczek, które pomogą skuteczniej korzystać z Dockera (i Linuksa). Wiele późniejszych i bardziej zaawansowanych technik zawartych w tej książce będzie opierać się na tym, co znajduje się tutaj, a zatem należy na to zwrócić szczególną uwagę.
Rysunek 2.1 przedstawia architekturę Dockera, która będzie centralnym punktem tego rozdziału. Zaczniemy od ogólnego spojrzenia, a następnie skupimy się na każdej części, stosując techniki zaprojektowane tak, aby wzmocnić nasze zrozumienie poszczególnych elementów.
Docker na naszym hoście jest (w momencie pisania) podzielony na dwie części – demona z RESTful API i klienta, który z nim rozmawia. Rysunek 2.1 przedstawia maszynę hosta z uruchomionym klientem i demonem Dockera.
Rysunek 2.1. Przegląd architektury Dockera
WSKAZÓWKA Interfejs RESTful API wykorzystuje standardowe typy żądań HTTP, takie jak GET, POST, DELETE i inne, aby reprezentować zasoby i działania na nich. W tym przypadku obrazy, kontenery, woluminy i tym podobne są reprezentowanymi zasobami.
Wywołujemy klienta Dockera, aby uzyskać informacje od demona lub przekazać mu instrukcje; demon to serwer, który odbiera żądania i zwraca odpowiedzi do klienta za pomocą protokołu HTTP. On z kolei wykonuje żądania do innych usług w celu wysyłania i pobierania obrazów, również przy użyciu protokołu HTTP. Serwer akceptuje żądania od wiersza poleceń klienta lub kogokolwiek innego upoważnionego do połączenia. Demon jest również odpowiedzialny za dbanie o obrazy i kontenery, podczas gdy klient działa jako pośrednik między nami a RESTful API.
Prywatny rejestr Dockera to usługa, która przechowuje dockerowe obrazy. Można ich zażądać od dowolnego demona Dockera, który ma uprawnienia dostępu. Ten rejestr może być w sieci wewnętrznej i nie jest publicznie dostępny, zatem jest uważany za prywatny.
Nasza maszyna hosta zazwyczaj znajduje się w sieci prywatnej. Aby pobrać obrazy, demon Dockera będzie wykorzystywał internet, jeśli jest to wymagane.
Docker Hub to publiczny rejestr prowadzony przez firmę Docker. W internecie mogą znajdować się inne publiczne rejestry, z którymi może współpracować demon Dockera.
W pierwszym rozdziale powiedzieliśmy, że kontenery można wysyłać do dowolnego miejsca, w którym można uruchomić Dockera – to nie jest do końca prawda. W rzeczywistości kontenery będą działać na komputerze tylko wtedy, gdy może zostać zainstalowany demon.
Kluczową kwestią do zapamiętania z rysunku 2.1 jest to, że po uruchomieniu Dockera na komputerze użytkownik może wchodzić w interakcje z innymi procesami na nim, a nawet z usługami działającymi w sieci lub w internecie.
Teraz, gdy mamy już pojęcie o tym, w jaki sposób jest poukładany Docker, przedstawimy różne techniki odnoszące się do poszczególnych części rysunku.
