Регистрация

[Open source, Git, Виртуализация, Openshift] Red Hat Advanced Cluster Management и управление приложениями, часть 1. Развертывание в нескольких средах

Ответить на тему
Автор Сообщение
news_bot ®

Стаж: 6 лет 8 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
12-Ноя-2020 14:32
Цитировать

Мы начинаем серию постов, в которой покажем, как 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, для миграции приложений, а также для аварийного восстановления.
 ===========
 Источник:
habr.com
===========
Похожие новости: Теги для поиска: #_open_source, #_git, #_virtualizatsija (Виртуализация), #_openshift, #_red_hat, #_open_source, #_acm, #_gitops, #_openshift, #_aws, #_kubernetes, #_helm, #_kustomize, #_github, #_blog_kompanii_red_hat (
Блог компании Red Hat
), #_open_source, #_git, #_virtualizatsija (
Виртуализация
), #_openshift
Профиль  ЛС 
Показать сообщения:     
Ответить на тему

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

Текущее время: 01-Ноя 07:20
Часовой пояс: UTC + 5