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).
Конечно, можно использовать какое-либо специализированное ПО, здесь всё зависит от конкретного кейса и потребностей заказчика. Если уже используется GitLab для деплоя в кубы, то принести эту реализацию может быть удобнее, чем дополнительно внедрять и поддерживать что-то новое. Например, если мы применяем blue-green только для одного приложения/группы приложений, то внедрение специализированного ПО, может только усложнить схему. Особенностью данного способа является как раз отсутствие необходимости переписывания пайплайнов под тот же Argo CD.
Что касается других паттернов, например, упомянутого canary - у него чуть другая задача. При blue-green мы не переключаем никакую часть пользователей на новый функционал, минимизируя тем самым простой и обеспечивая возможность быстрого отката к предыдущей версии. Это важно при необходимости поддержки критической инфраструктуры. Canary же больше подходит в случаях, когда необходимо протестировать новый функционал на ограниченной группе пользователей.
Добрый день, тут есть несколько вариантов:
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).
Конечно, можно использовать какое-либо специализированное ПО, здесь всё зависит от конкретного кейса и потребностей заказчика. Если уже используется GitLab для деплоя в кубы, то принести эту реализацию может быть удобнее, чем дополнительно внедрять и поддерживать что-то новое. Например, если мы применяем blue-green только для одного приложения/группы приложений, то внедрение специализированного ПО, может только усложнить схему. Особенностью данного способа является как раз отсутствие необходимости переписывания пайплайнов под тот же Argo CD.
Что касается других паттернов, например, упомянутого canary - у него чуть другая задача. При blue-green мы не переключаем никакую часть пользователей на новый функционал, минимизируя тем самым простой и обеспечивая возможность быстрого отката к предыдущей версии. Это важно при необходимости поддержки критической инфраструктуры. Canary же больше подходит в случаях, когда необходимо протестировать новый функционал на ограниченной группе пользователей.