GSP053

Présentation

Les équipes DevOps font souvent appel à différents types de déploiements pour gérer divers scénarios de déploiement d'applications, comme les "déploiements continus", les "déploiements bleu-vert" et les "déploiements Canary", entre autres. Au cours de cet atelier, vous vous entraînerez à effectuer le scaling de conteneurs et à les gérer pour apprendre à mettre en place ces scénarios courants composés de plusieurs déploiements hétérogènes.

Objectifs

Dans cet atelier, vous apprendrez à effectuer les tâches suivantes :

• Vous familiariser avec l'outil kubectl
• Créer des fichiers de déploiement YAML
• Lancer, modifier et faire évoluer des déploiements
• Modifier des déploiements et découvrir les styles de déploiements

Prérequis

Pour profiter pleinement de cet atelier de formation, vous devez respecter les recommandations suivantes :

• Vous avez suivi les ateliers Google Cloud Skills Boost suivants :
  • Présentation de Docker
  • Hello Node Kubernetes
• Vous possédez des compétences en administration système sous Linux.
• Vous disposez de connaissances théoriques en DevOps (principes du déploiement continu).

Présentation des déploiements

Les déploiements hétérogènes consistent généralement à connecter au moins deux environnements ou régions ayant des infrastructures distinctes dans le but de répondre à des besoins techniques ou opérationnels spécifiques. Selon leurs spécificités, ces déploiements peuvent être "hybrides", "multicloud" ou "public-privé".

Dans le cadre de cet atelier, nous aborderons des déploiements hétérogènes qui s'étendent sur diverses régions dans un environnement cloud unique, dans plusieurs environnements cloud publics (multicloud) ou dans une combinaison d'environnements sur site et cloud public (hybride ou public-privé).

Différents problèmes d'ordre opérationnel et technique peuvent se présenter lors des déploiements qui se limitent à un environnement ou une région :

• Ressources insuffisantes : dans un environnement donné, en particulier s'il s'agit d'un environnement sur site, les ressources de calcul, de stockage ou réseau disponibles ne suffisent pas toujours à répondre aux besoins de production.
• Portée géographique limitée : dans un environnement unique, des utilisateurs géographiquement éloignés doivent tous accéder au même déploiement. Leur trafic peut être réparti sur toute la planète et converger vers une position centrale.
• Disponibilité restreinte : un trafic à l'échelle du Web exige des applications ayant une certaine tolérance aux pannes et de la résilience.
• Dépendance vis-à-vis d'un fournisseur : les abstractions de plate-forme et d'infrastructure liées à certains fournisseurs peuvent empêcher le portage des applications.
• Manque de flexibilité des ressources : vos ressources peuvent être limitées à un ensemble spécifique de fonctionnalités de calcul, de stockage ou réseau.

Les déploiements hétérogènes peuvent aider à résoudre ces problèmes, à condition d'être structurés par des processus et des procédures programmatiques et déterministes. Les procédures ponctuelles ou ad hoc peuvent donner lieu à des déploiements ou des processus fragiles et peu tolérants aux pannes. Les processus ad hoc peuvent entraîner des pertes de données ou de trafic. Pour être efficaces, les processus de déploiement doivent être reproductibles et mettre en œuvre des méthodes éprouvées de gestion des comptes, de configuration et de maintenance.

Les trois scénarios de déploiement hétérogènes les plus courants sont les déploiements multicloud, les déploiements appliqués à des données sur site, et les processus d'intégration et de livraison continues (CI/CD).

Les exercices suivants illustrent certains cas d'utilisation courants des déploiements hétérogènes, ainsi que des méthodes de déploiement bien structurées basées sur Kubernetes et d'autres ressources d'infrastructure.

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

• vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome) ;

Remarque : Ouvrez une fenêtre de navigateur en mode incognito/navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le temporaire étudiant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

• vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.

Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier afin d'éviter que des frais supplémentaires ne vous soient facturés.

Démarrer l'atelier et se connecter à la console Google Cloud

1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, un pop-up s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau Détails concernant l'atelier, qui contient les éléments suivants :

   • Le bouton Ouvrir la console Google
   • Le temps restant
   • Les identifiants temporaires que vous devez utiliser pour cet atelier
   • Des informations complémentaires vous permettant d'effectuer l'atelier

2. Cliquez sur Ouvrir la console Google. L'atelier lance les ressources, puis ouvre la page Se connecter dans un nouvel onglet.

   Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

   Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.

