Konteneryzacja, o której już trochę pisaliśmy na naszym blogu, to temat bardzo modny i coraz więcej pytań rodzi się wokół kontenerów.

Dziś przeczytacie o tym jakie trzy główne cechy wyróżniają kontenery i o tym czego nie powinniście robić w Dockerze

Zacznijmy od tego co dobre 😉

1. Po pierwsze: kontenery są „niezmienne”/stałe. Wszystko co jest wewnątrz kontenera: system operacyjny, wersje bibliotek, konfiguracja, aplikacje – wszystkie one są opakowane w kontener, przez co możecie zagwarantować, że ten sam kontener na testach i na produkcji będzie zachowywał się identycznie.
2. Po drugie: kontenery są lekkie. Zapotrzebowanie kontenera na pamięć jest bardzo mała. Oczywiście uzależniona od tego co w nim jest, ale generalnie nie potrzebuje on setek GB RAM, tylko rezerwuje tyle ile wymaga jego główny proces.
3. Po trzecie: kontenery są szybkie. Na pewno sami zauważyliście, ze kontenery są tak szybkie jak powołanie nowego procesu w systemie. Nie potrzebujemy minut, jak do startu maszyny wirtualnej, a tylko sekund by nasz kontener zaczął świadczyć usługi.

Użytkownicy bardzo często zapominają o najważniejszej właściwości kontenerów – są one krótkotrwałe. Można powiedzieć „jednorazowe”. Wszystko co w kontenerze miało miejsce, znika wraz z kontenerem. Jest to swego rodzaju uproszczenie, ale jeśli nie zastosujemy pewnych „chwytów”, to dokładnie tak działa konteneryzacja.

Czego zatem nie powinniście robić w kontenerach?

1. Po pierwsze: nie trzymajcie danych w kontenerach. Kontener może zostać zniszczony, przebudowany, aplikacja wewnątrz może być zmieniona, a wszystko to może wpływać na dane, które gromadzilibyście w kontenerze. Wszystkie dane, które przetwarza kontener, (a których potrzebujecie) powinny być wysyłane na zewnątrz kontenera do volumenów. Oczywiście należy pamiętać o tym, by nie podłączyć tego samego volumenu dwóm lub więcej kontenerom (chyba, że wasza aplikacja wspiera takie współdzielone dane).

2. Po drugie: nie dokładajcie kolejnych funkcjonalności. Wielu użytkowników wciąż uważa kontenery za rodzaj „małej wirtualki” i osadza w już działającym kontenerze nowe aplikacje i serwisy. Kontener od początku do końca powinien być spójny. Pamiętajcie, że jest niezmienny i taki podejście nie jest zgodne z najlepszą praktyką, a wy za każdym razem będziecie musieli wgrywać te aplikacje i serwisy od nowa. Twórzcie kontenery, które w pełni odpowiadają waszym potrzebom.

3. Po trzecie: nie twórzcie wielkich obrazów/kontenerów. Im większy obraz kontenera tym trudniej go rozpropagować. Umieszczajcie w kontenerze tylko to czego potrzebujecie. Nie aktualizujcie np.: fedory w kontenerze. Usuńcie z niego wszystko co jest zbędne.

4. Po czwarte: unikajcie obrazów jednowarstwowych. Budując kontener twórzcie np.: warstwę podstawowa jaką jest OS, następnie wykreujcie potrzebnych wam użytkowników, w kolejnej warstwie instalujcie potrzebne aplikacje, następna warstwa to konfiguracja, i tak dalej… Im więcej warstw pośrednich tym łatwiej budować kolejne kontenery w oparciu o waszą poprzednią pracę i tym łatwiej je dystrybuować.

5. Po piąte: nie budujcie obrazu z uruchomionego kontenera. Inaczej mówiąc nie używajcie komendy docker commit by zapisać zmiany w obrazie. Wszystko co tam zrobiliście nie będzie zautomatyzowane i przy kolejnym tworzeniu obrazu, będziecie musieli wszystko powtarzać ręcznie. Wszystko co ma się stać z obrazem i tym co ma się w nim znajdować powinno być opisane w Dockerfile.

6. Po szóste: nie używajcie jedynie tagu „latest”. Ten tag to jak snapshot dla użytkowników Maven’a 🙂 Tagi to zachęta do tego byście sami opisywali swoje obrazy. Dzięki temu tworząc jakiś obraz przy pomocy Dockerfile użyjecie swojego tagu, a nie tagu latest, który może okazać się już na tyle nowy, że nie pasuje do waszego opisu i nie da się zbudować obrazu w oparciu o ten tag (latest).

7. Po siódme: nie uruchamiajcie więcej niż jeden proces w kontenerze. Kontenery właśnie do tego zostały stworzone. Pojedynczy kontener oznacza pojedynczego Apache’a, serwer MySQL czy JBossa. Jeśli uruchomicie wszystkie powyższe procesy w jednym kontenerze będą działały, ale … będziecie mieć duży problem
   z zarządzaniem tymi procesami, z otrzymaniem logów czy danych z bazy danych. Kontener będzie duży i słabo zarządzalny, przez co jest niezgodny z punktem 3 – nie budujcie wielkich obrazów.

8. Po ósme: nie trzymajcie danych do logowania w kontenerze. Używajcie do tego celu zmiennych środowiskowych, które będą dostarczały potrzebne informacje spoza kontenera.

9. Po dziewiąte: nie uruchamiajcie procesów w kontenerze jako root. Docker domyślnie tak uruchamia swoje procesy, ale poczytajcie więcej tutaj: http://www.projectatomic.io/docs/docker-image-author-guidance/ (na końcu strony)

10. Po dziesiąte: nie ufajcie adresom IP. Każdy kontener ma swój własny adres IP. Może on zostać zmieniony przy każdym uruchomieniu kontenera. Jeśli wasze kontenery muszą się ze sobą łączyć użyjcie zmiennych środowiskowych by przekazać hostname z jednego kontenera do innego. Jeśli używacie np.: Kubernetes zastosujcie serwisy.

Mam nadzieję, że te kilka rad pomoże wam lepiej zarządzać waszymi kontenerami oraz poprawi wydajność tworzenia nowych obrazów jak i prace już utworzonych.