Question

У нас есть управляемая группа экземпляров на GCP, настроенная с помощью правила автомасштабирования.

Группа экземпляров ссылается на шаблон экземпляра, созданный с помощью gcloud compute instance-templates create-with-container. Образ контейнера размещен в GCR.

Я пытаюсь понять, как лучше всего развертывать частые обновления для этой группы экземпляров, например, в конвейере CI / CD.

На основе моих В соответствии с текущим пониманием, процедура выглядит так:

Создайте и перенесите sh новое изображение docker в GCR
Создайте новый шаблон экземпляра.
Отправьте непрерывное обновление в группу экземпляров, которая указывает на новый шаблон экземпляра.

Однако в конвейере CI / CD кажется:

Это будет создавать сотни, а возможно, и тысячи шаблонов висящих экземпляров, которые используются только один раз и никогда больше. Есть ли здесь проблема?
Непонятно, как должны называться или версироваться шаблоны экземпляров. Я думал записать ha sh изображения docker в имя шаблона экземпляра при создании шаблона, но это кажется излишним ручным.

Действительно ли это оптимальный способ развертывания обновления для группы экземпляров, или мне что-то не хватает? Упростит ли это все это в диспетчере развертывания, например, при генерации имени или очистке шаблона?

mebius99 · Answer 1 · 19 мая 2020

Чтобы сделать поведение развертываний более предсказуемым, было бы лучше следовать подходу «детерминизма c», который предполагает указание тегов с точной версией сборки или ha sh. Следствием этого является множество экземпляров шаблонов, которыми придется управлять позже.

С другой стороны, это обеспечивает возможность контроля версий и отката. Существуют свойства versions и instanceTemplate объекта MIG и имя образа контейнера и тег шаблона экземпляра, которые можно использовать для управления версиями.

Kubernetes Engine выглядит аксиомой c подход в случаях, подобных вашему. Но если GKE не подходит по объективным причинам, можно рассмотреть Cloud Run . Он поддерживает автомасштабирование, сервисные версии и заботится о imageDigest. Как и в случае с шаблонами экземпляров, конфигурации каждой ревизии неизменны.

Сильная сторона Deployment Manager заключается в создании сложных развертываний. В DM каждая сборка должна быть в форме отдельного развертывания. Шаблоны на основе Python или Jinja2 могут помочь в создании значимых имен, меток, метаданных, которые можно использовать во время очистки позже. Но сами развертывания должны управляться и очищаться в любом случае: с помощью gcloud deployment-manager deployments delete.

Что бы вы ни выбрали, существует необходимость в сортировке и очистке устаревших «управляемых элементов»: шаблонов экземпляров, ревизий или развертываний. Это зависит от пользователя, Google не предоставляет услуги по управлению жизненным циклом.

Примитивное решение жизненного цикла может быть вызвано gcloud из задания cron, запущенного на виртуальной машине с учетной записью службы, которой предоставлены соответствующие разрешения. Управляемые элементы могут быть запрошены на основе ключевых атрибутов, таких как идентификатор, временная метка, ha sh, дайджест. Списки элементов можно отсортировать по метке времени или тегу версии, чтобы удалить, например, самые старые 100 элементов или сохранить последние 100 элементов.

Compute Engine> Do c> Deterministi c шаблоны экземпляров

Compute Engine> Do c> Развертывание контейнеров на виртуальных машинах и MIG> Обновление управляемой группы экземпляров до новой версии образа контейнера

Compute Engine> Do c> Создание MIG> Изменение шаблона экземпляра для MIG

Compute Engine> Do c> Развертывание обновлений для MIG> Взаимосвязь между версиями и свойствами instanceTemplate для управляемой группы экземпляров