3. Si nécessaire, copiez le nom d'utilisateur inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue Se connecter. Cliquez sur Suivant.

4. Copiez le mot de passe inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue de bienvenue. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis dans le panneau de gauche. Ne saisissez pas vos identifiants Google Cloud Skills Boost. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

5. Accédez aux pages suivantes :

   • Acceptez les conditions d'utilisation.
   • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
   • Ne vous inscrivez pas aux essais offerts.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Vous pouvez afficher le menu qui contient la liste des produits et services Google Cloud en cliquant sur le menu de navigation en haut à gauche.

Activer Cloud Shell

Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

1. Cliquez sur Activer Cloud Shell  en haut de la console Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Le résultat contient une ligne qui déclare YOUR_PROJECT_ID (VOTRE_ID_PROJET) pour cette session :

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

2. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

3. Cliquez sur Autoriser.

4. Vous devez à présent obtenir le résultat suivant :

Résultat :

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project = <ID_Projet>

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Définir la zone

Exécutez la commande suivante pour définir votre zone Google Cloud de travail, en veillant à remplacer la zone locale par  :

gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}

Télécharger l'exemple de code pour cet atelier

1. Téléchargez l'exemple de code permettant de créer et d'exécuter des conteneurs et des déploiements :

gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes . cd orchestrate-with-kubernetes/kubernetes

2. Créez un cluster avec trois nœuds (cette opération prend quelques minutes) :

gcloud container clusters create bootcamp \ --machine-type e2-small \ --num-nodes 3 \ --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

Tâche 1 : Découvrir l'objet Déploiement

Commencez par examiner l'objet Déploiement.

1. Dans kubectl, la commande explain nous permet d'en savoir plus sur l'objet Déploiement :

kubectl explain deployment

2. Vous pouvez aussi afficher l'ensemble des champs en ajoutant l'option --recursive :

kubectl explain deployment --recursive

3. Vous pourrez utiliser la commande explain tout au long de l'atelier pour comprendre la structure d'un objet Déploiement et voir l'effet des différents champs :

kubectl explain deployment.metadata.name

Tâche 2 : Créer un déploiement

1. Mettez à jour le fichier de configuration deployments/auth.yaml :

vi deployments/auth.yaml

2. Lancez l'éditeur :

i

3. Modifiez le champ image dans la section "containers" du déploiement comme suit :

... containers: - name: auth image: "kelseyhightower/auth:1.0.0" ...

4. Pour enregistrer le fichier auth.yaml, appuyez sur <Échap>, puis saisissez la commande ci-dessous :

:wq

5. Appuyez sur <Entrée>. À présent, créez un déploiement simple. Examinez le fichier de configuration du déploiement :

cat deployments/auth.yaml

Résultat :

apiVersion: apps/v1 kind: Deployment metadata: name: auth spec: replicas: 1 selector: matchLabels: app: auth template: metadata: labels: app: auth track: stable spec: containers: - name: auth image: "kelseyhightower/auth:1.0.0" ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

Notez que le déploiement crée une instance dupliquée et utilise la version 1.0.0 du conteneur auth.

L'exécution de la commande kubectl create pour créer le déploiement auth crée un pod conforme aux données du fichier manifeste du déploiement. Vous pouvez donc faire évoluer le nombre de pods en modifiant le nombre spécifié dans le champ replicas.

6. Créez maintenant votre objet Déploiement avec la commande kubectl create :

kubectl create -f deployments/auth.yaml

7. Vérifiez ensuite que le déploiement a bien été créé :

kubectl get deployments

8. Une fois le déploiement généré, Kubernetes crée un ReplicaSet pour celui-ci. Vous pouvez vérifier si ce ReplicaSet a bien été créé pour le déploiement :

kubectl get replicasets

Vous devriez voir apparaître un ReplicaSet portant un nom du type auth-xxxxxxx.

9. Affichez les pods créés pour le déploiement. Kubernetes crée un pod en même temps que le ReplicaSet :

kubectl get pods

Nous allons maintenant créer un service pour le déploiement auth. Comme vous avez déjà vu les fichiers manifestes des services, nous ne nous pencherons pas en détail sur ce sujet ici.

10. Utilisez la commande kubectl create pour créer le service auth :

kubectl create -f services/auth.yaml

11. Procédez de la même façon pour créer et exposer le déploiement hello :

