Все, кто пользуются докером в той или иной степени используют кэширование при сборке образов. В чём суть вопроса?
Я общаюсь с девопсом в своей команде. У нас проект на Node, подготовка образа включает установку зависимостей и билд проекта. Я предлагаю разделить этапы установки зависимостей и этап сборки проекта, потому что зависимости устанавливаются в несколько раз дольше, чем выполняется сборка. Зависимости меняются редко, поэтому я вижу смысл в том, чтобы кешировать этап установки зависимостей. Девопс смеётся и говорит, что это всё ерунда
Докер-образы собираются из инструкций в докерфайле по порядку. Результат выполнения почти каждой команды (слой) кэшируется. И лежит себе, пока его не потрут
Какое конкретно? Дефолтное само используется обычно, новые фичи билд кита надо настраивать
Это вроде как рекомендуемм способ для ноды, вернее для npm/yarn
Кеширование слоёв. Популярная ли это практика среди девопсов в проектах? Целесообразно ли его отключать?
Не целесообразно. Он очень хорошо работает. Целесообразно даже пуллить предыдущий билд на чистую ноду
А как девопс-то этот проект собирает?
sudo docker build --pull \ --no-cache \ --build-arg SSH_KEY="\$key" \ --build-arg IMAGE_TAG=$KEBAB_BRANCH \ -t \${full_tag_name} \ -f deploy/Dockerfile .
Ну вот пусть no-cache уберёт. Докер без лишней помощи может проверить изменения в окружении для сборки. Ну и SSH ключ запекать в сборку – вообще не очень
Да, где-то пушим в реджистри как слои, конкретно за node_modules - пушим кеш в s3.
А вообще есть несколько вещей тут потенциально нехороших: ––pull – сдёргивать всегда свежую версию контейнера (FROM node:latest условный может быть написан, и всё похерит). Девопсу, наверное, лучше пинить версии, в особенности, если это продакшен --no-cache вместе c --build-arg SSH_KEY кстати имеет смысл: можно терморектально отгородиться от утечки данных в кэш (он собирает с грязным трюком, но приложил подорожник, вот и никакого вам кэша)
Не подскажешь, как правильно чистить кеш? Так, чтобы удалялись только старые полные образы, но не промежуточные слои с зависимостями, которые давно не обновлялись, но всё ещё актуальны?
Если собираете с --no-cache (могу ошибаться), слоёв никаких и так нет
А если включим кеш?
Игнорирует локальные промежуточные слои.
А сам их пишет всё равно? Я вот не помню, а в доке очень кратко
When the ‘–no-cache’ option is passed to ‘Docker build…’, then that build will always start from scratch, writing a new image to the file system even if nothing in the Dockerfile has changed. This is guaranteed to not reuse stale results, but will always take the maximum amount of time. Всё же пишет.
Можно сделать несколько вещей: – Начать хранить сикреты безопасно (не билдить с ними) и наслаждаться кэшем докера – Если это удобно – собрать свой образ с зависимостями для основы, положить в свой реджистри и юзать его, обновляя централизованно. А везде, куда сикреты пихаете, поступать на свой страх и риск
SSH-ключ используется при сборке образа для копирования репозитория из Github. Для авторизации в Github нужны логин и пароль или SSH-ключ. Не подскажешь, как правильно нужно в таком случае поступать?
https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066 А лучше всего пользоваться каким-то CI/CD, который централизованно всё скачает (или сам будет описан в репозитории проекта, как в GitLab)
Обсуждают сегодня