Является ли изображение Docker в CI/CD полезным только для нескольких хостов?

Question

Мы двое людей, разрабатывающих одно хост-приложение в Docker, где мы хотели бы сократить время тестирования и использовать CI/CD.

Многие статьи посвящены использованию платной услуги для запуска тестов и создания изображений Docker, а затем развертывания изображений.

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

Развертывает ли изображения только дополнительный уровень сложности в случаях с одним хостом?

Update

То, что мы делаем сейчас толкаем изменения в Git, а затем вручную протестировать приложение, и если это нормально, то сливаться освоить и вход на сервер производства и сделать git pull && docker-compose build.

Когда я говорю о размещении изображений Docker в вопросе, развертывание на производстве почти будет docker pull. Ключевое отличие - это изображение докера, которое не построено на производственном сервере, а где-то еще.

Это все, о чем я прошу. Существуют ли какие-либо преимущества в создании изображений где-то еще, когда они развертываются только на одном хосте/машине/сервере/узле?

Answer 1

Я отвечаю на уже обновленный вопрос:

Существуют ли какие-либо преимущества построения изображения где-то еще < ...>?

Да, есть некоторые.

1. Вы не должны держать сборки инструментов на производственном сервере обновляется; на самом деле, они вам вообще не нужны. Это уменьшает вероятность возможного несоответствия версий между средами dev/QA/prod, снижает вероятность наличия некоторых 0-дневных уязвимостей на вашем сервере и т. Д. Вообще говоря, чем меньше дополнительного программного обеспечения живет на производственном сервере, тем лучше.
2. С уже построен контейнер вы открыты для многих вариантов немедленно:
   • Динамическая масштабируемость. Как только вы обнаружите, что у вас есть поток пользователей, все, что вам нужно сделать, это поднять новую виртуальную машину и вытащить контейнер. Или даже запустить другой контейнер на том же хосте и сбалансировать их.
   • Распространение исправлений. Возможно, что при большой нагрузке возникает какая-то ошибка. И производственный сервер может просто оказаться вне ресурсов, когда вы пытаетесь одновременно обслуживать тонны пользователей и создать новый контейнер для исправлений ошибок.
   • Аварийное восстановление. Если ваш производственный узел внезапно мертв, все, что вам нужно сделать, это запустить контейнер докеров в другом месте. В этом случае вы можете столкнуться с неоптимизированной средой, но по крайней мере вам не придется писать объяснение по электронной почте пользователям о простоях в течение N часов.

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