Comprendre les stratégies de déploiement

Les architectures décrites dans cet article illustrent comment construire et déployer une application moderne avec des stratégies de déploiement Blue-Green et Canary. Les stratégies de déploiement sont des modèles et des pratiques qui permettent de modifier ou de mettre à niveau l'application. Les stratégies de déploiement permettent aux équipes DevOps de définir la manière dont les applications sont déployées dans l'environnement de production.

Le choix entre différentes stratégies de déploiement permet aux administrateurs d'effectuer le bon compromis entre le risque de déploiement d'une nouvelle version, l'impact de la nouvelle version sur ses utilisateurs et la surcharge d'infrastructure nécessaire à l'implémentation de la stratégie. Nous voulons donner à nos clients plus d'options pour faire le bon compromis compte tenu de leurs besoins d'application.

A propos des déploiements bleus-verts

Avec une stratégie de déploiement bleu-vert, les équipes DevOps veulent publier une nouvelle version de leur application à l'aide de deux environnements identiques dans lesquels l'un d'entre eux est actif à un moment donné. La version actuelle de l'application est provisionnée sur l'environnement actif, tandis que la nouvelle version est déployée sur l'environnement de secours.

Le déploiement vers l'environnement de secours n'a aucune incidence sur l'environnement actif ou le trafic utilisateur. Le pipeline de version DevOps peut exécuter des tests de validation sur la nouvelle version. Une fois approuvé, il est promu en production en basculant simplement le trafic utilisateur vers l'environnement de secours. Ce processus se répétera pour chaque nouvelle version de l'application.

L'avantage principal de cette stratégie est qu'elle offre des capacités de temps d'arrêt quasi nul et de restauration instantanée. En cas de problème avec la nouvelle version, le trafic peut revenir instantanément à la version stable précédente. En outre, l'environnement de secours permet de déboguer les problèmes survenus dans la version de l'application.

Le schéma suivant illustre une architecture de déploiement bleu-vert :

Description de l'illustration blue-green-deployment.png

Comprendre les composants d'un déploiement bleu-vert

L'architecture précédente comporte les composants suivants.

• Région

  Une région OCI est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (dans les pays ou même les continents). L'architecture utilise une seule région.

• Projet DevOps

  Regroupement logique de ressources DevOps nécessaires pour implémenter un workflow d'intégration continue et de déploiement continu. Les ressources DevOps peuvent être des artefacts, des pipelines de build, des pipelines de déploiement, des connexions externes, des déclencheurs et des environnements. Les projets DevOps facilitent la journalisation, la surveillance et les notifications pour toutes vos ressources DevOps.

• Pipeline de build

  Un pipeline de build extrait un ID de validation des référentiels de code source et utilise ce code source pour exécuter les instructions de build. Les pipelines de build définissent un ensemble d'étapes pour le processus de création : création, test et compilation d'artefacts logiciels, distribution d'artefacts aux référentiels OCI et, éventuellement, déclenchement d'un déploiement. Vous définissez le flux et les instructions de l'exécution de build dans le fichier de spécification de build.

• Etapes de création

  Les phases sont des actions individuelles qui ont lieu lors d'une exécution d'un pipeline. Les différentes étapes de construction mentionnées ici sont : Etapes de construction gérées : Phase de construction gérée pour créer et tester le code source. Phase de transmission d'artefacts : phase permettant de propager les sorties de l'étape de création vers différents référentiels. Comme les images de conteneur vers le référentiel de conteneur et le manifeste de déploiement vers le registre d'artefacts. Invoke Deployment : phase permettant d'appeler un pipeline de déploiement une fois les étapes de création terminées, et d'analyser les variables exportées de l'étape de création gérée vers les étapes de pipeline de déploiement.

• Référentiel de code

  Référentiels Git privés hébergés par le service DevOps. Vous pouvez stocker, gérer et développer du code source avec nos référentiels de code DevOps. Pipeline de déploiement Séquence d'étapes permettant de distribuer et de déployer un ensemble d'artefacts vers un environnement cible. Le flux et la logique de votre version logicielle peuvent être contrôlés en définissant des étapes qui peuvent s'exécuter en série ou en parallèle.

• Etapes de déploiement

  Les étapes sont des actions individuelles qui ont lieu lors de l'exécution d'un pipeline. Différentes étapes de construction mentionnées ici sont :

  • Déploiement OKE bleu/vert ou Déploiement de groupe d'instances bleu/vert : phase de déploiement du code mis à jour vers les environnements cible.
  • Validation du déploiement : étape facultative permettant de valider les déploiements (fonctions Via)
  • Contrôle : Approbation : phase de contrôle permettant d'approuver le déploiement dans l'environnement de production cible.
  • Changement de trafic OKE bleu/vert ou Changement de trafic de groupe d'instances bleues/vertes : étape finale dans laquelle le trafic de production sera basculé vers le dernier environnement déployé.

