Tworzenie lekkich i optymalnych obrazów dockerowych

Tworzenie obrazów dockerowych

Tworzenie obrazów dockerowych to temat rzeka. Dla każdej technologii obraz będzie wyglądał nieco inaczej. Są jednak pewne “wspólne” dobre praktyki, które możemy stosować niezależnie od technologii, w której stworzona została aplikacja.

Przypomnijmy, że to obraz to działająca instancja kontenera. Jeżeli chcesz, by Twoje kontenery po uruchomieniu były lekkie i bezpieczne — koniecznie stosuj dobre praktyki podczas tworzenia obrazów

Zacznij od ustalenia konkretnej wersji obrazu bazowego

Może to się wydawać oczywiste, ale wiele osób zapomina o ustaleniu konkretnej wersji obrazu bazowego. Dlaczego jest to takie ważne?

Ten kod:

FROM node

WORKDIR /app

COPY package.json .
RUN npm install
COPY . .

CMD ["node", "server.js"]

Zastąp tym:

FROM node:14.4

WORKDIR /app

COPY package.json .
RUN npm install
COPY . .

CMD ["node", "server.js"]

Jeżeli nie podasz konkretnej wersji, to domyślną wersją obrazu będzie latest, która każdej chwili może zostać zaktualizowana na Docker Hubie.

W chwili przeprowadzania testów wszystko działało, a nagle po upływie kilku miesięcy…

NIE DZIAŁA.

Zastanawiasz się, co może być przyczyną. Spędzasz masę czasu na znalezienie problemu. Okazuje się, że obraz z tagiem :latest został w tym czasie kilkukrotnie zaktualizowany (w obrazie wprowadzono zmiany), co spowodowało, że Twoja aplikacja zachowuje się teraz inaczej.

Poszukaj minimalnego obrazu bazowego

Ten kod:

FROM node:14.4.0

WORKDIR /app

COPY package.json .
RUN npm install
COPY . .

CMD ["node", "server.js"]

Zastąp tym:

FROM node:14.4.0-buster-slim

WORKDIR /app

COPY package.json .
RUN npm install
COPY . .

CMD ["node", "server.js"]

Dzięki temu otrzymujemy oszczędność około ~250MB na rozmiarze obrazu, co oznacza szybszy czas budowania, pobierania i pushowania do Docker Registry.

Korzystaj z pliku .dockerignore

.git
node_modules
build

Na pewno kojarzysz i wiesz do czego służy plik .gitignore w przypadku systemu kontroli wersji Git. Aby wykluczyć niepotrzebne pliki z procesu budowania obrazu (bez konieczności zmian twojego katalogu), użyj pliku .dockeringore. Docker tworząc to rozwiązanie, wzorował się na .gitignore (które to podejście zapewne doskonale znasz). Przykładem mogą być zbudowane paczki lub pliki wykonywalne (.dll, .exe, katalog node_modules itp), utworzone lokalnie podczas developmentu aplikacji.

Przygotowując kontener, nie chcemy ich kopiować. Chcemy, by zostały one zbudowane na nowo wewnątrz kontenera.

Już to wiem, ale jak ogarnąć resztę?

Są dwie drogi.

Pierwsza z nich to dołączenie do programu Docker Maestro, czyli najbardziej obszernego kursu online z Docker po polsku. Budowanie własnych obrazów to tylko mały fragment tego co znajduje się w całym kursie. Łącznie znajdziesz tam:

12 modułów
89 lekcji
Wiedza w pigułce
Praktyka & teoria


Od podstaw aż po zaawansowane tematy.

Jeżeli jednak z jakichś powodów nie możesz dołączyć do Docker Maestro, to zachęcam do obejrzenia poniższego wideo, gdzie na przykładzie dwóch aplikacji — ReactJS oraz NodeJS pokazuję jak optymalizować swoje obrazy.

Jest to tylko przykład i nawet jeśli na co dzień używasz innych technologii, poprzez analogię możesz przenieść te dobre praktyki do siebie.

1. Co robić by po zbudowaniu nie ważyły setek megabajtów?
2. Jak zadbać o ich bezpieczeńśtwo?
3. A co z obrazami bazującymi na Alpine Linux
4. Jakich narzędzi używać, by ciągle pilnować ich jakości?

Zapraszam do oglądania!

Jak już obejrzysz, to wpadnij na stronę Docker Maestro i sprawdź TRZY darmowe lekcje DEMO.

Dzięki i do usłyszenia!




.

Leave a Comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *