#docker

Docker to narzędzie, które pakuje program wraz z jego bibliotekami i ustawieniami w jedną paczkę, a potem uruchamia ją na dowolnym serwerze. Nazwa nie jest przypadkowa i metafora jest tu wyjątkowo trafna. Kontener morski ma ustalone wymiary i uchwyty, więc dźwig w każdym porcie podnosi go tak samo, nie interesując się zawartością. Docker robi to samo z programem: standaryzuje opakowanie, żeby serwer nie musiał wiedzieć, co jest w środku.

Obraz, warstwy, kontener

Obraz to gotowa paczka, przepis i zawartość w jednym: system plików z zainstalowanym programem, jego bibliotekami i domyślną konfiguracją. Obraz jest niezmienny, więc ten sam obraz uruchomiony dziś i za rok da to samo.

Zbudowany jest z warstw dokładanych po kolei według przepisu: najpierw system bazowy, potem zainstalowane biblioteki, na końcu sama aplikacja. Te warstwy bywają wspólne dla wielu obrazów i zostają zapamiętane przy budowaniu, dlatego druga budowa tego samego obrazu trwa sekundy, a nie minuty, i dlatego dziesięć obrazów opartych o ten sam system zajmuje znacznie mniej miejsca niż dziesięć osobnych instalacji.

Kontener to uruchomiony obraz. Na czas pracy dostaje własną warstwę zapisywalną, i to właśnie w niej zaczyna się najczęstsze nieporozumienie.

Kontener a maszyna wirtualna

Maszyna wirtualna niesie własny system operacyjny wraz z jądrem, więc uruchamia się jak prawdziwy komputer: kilkadziesiąt sekund, kilka gigabajtów miejsca, pełna izolacja.

Kontener dzieli jądro z serwerem, na którym stoi, a pakuje wyłącznie to, co leży nad jądrem. Stąd bierze się różnica w czasie startu i w zajętości, mierzona rzędami wielkości, i stąd bierze się granica: kontenery na jednym serwerze są oddzielone od siebie, ale nie tak szczelnie jak osobne maszyny, i tą drogą nie postawi się systemu z innej rodziny niż ta, którą ma gospodarz.

Dane, które znikają

To jest ten fragment, dla którego warto przeczytać cały tekst. Dokumentacja Dockera stwierdza wprost, że kiedy kontener zostaje zniszczony, jego warstwa zapisywalna ginie razem z nim, a zawartość wolumenu istnieje niezależnie od cyklu życia kontenera.

Konsekwencja jest bezpośrednia. Aktualizacja aplikacji w tym modelu nie polega na poprawieniu czegoś w środku działającego kontenera, tylko na wymianie go na kontener z nowszego obrazu. Wszystko, co program zapisał w swojej warstwie zapisywalnej, przestaje wtedy istnieć.

Dlatego dane trwałe, czyli bazy, załączniki i pliki użytkowników, muszą leżeć w wolumenie, czyli w miejscu zarządzanym przez Dockera i podpiętym do kontenera z zewnątrz. Wolumeny są też tym, co obejmuje się kopią zapasową. Kopiowanie samego obrazu nie zabezpiecza niczego, bo obraz da się w każdej chwili zbudować od nowa, a dane nie.

Wdrożenia, w których pominięto ten podział, tracą dane przy pierwszej aktualizacji wykonanej dokładnie według instrukcji producenta aplikacji.

Gdzie kontener pojawia się w małej firmie

Częściej, niż się wydaje, i rzadko z powodu mody. Programy udostępniane dziś jako obraz kontenera to między innymi systemy zgłoszeń, wewnętrzne wiki, narzędzia do monitoringu, panele do zarządzania kopiami, systemy magazynowe i sklepy. Instrukcja instalacji sprowadza się wtedy do jednego pliku opisującego, co uruchomić, z jakimi ustawieniami i gdzie podpiąć wolumeny.

Drugim zastosowaniem jest stara aplikacja wymagająca wersji bibliotek, których nikt już nie postawi na aktualnym serwerze. Zamknięcie jej w obrazie zamraża jej otoczenie i pozwala przenieść ją na nowszy sprzęt.

Kiedy kontener nie pomoże

Nie naprawi aplikacji, która jest źle napisana, tylko przeniesie jej problemy w nowe miejsce. Kopii zapasowych ani aktualizacji z niczego nie zdejmuje: obraz zbudowany dwa lata temu zawiera biblioteki sprzed dwóch lat wraz z ich dziurami, a niezmienność obrazu, która jest jego zaletą, tutaj działa przeciw firmie. Nie przyniesie również oszczędności przy jednej aplikacji na jednym serwerze, bo dokłada wtedy warstwę do nauczenia się i utrzymania, nie dając nic w zamian. Zysk pojawia się przy kilku aplikacjach, przy powtarzalnych wdrożeniach i wszędzie tam, gdzie liczy się, żeby środowisko testowe było identyczne z produkcyjnym.