• Artefact DevOps

  Un artefact DevOps est une référence ou un pointeur vers un fichier, un fichier binaire, un package, un manifeste ou une image qui constitue votre application. Lors de la création d'un artefact, informez Oracle DevOps de l'emplacement source de l'artefact réel. DevOps prend en charge le registre d'images de conteneur OCI et les référentiels de registre d'artefacts OCI.

• Référentiel d'artefacts

  Le référentiel d'artefacts crée des référentiels pour regrouper des artefacts similaires. Une fois le référentiel créé, vous pouvez y télécharger des artefacts. Ces artefacts sont un ensemble de fichiers texte, de fichiers binaires et de manifestes de déploiement fournis à l'environnement de déploiement cible. Chaque artefact a un nom, composé de son chemin : version. Le chemin est une chaîne permettant d'organiser les artefacts.

• Services de journalisation et de notification OCI

  Le service OCI Logging stocke les journaux liés au déploiement. La sortie d'exécution du déploiement et les résultats finaux du déploiement sont affichés sous forme d'entrées de journal. Le service Notifications OCI offre une visibilité sur l'état le plus récent du projet de déploiement et de ses ressources et prend toutes les mesures nécessaires. Par exemple, vous êtes averti lorsqu'un événement important, tel qu'une étape d'un pipeline de déploiement en attente d'approbation, est généré. Lorsque vous recevez le message de notification, vous pouvez accéder aux pipelines de déploiement DevOps et approuver la phase.

• Environnements de déploiement

  Un environnement est un ensemble de ressources informatiques d'un client où des artefacts sont déployés. Les environnements peuvent être une fonction, une machine virtuelle de calcul ou une instance Bare Metal, ou un cluster OKE. Le déploiement Blue Green est disponible uniquement avec le cluster OKE et les machines virtuelles de calcul.

Comprendre les avantages et les inconvénients des déploiements verts bleus

Les avantages et les inconvénients de l'utilisation d'une stratégie verte bleue lors du déploiement d'une application moderne sont présentés.

Les avantages des déploiements bleu-vert sont les suivants :

• Les déploiements Blue Green permettent des déploiements rapides et sans risque.
• Ils permettent un mécanisme de restauration simple et efficace.
• Il s'agit d'un moyen efficace d'orchestrer les tests logiciels A/B.
• Aucun ou presque zéro temps d'inactivité car la production est toujours assurée via l'un des environnements actifs (contrairement à un équilibreur de charge).

Les cons de déploiements Blue-Green sont les suivants :

• La maintenance de l'environnement d'un déploiement bleu-vert nécessite un coût intense pour des environnements et des ressources identiques.
• Vous devez surveiller étroitement les deux environnements pour gérer la version entre deux environnements identiques.
• La gestion des dépendances de base de données entre les déploiements est compliquée.

A propos des déploiements Canary

Avec une stratégie de déploiement Canary, la version de l'application est incrémentielle pour un sous-ensemble d'utilisateurs. Initialement, la nouvelle version est déployée dans un environnement canaire sans trafic utilisateur. Le pipeline de version DevOps peut exécuter des tests de validation sur la nouvelle version et, une fois prêt, acheminer uniquement un sous-ensemble d'utilisateurs vers l'environnement canaire.

Cette technique permet à l'équipe DevOps d'évaluer la nouvelle version d'application par rapport au trafic utilisateur réel. Ils peuvent comparer les deux versions d'application côte à côte avant de déployer la nouvelle version vers une base d'utilisateurs plus large. Il offre également une atténuation des risques car la nouvelle version n'est activée que pour un petit sous-ensemble d'utilisateurs. Ces utilisateurs peuvent facilement revenir à la version précédente en cas de problème.

Le schéma suivant illustre une stratégie de déploiement Canary :

Description de l'illustration canary-deployment.png

Comprendre les composants d'un déploiement canaire

L'architecture précédente comporte les composants suivants.

• Région

  Une région OCI est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (dans les pays ou même les continents). L'architecture utilise une seule région.

• Projet DevOps

  Regroupement logique de ressources DevOps nécessaires pour implémenter un workflow d'intégration continue et de déploiement continu. Les ressources DevOps peuvent être des artefacts, des pipelines de build, des pipelines de déploiement, des connexions externes, des déclencheurs et des environnements. Les projets DevOps facilitent la journalisation, la surveillance et les notifications pour toutes vos ressources DevOps.

• Pipeline de build

  Un pipeline de build extrait un ID de validation des référentiels de code source et utilise ce code source pour exécuter les instructions de build. Les pipelines de build définissent un ensemble d'étapes pour le processus de création : création, test et compilation d'artefacts logiciels, distribution d'artefacts aux référentiels OCI et, éventuellement, déclenchement d'un déploiement. Vous définissez le flux et les instructions de l'exécution de build dans le fichier de spécification de build.

