Привет всем в этом блоге! В предыдущем посте мы рассмотрели базовые концепции жизненного цикла приложения в Red Hat Advanced Cluster Management (ACM) и показали, как их применять на примере развертывания приложения в двух кластерах. Сегодня расскажем, как применять ACM для сине-зеленого развертывания, миграции приложений между кластерами и аварийного восстановления.
Напомним, что мы используем модельную конфигурацию, представленную на схеме ниже, и просим обратить внимание на имеющиеся там метки, поскольку будем активно использовать их в наших примерах.
Мы также будем использовать Git-репозиторий из предыдущей статьи:
В предыдущей статье мы развернули наше приложение reversewords в двух средах, в девелоперской и в продакшн. Скажем, в Development, у нас стоит версия 0.0.3, а в Production – 0.0.2.
Теперь допустим, что разработчики выпустили версию 0.0.4, и мы хотим выполнить сине-зеленое развертывание в кластерах Development и Production, задействуя GitOps-возможности ACM.
В предыдущей статье мы создали в ACM необходимые ресурсы Channel, PlacementRules, Subscriptions и Applications, так что при развертывании новой версии в обоих кластерах будем работать только Git.
Поскольку все требуемые ресурсы уже созданы, нам остается только изменить описания приложения в Git-е, чтобы обновить версии в соответствующих средах.
ПРИМЕЧАНИЕ. Поскольку здесь мы только демонстрируем GitOps-возможности ACM, то будем push-ить изменения сразу в ветки репозитория, что не есть хорошо. В реальной практике у вас должен быть хорошо прописанный процесс внесения изменений в различные среды, подробнее об этом можно прочитать здесь.
1. Переходим в наш клонированный репозиторий Git:
ПРИМЕЧАНИЕ: Если вы воспроизводили у себя примеры из предыдущей статьи, то у вас уже есть клонированная ветвь вот этого репозитория.
2. Для начала мы хотим обновить версию приложения в среде Development, чтобы иметь возможность проверить ее, прежде чем отправлять изменения в Production-среду. Поэтому мы будем работать с веткой stage.
3. Теперь необходимо обновить overlay для application deployment, чтобы этот deployment использовал образ с новой версией (0.0.4).
Пока что в Development-кластере работает релиз 0.0.3.
4. Прежде чем делать commit изменений, проверим текущее состояние приложения в кластере development.
Как видите, сейчас в Development-среде работает версия 0.0.3:
5. Делаем commit файла и push’им его в ветку stage.
ПРИМЕЧАНИЕ. Еще раз, в реальной жизни так делать не надо. У вас для этого должен быть четко прописанный процесс.
6. Поскольку Subscription у нас уже есть, то обнаружив новый commit в наш репозиторий и ветку, ACM выполнит действия по изменению состояния с текущего на желаемое, как прописано в Git.
Как видим, изменения были детектированы и новая версия pod’а развертывается с новой версией приложения.
7. Теперь выполним запрос к приложению и убедимся, что мы развернули релиз 0.0.4.
8. Продакшн-релиз при это остался нетронутым.
9. Теперь можно выполнять валидационные тесты и, если все нормально, выкатывать новую версию приложения в продакшн.
1. Переходим в клонированный Git-репозиторий.
2. Считаем, что мы успешно протестировали новую версию приложения в кластере Development и пора внести соответствующие изменения, чтобы развернуть ее в кластере Production, поэтому теперь мы будем работать с веткой prod.
3. Необходимо обновить overlay для application deployment, чтобы этот deployment использовал образ новой версии (0.0.4).
Пока что в Production-кластере работает релиз 0.0.2
4. Прежде чем делать commit изменений, проверим текущее состояние приложения в кластере production.
Как видите, сейчас в Production -среде работает версия 0.0.2:
5. Делаем commit файла и push’им его в ветку prod.
ПРИМЕЧАНИЕ. Еще раз, в реальной жизни так делать не надо. У вас для этого должен быть четко прописанный процесс.
6. Поскольку Subscription у нас уже есть, то обнаружив новый commit в наш репозиторий и ветку, ACM выполнит действия по изменению состояния с текущего на желаемое, как прописано в Git.
Как видим, изменения были детектированы и новая версия pod’а развертывается с новой версией приложения.
7. Теперь выполним запрос к приложению и убедимся, что мы развернули релиз 0.0.4.
8. Всё, мы обновили наше приложение до версии 0.0.4 в обеих средах: и в Development, и в Production.
В первой части этой серии мы разобрали те аспекты ACM, которые относятся к категории GitOps. Сегодня мы научились применять ACM для сине-зеленого развертывания, миграции приложений между кластерами и аварийного восстановления. В следующем посте мы покажем, как с помощью ACM провести бесшовную миграцию приложения reversewords между нашими кластерами.
Напомним, что мы используем модельную конфигурацию, представленную на схеме ниже, и просим обратить внимание на имеющиеся там метки, поскольку будем активно использовать их в наших примерах.
| Компоненты ПО | Версии |
|---|---|
| Red Hat OpenShift Container Platform | 4.5.7 |
| Red Hat Advanced Cluster Management | 2.0 Fix Pack 2.0.2 |
Git-репозиторий
Мы также будем использовать Git-репозиторий из предыдущей статьи:
| Ветвь | Описание |
|---|---|
| config | Хранит базовые файлы для приложений, которые применяются во всех средах. |
| Prod | Хранит overlay-файлы для приложений, которые применяются в продакшн-средах. |
| stage | Хранит overlay-файлы для приложений, которые применяются в тестовых средах |
Сине-зеленое развертывание с помощью Red Hat ACM
В предыдущей статье мы развернули наше приложение reversewords в двух средах, в девелоперской и в продакшн. Скажем, в Development, у нас стоит версия 0.0.3, а в Production – 0.0.2.
Теперь допустим, что разработчики выпустили версию 0.0.4, и мы хотим выполнить сине-зеленое развертывание в кластерах Development и Production, задействуя GitOps-возможности ACM.
В предыдущей статье мы создали в ACM необходимые ресурсы Channel, PlacementRules, Subscriptions и Applications, так что при развертывании новой версии в обоих кластерах будем работать только Git.
Обновляем приложение в девелоперской среде
Поскольку все требуемые ресурсы уже созданы, нам остается только изменить описания приложения в Git-е, чтобы обновить версии в соответствующих средах.
ПРИМЕЧАНИЕ. Поскольку здесь мы только демонстрируем GitOps-возможности ACM, то будем push-ить изменения сразу в ветки репозитория, что не есть хорошо. В реальной практике у вас должен быть хорошо прописанный процесс внесения изменений в различные среды, подробнее об этом можно прочитать здесь.
1. Переходим в наш клонированный репозиторий Git:
ПРИМЕЧАНИЕ: Если вы воспроизводили у себя примеры из предыдущей статьи, то у вас уже есть клонированная ветвь вот этого репозитория.
cd /path/to/acm-app-lifecycle-blog/forked/repository/
2. Для начала мы хотим обновить версию приложения в среде Development, чтобы иметь возможность проверить ее, прежде чем отправлять изменения в Production-среду. Поэтому мы будем работать с веткой stage.
git checkout stage
3. Теперь необходимо обновить overlay для application deployment, чтобы этот deployment использовал образ с новой версией (0.0.4).
Пока что в Development-кластере работает релиз 0.0.3.
sed -i "s/v0.0.3/v0.0.4/g" apps/reversewords/overlays/deployment.yaml
4. Прежде чем делать commit изменений, проверим текущее состояние приложения в кластере development.
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Как видите, сейчас в Development-среде работает версия 0.0.3:
Reverse Words Release: Stage Release v0.0.3. App version: v0.0.3
5. Делаем commit файла и push’им его в ветку stage.
ПРИМЕЧАНИЕ. Еще раз, в реальной жизни так делать не надо. У вас для этого должен быть четко прописанный процесс.
git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed development reverse-words app version to v0.0.4"
git push origin stage
6. Поскольку Subscription у нас уже есть, то обнаружив новый commit в наш репозиторий и ветку, ACM выполнит действия по изменению состояния с текущего на желаемое, как прописано в Git.
oc --context dev -n reverse-words-stage get pods
Как видим, изменения были детектированы и новая версия pod’а развертывается с новой версией приложения.
NAME READY STATUS RESTARTS AGE
reverse-words-5ff744d4bd-kkfvn 0/1 ContainerCreating 0 3s
reverse-words-68b9b894dd-jfgpf 1/1 Running 0 109m
7. Теперь выполним запрос к приложению и убедимся, что мы развернули релиз 0.0.4.
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Stage Release v0.0.4. App version: v0.0.4
8. Продакшн-релиз при это остался нетронутым.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Production release v0.0.2. App version: v0.0.2
9. Теперь можно выполнять валидационные тесты и, если все нормально, выкатывать новую версию приложения в продакшн.
Обновляем приложение в продакшн-среде
1. Переходим в клонированный Git-репозиторий.
cd /path/to/acm-app-lifecycle-blog/forked/repository/
2. Считаем, что мы успешно протестировали новую версию приложения в кластере Development и пора внести соответствующие изменения, чтобы развернуть ее в кластере Production, поэтому теперь мы будем работать с веткой prod.
git checkout prod
3. Необходимо обновить overlay для application deployment, чтобы этот deployment использовал образ новой версии (0.0.4).
Пока что в Production-кластере работает релиз 0.0.2
sed -i "s/v0.0.2/v0.0.4/g" apps/reversewords/overlays/deployment.yaml
4. Прежде чем делать commit изменений, проверим текущее состояние приложения в кластере production.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Как видите, сейчас в Production -среде работает версия 0.0.2:
Reverse Words Release: Stage Release v0.0.2. App version: v0.0.2
5. Делаем commit файла и push’им его в ветку prod.
ПРИМЕЧАНИЕ. Еще раз, в реальной жизни так делать не надо. У вас для этого должен быть четко прописанный процесс.
git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed production reverse-words app version to v0.0.4"
git push origin prod
6. Поскольку Subscription у нас уже есть, то обнаружив новый commit в наш репозиторий и ветку, ACM выполнит действия по изменению состояния с текущего на желаемое, как прописано в Git.
oc --context pro -n reverse-words-prod get pods
Как видим, изменения были детектированы и новая версия pod’а развертывается с новой версией приложения.
NAME READY STATUS RESTARTS AGE
reverse-words-68795d69ff-6t4c7 0/1 ContainerCreating 0 5s
reverse-words-7dd94446c-vkzr8 1/1 Running 0 115m
7. Теперь выполним запрос к приложению и убедимся, что мы развернули релиз 0.0.4.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Production Release v0.0.4. App version: v0.0.4
8. Всё, мы обновили наше приложение до версии 0.0.4 в обеих средах: и в Development, и в Production.
Заключение
В первой части этой серии мы разобрали те аспекты ACM, которые относятся к категории GitOps. Сегодня мы научились применять ACM для сине-зеленого развертывания, миграции приложений между кластерами и аварийного восстановления. В следующем посте мы покажем, как с помощью ACM провести бесшовную миграцию приложения reversewords между нашими кластерами.
