Уменьшение размера изображения Docker

При разработке приложений Docker поддержание ваших изображений как можно более легким имеет много практических преимуществ. Это делает вещи быстрее, более портативными и менее подверженными разрывам. Облегченные изображения также облегчают использование таких сервисов, как Jet, платформа Codeship Docker CI / CD ; они с меньшей вероятностью представляют сложные проблемы, которые трудно устранить, и для их совместного использования требуется меньше времени.

Имея это в виду, давайте поговорим о некоторых отличных способах упростить ваши изображения Docker и сделать их как можно меньше. Спасибо всем в команде Codeship и нашим друзьям, которые предоставили эти советы!

Используйте столько слоев, сколько требуется

Как правило, чем меньше слоев, тем проще Dockerfile. Это означает, что вы должны комбинировать связанные команды как можно больше, но, конечно, не пытайтесь комбинировать несвязанные команды просто ради создания крошечного изображения. Особенно, если вы новичок в Docker.

Лучше разбивать слои при добавлении файлов (для увеличения степени детализации и кэширования), но комбинировать слои при выполнении связанных команд. Например, запустите apt get update && apt-get install чтобы зависимая команда всегда выполнялась с последней версией родительской команды, и чтобы любая очистка команды выполнялась на одном уровне.

Есть несколько инструментов для проверки состава ваших изображений Docker, чтобы увидеть, какие слои могут способствовать раздутию. Попробуйте посмотреть на слои вашего изображения на MicroBadger .

Убери сразу

При выполнении команд выполните простейшую цепочку команд, чтобы все заработало. Кроме того, как я упоминал ранее, всегда старайтесь выполнять очистку в том же слое, где вы выполняете свои оригинальные команды. Распространено загрузить архив, распаковать его, а затем отредактировать файл или переместить его на место, а затем забыть удалить исходный архив.

Удаление файлов такого типа, а также других временных журналов и каталогов кеша может уменьшить пространство в вашем конечном изображении. Однако, если вы не сделаете это в той же строке Dockerfile, удаленный файл все равно будет существовать в предыдущем слое изображения. Этот тип очистки применяется ко всем взаимодействиям в файловой системе во время сборки образа Docker.

Например:

Вместо:

! Новый призыв к действию

Используйте урезанное базовое изображение

Использование подходящего базового изображения для вашего проекта может иметь огромное значение. Имеет смысл использовать официальный образ Ruby для вашего проекта Rails, но если вы просто запускаете двоичный файл в контейнере, нужен ли вам полный образ Ubuntu? Может быть, вы можете использовать меньшее изображение, например, Alpine, или просто запустить Scratch-контейнер?

Одной из возможностей будет создание собственного базового образа только с необходимыми вам компонентами. Не бойтесь снимать урезанные изображения и добавлять только необходимые компоненты. Иногда изображение меньшего размера, адаптированное к вашим потребностям, предпочтительнее, чем готовое изображение.

Используйте правильное изображение для правильного сервиса

Везде, где это имеет смысл, делитесь изображениями между службами. Но если одному сервису нужен Ruby, а не Rails, в то время как всем другим сервисам требуется Rails, вы, вероятно, можете выделить их для создания нескольких контекстно-упорядоченных изображений.

Делать:

• Используйте существующее подобное изображение или более сложное изображение, когда
  • это изображение в любом случае строится;
  • и дополнительное время ожидания необходимого образа не замедляет общий процесс сборки.
• Используйте сервис с самым простым базовым образом во всех остальных случаях.

Не делайте:

• Используйте более сложное изображение в качестве артефакта сборки.

Оптимизировать dockerignore

Это может иметь большое значение: добавьте как можно больше к вашему .dockerignore .

В зависимости от вашего приложения вы, возможно, захотите как минимум игнорировать папки .git , log и tmp (хотя в некоторых случаях может потребоваться включение .git ). Вы также можете обновить другие части вашего конвейера, чтобы избежать сброса больших двоичных файлов в каталоги, которые не требуются в контексте сборки. Это поможет предотвратить всплывающие изображения в результате непреднамеренного добавления артефактов сборки в среду сборки.

Один из способов выяснить, что нужно удалить, — запустить изображение, переопределяя точку входа в интерактивную оболочку. Таким образом, вы можете взглянуть на все файлы, которые были добавлены, и отметить любые, которые вам на самом деле не нужны.

Вы можете покопаться в работающем контейнере, чтобы увидеть, не осталось ли на вашем изображении ненужных файлов.

Одним из замечательных побочных эффектов этой оптимизации является то, что ваши сборки изображений будут выполняться быстрее, поскольку в ваших слоях изображений будет меньше файлов, которые могут сделать их недействительными.

Сборка против начальной загрузки

Решение, которое повлияет на многие другие ваши варианты и окажет большое влияние на ваши конечные результаты, заключается в том, нужно ли встроить ресурсы в образ или вместо этого подготовить их во время выполнения.

Хотя вы можете компилировать ресурсы во время сборки и включать их в свои изображения, вы также можете генерировать их во время выполнения. Вы даже можете извлечь их из внешнего источника, в котором они были сгенерированы либо во время сборки, во время предыдущей сборки, либо из совершенно внешнего процесса. Вы также можете добавить свои активы к вашему изображению в сжатом формате и распаковать их во время выполнения.

Правильный путь для вас зависит от вашей архитектуры и ваших целей, но вы должны учитывать, насколько тяжелым или легким вы в конечном итоге хотите, чтобы ваши изображения были.

Вывод

Как видите, существует множество отличных способов уменьшить размер изображения. Некоторые из них выходят за рамки простой эффективности и полагаются на решения, которые пронизывают остальную часть архитектуры вашего приложения.

Просто помните: эффективные изображения — это, в конечном счете, компромисс размера, сбалансированного с тем, что вам нужно для надежной и простой поддержки вашего приложения.