• Etapes de création

  Les étapes sont des actions individuelles qui ont lieu lors d'une exécution d'un pipeline. Les différentes étapes de construction mentionnées ici sont les suivantes :

  • Etapes de construction gérées : phase de construction gérée permettant de créer et de tester le code source.
  • Transmettre l'étape des artefacts : étape permettant de propager les sorties de l'étape de construction vers différents référentiels. A l'instar des images de conteneur vers le référentiel de conteneur et du manifeste de déploiement vers le registre d'artefacts.
  • Appeler le déploiement : étape permettant d'appeler un pipeline de déploiement une fois les étapes de création terminées, et d'analyser les variables exportées de l'étape de création gérée vers les étapes de pipeline de déploiement.

• Référentiel de code

  Référentiels Git privés hébergés par le service DevOps. Vous pouvez stocker, gérer et développer du code source avec nos référentiels de code DevOps.

• Pipeline de déploiement

  Séquence d'étapes de distribution et de déploiement d'un ensemble d'artefacts vers un environnement cible. Le flux et la logique de votre version logicielle peuvent être contrôlés en définissant des étapes qui peuvent s'exécuter en série ou en parallèle.

• Etapes de déploiement

  Les étapes sont des actions individuelles qui ont lieu lors de l'exécution d'un pipeline. Différentes étapes de construction mentionnées ici sont :

  • Déploiement OKE Canary ou Déploiement de groupe d'instances Canary : préparation pour déployer le code mis à jour vers les environnements canaries cible.
  • Validation du déploiement : étape facultative permettant de valider les déploiements (fonctions Via)
  • Canary OKE Traffic Shift ou Canary Instance Group Traffic Shift : phase permettant de basculer le trafic vers l'environnement canaire en fonction de la limite de rampe (% du trafic vers le décalage).
  • Contrôle : Approbation : phase de contrôle permettant d'approuver le déploiement dans l'environnement de production cible.
  • Canary Deploy Instance Group Production ou OKE Deploy Production : phase finale de basculement du trafic de production vers le dernier environnement déployé.

• Artefact DevOps

  Un artefact DevOps est une référence ou un pointeur vers un fichier, un fichier binaire, un package, un manifeste ou une image qui constitue votre application. Lors de la création d'un artefact, informez Oracle DevOps de l'emplacement source de l'artefact réel. DevOps prend en charge le registre d'images de conteneur OCI et les référentiels de registre d'artefacts OCI.

• Référentiel d'artefacts

  Le référentiel d'artefacts crée des référentiels pour regrouper des artefacts similaires. Une fois le référentiel créé, vous pouvez y télécharger des artefacts. Ces artefacts sont un ensemble de fichiers texte, de fichiers binaires et de manifestes de déploiement fournis à l'environnement de déploiement cible. Chaque artefact a un nom, composé de son chemin : version. Le chemin est une chaîne permettant d'organiser les artefacts.

• Services de journalisation et de notification OCI

  Le service OCI Logging stocke les journaux liés au déploiement. La sortie d'exécution du déploiement et les résultats finaux du déploiement sont affichés sous forme d'entrées de journal. Le service Notifications OCI offre une visibilité sur l'état le plus récent du projet de déploiement et de ses ressources et prend toutes les mesures nécessaires. Par exemple, vous êtes averti lorsqu'un événement important, tel qu'une étape d'un pipeline de déploiement en attente d'approbation, est généré. Lorsque vous recevez le message de notification, vous pouvez accéder aux pipelines de déploiement DevOps et approuver la phase.

• Environnements de déploiement

  Un environnement est un ensemble de ressources informatiques d'un client où des artefacts sont déployés. Les environnements peuvent être une fonction, une machine virtuelle de calcul ou une instance Bare Metal, ou un cluster OKE. Le déploiement Blue Green est disponible uniquement avec le cluster OKE et les machines virtuelles de calcul.

Comprendre les avantages et les inconvénients des déploiements Canary

Les avantages et les inconvénients de l'utilisation d'une stratégie Canary sont à la fois les suivants lors du déploiement d'une application moderne.

Les avantages des déploiements Canary sont les suivants :

• Il vous permet de tester deux versions d'application côte à côte avec des utilisateurs réels.
• Aucun temps d'inactivité pour la nouvelle version.
• Le retour à une version précédente est très facile et présente le moins de risques.

Les cons de déploiements Canary sont les suivants :

• Le test et la validation de la nouvelle version peuvent s'avérer complexes à grande échelle.
• L'extraction des commentaires hors des tests utilisateur sur une nouvelle version est une tâche chronophage.