Мы начинаем серию постов, в которой покажем, как Advanced Cluster Management (ACM) предоставляет обширные возможности для управление жизненным циклом приложений, которые должны существовать сразу в нескольких средах, неважно, в облаке или в корпоративном дата-центре.
Сегодня мы сосредоточимся на тех аспектах ACM, которые относятся к категории GitOps, и разберем их, используя следующую модельную конфигурацию:
Итак, у нас здесь три кластера OpenShift. В ACM для управления кластерами используется модель «hub-managed» (центральный кластер-управляемые кластеры), где hub – это кластер, на котором выполняется ACM, а managed – это кластеры, которые управляются этой ACM. На хабе используется следующий софт Red Hat:
Обратите внимание, что у managed– кластеров есть разные метки, мы будем ими активно пользоваться при размещении приложений в разных средах.
Как показано на рисунке, у нас есть управляемый development-кластер, который называется managed-cluster1-dev и развернут в облаке AWS в регионе EU. А также есть управляемый production-кластер, который называется managed-cluster2-prod и тоже развернут в AWS, в регионе US.
ACM предлагает обширные возможности для управления жизненным циклом приложений. Здесь мы рассмотрим те из них, что относятся к категории GitOps и пригодятся в следующих сценариях:
Для начала определимся с терминами и концепциями, которые мы будем оперировать в этой статье.
Каналы (Channels)
Каналы указывают на некое физическое место, где хранятся подлежащие развертыванию ресурсы. Здесь мы будем использовать каналы с типом Git, хотя у каналов бывают и другие типы (Helm, Namespaces и т. д.).
Подробнее
Правила размещения (PlacementRules)
Создавая и управляя правилами размещения, вы задаете, куда надо развертывать подписки на Kubernetes-ресурсы и Helm-релизы. Применяя эти правила, можно сильно упростить развертывание Kubernetes-ресурсов в нескольких средах.
Подробнее
Подписки (Subscriptions)
Подписки – это наборы дефиниций для отбора Kubernetes-ресурсов в каналах с помощью аннотаций, меток и версий. Ресурсы подписки задаются на хабе и передаются на управляемые кластеры. Контроллер подписки мониторит локацию-источник (канал) на предмет появления новых или обновленных ресурсов. Когда это происходит, он может скачать соответствующий ресурс напрямую из локации-источника (канала) на управляемый кластер, не проверяя перед этим Hub-кластер (поскольку подписка уже была отправлена).
Подписка может выполнять фильтрацию Helm-релизов для выбора нужной версии chart. В этом случае контроллер подписки смотрит параметр version, чтобы понять, какую версию Helm-релиза (chart) надо взять для развертывания.
Подробнее
Приложения (Applications)
Объект «Приложение» можно рассматривать, как способ агрегирования подписок в группу. Для этого есть соответствующие инструменты и консоль, чтобы выполнять агрегирование и просматривать все компоненты Приложения.
Подробнее
Наши приложения будут развертываться согласно шаблонам GitOps, причем для разных сред понадобятся разные манифесты, которые будут храниться в Git-репозитории, структура которого представлена в таблице ниже:
Примечание. Red Hat ACM никак ограничивает способы структурирования Git-репозитория. Его можно организовать не только так, как показано в этой таблице, но и любым другим удобным для вас образом.
Теперь рассмотрим, как ACM может помочь в развертывании приложения в нескольких средах на примере простого веб-сервиса, который инвертирует слова. У этого сервиса есть два релиза: stage (это версия, которую в данный момент тестируют разработчики) и production (это версия, которой пользуются клиенты).
В ACM есть поддержка Kustomize, что очень сильно облегчает настройку приложений под целевую среду развертывания.
Как уже говорилось, в обеих средах у нас используется одно и то же приложение, но только в разных релизах.
Для развертывания приложения воспользуемся инструментом oc и набором yaml-манифестов с необходимыми конфигурациями для ACM, которые задают Channel, Subscription и PlacementRule. Все, что мы делаем из командной строки, можно сделать и из веб-консоли.
В инструменте oc у нас будет три сконфигурированных контекста, по одному для каждой среды:
Подробнее о CLI-профилях можно прочитать здесь.
Теперь разберем ресурсы, которые будут использоваться в нашем примере:
Channel
Мы задаем Channel как Git с типом Channel, который наши подписки будут использовать для получения Kubernetes-ресурсов, развертывающих наше приложение.
В нашем случае канал сконфигурирован на получение Kubernetes-ресурсов из Git-репозитория github.com/RHsyseng/acm-app-lifecycle-blog.git.
Namespace
Когда мы используем Subscription, пространство имен, содержащее эту подписку передается в целевой кластер развертывания. Поэтому здесь мы создаем пространство имен под названием reverse-words-stage, которое будет передаваться в наши dev-кластеры посредством этой Subscription.
PlacementRule
Список кластеров, куда передаются подписки, берется из того, что возвращает PlacementRule. Иначе говоря, нам нужно как-то выбирать определенные кластеры из наших сред и передавать их различным подпискам, именно эту задачу и решают PlacementRules
В нашем примере PlacementRule с именем development-clusters возвращает все кластеры, помеченные как Available, и с меткой, отвечающей условию environment: dev. То есть в нашем случае на выходе получим управляемый dev-кластер с именем managed-cluster1-dev.
Subscription
В примере выше Subscription отвечает за развертывание списка Kubernetes-ресурсов (берутся из Channel) на кластерах из списка (берется из PlacementRule). Но помимо этого также можно задать, где именно эти Kubernetes-ресурсы располагаются в репозитории Git (канал).
Наша подписка использует Channel, который мы задали выше, и берет Kubernetes-ресурсы из ветки stage, где она ищет их в папке apps/reversewords/.
Application
Application помогает создать топологию нашего приложения на кластерах, управляемых посредством ACM. Для этого Application выполняет отбор одной или более подписок, которые в конечном итоге и создают ресурсы на различных кластерах, поэтому мы можем отследить, кто что создал и где оно создалось.
Примечание. Здесь мы рассмотрели только те ресурсы, которые будут использоваться при развертывании приложения в dev-среде. Ресурсы для других сред можно найти в репозитории на GitHub, они довольно понятны и похожи на уже рассмотренные.
1. Первым делом создаем определение Channel.
2. Затем создаем Namespace для хранения манифестов нашего приложения.
3. Теперь создаем PlacementRule, которое будет отбирать наши управляемые dev-кластера.
Смотрим статус PlacementRule. Обратите внимание, что это правило отобрало управляемый dev-кластер managed-cluster1-dev:
4. Теперь можно создавать Subscription и Application для задания dev-кластера в качестве целевого посредством PlacementRule.
Смотрим статус Subscription. Обратите внимание на слово propagated, оно означает, что подписка была отправлена на целевой кластер:
5. И, наконец, смотрим dev-кластер и видим, что приложение было развернуто и работает.
Если попытаться выполнить запросы к продакшн-кластеру, то мы увидим, что там приложение не запущено.
6. Теперь выполним запрос к нашему приложения и убедимся, что мы развернули нужный релиз, а именно staging:
1. Новый Channel создавать не надо, поскольку в качестве источника мы будем использовать тот же Git-репо, но только другую ветку.
2. Создаем Namespace для хранения манифестов нашего приложения.
3. Теперь создаем PlacementRule, которое отбирает продакшн-кластеры:
Смотрим статус PlacementRule. Обратите внимание, что это правило отобрало управляемый продакшн-кластер managed-cluster2-prod.
4. Теперь можно создавать Subscription и Application для задания продакшн-кластера в качестве целевого посредством PlacementRule.
Смотрим статус Subscription. Обратите внимание на слово propagated, оно означает, что подписка была отправлена на целевой кластер:
5. И, наконец, смотрим продакшн-кластер и видим, что приложение было развернуто и работает.
6. Теперь выполним запрос к нашему приложения и убедимся, что мы развернули нужный релиз, а именно production:
7. Теперь у нас есть разные версии нашего приложения для разных сред развертывания:
И, наконец, посмотрим, как это выглядит в веб-консоли:
ACM Applications General View
ACM Development Application View
В следующем посте мы покажем, как использовать ACM для развертывания по схеме Blue/Green, для миграции приложений, а также для аварийного восстановления.
Сегодня мы сосредоточимся на тех аспектах ACM, которые относятся к категории GitOps, и разберем их, используя следующую модельную конфигурацию:
Итак, у нас здесь три кластера OpenShift. В ACM для управления кластерами используется модель «hub-managed» (центральный кластер-управляемые кластеры), где hub – это кластер, на котором выполняется ACM, а managed – это кластеры, которые управляются этой ACM. На хабе используется следующий софт Red Hat:
| ПО | Версия |
|---|---|
| Red Hat OpenShift Container Platform | 4.5.7 |
| Red Hat Advanced Cluster Management | 2.0 Fix Pack 2.0.2 |
Обратите внимание, что у managed– кластеров есть разные метки, мы будем ими активно пользоваться при размещении приложений в разных средах.
Как показано на рисунке, у нас есть управляемый development-кластер, который называется managed-cluster1-dev и развернут в облаке AWS в регионе EU. А также есть управляемый production-кластер, который называется managed-cluster2-prod и тоже развернут в AWS, в регионе US.
Жизненный цикл приложения
ACM предлагает обширные возможности для управления жизненным циклом приложений. Здесь мы рассмотрим те из них, что относятся к категории GitOps и пригодятся в следующих сценариях:
- Развертывание приложения в нескольких средах.
- Развертывание Blue/Green.
- Миграция приложения.
- Аварийное восстановление
Для начала определимся с терминами и концепциями, которые мы будем оперировать в этой статье.
Каналы (Channels)
Каналы указывают на некое физическое место, где хранятся подлежащие развертыванию ресурсы. Здесь мы будем использовать каналы с типом Git, хотя у каналов бывают и другие типы (Helm, Namespaces и т. д.).
Подробнее
Правила размещения (PlacementRules)
Создавая и управляя правилами размещения, вы задаете, куда надо развертывать подписки на Kubernetes-ресурсы и Helm-релизы. Применяя эти правила, можно сильно упростить развертывание Kubernetes-ресурсов в нескольких средах.
Подробнее
Подписки (Subscriptions)
Подписки – это наборы дефиниций для отбора Kubernetes-ресурсов в каналах с помощью аннотаций, меток и версий. Ресурсы подписки задаются на хабе и передаются на управляемые кластеры. Контроллер подписки мониторит локацию-источник (канал) на предмет появления новых или обновленных ресурсов. Когда это происходит, он может скачать соответствующий ресурс напрямую из локации-источника (канала) на управляемый кластер, не проверяя перед этим Hub-кластер (поскольку подписка уже была отправлена).
Подписка может выполнять фильтрацию Helm-релизов для выбора нужной версии chart. В этом случае контроллер подписки смотрит параметр version, чтобы понять, какую версию Helm-релиза (chart) надо взять для развертывания.
Подробнее
Приложения (Applications)
Объект «Приложение» можно рассматривать, как способ агрегирования подписок в группу. Для этого есть соответствующие инструменты и консоль, чтобы выполнять агрегирование и просматривать все компоненты Приложения.
Подробнее
Git-репозиторий
Наши приложения будут развертываться согласно шаблонам GitOps, причем для разных сред понадобятся разные манифесты, которые будут храниться в Git-репозитории, структура которого представлена в таблице ниже:
| Ветвь | Описание |
|---|---|
| Config | Хранит базовые файлы для приложений, которые применяются во всех средах |
| Prod | Хранит overlay-файлы для приложений, которые применяются в продакшн-средах |
| Stage | Хранит overlay-файлы для приложений, которые применяются в тестовых средах |
Примечание. Red Hat ACM никак ограничивает способы структурирования Git-репозитория. Его можно организовать не только так, как показано в этой таблице, но и любым другим удобным для вас образом.
Развертывание приложения в нескольких средах
Теперь рассмотрим, как ACM может помочь в развертывании приложения в нескольких средах на примере простого веб-сервиса, который инвертирует слова. У этого сервиса есть два релиза: stage (это версия, которую в данный момент тестируют разработчики) и production (это версия, которой пользуются клиенты).
В ACM есть поддержка Kustomize, что очень сильно облегчает настройку приложений под целевую среду развертывания.
Как уже говорилось, в обеих средах у нас используется одно и то же приложение, но только в разных релизах.
Для развертывания приложения воспользуемся инструментом oc и набором yaml-манифестов с необходимыми конфигурациями для ACM, которые задают Channel, Subscription и PlacementRule. Все, что мы делаем из командной строки, можно сделать и из веб-консоли.
В инструменте oc у нас будет три сконфигурированных контекста, по одному для каждой среды:
| Контекст | Описание |
|---|---|
| Hub | CLI-профиль для HUB -кластера (там, где развернут ACM) |
| Dev | CLI-профиль для управляемого development-cкластера (managed-cluster1-dev) |
| Pro | CLI-профиль для управляемого production cluster (managed-cluster2-prod) |
Подробнее о CLI-профилях можно прочитать здесь.
Теперь разберем ресурсы, которые будут использоваться в нашем примере:
Channel
apiVersion: apps.open-cluster-management.io/v1
kind: Channel
metadata:
name: acm-app-lifecycle-blog
namespace: open-cluster-management
spec:
type: Git
pathname: https://github.com/RHsyseng/acm-app-lifecycle-blog.git
Мы задаем Channel как Git с типом Channel, который наши подписки будут использовать для получения Kubernetes-ресурсов, развертывающих наше приложение.
В нашем случае канал сконфигурирован на получение Kubernetes-ресурсов из Git-репозитория github.com/RHsyseng/acm-app-lifecycle-blog.git.
Namespace
apiVersion: v1
kind: Namespace
metadata:
name: reverse-words-stage
Когда мы используем Subscription, пространство имен, содержащее эту подписку передается в целевой кластер развертывания. Поэтому здесь мы создаем пространство имен под названием reverse-words-stage, которое будет передаваться в наши dev-кластеры посредством этой Subscription.
PlacementRule
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
name: development-clusters
namespace: reverse-words-stage
spec:
clusterConditions:
- type: "ManagedClusterConditionAvailable"
status: "True"
clusterSelector:
matchExpressions: []
matchLabels:
environment: "dev"
Список кластеров, куда передаются подписки, берется из того, что возвращает PlacementRule. Иначе говоря, нам нужно как-то выбирать определенные кластеры из наших сред и передавать их различным подпискам, именно эту задачу и решают PlacementRules
В нашем примере PlacementRule с именем development-clusters возвращает все кластеры, помеченные как Available, и с меткой, отвечающей условию environment: dev. То есть в нашем случае на выходе получим управляемый dev-кластер с именем managed-cluster1-dev.
Subscription
apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
name: reversewords-dev-app-subscription
namespace: reverse-words-stage
labels:
app: reversewords-dev-app
annotations:
apps.open-cluster-management.io/git-path: apps/reversewords/
apps.open-cluster-management.io/git-branch: stage
spec:
channel: open-cluster-management/acm-app-lifecycle-blog
placement:
placementRef:
kind: PlacementRule
name: development-clusters
В примере выше Subscription отвечает за развертывание списка Kubernetes-ресурсов (берутся из Channel) на кластерах из списка (берется из PlacementRule). Но помимо этого также можно задать, где именно эти Kubernetes-ресурсы располагаются в репозитории Git (канал).
Наша подписка использует Channel, который мы задали выше, и берет Kubernetes-ресурсы из ветки stage, где она ищет их в папке apps/reversewords/.
Application
apiVersion: app.k8s.io/v1beta1
kind: Application
metadata:
name: reversewords-dev-app
namespace: reverse-words-stage
spec:
componentKinds:
- group: apps.open-cluster-management.io
kind: Subscription
descriptor: {}
selector:
matchExpressions:
- key: app
operator: In
values:
- reversewords-dev-app
Application помогает создать топологию нашего приложения на кластерах, управляемых посредством ACM. Для этого Application выполняет отбор одной или более подписок, которые в конечном итоге и создают ресурсы на различных кластерах, поэтому мы можем отследить, кто что создал и где оно создалось.
Примечание. Здесь мы рассмотрели только те ресурсы, которые будут использоваться при развертывании приложения в dev-среде. Ресурсы для других сред можно найти в репозитории на GitHub, они довольно понятны и похожи на уже рассмотренные.
Развертываем приложение в среде разработки
1. Первым делом создаем определение Channel.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/base/00_channel.yaml
2. Затем создаем Namespace для хранения манифестов нашего приложения.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-stage/00_namespace.yaml
3. Теперь создаем PlacementRule, которое будет отбирать наши управляемые dev-кластера.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-stage/01_placement_rule.yaml
Смотрим статус PlacementRule. Обратите внимание, что это правило отобрало управляемый dev-кластер managed-cluster1-dev:
oc --context hub -n reverse-words-stage get placementrule development-clusters -o yaml
<OMITTED_OUTPUT>
status:
decisions:
- clusterName: managed-cluster1-dev
clusterNamespace: managed-cluster1-dev
4. Теперь можно создавать Subscription и Application для задания dev-кластера в качестве целевого посредством PlacementRule.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-stage/02_subscription-dev.yaml
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-stage/03_application-dev.yaml
Смотрим статус Subscription. Обратите внимание на слово propagated, оно означает, что подписка была отправлена на целевой кластер:
oc --context hub -n reverse-words-stage get subscription reversewords-dev-app-subscription -o yaml
<OMITTED_OUTPUT>
status:
message: Active
phase: Propagated
5. И, наконец, смотрим dev-кластер и видим, что приложение было развернуто и работает.
oc --context dev -n reverse-words-stage get deployments,services,pods
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.extensions/reverse-words 1/1 1 1 73s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/reverse-words LoadBalancer 172.30.217.208 a84668cb23acf4d109a78b119dfddbef-750551.eu-central-1.elb.amazonaws.com 8080:30053/TCP 73s
NAME READY STATUS RESTARTS AGE
pod/reverse-words-68b9b894dd-jfgpf 1/1 Running 0 73s
Если попытаться выполнить запросы к продакшн-кластеру, то мы увидим, что там приложение не запущено.
oc --context pro -n reverse-words-stage get deployments,services,pods
No resources found in reverse-words-stage namespace.
6. Теперь выполним запрос к нашему приложения и убедимся, что мы развернули нужный релиз, а именно staging:
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.3. App version: v0.0.3
Развертываем приложение в продакшн-среде
1. Новый Channel создавать не надо, поскольку в качестве источника мы будем использовать тот же Git-репо, но только другую ветку.
2. Создаем Namespace для хранения манифестов нашего приложения.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-prod/00_namespace.yaml
3. Теперь создаем PlacementRule, которое отбирает продакшн-кластеры:
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-prod/01_placement_rule.yaml
Смотрим статус PlacementRule. Обратите внимание, что это правило отобрало управляемый продакшн-кластер managed-cluster2-prod.
oc --context hub -n reverse-words-prod get placementrule production-clusters -o yaml
<OMITTED_OUTPUT>
status:
decisions:
- clusterName: managed-cluster2-prod
clusterNamespace: managed-cluster2-prod
4. Теперь можно создавать Subscription и Application для задания продакшн-кластера в качестве целевого посредством PlacementRule.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-prod/02_subscription-pro.yaml
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-prod/03_application-pro.yaml
Смотрим статус Subscription. Обратите внимание на слово propagated, оно означает, что подписка была отправлена на целевой кластер:
oc --context hub -n reverse-words-prod get subscription reversewords-pro-app-subscription -o yaml
<OMITTED_OUTPUT>
status:
message: Active
phase: Propagated
5. И, наконец, смотрим продакшн-кластер и видим, что приложение было развернуто и работает.
oc --context pro -n reverse-words-prod get deployments,services,pods
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.extensions/reverse-words 1/1 1 1 93s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/reverse-words LoadBalancer 172.30.100.0 a6067d9a2cd904003a1b53b65f9e1cb3-450574743.us-west-2.elb.amazonaws.com 8080:30293/TCP 96s
NAME READY STATUS RESTARTS AGE
pod/reverse-words-7dd94446c-vkzr8 1/1 Running 0 94s
6. Теперь выполним запрос к нашему приложения и убедимся, что мы развернули нужный релиз, а именно production:
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
7. Теперь у нас есть разные версии нашего приложения для разных сред развертывания:
# Query development environment
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
# Query production environment
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
# Dev Query
Reverse Words Release: Stage Release v0.0.3. App version: v0.0.3
# Pro Query
Reverse Words Release: Production release v0.0.2. App version: v0.0.2
И, наконец, посмотрим, как это выглядит в веб-консоли:
ACM Applications General View
ACM Development Application View
Продолжение следует
В следующем посте мы покажем, как использовать ACM для развертывания по схеме Blue/Green, для миграции приложений, а также для аварийного восстановления.
