Обновить

Комментарии 4

Хм, довольно сложно ожидать надежности и хорошей работы системы, если она не прошла тестирование. А по вашей статье получается, что образы сразу из upstream идут в prod. Или я что--то неправильно понял?
Реплицироваться независимо в каждом регионе, да еще из 3p источников - это большой риск.
Допустим какой-то образ содержит ошибки или обратно-несовместимые изменения, которые роняют вашу систему. Каждый регион подтнянул это изменение и у вас получится каскад проблем мирового масштаба. Чтобы такого не было - нужна pipeline. Все регионы должны получать единый, прошедший тестирование набор образов. Этой "репликацией" и должна заниматься pipeline - последовательно - сначала собрать систему, запустить, протестировать и прогнать весь этот комплект, как единый бандл, через все регионы, один за другим, внимательно следя за метриками и alarms на каждом promotion. У нас это считается лучшими практиками. Поэтому какая-то AZ может отвалиться, и это редко, но случается. Какой-то регион тоже может отвалиться, но уже значительно реже.

реплицируеться уже протестированный образ(релиз). И конечно у него везде одинаковое содержимое и контрольная сумма;
Это не часть CI/CD, это нечто что происходит между CI и CD - просто технический момент. Так сказать кэширование.

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

PS конечно у нас не один сервис, но на примере одного проще пояснить


Просто вы свой образ ложите возможно в одно место и вам хватает

Нет, не одно место. Места как раз региональные/AZ и мельче и у каждой pipeline своя структура.
CICD подразумевает автоматические тесты. А вы запускаете каждый регион через свою pipeline?

тестам то все равно какой у имеджа регион, мы точно про Docker registry говорим? это место откуда имеджи скачивают для запуска контейнеры. Мы тесты напротив энвайромента запускаем а там может быть сколько угодно регионов, за то что бы версия правильная была совсем другая часть отвечает которая GitOps называеться
А это часть отвечает только за то чтобы одинаковые имеджи были во всех регионах где сервисы надо ранать- максимально близко, чтобы скорость загрузки имеджа была не 100мс а 2мс, это влияет на скорость старта контейнера.
А в деплойментах каждого региона hash контейнера даже а не тег имеджа так что самому деплойменту, да и контейнеру неважно откуда он там береться если хеш совпадает.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации