Jak zmniejszyłem obraz Docker z 1.2GB do 180MB bez kodu

Pierwszy krok: usunięcie zbędnych narzędzi

Pierwsza i najbardziej efektywna zmiana dotyczyła usunięcia narzędzi do budowy aplikacji z finalnego obrazu. Początkowy Dockerfile zawierał cały zestaw narzędzi deweloperskich, takich jak kompilatory czy nagłówki, które nie były potrzebne w środowisku produkcyjnym. Zmiana ta pozwoliła na zaoszczędzenie około 500MB, co znacząco wpłynęło na szybkość ściągania obrazu i czas potrzebny na wdrożenie.

Drugi krok: mniejsza baza

Zastosowanie obrazu node:20-slim zamiast pełnego node:20 również przyniosło korzyści. Oprócz tego, że mniejsza baza zmniejsza rozmiar obrazu, ogranicza także powierzchnię ataku, co jest istotne z punktu widzenia bezpieczeństwa. Dla aplikacji napisanych w językach takich jak Go czy Rust, można pójść jeszcze dalej i użyć obrazów distroless, co eliminuje wszelkie zbędne elementy systemu operacyjnego, jednak wiąże się to z pewnymi ograniczeniami w zakresie debugowania.

Trzeci krok: efektywne zarządzanie warstwami

Docker zarządza warstwami w sposób, który może prowadzić do nieefektywności. Gdy zmiany są wprowadzane w kodzie, a polecenie COPY . . jest wywoływane przed instalacją zależności, cały proces instalacji jest powtarzany. Przemodelowanie Dockerfile tak, aby najpierw kopiować plik lock, a następnie instalować zależności, a dopiero później dodawać resztę kodu, znacznie przyspiesza proces budowy, skracając go z czterech minut do zaledwie dwudziestu sekund.

Co to znaczy dla Ciebie

Optymalizacja obrazów Docker nie tylko przyspiesza procesy budowy i wdrażania, ale także ma bezpośredni wpływ na koszty operacyjne, zwłaszcza w dużych organizacjach. Mniejsze obrazy oznaczają szybsze ściąganie, co przekłada się na mniejsze obciążenie sieci i szybsze dostarczanie oprogramowania. W dobie DevOps i CI/CD, te drobne zmiany mogą znacząco wpłynąć na efektywność zespołów deweloperskich oraz bezpieczeństwo aplikacji.