kubectl create -f deployments/hello.yaml kubectl create -f services/hello.yaml

12. Répétez encore une fois l'opération pour créer et exposer le déploiement frontend :

kubectl create secret generic tls-certs --from-file tls/ kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf kubectl create -f deployments/frontend.yaml kubectl create -f services/frontend.yaml Remarque : Vous avez créé un ConfigMap pour le déploiement frontend.

13. Interagissez avec le déploiement frontend en capturant son adresse IP externe, puis en l'appelant avec curl :

kubectl get services frontend Remarque : Le remplissage du champ d'adresse IP externe pour votre service peut prendre quelques secondes. Ceci est normal. Il vous suffit d'exécuter de nouveau la commande ci-dessus à quelques secondes d'intervalle jusqu'à ce que le champ soit renseigné. curl -ks https://<IP_EXTERNE>

Vous obtenez la réponse "hello".

14. Vous pouvez également associer la fonctionnalité de modélisation de sortie de kubectl à la commande curl, sur une seule ligne :

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

Tester la tâche terminée

Cliquez sur Vérifier ma progression ci-dessous pour valider votre progression dans l'atelier. Si le cluster Kubernetes et les déploiements auth, hello et frontend ont correctement été créés, vous recevrez une note d'évaluation.

Créer un cluster Kubernetes et des déploiements (auth, hello et frontend)

Effectuer le scaling d'un déploiement

Maintenant que vous avez créé le déploiement, vous pouvez effectuer son scaling. Pour ce faire, mettez à jour le champ spec.replicas.

1. Là encore, la commande kubectl explain vous permet de consulter la description de ce champ, si vous le souhaitez :

kubectl explain deployment.spec.replicas

2. La méthode la plus simple pour mettre à jour le champ "replicas" consiste à utiliser la commande kubectl scale :

kubectl scale deployment hello --replicas=5 Remarque : Le lancement des nouveaux pods peut demander environ une minute.

Une fois le déploiement modifié, Kubernetes met automatiquement à jour le ReplicaSet associé et lance les nouveaux pods de façon à obtenir un nombre total de cinq pods.

3. Vérifiez que cinq pods hello sont en cours d'exécution :

kubectl get pods | grep hello- | wc -l

4. Maintenant, effectuez le scaling inverse de l'application :

kubectl scale deployment hello --replicas=3

5. Vérifiez à nouveau que vous avez le bon nombre de pods :

kubectl get pods | grep hello- | wc -l

Vous avez découvert les déploiements Kubernetes, et appris à gérer un groupe de pods et à effectuer son scaling.

Tâche 3 : Effectuer une mise à jour progressive

Dans un déploiement, vous pouvez mettre à jour les images vers une nouvelle version par le biais d'un mécanisme de mise à jour progressive. Ainsi, votre déploiement augmente progressivement le nombre d'instances dupliquées dans le nouveau ReplicaSet qu'il a créé, à mesure qu'il réduit le nombre d'instances dupliquées dans l'ancien ReplicaSet.

Déclencher une mise à jour progressive

1. Pour mettre à jour votre déploiement, exécutez la commande suivante :

kubectl edit deployment hello

2. Modifiez le champ image dans la section "containers" du déploiement comme suit :

... containers: image: kelseyhightower/hello:2.0.0 ...

3. Enregistrez la modification et quittez l'éditeur.

Ensuite, le déploiement modifié est enregistré dans votre cluster et Kubernetes lance une mise à jour progressive.

4. Affichez le nouveau ReplicaSet créé par Kubernetes :

kubectl get replicaset

5. Vous pouvez voir une nouvelle entrée dans l'historique des déploiements :

kubectl rollout history deployment/hello

Suspendre une mise à jour progressive

Si vous constatez des problèmes liés à un déploiement en cours d'exécution, suspendez la mise à jour.

1. Essayez maintenant :

kubectl rollout pause deployment/hello

2. Vérifiez l'état actuel du déploiement :

kubectl rollout status deployment/hello

3. Vous pouvez également le vérifier directement sur les pods :

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Reprendre une mise à jour progressive

Le déploiement est suspendu. Par conséquent, certains pods utilisent la nouvelle version, et d'autres l'ancienne.

1. Poursuivez le déploiement avec la commande resume :

kubectl rollout resume deployment/hello

2. Une fois le déploiement terminé, la commande status devrait afficher le résultat suivant :

