Пересоберёшь образ дважды и увидишь, какие шаги docker берёт готовыми.
Каждый шаг сборки docker печатает строкой вида #6 [2/4] WORKDIR /www, а последней строкой с тем же номером — чем шаг кончился: CACHED или DONE и время. Сравни две сборки одного Dockerfile: без правок и после правки index.html.
Пересобери образ дважды
В ~/site собери site:2 ещё раз без правок, потом замени в index.html v2 на v3 и собери site:3.
Сначала предположи
Какие шаги вторая сборка — после правки index.html — выполнит заново?
Теперь начни упражнение, выполни команду и сверь прогноз с выводом.
Перед каждым шагом docker ищет готовый слой: собранный поверх того же предыдущего слоя той же инструкцией, а для COPY — ещё и из тех же файлов. Нашёл — пишет CACHED и шаг не выполняет. Это кэш сборки. Сборка без правок вся прошла по кэшу: слои site:2 остались прежними.
Правка index.html изменила слой COPY. Шаги ниже строятся уже поверх нового слоя, и готовых для них нет: RUN выполнился заново, хотя его строка прежняя. Время в built.txt у site:3 — новое.
Поэтому то, что меняется часто, — страницы, код — копируют ближе к концу Dockerfile, а долгие шаги, которым эти файлы не нужны, ставят выше: правка пересобирает только хвост.
В другом Dockerfile строка RUN date -u '+%F %T' > built.txt стоит выше COPY index.html .. Ты правишь index.html и пересобираешь образ. Что будет в built.txt нового образа?
-
date от index.html не зависит и время пишет при любом порядке шагов. А здесь он даже не запустится: шаг возьмётся из кэша.
-
Прошлый образ новой сборке не мешает: она пройдёт до конца, шаг RUN — с пометкой
CACHED. -
RUN стоит выше COPY: под ним тот же предыдущий слой и та же строка, docker пишет
CACHEDи date не запускает.
Шаг выше правки docker берёт из кэша и не выполняет, поэтому в built.txt остаётся время прошлой сборки. Так кэш экономит долгие шаги — и так же может оставить их результат устаревшим.