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

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

Блог компании Red Hat Open source *Git *Виртуализация *Openshift *
Мы начинаем серию постов, в которой покажем, как Advanced Cluster Management (ACM) предоставляет обширные возможности для управление жизненным циклом приложений, которые должны существовать сразу в нескольких средах, неважно, в облаке или в корпоративном дата-центре.

Сегодня мы сосредоточимся на тех аспектах 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, для миграции приложений, а также для аварийного восстановления.
Теги:
Хабы:
Всего голосов 4: ↑4 и ↓0 +4
Просмотры 1.4K
Комментарии Комментировать

Информация

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