В чем преимущество каждого развертывания - создание нового образа докера, содержащего приложение, а не просто обновление приложения?

Question

Я переношу приложение в Nodejs на kubernetes в GCP. В руководствах по CI я вижу, как обновленное приложение копируется в новый образ докера и отправляется в GCR.

Процесс загрузки изображения идет медленно по сравнению с обновлением только кода. Так в чем же выгода при отправке нового изображения, содержащего приложение?

Answer 1

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

Решение

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

Минимальные изображения докера

Answer 2

Философия Docker проста - слои можно использовать повторно [1]. Пока слои не изменились, они повторно используются в изображениях. Пока вы сохраняете уровень приложения как последние несколько, базовые слои можно использовать повторно, сводя количество слоев к минимуму. Вы должны рассмотреть возможность использования многоэтапных сборок, чтобы минимизировать зависимости между этапами сборки и доставки вашего контейнера. У Hasura.io есть отличная статья [2] об эффективном использовании многоступенчатых сборок для приложений NodeJS.

1. https://www.infoworld.com/article/3077875/linux/containers-101-docker-fundamentals.html
2. https://blog.hasura.io/an-exhaustive-guide-to-writing-dockerfiles-for-node-js-web-apps-bbee6bd2f3c4

Answer 3

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