Jak odbywa się buforowanie w Dockerze?

Korzystanie z pamięci podręcznej w Dockerze opiera się na warstwach podczas budowania obrazu. Dockerfile składa się z instrukcji, z których każda tworzy nową warstwę. Przy kolejnych budowach, jeśli instrukcja i jej kontekst się nie zmieniły, Docker używa istniejącej warstwy z pamięci podręcznej zamiast ponownego wykonywania instrukcji.

Czynniki wpływające na unieważnienie pamięci podręcznej:

Zmiana instrukcji: Każda zmiana samej instrukcji (np. z RUN apt-get update na RUN apt-get install).
Zmiana kontekstu: Zmiana plików lub katalogów używanych przez instrukcję (COPY, ADD). Na przykład zmiana zawartości pliku kopiowanego do obrazu.
Kolejność instrukcji: Zmiana kolejności instrukcji w Dockerfile.
Użycie --no-cache: Wyraźne wyłączenie pamięci podręcznej dla całego procesu budowania.

Proces buforowania:

Docker czyta Dockerfile od góry do dołu.
Dla każdej instrukcji sprawdza, czy istnieje warstwa w lokalnej pamięci podręcznej, która odpowiada dokładnie tej samej instrukcji i kontekstowi.
Jeśli znajdzie dopasowanie, Docker ponownie używa tej warstwy i przechodzi do następnej instrukcji.
Jeśli dopasowania nie ma (pamięć podręczna jest unieważniona), Docker wykonuje instrukcję, tworzy nową warstwę i dodaje ją do pamięci podręcznej. Wszystkie instrukcje po unieważnionej warstwie również nie będą korzystać z pamięci podręcznej.

Przykład wpływu kolejności instrukcji:

Załóżmy, że masz Dockerfile, który najpierw kopiuje Twój kod, a następnie instaluje zależności. Jeśli często zmieniasz kod, ale rzadko zależności, bufor instalacji zależności będzie bezużyteczny, ponieważ za każdym razem, gdy zmieni się kod, bufor na kroku COPY zostanie unieważniony.

# Dockerfile 1 (Zła pamięć podręczna przy częstych zmianach kodu)
COPY . /app
RUN pip install -r requirements.txt

Zmiana kolejności instrukcji może poprawić buforowanie:

# Dockerfile 2 (Dobra pamięć podręczna przy częstych zmianach kodu)
COPY requirements.txt /app/
RUN pip install -r /app/requirements.txt
COPY . /app

W tym przypadku, jeśli zmieni się tylko kod (nie requirements.txt), bufor dla RUN pip install zostanie zachowany.

Instrukcje ADD i COPY używają hasha zawartości plików do unieważniania pamięci podręcznej.

Polecenie docker build domyślnie korzysta z pamięci podręcznej. Aby ją wyłączyć, używa się flagi --no-cache.

# Budowa z użyciem pamięci podręcznej (domyślnie)
docker build -t myimage .

# Budowa bez użycia pamięci podręcznej
docker build --no-cache -t myimage .