Как стать автором
Обновить
0
Red Hat
Программные решения с открытым исходным кодом

Red Hat Advanced Cluster Management и управление приложениями, часть 2. Сине-зеленое развертывание, миграция…

Время на прочтение5 мин
Количество просмотров1.2K
Привет всем в этом блоге! В предыдущем посте мы рассмотрели базовые концепции жизненного цикла приложения в Red Hat Advanced Cluster Management (ACM) и показали, как их применять на примере развертывания приложения в двух кластерах. Сегодня расскажем, как применять ACM для сине-зеленого развертывания, миграции приложений между кластерами и аварийного восстановления.



Напомним, что мы используем модельную конфигурацию, представленную на схеме ниже, и просим обратить внимание на имеющиеся там метки, поскольку будем активно использовать их в наших примерах.

Компоненты ПО Версии
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 между нашими кластерами.
Теги:
Хабы:
Всего голосов 5: ↑5 и ↓0+5
Комментарии0

Публикации

Информация

Сайт
www.redhat.com
Дата регистрации
Дата основания
Численность
5 001–10 000 человек
Местоположение
США

Истории