Prędzej czy później możemy natknąć się na sytuację, gdzie kontener na produkcji po jakimś czasie puchnie. Inaczej mówiąc, z czasem jego rozmiar na dysku jest coraz to większy i większy. Przyjrzymy się dzisiaj temu problemowi oraz pokażę potencjalne miejsca, które mogą być tego powodem.
Problem puchnięcia kontenera (jak i sposób jak tego uniknąć) jest na tyle uniwersalny, że przedstawione w tym artykule praktyki śmiało możesz od razu wdrożyć u siebie.
Gdzie kontener domyślnie zapisuje dane?
Żeby móc zrozumieć gdzie tkwi problem, zaczniemy od podstaw – czyli od tego gdzie domyślnie kontener zapisuje swoje dane.
Po uruchomieniu dowolnego kontenera tworzy nam się minimum jeden proces.
Każdy taki proces ma prawo do modyfikacji systemu plików kontenera. Gdzie zatem zapisywane są te zmiany?
Domyślnym katalogiem, gdzie Docker przechowuje warstwy obrazów jest /var/lib/docker/overlay2. Więcej na ten temat możesz znaleźć TUTAJ.
**Mowa tutaj o kontenerach odpalonych za pomocą Dockera
Oprócz warstw obrazu, na podstawie którego tworzony jest kontener, dodatkowo tworzy się warstwa – writeable layer. Służy ona do przechowywania zmian zachodzących w kontenerze.
Warto jeszcze wspomnieć, że warstwa writeable istnieje do momentu usunięcia kontenera. Chcąc zapisać naniesione w kontenerze zmiany, możemy to zrobić za pomocą polecenia docker container commit <nazwa_lub_id_kontenera> <nowy_obraz:tag>.
To polecenie jest odpowiedzialne za utworzenie nowego obrazu na podstawie kontenera, uwzględniając wszystkie zmiany, jakie zaszły w warstwie writeable.
Co może powodować, że kontener puchnie?
Wiemy już, gdzie kontener zapisuje dane. Teraz czas na przedstawienie dwóch najczęstszych błędów w podejściu do konteneryzacji.
Jak to kiedyś ktoś fajnie powiedział:
„Żyj krótko, umieraj młodo”
Po pierwsze – kontenery zostały stworzone dla aplikacji BEZSTANOWYCH.
Oznacza to, że stan kontenera powinien być wyniesiony na zewnątrz. Jednym z powodów przyrostu miejsca na dysku może być przechowywanie stanu aplikacji w systemie plików kontenera.
Sprawdź, czy i jakie pliki są tworzone podczas działania kontenera
Po drugie – zapisywanie logów aplikacji do pliku
To podejście doskonale znamy z ery przed Dockerem i konteneryzacją. Powiedziałbym, że nadal coś takiego ma miejsce dla aplikacji hostowanych na VM-kach (szczególnie windowsowych).
Sprawdź, gdzie przechowane są logi aplikacji lub usługi uruchomionej w kontenerze
Mam tutaj na myśli logowania do pliku tekstowego (.log). Zaraz po przechowywaniu stanu, jest to najczęstszy powód puchnięcia kontenera.
Jak sprawdzić jakie zmiany zaszły w kontenerze?
Wiemy już, co może być przyczyną puchnięcia kontenera. Jak zatem upewnić się i dokładnie zidentyfikować problem?
Rozważmy to na poniższym przykładzie:
docker container run -it --name mydebian debian:stretch bash echo 'Tekst, tekst, tekst' > tekst.txt exit
Co się stało powyżej? Odpalony został kontener o nazwie mydebian, wewnątrz którego stworzony został plik text.txt. Polecenie exit spowodowało zatrzymanie kontenera.
Sprawdzenie co zostało zmienione za pomocą poniższej instrukcji:
docker container diff mydebian A /tekst.txt C /root A /root/.bash_history
Instrukcja docker container diff zwraca to, co zostało zmienione w systemie plików kontenera względem obrazu. Inaczej mówiąc, zwraca to, co zostało zapisane w warstwie writeable.
Docker Maestro – najbardziej obszerny kurs online Dockera po polsku
Poruszana tematyka:
- Tworzenie własnych obrazów
- narzędzia wspomagające pracę z Dockerem
- bezpieczeństwo,
- orkiestracja
- zagadnienia DevOps
- …i wiele, wiele więcej
Sprawdź na http://dockermaestro.pl
Jak sprawdzić ile miejsca na dysku zajmują zmiany?
Pomocne tutaj będzie kolejne polecenie (które częściowo już napewno znasz). Tym poleceniem jest docker container ls (lub docker ps) rozbudowane o dodatkowy parametr -s.
Sprawdźmy całość na poniższym przykładzie:
docker container ls -as CONTAINER ID IMAGE STATUS NAMES SIZE 5ce9595d1e76 debian:stretch Exited (0) 10 minutes ago mydebian 70B (virtual 101MB)
Zwróć uwagę na ostatnią kolumne SIZE.
Wartość przed nawiasem, to ilość miejsca na dysku po zmianach zachodzących w kontenerze.
Jeżeli chcemy wyświetlić, ile miejsca zajmują również zatrzymane kontenery, do docker container ls dorzucamy parametr -as.
Rozwiązanie problemu
Mierząc się z problemem puchnięcia danych, zacząłbym od dwóch czynności:
- Stan aplikacji nie powinien zostać zapisywany w systemie plików kontenera
- Logi kontenera powinny zostać wyniesione do zewnętrznej usługi lub do STDOUT/STDERR
Z reguły są to dwie najczęstsze przyczyn.
