Как управлять логической группировкой приложения на основе микросервиса для обеспечения совместимости версий для CI / CD Pipeline?

Question

Для приложения на основе архитектуры MicroService я пытаюсь понять стандартный процесс о том, как логически группировать и управлять правильной совместимостью версий среди независимо развертываемых микросервисов. Позвольте мне остановиться на практическом сценарии:

Скажем, я создаю программное приложение, которое состоит из 10 микросервисов. Все микросервисы имеют свои независимые репозитории (ветвление workflow et c.) И отдельный конвейер CI / CD. Конвейер CI / CD запускается всякий раз, когда любое изменение передается в «главную» ветвь для соответствующего микросервиса.

С учетом диаграммы Хелма и развертывания на основе Kubernetes все микросервисы будут развернуты с версией 1.0 для самого первого развертывания, и наши Система будет работать. Для последующих выпусков у нас может быть только пара сервисов, которые будут развернуты. Таким образом, после нескольких производственных выпусков каждый микросервис будет иметь свою версию для создания приложения на тот момент.

Мой вопрос:

1. Как логически группировать самостоятельно развертываемые микросервисы для развертывания или возврата к более раннему выпуску, т. е. как определить, какой была версия различных микросервисов для более ранних выпусков?

2. Существует ли какой-либо существующий инструмент или стандартная практика для отслеживания версий каждого микросервиса для данного выпуска для плавного отката к ожидаемому выпуску?

3. Если бы не автоматизированное решение, каким был бы правильный подход для удовлетворения такого требования?

Ценю ваши мысли и предложения по этому вопросу.

Answer 1

Это довольно новая проблема, мы только что запустили новый инструмент Reliza Hub , чтобы решить эту проблему. Также вот мой пост на эту тему: Микросервисы - комбинаторный взрыв версий . В настоящее время мы находимся на этапе MVP, и много работы продолжается - посмотрите это видеоурок, если наше направление имеет смысл для вас https://www.youtube.com/watch?v=yDlf5fMBGuI

Если вы решили внедрить и иметь любые вопросы или нужна помощь с интеграцией, просто пометьте меня на SO, и я бы очень хотел, чтобы это сработало для вас.

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

И мы говорим, что Продукты по сути являются составной частью Проектов и предоставляют инструментарий, позволяющий компилировать различные версии Проектов в так называемый пакет Продуктов. Затем вы можете интегрировать это в любой инструмент CI или CD или запустить вручную, если вы еще не настроили CICD.

Кроме этого, да - я очень рекомендую helm и kubernetes - это то, что мы используем на новые проекты. (И я также могу добавить ArgoCD и Spinnaker к существующим инструментам). Но этого недостаточно для отслеживания перестановок различных версий микросервисов и определения, какие конфигурации хороши, а какие нет в разных средах.

Answer 2

С учетом куберенца: 1. Шлем - это хороший инструмент для развертывания и отслеживания. 2. Нативное развертывание k8s работает хорошо, вам нужно правильно использовать развертывание, особенно посмотрите флаг --record в командах k8s, например проверьте эту ссылку

С AWS кластерами ECS: 1. они имеют определения задач и задач. Я думаю, что это работает для вас.

Нет указателей для docker -состава, роя и других инструментов. Но вы всегда можете использовать возможности git и некоторые сценарии. Идея в том, чтобы создать файл, в котором перечислены все версии сервисов / контейнеров / кода. и передайте этот файл в git с кодом. Сделайте из него метку для простоты. Ваш скрипт должен сравнить этот файл состояния и текущее состояние и применить только указанные c изменения. Смотрите также git подмодули . это всего лишь группа из множества git проектов, и она отслеживает состояние каждого проекта с помощью идентификатора коммитов каждого проекта. Это помогло нам в ситуации, которую вы упоминаете.