Docker - początek

Powyższy proces może zająć dużo czasu, co nie jest ani produktywne ani opłacalne. Twórcy oprogramowania chcąc skrócić czas potrzebny na wdrożenie np. w kroku w jakim zlecają do utrzymania doinstalowywanie kolejnych komponentów mogą pokusić się o zaszycie ich już wewnątrz samej aplikacji we własnym zakresie, by ominąć ten krok. 

Tutaj swoje zastosowanie i siłę pokazują takie narzędzia jak heroku, które często porównywane jest do standardowych metod wdrożeniowych jako bardziej efektywne.

Docker nie jest heroku ale umożliwia osiągnięcie podobnych rezultatów. Do tego stosuje troszkę inne bardziej otwarte podejście oferując swoje rozwiązania w raz z wszystkimi potrzebnymi elementami umożliwiając jednocześnie ich wymianę na inne. Punktem wyjścia jest wykorzystanie repozytorium obrazów separując tym samym odpowiedzialność za kompilacje od wdrożenia i utrzymania. 

Powyższe daje już wyobrażenie o korzyściach z wykorzystania tego rozwiązania. Do tego zaobserwować można też duże wsparcie dla tego projektu przez dużych graczy rynku IT. Projekt z biegiem czasu jest stale rozwijany i ulepszany. Od czerwca 2015 r. można również mówić o standaryzacji tego typu rozwiązań za sprawą The Open Container Initiative. 

Docker oferuje duże możliwości i ma zastosowanie w skomplikowanych rozwiązaniach. Sam w sobie nie jest już taki straszny i stanowi klasyczny model architektury klient - serwer. Posiada pojedynczy moduł wykonywalny obsługujący oba komponenty różnice stanowi parametr z jakim zostanie uruchomiony. 

Docker Compose

Narzędzie do uruchamiania aplikacji wielo-kontenerowych. Umożliwia utworzenie pliku kompozycji (compose file) konfigurując tym samym wszystkie potrzebne serwisy jakie mają zostać uruchomione przy użyciu jednego polecenia. Dokumentacja.

Docker Machine 

Narzędzie umożliwiające zainstalowanie silnika Docker na lokalnym hoście Windows i przy jego pomocy wydawanie poleceń i obsługę istniejących w infrastrukturze hostów z zainstalowanym Dockerem. Używając poleceń docker-machine można uruchomić, sprawdzić, zatrzymać i zrestartować hosty zarządzane, podnieść wersję serwera i klienta dockera oraz wykonać zmiany konfiguracji.  Dokumentacja. 

Docker Swarm.

Rozwiązanie stanowiące natywny klaster dla Dockera. Umożliwia wykorzystanie puli hostów z Dockera z jednego macierzystego hosta. Ponieważ Swarm komunikuje się ze światem tym samym API co Docker możliwe jest wykorzystanie każdego narzędzia które już komunikuje się z Dockerem do korzystania z możliwości Swarm. Dokumentacja.

Klient Dockera

Najważniejszy interfejs jaki spotkamy w Docker jest klientem tekstowym napisanym w języku GO. Zadania jakie możemy wykonać za jego pomocą to : 

• Utworzenie obrazów kontenera
• Pobranie obrazu kontenera z istniejącego rejestru obrazów 
• Umieszczenie utworzonych obrazów w rejestrze obrazów
• Uruchomienie kontenera na serwerze Docekra 
• Pobranie logów zdalnego serwera 
• Uruchomienie wiersza poleceń wewnątrz kontenera na zdalnym serwerze

Poza komunikacją z klienta tekstowego możliwe jest również wykorzystanie interfejsu API. 

Dokumentacja API - https://docs.docker.com/engine/api/

Sieć

Pomimo, że procesy kontenerowe umieszczone są w samym systemie hosta ich zachowanie jest nieco odmienne niż standardowych procesów w warstwie sieci. Jako odniesienie można tu zastosować porównanie kontenerów jak pojedynczych komputerów w prywatnej sieci lokalnej. Serwer Dokera działa jako wirtualny most sieciowy, kontenery natomiast stanowią klientów połączonych za jego pomocą. Można powiedzieć, że jest to taka małą wewnętrzna sieć z podłączonymi hostami.

Każdy kontener posiada swój własny interfejs sieciowy, który jest połączony do mostka sieciowego Dockera, a następnie porty serwera łączone są z portami kontenera, co umożliwia widoczność kontenera na zewnątrz. Ruch kierowany do kontenera przechodzi przez mechanizm proxy istniejący w serwerze Dockera. Do działania wykorzystywany jest wolny blok podsieci prywatnej przypisywany do własnej sieci wirtualnej Dockera połaczony mostem z siecią lokalną używając do tego celu interfejsu docker0. Takie rozwiązanie gwarantuje również komunikacje pomiędzy kontenerami. Wyjście na zewnątrz realizowane jest przez wirtualny interfejs wirtualnego mostu docker0. 

