Est-ce adapté si je débute complètement ?

Oui. Le programme est conçu pour accompagner les débutants étape par étape.

Faut-il un diplôme ?

Non, seule votre motivation compte.

Combien de temps pour décrocher un job ?

En moyenne entre 3 et 6 mois selon votre implication.

Maîtriser la gestion des applications sur Kubernetes avec Istio - Formation devops, cloud & it : mentorat & emploi garanti

[VIDEO] – Démo : Déploiement Blue/Green

Dans cette démonstration, nous allons observer le fonctionnement d’un déploiement blue/green avec Istio.

Nous allons exécuter deux versions de notre application BookInfo, chacune accessible via des domaines distincts : l’un pour la version de test et l’autre pour la version en production.

Grâce à Istio, nous allons effectuer la transition de la version test vers la version live, et nous verrons également comment inverser le processus si nécessaire.

Étapes à suivre :

Créer un dossier : Créez un dossier nommé Demo 2.
Copier les fichiers : Copiez les fichiers bookinfo.yaml et namespace.yml utilisés dans la démonstration précédente dans le dossier demo2.
Déployer l’application et le namespace : Exécutez la commande suivante pour déployer l’application et le namespace :

				
					kubectl config set-context --current --namespace=bookinfo

Créer et déployer bookinfo-gateway.yaml

				
					apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  # The selector matches the ingress gateway pod labels.
  # If you installed Istio using Helm following the standard documentation, this would be "istio=ingress"
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 8080
      name: http
      protocol: HTTP
    hosts:
    - "*"
---

Ensuite, je vais effectuer un autre déploiement qui ajoutera une nouvelle version de mon application, accessible sous un nom de domaine différent.

Pour cela, créez un fichier nommé productpage-v2.yaml et insérez le code suivant :

				
					apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: bookinfo
  name: productpage-v2
  labels:
    app: productpage
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: productpage
      version: v2
  template:
    metadata:
      labels:
        app: productpage
        version: v2
    spec:
      serviceAccountName: bookinfo-productpage
      containers:
      - name: productpage
        image: sixeyed/examples-bookinfo-productpage-v2:1.18.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  namespace: bookinfo
  name: productpage
spec:
  host: productpage
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  namespace: bookinfo
  name: bookinfo-production
spec:
  hosts:
  - bookinfo.local
  gateways:
  - bookinfo-gateway
  http:
  - route:
    - destination:
        host: productpage
        subset: v1
        port:
          number: 9080
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  namespace: bookinfo
  name: bookinfo-test
spec:
  hosts:
  - test.bookinfo.local
  gateways:
  - bookinfo-gateway
  http:
  - route:
    - destination:
        host: productpage
        subset: v2
        port:
          number: 9080

Une fois ce déploiement effectué, un nouveau pod sera créé pour la version v2 de ma page produit, tandis que le pod existant continuera d’exécuter la version v1.

J’aurai également une DestinationRule configurée comme suit :

				
					---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  namespace: bookinfo
  name: productpage
spec:
  host: productpage
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Et cette configuration est similaire à celle que nous avons utilisée pour notre service interne, notamment pour le composant reviews.

Ici, la DestinationRule s’applique à l’hôte nommé productpage, avec deux sous-ensembles :

v1 sélectionne les Pods portant le label version: v1.
v2 sélectionne les Pods portant le label version: v2.

				
					apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  namespace: bookinfo
  name: bookinfo-test
spec:
  hosts:
  - test.bookinfo.local
  gateways:
  - bookinfo-gateway
  http:
  - route:
    - destination:
        host: productpage
        subset: v2
      port:
        number: 9080

C’est ici que je spécifie le nom de domaine externe public. Comme je fais cela localement plutôt qu’en utilisant un DNS global, j’utilise simplement un nom de domaine local.

Ce VirtualService est associé à mon gateway BookInfo. Lorsque le trafic arrive sur la passerelle Istio, celle-ci récupère l’hôte depuis la requête HTTP pour décider où l’acheminer.

Si l’hôte est bookinfo.local, la requête sera traitée par ce VirtualService, qui dirigera le trafic vers l’hôte interne de la page produit, en sélectionnant le sous-ensemble v1. Ainsi, bookinfo.local sera desservi par mon pod v1.
J’ai également défini un nouveau VirtualService pour rendre la version 2 de mon application accessible sous un nom de domaine différent.

