Comments 4
Не лучше ли использовать какое либо специализированное ПО - например argo rollout или flagger? Тогда можно будет и более сложные сценарии деплоя делать (например с промежуточными проверками), да и другие паттерны выкатки заюзать - например канареечное обновление + обычно там же есть интеграция с разными Nginx/Istio/etc из коробки, не нужно будет это руками описывать, особенно если таких сервисов десятки
есть конечно минусы: +1 компонент в системе и время на освоение, но последнее это разовая затрата
Конечно, можно использовать какое-либо специализированное ПО, здесь всё зависит от конкретного кейса и потребностей заказчика. Если уже используется GitLab для деплоя в кубы, то принести эту реализацию может быть удобнее, чем дополнительно внедрять и поддерживать что-то новое. Например, если мы применяем blue-green только для одного приложения/группы приложений, то внедрение специализированного ПО, может только усложнить схему. Особенностью данного способа является как раз отсутствие необходимости переписывания пайплайнов под тот же Argo CD.
Что касается других паттернов, например, упомянутого canary - у него чуть другая задача. При blue-green мы не переключаем никакую часть пользователей на новый функционал, минимизируя тем самым простой и обеспечивая возможность быстрого отката к предыдущей версии. Это важно при необходимости поддержки критической инфраструктуры. Canary же больше подходит в случаях, когда необходимо протестировать новый функционал на ограниченной группе пользователей.
Спасибо за статью. Подскажите, пожалуйста, а как можно было бы реализовать б\г, когда есть микросервисная архитектура и приложения общаются между собой без ингреса через сервисы?
Допустим, есть под А, и в этот под обращается под Б, В, Г и т.п. Если я задеплою новую версию пода А, как другие поды должны узнавать, что есть новая версия и к ней нужно обращаться, чтобы протестировать новую версию?
Это не говоря про то, что нужно будет деплоить новые версии всех зависимых приложений вместе сразу - и А, и Б, и В и т.д. :)
В голову приходит использование только через service mesh, но и то не конкретная реализация. Там тоже надо подумать.
Если вдруг у вас есть какие-то мысли по этому поводу, буду благодарен.
Добрый день, тут есть несколько вариантов:
1. У нас есть группа приложений, которые выкатываются вместе и можно задеплоить их все в новую версию. Этот случай как раз расписан во второй части моей статьи, пункт «Деплой нескольких приложений с помощью werf bundle». Поскольку для каждого приложения мы указываем {{ .Chart.Name }}{{ $deploy_version }}
, то и в переменных окружения можем указать сервис с нужной deploy_version
. Таким образом, все приложения А, Б, В и другие будут обращаться к своей версии (синие на синие, а зелёные на зелёные). Я бы посоветовал подумать над этим вариантом.
2. Можно управлять трафиком до приложений не на Ingress, а непосредственно на Service. У нас будут 2 версии Deployment и 1 версия Service, в которой указываются нужные лейблы в секции selector
. Из нюансов стоит отметить, что деплоить Service я бы советовал в этом случае отдельно от Deployment, иначе можем потерять одно из преимуществ blue-green - минимизацию простоя.
Я бы начал с того, что собрал требования, которым должна соответствовать инфраструктура, и уже от них отталкивался при выборе реализации. Как вариант, можно посмотреть в сторону реализации blue/green с помощью istio (если нужен именно blue/green).
Как использовать blue-green-деплой: руководство по выкату одного и нескольких приложений