kubectl rollout status deployment/hello

Résultat :

deployment "hello" successfully rolled out

Lancer le rollback d'une mise à jour

Supposons qu'un bug ait été détecté dans votre nouvelle version. Tous les utilisateurs connectés aux nouveaux pods rencontreront les problèmes associés à cette nouvelle version.

Dans un tel cas, vous devez revenir à la version précédente pour analyser et corriger la nouvelle version avant de la redéployer.

1. La commande rollout vous permet de lancer un rollback vers la version précédente :

kubectl rollout undo deployment/hello

2. Vérifiez le rollback dans l'historique :

kubectl rollout history deployment/hello

3. Enfin, vérifiez que le rollback vers la version précédente a été effectué pour tous les pods :

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

Parfait. À présent, vous en savez plus sur les mises à jour progressives des déploiements Kubernetes et vous avez appris à mettre à jour des applications sans temps d'arrêt.

Tâche 4 : Effectuer un déploiement Canary

Les déploiements Canary vous permettent de tester un nouveau déploiement en production sur un sous-ensemble d'utilisateurs. Cette technique est idéale pour déployer des modifications auprès d'un petit groupe d'utilisateurs et limiter ainsi les risques associés aux nouvelles versions.

Créer un déploiement Canary

Un déploiement Canary se compose d'un déploiement distinct incluant votre nouvelle version et d'un service qui cible à la fois votre déploiement normal (stable) et votre déploiement Canary.

1. Commencez par créer un déploiement Canary pour la nouvelle version :

cat deployments/hello-canary.yaml

Résultat :

apiVersion: apps/v1 kind: Deployment metadata: name: hello-canary spec: replicas: 1 selector: matchLabels: app: hello template: metadata: labels: app: hello track: canary # Use ver 2.0.0 so it matches version on service selector version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

2. À présent, créez le déploiement Canary :

kubectl create -f deployments/hello-canary.yaml

3. Vous devriez ensuite avoir un déploiement hello et un déploiement hello-canary. Vérifiez-le avec cette commande kubectl :

kubectl get deployments

Sur le service hello, le sélecteur utilisé est app:hello et il se rapporte à la fois aux pods du déploiement de production et du déploiement Canary. Cependant, le déploiement Canary étant associé à un nombre inférieur de pods, il ne sera visible que pour quelques utilisateurs.

Vérifier le déploiement Canary

1. Pour savoir quelle version de hello est diffusée par la requête, exécutez cette commande :

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

2. Si vous exécutez cette commande plusieurs fois, vous verrez que certaines requêtes sont diffusées par hello 1.0.0 et qu'un sous-ensemble d'entre elles (1/4 = 25 %) est diffusé par la version 2.0.0.

Tester la tâche terminée

Cliquez sur Vérifier ma progression ci-dessous pour valider votre progression dans l'atelier. Si le déploiement Canary a correctement été créé, vous recevrez une note d'évaluation.

Déploiement Canary

Déploiements Canary en production – Affinité de session

Au cours de cet atelier, chaque requête envoyée au service Nginx pouvait être diffusée par le déploiement Canary. Cependant, comment faire pour s'assurer qu'un utilisateur ne soit pas affecté par le déploiement Canary ? Cela peut s'avérer utile, par exemple, si vous souhaitez éviter qu'une modification apportée à l'UI d'une application vienne perturber l'utilisateur. Il s'agit alors de maintenir l'association entre l'utilisateur et l'un ou l'autre des déploiements concernés.

Vous pouvez y parvenir en créant un service avec affinité de session, de sorte que la même version soit toujours déployée pour le même utilisateur. Dans l'exemple ci-dessous, le service est le même que précédemment, à l'exception du champ sessionAffinity qui a été ajouté et défini sur la valeur "ClientIP". Ainsi, les requêtes associées à une même adresse IP de client seront toujours envoyées à la même version de l'application hello.

kind: Service apiVersion: v1 metadata: name: "hello" spec: sessionAffinity: ClientIP selector: app: "hello" ports: - protocol: "TCP" port: 80 targetPort: 80

Il aurait été difficile de configurer un environnement permettant de tester cette méthode. Vous n'aurez donc pas à le faire ici. Notez toutefois que vous pouvez utiliser le champ sessionAffinity pour les déploiements Canary en production.

Tâche 5 : Effectuer un déploiement bleu-vert

Les mises à jour progressives sont idéales si vous souhaitez déployer une application en douceur, en limitant au minimum les frais, l'impact sur les performances et les interruptions. Or, il peut parfois s'avérer judicieux de modifier les équilibreurs de charge de sorte qu'ils pointent vers la nouvelle version, mais après son déploiement complet. Si tel est votre cas, optez pour un déploiement bleu-vert.

Pour y parvenir, Kubernetes crée deux déploiements distincts : un "bleu" pour l'ancienne version et un "vert" pour la nouvelle. Votre déploiement hello actuel sera la version "bleue". L'accès aux déploiements se fera via un service agissant comme un routeur. Une fois que la nouvelle version "verte" sera opérationnelle, vous généraliserez son utilisation en mettant à jour le service.

Remarque : L'un des inconvénients majeurs des déploiements bleu-vert est qu'ils nécessitent au moins le double des ressources disponibles dans votre cluster pour héberger votre application. Assurez-vous que vous disposez de suffisamment de ressources dans votre cluster avant de déployer simultanément deux versions de l'application.

Le service

Utilisez le service hello existant, mais modifiez son sélecteur comme suit : app:hello, version: 1.0.0. Ainsi, le sélecteur désignera le déploiement "bleu", mais pas le déploiement "vert" qui est associé à une autre version.

• Commencez par mettre à jour le service :

kubectl apply -f services/hello-blue.yaml Remarque : Ignorez l'avertissement indiquant que le service de ressources/hello est manquant (resource service/hello is missing), car la correction est automatique.

Effectuer une mise à jour par déploiement bleu-vert

Afin de procéder à un déploiement bleu-vert, vous allez créer un déploiement vert pour la nouvelle version. Le déploiement vert met à jour l'étiquette de la version et le chemin d'accès de l'image.

apiVersion: apps/v1 kind: Deployment metadata: name: hello-green spec: replicas: 3 selector: matchLabels: app: hello template: metadata: labels: app: hello track: stable version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 resources: limits: cpu: 0.2 memory: 10Mi livenessProbe: httpGet: path: /healthz port: 81 scheme: HTTP initialDelaySeconds: 5 periodSeconds: 15 timeoutSeconds: 5 readinessProbe: httpGet: path: /readiness port: 81 scheme: HTTP initialDelaySeconds: 5 timeoutSeconds: 1

1. Créez le déploiement vert :

kubectl create -f deployments/hello-green.yaml

2. Une fois que votre déploiement vert a démarré correctement, vérifiez que la version 1.0.0 actuelle est toujours utilisée :

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

3. À présent, mettez à jour le service de sorte qu'il pointe vers la nouvelle version :

kubectl apply -f services/hello-green.yaml

4. Une fois le service mis à jour, le déploiement vert est utilisé immédiatement. Vous pouvez maintenant vérifier que la nouvelle version est utilisée systématiquement :

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Effectuer un rollback bleu-vert

Si nécessaire, vous pouvez effectuer un rollback vers l'ancienne version de la même manière.

1. Pendant l'exécution du déploiement bleu, il vous suffit de mettre à jour le service pour qu'il revienne à l'ancienne version :

kubectl apply -f services/hello-blue.yaml

2. Le rollback est effectué une fois le service mis à jour. Comme tout à l'heure, vérifiez que la bonne version est en cours d'utilisation :

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Bravo ! Vous avez découvert les déploiements bleu-vert et appris à déployer des mises à jour d'applications nécessitant un basculement immédiat entre deux versions.

Félicitations !

Notre atelier pratique sur la gestion des déploiements avec Kubernetes se termine ici. Au cours de cet atelier, vous avez eu l'occasion de pratiquer davantage l'outil de ligne de commande kubectl et différents types de configurations de déploiement par fichiers YAML pour assurer le lancement, la mise à jour et le scaling de vos déploiements. Ces exercices fondamentaux vous permettront de mettre en pratique vos compétences dans vos propres activités DevOps.

Étapes suivantes et informations supplémentaires

• Sur le site Web Google Cloud, vous pouvez en savoir plus sur les sujets suivants :

  • Modèles de déploiement avec Kubernetes
  • Solutions et guides DevOps dans la documentation de Google Cloud

• Sur le site Web Kubernetes, rejoignez la communauté Kubernetes.

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 26 janvier 2024

Dernier test de l'atelier : 14 août 2023

Copyright 2024 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.