Aujourd'hui, nous allons nous concentrer sur les aspects GitOps d'ACM et les décomposer à l'aide de la configuration de modèle suivante:
Nous avons donc trois clusters OpenShift ici. ACM utilise un modèle géré par le concentrateur pour gérer les clusters, où concentrateur est le cluster exécutant ACM et géré les clusters gérés par ACM. Le hub utilise le logiciel Red Hat suivant:
| PAR | Version |
|---|---|
| Plateforme de conteneurs Red Hat OpenShift | 4.5.7 |
| Gestion avancée des clusters Red Hat | 2.0 Groupe de correctifs 2.0.2 |
Veuillez noter que les clusters gérés ont des étiquettes différentes, nous les utiliserons activement lors du placement d'applications dans différents environnements.
Comme le montre la figure, nous avons un cluster de développement géré appelé managed-cluster1-dev déployé dans le cloud AWS dans la région de l'UE. Et il existe également un cluster de production géré appelé managed-cluster2-prod, qui est également déployé sur AWS, dans la région des États-Unis.
Cycle de vie de l'application
ACM offre des fonctionnalités étendues de gestion du cycle de vie des applications. Ici, nous examinerons ceux qui appartiennent à la catégorie GitOps et nous seront utiles dans les scénarios suivants:
- Déployez votre application dans plusieurs environnements.
- Déployez le bleu / vert.
- Migration d'applications.
- Reprise après sinistre
Tout d'abord, définissons les termes et concepts que nous allons exploiter dans cet article.
Canaux Les
canaux pointent vers un emplacement physique où les ressources à déployer sont stockées. Ici, nous utiliserons des tubes de type Git, bien qu'il existe d'autres types de tubes (Helm, Namespaces, etc.).
En savoir plus
PlacementRules
En créant et en gérant des règles de placement, vous définissez où déployer vos abonnements aux ressources Kubernetes et vos versions Helm. En appliquant ces règles, vous pouvez grandement simplifier le déploiement des ressources Kubernetes dans plusieurs environnements.
En savoir plus sur les
abonnements
Les abonnements sont un ensemble de définitions permettant de sélectionner des ressources Kubernetes dans des canaux à l'aide d'annotations, d'étiquettes et de versions. Les ressources d'abonnement sont configurées au niveau du concentrateur et transmises aux clusters gérés. Le contrôleur d'abonnement surveille l'emplacement source (canal) des ressources nouvelles ou mises à jour. Lorsque cela se produit, il peut télécharger la ressource correspondante directement depuis l'emplacement source (canal) vers le cluster géré sans vérifier au préalable le cluster Hub (puisque l'abonnement a déjà été envoyé).
L'abonnement peut filtrer les versions de Helm pour sélectionner la version correcte du graphique. Dans ce cas, le contrôleur d'abonnement examine le paramètre de version pour comprendre quelle version de la version Helm (graphique) doit être utilisée pour le déploiement.
Plus d'
applications
L'objet Application peut être considéré comme un moyen d'agréger les abonnements dans un groupe. Pour cela, il existe des outils appropriés et une console pour agréger et visualiser tous les composants de l'Application.
Plus de détails
Dépôt Git
Nos applications seront déployées selon les modèles GitOps, et pour différents environnements, vous aurez besoin de différents manifestes qui seront stockés dans un référentiel Git, dont la structure est indiquée dans le tableau ci-dessous:
| Branche | La description |
|---|---|
| Config | Stocke les fichiers de base pour les applications utilisées dans tous les environnements |
| Prod | Stocke les fichiers de superposition pour les applications utilisées dans les environnements de production |
| Étape | Stocke les fichiers de superposition pour les applications utilisées dans les environnements de test |
Remarque. Red Hat ACM restreint la manière dont vous structurez votre référentiel Git. Il peut être organisé non seulement comme indiqué dans ce tableau, mais également de toute autre manière qui vous convient.
Déployer l'application dans plusieurs environnements
Voyons maintenant comment ACM peut vous aider à déployer votre application dans plusieurs environnements à l'aide d'un simple service Web qui inverse les mots. Ce service a deux versions: stage (c'est la version que les développeurs testent actuellement) et production (c'est la version que les clients utilisent).
ACM prend en charge Kustomize , ce qui facilite la personnalisation des applications pour l'environnement de déploiement cible.
Comme déjà mentionné, dans les deux environnements, nous utilisons la même application, mais uniquement dans des versions différentes.
Pour déployer l'application, nous utiliserons l'outil oc et un ensemble de manifestes yaml avec les configurations nécessaires pour ACM, qui définissent Channel, Subscription et PlacementRule. Tout ce que nous faisons à partir de la ligne de commande peut être fait à partir de la console Web.
Dans l'outil oc, nous aurons trois contextes configurés, un pour chaque environnement:
| Le contexte | La description |
|---|---|
| Centre | Profil CLI pour le cluster HUB (où ACM est déployé) |
| Dev | Profil CLI pour cluster de développement géré (managed-cluster1-dev) |
| Pro | Profil CLI pour cluster de production géré (managed-cluster2-prod) |
Vous pouvez en savoir plus sur les profils CLI ici .
Regardons maintenant les ressources qui seront utilisées dans notre exemple:
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
Nous définissons Channel comme un Git de type Channel, que nos abonnements utiliseront pour obtenir des ressources Kubernetes déployant notre application.
Dans notre cas, le canal est configuré pour recevoir des ressources Kubernetes du référentiel Git github.com/RHsyseng/acm-app-lifecycle-blog.git.
Espace de noms
apiVersion: v1
kind: Namespace
metadata:
name: reverse-words-stage
Lorsque nous utilisons Subscription, l'espace de noms contenant cet abonnement est transmis au cluster de déploiement cible. Nous créons donc ici un espace de noms appelé reverse-words-stage qui sera poussé vers nos clusters de développement via cet abonnement.
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"
La liste des clusters où les abonnements sont passés est tirée de ce que le PlacementRule renvoie. En d'autres termes, nous devons d'une manière ou d'une autre sélectionner certains clusters de nos environnements et les transférer vers différents abonnements, c'est exactement la tâche que PlacementRules résout.Dans
notre exemple, PlacementRule nommé development-clusters renvoie tous les clusters marqués comme disponibles, et avec une étiquette qui répond à la condition d'environnement : dev. Autrement dit, dans notre cas, la sortie sera un cluster de développement géré nommé managed-cluster1-dev.
Abonnement
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
Dans l'exemple ci-dessus, Subscription est chargé de déployer une liste de ressources Kubernetes (extraites du canal) vers des clusters de la liste (extraites de PlacementRule). Mais en plus de cela, vous pouvez également spécifier où exactement ces ressources Kubernetes se trouvent dans le référentiel Git (canal).
Notre abonnement utilise le canal que nous avons défini ci-dessus et prend les ressources Kubernetes de la branche de scène, où il les recherche dans le dossier 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
L'application permet de créer la topologie de notre application sur des clusters gérés par ACM. Pour ce faire, l'application sélectionne un ou plusieurs abonnements, qui créent finalement des ressources sur différents clusters, afin que nous puissions suivre qui a créé quoi et où il a été créé.
Remarque. Ici, nous n'avons couvert que les ressources qui seront utilisées lors du déploiement d'une application dans un environnement de développement. Les ressources pour d'autres environnements peuvent être trouvées dans le référentiel GitHub et sont assez explicites et similaires à celles que nous avons couvertes.
Déployer l'application dans un environnement de développement
1. La première étape consiste à créer une définition de canal.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/base/00_channel.yaml
2. Ensuite, nous créons un espace de noms pour stocker les manifestes de notre application.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-stage/00_namespace.yaml
3. Nous créons maintenant un PlacementRule qui sélectionnera nos clusters de développement gérés.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-stage/01_placement_rule.yaml
Voir le statut de PlacementRule. Notez que cette règle a sélectionné le cluster managed-cluster1-dev 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. Vous pouvez maintenant créer un abonnement et une application pour cibler le cluster de développement à l'aide de 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
Voir l'état de l'abonnement. Faites attention au mot propagé, cela signifie que l'abonnement a été envoyé au cluster cible:
oc --context hub -n reverse-words-stage get subscription reversewords-dev-app-subscription -o yaml
<OMITTED_OUTPUT>
status:
message: Active
phase: Propagated
5. Enfin, nous examinons le cluster de développement et voyons que l'application a été déployée et fonctionne.
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
Si nous essayons d'exécuter des requêtes vers le cluster de production, nous verrons que l'application n'y est pas exécutée.
oc --context pro -n reverse-words-stage get deployments,services,pods
No resources found in reverse-words-stage namespace.
6. Maintenant, exécutons une requête à notre application et assurez-vous que nous avons déployé la version requise, à savoir la mise en scène:
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
Déployer l'application dans un environnement de production
1. Il n'est pas nécessaire de créer un nouveau canal, puisque nous utiliserons le même dépôt Git que la source, mais seulement une branche différente.
2. Créez un espace de noms pour stocker les manifestes de notre application.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-prod/00_namespace.yaml
3. Nous créons maintenant un PlacementRule qui sélectionne les clusters de production:
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-prod/01_placement_rule.yaml
Voir le statut de PlacementRule. Notez que cette règle a sélectionné le cluster de production 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. Vous pouvez maintenant créer un abonnement et une application pour définir le cluster de production comme cible à l'aide de 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
Voir l'état de l'abonnement. Faites attention au mot propagé, cela signifie que l'abonnement a été envoyé au cluster cible:
oc --context hub -n reverse-words-prod get subscription reversewords-pro-app-subscription -o yaml
<OMITTED_OUTPUT>
status:
message: Active
phase: Propagated
5. Et enfin, nous regardons le cluster de production et voyons que l'application a été déployée et fonctionne.
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. Lançons maintenant une requête à notre application et vérifions que nous avons déployé la version requise, à savoir la 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. Nous disposons désormais de différentes versions de notre application pour différents environnements de déploiement:
# 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
Enfin, voyons à quoi cela ressemble dans la console Web:
Vue générale des applications ACM
Vue de l'application de développement ACM
À suivre
Dans le prochain article, nous vous montrerons comment utiliser ACM pour les déploiements Blue / Green, la migration d'applications et la reprise après sinistre.