fbpx
Docker Maestro → Dołącz już dziś! »»

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.

Warstwa writeable

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:

  1. Stan aplikacji nie powinien zostać zapisywany w systemie plików kontenera
  2. Logi kontenera powinny zostać wyniesione do zewnętrznej usługi lub do STDOUT/STDERR

Z reguły są to dwie najczęstsze przyczyn.

.

Damian Naprawa

Praktykujący pasjonat konteneryzacji. Lubi dzielić się wiedzą, prowadząc warsztaty i szkolenia. Chętnie występuje również w roli prelegenta na meetupach i konferencjach. Uczestnik globalnego programu partnerskiego Docker Enablement. Pracuje z Dockerem na co dzień od kilku lat. Odpowiedzialny za tworzenie i utrzymanie systemów działających w oparciu o kontenery. Fan automatyzacji oraz podejścia "As a Code".

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *