Комментарии 7
Может есть рецепт, как направлять только часть трафика на новую версию, а часть по прежнему на старую?
Istio canary
https://habr.com/ru/company/ru_mts/blog/695242/ я в самом начале писал, про ingress canary. Istio тоже можно, но сложнее
Посмотрите GitOps инструмент ArgoRollouts - реализация Canary там, как мне кажется, одна из самых понятных и удобных
Да, stateless приложение типа hello world без БД отлично работает в такой схеме. Зачем, правда, таким приложениям столь сложная схема переключения? Фаулер в схеме указывает еще и две БД - для blue и green. И этот прекрасный момент все сторонники b/g подхода почему-то обходят стороной. Делов-то, обеспечить синхронизацию БД сначала blue -> green, применить миграции к green, переключить нагрузку на БД green, ...[какая-то магия]..., и blue с green поменялось местами без потери данных. Если из схемы b/g убрать раздельные БД, оставив одну центральную, то начинаются пляски с совместимыми миграциями, и начинаются вопросы к миграциям при откате приложения на предыдущую версию, если не взлетело. По сравнению с которыми плюс одномоментного переключения на новую версию и обратно несколько меркнет
А как выглядит переключение трафика, если мы развернем сервисы в Грин и Блю неймспейсах?
Совершенствуем развертывание приложений в Kubernetes с помощью Blue-Green Deployment