Red Hat Advanced Cluster Management и управление приложениями, часть 1. Развертывание в нескольких средах

Мы начинаем серию постов, в которой покажем, как 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 и пригодятся в следующих сценариях:

• Развертывание приложения в нескольких средах.
• Развертывание Blue/Green.
• Миграция приложения.
• Аварийное восстановление

Для начала определимся с терминами и концепциями, которые мы будем оперировать в этой статье.

Каналы (Channels)

Каналы указывают на некое физическое место, где хранятся подлежащие развертыванию ресурсы. Здесь мы будем использовать каналы с типом Git, хотя у каналов бывают и другие типы (Helm, Namespaces и т. д.).

Подробнее

Правила размещения (PlacementRules)

Создавая и управляя правилами размещения, вы задаете, куда надо развертывать подписки на Kubernetes-ресурсы и Helm-релизы. Применяя эти правила, можно сильно упростить развертывание Kubernetes-ресурсов в нескольких средах.

Подробнее

Подписки (Subscriptions)

Подписки – это наборы дефиниций для отбора Kubernetes-ресурсов в каналах с помощью аннотаций, меток и версий. Ресурсы подписки задаются на хабе и передаются на управляемые кластеры. Контроллер подписки мониторит локацию-источник (канал) на предмет появления новых или обновленных ресурсов. Когда это происходит, он может скачать соответствующий ресурс напрямую из локации-источника (канала) на управляемый кластер, не проверяя перед этим Hub-кластер (поскольку подписка уже была отправлена).

Подписка может выполнять фильтрацию Helm-релизов для выбора нужной версии chart. В этом случае контроллер подписки смотрит параметр version, чтобы понять, какую версию Helm-релиза (chart) надо взять для развертывания.

Подробнее

Приложения (Applications)

Объект «Приложение» можно рассматривать, как способ агрегирования подписок в группу. Для этого есть соответствующие инструменты и консоль, чтобы выполнять агрегирование и просматривать все компоненты Приложения.

Подробнее

Git-репозиторий

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

Примечание. Red Hat ACM никак ограничивает способы структурирования Git-репозитория. Его можно организовать не только так, как показано в этой таблице, но и любым другим удобным для вас образом.

Развертывание приложения в нескольких средах

Теперь рассмотрим, как ACM может помочь в развертывании приложения в нескольких средах на примере простого веб-сервиса, который инвертирует слова. У этого сервиса есть два релиза: stage (это версия, которую в данный момент тестируют разработчики) и production (это версия, которой пользуются клиенты).

В ACM есть поддержка Kustomize, что очень сильно облегчает настройку приложений под целевую среду развертывания.

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

Для развертывания приложения воспользуемся инструментом oc и набором yaml-манифестов с необходимыми конфигурациями для ACM, которые задают Channel, Subscription и PlacementRule. Все, что мы делаем из командной строки, можно сделать и из веб-консоли.

В инструменте oc у нас будет три сконфигурированных контекста, по одному для каждой среды:

Подробнее о 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, для миграции приложений, а также для аварийного восстановления.