[Open source, Git, Виртуализация, Openshift] Red Hat Advanced Cluster Management и управление приложениями, часть 1. Развертывание в нескольких средах
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Мы начинаем серию постов, в которой покажем, как 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, Программирование, C++] Новая функциональность в RESTinio и опять с помощью C++ных шаблонов
- [IT-инфраструктура, DevOps, Openshift] Все об OpenShift Egress. Часть 1
- [Open source, Erlang/OTP, Elixir/Phoenix] Типы, где их не ждали
- [Информационная безопасность, Программирование, Java, GitHub, Софт] Архитектурные подходы к авторизации в серверных приложениях: Activity-Based Access Control Framework
- [Open source, Git, Системы управления версиями, DevOps] Вышел релиз GitLab 13.5 с обновлениями для безопасности мобильных приложений и вики-страницами групп
- [Виртуализация, Разработка под Linux] Linux-контейнеры в паре строчек кода (перевод)
- [Облачные сервисы] Доходы крупнейших облачных провайдеров благодаря коронавирусу выросли на 33%
- [Open source, PHP, Программирование, Компиляторы] ВКонтакте снова выкладывает KPHP
- [Open source, Терминология IT, IT-компании] Google вводит обязательную инклюзивную терминологию во всех своих открытых проектах
- [Виртуализация, Big Data, Хранение данных, Облачные сервисы] Вебинар «Как управляться с большими данными в облаке» 19 ноября от Mail.ru Group
Теги для поиска: #_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
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:26
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Мы начинаем серию постов, в которой покажем, как 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 и пригодятся в следующих сценариях:
Для начала определимся с терминами и концепциями, которые мы будем оперировать в этой статье. Каналы (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 =========== Похожие новости:
Блог компании Red Hat ), #_open_source, #_git, #_virtualizatsija ( Виртуализация ), #_openshift |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:26
Часовой пояс: UTC + 5