Szczegółowa dokumentacja sieci w Docker jest dostępna pod adresem:
https://docs.docker.com/engine/userguide/networking/

Gdzie zastosować rozwiązanie Docker ?

Technologia kontenerowa oferowana przez Dockera sprawdzi się zapewne w wielu miejscach. Są jednak takie miejsca gdzie pasuje bardziej, a do innych mniej. Warto zrozumieć w jaki sposób w pełni wykorzystać dane narzędzie i zdawać sobie sprawę do czego nie będzie się nadawało.

Zastosowana architektura tego rozwiązania znakomicie sprawdzi się dla aplikacji bezstanowych lub takich gdzie dane na temat stanu trzymane są w wewnętrznych magazynach danych np.: pamięć podręczna lub baza danych. W takich przypadkach Docker wymusza niejako używanie tak zwanych dobrych praktyk programistycznych. Różnica pomiędzy aplikacjami stanowymi i bezstanowymi polega na tym, iż te stanowe przechowują istotne dane w pamięci , bazie danych. plikach płaskich i narażone są na ich utratę w momencie restartu usługi jeżeli wcześniej nie zostały trwale zapisane. Istota bezstanowych aplikacji jest taka, iż stworzone są po to by szybko reagować na pojedyncze zapytania do klientów bez przechowywania jakichkolwiek danych.

Ogólne wyobrażenie o Docker. 

Wykorzystując analogię do innych rozwiązań w przypadku Dockera należy myśleć w taki sposób jak o odrębnej przestrzeni do przechowywania pojedynczych procesów systemu Unix. Proces taki potrafi również wywołać inne procesy, a całość zamknięta jest jak gdyby w jednym odrębnym opakowaniu. Można uznać, że przypomina to maszyny wirtualne jednak kontenery mogą zostać zdecydowanie łatwiej utworzone i usunięte. Kontener w porównaniu do maszyn wirtualnych potrzebuje bardzo mało zasobów. Istnieją przykłady w jakich kontener zbudowany z istniejącego obrazu na dysku zajmuje jedynie 12 kilobajtów. Dzieje się tak dlatego ponieważ kontener w tym wypadku zawiera jedynie wskaźnik do warstwy systemu plików i metadanych  zawierających informacje o konfiguracji. Powyższe sprowadza się do tego, że prawdopodobnie nie użyto by nowej maszyny wirtualnej jedynie po to by wykonać pojedyncze zapytanie sql lub curl ale kontener nadaje się już do tego doskonale.

Choć ogólnie uważa się, że kontenery są niezależnymi odizolowanymi od siebie bytami to tak naprawdę jest to bardziej ograniczone niż można by się spodziewać. Istnieje możliwość ograniczania ich zasobów to przy zastosowaniu konfiguracji podstawowej kontenery zachowają się tak samo jak każdy proces środowiska Unix współdzieląc i rywalizując o dostępne zasoby hosta na jakim się znajdują. Dobrze jest wcześniej przewidzieć czy wiele kontenerów będzie dzieliło jedną warstwę systemu plików. Chodzi o fakt, że jeżeli dojdzie do aktualizacji obrazu jaki jest współdzielony trzeba będzie wówczas odtworzyć wiele kontenerów.

Procesy działające w kontenerach istnieją również na samym serwerze Dockera ponieważ wykorzystują to samo jądro Linuxa. Można je również zobaczyć na systemie operacyjnym hosta na jakim działa Docker używając polecenia - ps. Jest to widoczna różnica pomiędzy rozwiązaniem Docker a znanym z wirtualizacji hipernadzorcy  gdzie izolacja procesów wynika z uruchomienia ich w zupełnie odrębnym systemie operacyjnym maszyny wirtualnej.

Bezpieczeństwo
  

Domyślna konfiguracja kontenerów jest tak ustawiona, że wiele z nich do uruchamiania procesów używa UID 0, co nie budzi zastrzeżeń szczególnie, że o kontenerze mówimy jako o zamkniętym osobnym tworze. Ponieważ do działania wykorzystywane jest to samo jądra Linuxa najprostsze nawet błędy konfiguracyjne mogą umożliwić użytkownikowi  root kontenera do uzyskania dostępu do zasobów systemowych i procesów hosta na jakim kontener się znajduje.

Wcześniej pisałem, że docker najlepiej działa z aplikacjami bezstanowymi. Co jednak jeżeli taki stan musi być zapisany i przekazany ? Można w tym celu wykorzystać zmienne środowiskowe przechowywane w metadanych opisujących konfiguracje kontenera. Daje to możliwość przekazania do kontenera tej samej konfiguracji przy każdym jego restarcie.