Ce VirtualService peut utiliser le même gateway, car celui-ci écoute tous les hôtes. Le trafic sera redirigé vers ce VirtualService si la requête est adressée à test.bookinfo.local.

Ce VirtualService pointe toujours vers la destination productpage, mais cette fois, il sélectionne le sous-ensemble v2.
Ainsi, une requête envoyée à test.bookinfo.local sera desservie par mon nouveau pod v2.

Ouvrons maintenant le terminal et déployons cette configuration comme d’habitude. Cette action va :

Créer mon nouveau déploiement,
Ajouter ma DestinationRule,
Mettre à jour mon VirtualService existant,
Créer un nouveau VirtualService pour le domaine de test.

				
					kubectl get pods -l app=productpage --show-labels

Je constate que seul le pod v1 de l’application productpage a été créé. Appliquez la configuration de la version v2 avec la commande :

				
					kubectl apply -f productpage-v2.yaml

Vérifions si les v1 et v2 utilisent le même label :

				
					kubectl get pods -l app=productpage --show-labels

Ainsi, pour ma page produit, j’ai un pod v1 et un pod v2.

Ensuite, exécutez la commande suivante :

				
					kubectl describe virtualService bookinfo-production

Le VirtualService de mon site en production utilise le sous-ensemble v1 et est associé à l’hôte bookinfo.local.

Faisons de même pour la version deux : le nom du VirtualService est bookinfo-test.

				
					kubectl describe virtualService bookinfo-test

Le VirtualService de mon site de test utilise le sous-ensemble v2 et écoute les requêtes adressées à test.bookinfo.local.

Ces noms de domaine ne sont pas réels, donc pour tester localement, il est nécessaire de les ajouter au fichier hosts et de les faire pointer vers l’adresse IP de la passerelle Istio.

Sur Windows, ce fichier se trouve dans le dossier System32.
Sur Linux ou Mac, il est situé dans /etc/hosts.

Cela permet simplement de rediriger ces domaines vers ma machine locale, car tout fonctionne à l’intérieur de mon cluster local.

Voici la configuration de mon fichier /etc/hosts :

				
					172.18.0.4 bookinfo.local
172.18.0.4 test.bookinfo.local

Maintenant, si je me rends sur mon site v1, je vois la même application que nous avons utilisée jusqu’à présent. En zoomant un peu, on peut confirmer qu’il s’agit bien de la version 1 de mon application. Rien n’a changé dans mon déploiement d’origine, et j’utilise toujours la version 1 de mon composant reviews.

Cependant, nous y accédons avec un nom de domaine réel, et le trafic passe par le gateway, entre dans le VirtualService, puis applique les DestinationRules.

Si, au lieu de cela, je me rends sur test.bookinfo.local, je vois la version v2, avec un nouveau design.

Tout est donc en place pour mon déploiement blue/green.

Si je souhaite remplacer mon site de test par la version en production, il me suffit de créer un nouveau manifeste nommé productpage-production-to-test.yaml (le site de production), puis d’insérer le code suivant :

				
					apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  namespace: bookinfo
  name: bookinfo-production
spec:
  hosts:
  - bookinfo.local
  gateways:
  - bookinfo-gateway
  http:
  - route:
    - destination:
        host: productpage
        subset: v2
      port:
        number: 9080
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  namespace: bookinfo
  name: bookinfo-test
spec:
  hosts:
  - test.bookinfo.local
  gateways:
  - bookinfo-gateway
  http:
  - route:
    - destination:
        host: productpage
        subset: v1
      port:
        number: 9080

Ce fichier YAML modifie les sous-ensembles (subsets) de chacun de mes VirtualServices. L’idée est de créer un manifeste qui ne change que le bloc de configuration du VirtualService, déployé à l’aide du fichier productpage-v2.yaml. Cela me permet de passer du site de développement au site de production, et inversement.

Le VirtualService du site de production (bookinfo.local) est désormais associé au sous-ensemble v2, correspondant au nouveau déploiement. De son côté, le VirtualService du site de test est modifié pour pointer vers v1. En d’autres termes, les sous-ensembles sont inversés dans mes VirtualServices.

Les Pods restent identiques, les services Kubernetes restent les mêmes. Seul le subset défini dans les VirtualServices a été modifié. Et encore une fois, ce déploiement s’effectue avec une simple commande kubectl apply. Cela ne fait que modifier la configuration des deux VirtualServices.

