Krzysztof Olszewski
Dyrektor Technologii i Architektury Oprogramowania
Historia, którą poniżej krótko przedstawię, zaczęła się w początkach naszego stulecia, gdzieś w kręgu osób zajmujących się rozwojem jądra Linux’a. Jest to historia warta prześledzenia i nie pomylę się wcale jeśli napiszę, że w ostatnich latach zmieniła kilka podstawowych aspektów świata IT.
Rohit Seth (programista w Google), wieczorem 14 września 2006 wysyła do Andrew Morton’a (programista w Open Source Development Labs, potem Google) wiadomość, która zaczyna się tak:
„… Sprzęt komputerowy staje się coraz bardziej wydajny. Daje to możliwość uruchamiania różnych obciążeń na tej samej platformie w celu lepszego wykorzystania zasobów sprzętowych. (…) Używamy terminu kontener, aby wskazać strukturę, względem której śledzimy i rozliczamy wykorzystanie zasobów systemowych takich jak pamięć, zadania itp. dla danego obciążenia. Kontenery pozwolą administratorom systemu na dostosowanie
platformy bazowej dla różnych aplikacji w oparciu o ich wydajności i potrzeb wykorzystania zasobów sprzętowych. Kontenery zawierają wystarczającą infrastrukturę, aby umożliwić optymalne wykorzystanie zasobów nie obciążając reszty jądra. Administrator systemu powinien być w stanie tworzyć, zarządzać i zwalniać kontenery w prosty sposób. …”
Wiadomość ta, to jednocześnie „łata” (patch) na jądro zmieniająca 20 plików źródłowych, łącznie ok 1800 linii, która wprowadza do jądra Linux’a pojęcie „containers”, zamienione potem na „control groups”, znane pod skrótową nazwą
cgroups
Mechanizm ten (autorzy Paul Menage i Rohit Seth) stał się początkiem zmiany myślenia o uruchamianiu procesów wewnątrz systemu operacyjnego. Dzięki niemu, działająca maszyna z systemem operacyjnym może stać się gospodarzem wielu oddzielonych od siebie grup procesów, nad którymi administrator posiada pełną kontrolę. To jakby wiele OS’ów na jednej maszynie, jednak nie na sposób znany z wirtualizacji (ciężki, powolny, zasobożerny), tylko oparty na jądrze systemu, lekki, prosty, przeźroczysty. Takie były początki, dziś projekty w rodzaju LXC, Docker czy Kubernetes używają idei, jak i samego cgruops’ea, jako jednego z własnych fundamentów. Efektem tej historii, silnie namacalnym w naszym informatycznym świecie, jest
kontener
Aktualnie nie instalujemy, tylko pobieramy obraz kontenera , nie uruchamiamy aplikacji tylko startujemy kontener z obrazu, nie konfigurujemy zależności, bo jest to już gotowe w obrazie. Dystrybucja oprogramowania, jego proces dostarczania, konfigurowania, uruchamiania, nadzorowania, monitorowania i wiele innych złożonych aspektów została zaadresowana przez mechanizmy konteneryzacji.
Przykład. Aby mieć dostęp do serwera np. Postgres’a w wersji np. 9.5.10 kiedyś mieliśmy kilka możliwości. Pierwszą, bardziej formalną, to prośba do administratora w naszej organizacji aby stworzył nam wirtualną maszynę, zainstalował tam odpowiedniego Linuxa oraz odpowiednią wersję Postgres’a, oczywiście trzeba było dobrać taką wersję dystrybucji aby w jej repozytorium znajdowały się odpowiednie paczki Postgres’a., to jasne. Trwało to przy dużym szczęściu kilka godzin. Druga możliwość to instalacja potrzebnej wersji Postgres’a na własnym laptopie … to wersja dla tych bardziej odważnych. Trzeba zająć się wieloma problemami, a czy na pewno moja dystrybucja obsługuje taką wersję Postgres’a? Skoro mam już zainstalowaną inną wersję to czy one się nie „pogryzą”, konflikty wersji pakietów, portów? Jak to potem odinstalować? Jak mieć kilka znacząco różnych wersji Postgres’a zainstalowanych i działających jednocześnie?
Przy użyciu Dockera, dowolną wersję Postgres’a możemy mieć na własnym laptopie po kilku sekundach, wydając jedno polecenie (dla wersji 9.5.10):
$ docker run postgres:9.5.10
To wszystko. Bez angażowania admina, bez zaśmiecania systemu, bez instalowania i konfigurowania czegokolwiek. Świat stał się prostszy.
Oczywiście Postgres jest tu tylko przykładem. W publicznych repozytoriach (np. https://hub.docker.com/) dostępne są obrazy dla kontenerów zawierające w zasadzie większość nowoczesnego oprogramowania, a dostępne narzędzia pozwalają tworzyć w prosty sposób nie tylko pojedyncze usługi, ale także ich współdziałające wysoko funkcjonalne grupy (np. Docker Compose, Kubernetes). Podsumowując, bez przesady można określić to co się stało/dzieje mianem rewolucji. Czy Paul i Rohit mieli tego świadomość pisząc swoje 1800 linii? Domyślam się, że nie :). Na koniec zachęcam do własnych eksperymentów z kontenerami, dobrze jest rozpocząć od Dockera, jest łatwy w użyciu, działa od razu i ma duże wsparcie w sieci.
