
Комментарии 4
Хм, довольно сложно ожидать надежности и хорошей работы системы, если она не прошла тестирование. А по вашей статье получается, что образы сразу из upstream идут в prod. Или я что--то неправильно понял?
Реплицироваться независимо в каждом регионе, да еще из 3p источников - это большой риск.
Допустим какой-то образ содержит ошибки или обратно-несовместимые изменения, которые роняют вашу систему. Каждый регион подтнянул это изменение и у вас получится каскад проблем мирового масштаба. Чтобы такого не было - нужна pipeline. Все регионы должны получать единый, прошедший тестирование набор образов. Этой "репликацией" и должна заниматься pipeline - последовательно - сначала собрать систему, запустить, протестировать и прогнать весь этот комплект, как единый бандл, через все регионы, один за другим, внимательно следя за метриками и alarms на каждом promotion. У нас это считается лучшими практиками. Поэтому какая-то AZ может отвалиться, и это редко, но случается. Какой-то регион тоже может отвалиться, но уже значительно реже.
реплицируеться уже протестированный образ(релиз). И конечно у него везде одинаковое содержимое и контрольная сумма;
Это не часть CI/CD, это нечто что происходит между CI и CD - просто технический момент. Так сказать кэширование.
Просто вы свой образ ложите возможно в одно место и вам хватает. У нас очень важно время старта подов(их тясячи), потому нам приходиться заморачиваться и копировать их в каждый регион- поближе;
PS конечно у нас не один сервис, но на примере одного проще пояснить
Просто вы свой образ ложите возможно в одно место и вам хватает
Нет, не одно место. Места как раз региональные/AZ и мельче и у каждой pipeline своя структура.
CICD подразумевает автоматические тесты. А вы запускаете каждый регион через свою pipeline?
тестам то все равно какой у имеджа регион, мы точно про Docker registry говорим? это место откуда имеджи скачивают для запуска контейнеры. Мы тесты напротив энвайромента запускаем а там может быть сколько угодно регионов, за то что бы версия правильная была совсем другая часть отвечает которая GitOps называеться
А это часть отвечает только за то чтобы одинаковые имеджи были во всех регионах где сервисы надо ранать- максимально близко, чтобы скорость загрузки имеджа была не 100мс а 2мс, это влияет на скорость старта контейнера.
А в деплойментах каждого региона hash контейнера даже а не тег имеджа так что самому деплойменту, да и контейнеру неважно откуда он там береться если хеш совпадает.
Как мы перестали толкать и начали тянуть (AWS ECR)