Si je consulte le VirtualService de production, il écoute toujours sur bookinfo.local, mais redirige maintenant le trafic vers le subset v2. Je peux le constater en naviguant sur le site : le nom d’hôte est le même, mais mon site de production est maintenant sur v2.

Pour revenir au site de test, il suffit d’accéder à http://test.bookinfo/productpage, ce qui nous basculera sur v1.

Aucune définition Kubernetes n’a été modifiée :

Les Pods et les services restent inchangés.
Le déploiement blue/green s’est simplement fait en modifiant les subsets dans les VirtualServices.

Si, après la mise en production de la nouvelle version, le PDG vient me voir en disant qu’il n’aime pas particulièrement le nouveau design, l’ancienne version de mon application tourne toujours, avec la même échelle qu’avant.

Je peux alors revenir à v1 simplement en réinversant les subsets.

Dans ce nouveau manifeste, je fais simplement en sorte que :

Le VirtualService de bookinfo.local revienne au subset v1 (production).
Le site de test repasse sur v2.

Nous pouvons ainsi reprendre la phase de test et affiner le design si nécessaire.

Je vais maintenant inverser à nouveau mon déploiement blue/green.

Créer un manifeste pour basculer la production vers le test

Créez un fichier nommé productpage-test-to-production.yaml et insérez le code suivant :

				
					apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  namespace: bookinfo
  name: bookinfo-production
spec:
  hosts:
  - bookinfo.local
  gateways:
  - bookinfo-gateway
  http:
  - route:
    - destination:
        host: productpage
        subset: v2
        port:
          number: 9080
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  namespace: bookinfo
  name: bookinfo-test
spec:
  hosts:
  - test.bookinfo.local
  gateways:
  - bookinfo-gateway
  http:
  - route:
    - destination:
        host: productpage
        subset: v1
        port:
          number: 9080

Ensuite, déployez avec la commande :

kubectl apply -f

Une fois appliqué, le site de production basculera vers la version 1. Il se peut que cette version soit finalement préférable au nouveau design.

Si vous ne souhaitez pas associer vos déploiements à une version spécifique, tout dépend de la nomenclature de vos subsets et de l’étiquetage de vos pods.

Si je le voulais, je pourrais nommer mes subsets blue et green, ce qui est à l’origine du terme déploiement blue/green.

En conclusion, le processus de déploiement consiste simplement à basculer le site de production du subset blue vers le subset green. Il s’agit essentiellement d’une question de terminologie, et la méthode pour passer de l’un à l’autre reste la même.

Dans cette démonstration, nous avons exploré le déploiement blue/green avec Istio.

L’élément clé de cette approche est de maintenir deux versions de l’application en parallèle. Dans cet exemple, chaque version était accessible sous un nom de domaine distinct. Le basculement entre ces versions est le mécanisme permettant de mettre en production une nouvelle version.

Istio facilite grandement ce processus, car il suffit de définir les règles de routage dans les DestinationRules et les VirtualServices.

Dans le modèle de pods de mes déploiements, j’utilise un label de version, qui est également utilisé dans ma DestinationRule Istio.

Ici, deux subsets sont définis :

Le subset v1 dirige le trafic vers les pods avec le label version v1.
Le subset v2 dirige le trafic vers les pods avec le label version v2.

Deux VirtualServices sont également en place :

L’un pour le site de production.
L’autre pour le site de test.

Ces éléments sont exposés au public, donc nous souhaitons que le trafic externe passe par Istio, qui redirige ensuite les requêtes vers ces VirtualServices via le gateway.

Le gateway est configuré pour écouter tout le trafic HTTP entrant dans le cluster, quel que soit l’hôte. En fonction du nom d’hôte reçu dans la requête, il redirige celle-ci vers le VirtualService de production ou celui de test.

Le basculement blue/green s’effectue simplement en modifiant le subset utilisé par chaque VirtualService.

Lorsque je veux déployer une nouvelle version en production, je modifie simplement le subset utilisé par chaque VirtualService, redirigeant ainsi le trafic vers une autre version de l’application.

Si la nouvelle version a déjà été testée et validée, les pods sont prêts à recevoir du trafic immédiatement.

Les déploiements blue/green offrent une grande amélioration par rapport aux méthodes de déploiement traditionnelles. Cependant, ils ne permettent pas un contrôle très granulaire, car la nouvelle version du site est soit entièrement active, soit non disponible.

Maintenant, modifiez vos VirtualServices pour que :

bookinfo.local pointe vers v1.
test.bookinfo.local pointe vers v2.