#konteneryzacja

Konteneryzacja to sposób dostarczania oprogramowania, w którym aplikacja jedzie razem ze wszystkim, czego potrzebuje do pracy: bibliotekami, plikami konfiguracyjnymi, właściwymi wersjami narzędzi. Całość zamyka się w obrazie, a obraz uruchamia się na dowolnym serwerze, nie instalując w nim niczego.

Skąd wzięła się nazwa

Porównanie z kontenerem morskim jest tu wyjątkowo dokładne i warto je rozwinąć, bo niesie cały mechanizm.

Zanim wprowadzono kontenery, każdy ładunek pakowano inaczej i każdy port musiał umieć obsłużyć wszystkie rodzaje opakowań. Kontener odwrócił zależność: ładunek pakuje nadawca, w sposób, o którym port nie musi nic wiedzieć, a port obsługuje wyłącznie jednakowe skrzynie o znanych wymiarach.

Tak samo działa kontener z oprogramowaniem. Wcześniej program instalowało się na serwerze, dopasowując serwer do jego wymagań, a dwa programy potrzebujące różnych wersji tej samej biblioteki wchodziły sobie w drogę. Teraz każdy jedzie z własnym wyposażeniem, a serwer musi umieć tylko jedno: uruchamiać kontenery.

Jak powstaje obraz

Obraz nie jest zrzutem dysku, tylko wynikiem przepisu zapisanego w pliku tekstowym. Przepis mówi, od czego zacząć, co doinstalować, co skopiować i co uruchomić przy starcie.

Ma to dwa skutki. Po pierwsze, obraz jest powtarzalny: ten sam przepis daje ten sam wynik, więc różnica między środowiskiem programisty a serwerem produkcyjnym przestaje być tematem. Po drugie, obraz powstaje warstwami odpowiadającymi kolejnym krokom przepisu, a te bywają wspólne dla wielu różnych obrazów. Dziesięć aplikacji zbudowanych na tej samej podstawie nie zajmuje dziesięciu kopii tej podstawy.

Kontener a maszyna wirtualna

Oba rozwiązania oddzielają aplikacje od siebie, tylko na innej głębokości.

Maszyna wirtualna udaje komputer. Ma własny system operacyjny, własne jądro, własny rozruch, więc startuje minutami i zajmuje gigabajty. Kontener nie ma własnego systemu: korzysta z jądra gospodarza, a oddzielenie od sąsiadów zapewniają mu mechanizmy tego jądra. Dlatego startuje w sekundę i waży dziesiątki megabajtów.

Cena tej lekkości jest jedna i konkretna: skoro jądro jest wspólne, w kontenerze nie da się postawić systemu spoza rodziny gospodarza, a oddzielenie jest słabsze niż w maszynie wirtualnej. Do uruchomienia obcego kodu, któremu się nie ufa, maszyna wirtualna jest bezpieczniejszym wyborem.

Co to zmienia przy aktualizacji

Największa zmiana dotyczy sposobu wprowadzania nowych wersji. Nie poprawia się działającej instalacji, tylko uruchamia nowy obraz obok starego i przełącza ruch. Stary zostaje jeszcze przez chwilę, więc wycofanie zmiany polega na przełączeniu ruchu z powrotem, a nie na odtwarzaniu z kopii.

Z tego bierze się reguła, która bywa niewygodna: kontenera się nie naprawia. Zmiana wprowadzona ręcznie w środku działającego kontenera zniknie przy pierwszym jego odtworzeniu, bo odtworzenie oznacza uruchomienie obrazu od nowa. Poprawki wprowadza się w przepisie i buduje nowy obraz.

Na co uważać

Kontener nie ma pamięci i to jest rzecz, na której najczęściej się przewraca. Wszystko zapisane w jego wnętrzu znika razem z nim, więc dane muszą leżeć w wydzielonym miejscu podpiętym z zewnątrz, a kopia zapasowa obejmuje właśnie je, nie obrazy. Zespoły, które pominęły ten podział, tracą bazę danych przy pierwszej podmianie obrazu, wykonanej dokładnie tak, jak opisuje dokumentacja producenta aplikacji.

Druga rzecz to pochodzenie obrazów. Gotowy obraz pobrany z publicznego rejestru jest cudzym oprogramowaniem uruchamianym z pełnym zaufaniem, razem ze wszystkim, co ktoś do niego dołożył. Obrazy bierze się z rejestrów oznaczonych przez producenta i sprawdza, kiedy powstały, bo obraz sprzed dwóch lat zawiera podatności sprzed dwóch lat.

Trzecia to złudzenie, że kontener jest zabezpieczeniem. Aplikacja uruchomiona w kontenerze z uprawnieniami administratora i z dostępem do katalogów gospodarza ma niewiele mniejsze możliwości niż uruchomiona wprost w systemie.

Kiedy konteneryzacja nie jest odpowiedzią

Pojedyncza aplikacja stojąca na jednym serwerze i zmieniana raz na rok nie zwróci nakładu na naukę i utrzymanie tej warstwy. Podobnie wygląda to przy gotowym programie kupionym od dostawcy, który dostarcza go w postaci instalatora i nie wspiera innej: pakowanie go samodzielnie w kontener oznacza wzięcie na siebie odpowiedzialności za jego środowisko. Bazy danych też częściej zostawia się poza kontenerami i nie jest to porażka, tylko uznanie, że trwałość i jednorazowość źle się ze sobą łączą.