Comprendre les stratégies modernes de déploiement d'applications avec Oracle Cloud Infrastructure DevOps
La livraison rapide des logiciels est essentielle à l'exécution efficace de vos applications dans le cloud. Le service Oracle DevOps fournit une plate-forme d'intégration et de déploiement continus aux développeurs que vous pouvez utiliser pour créer, tester et déployer facilement des logiciels et des applications sur Oracle Cloud.
DevOps Les pipelines de création et de déploiement réduisent les erreurs basées sur les modifications et réduisent le temps passé par les clients à créer et à déployer des versions. Le service fournit également des référentiels Git privés pour stocker votre code et prend en charge les connexions aux référentiels de code externes. Que ce soit pour migrer des charges globales vers OCI (à partir de clouds sur site ou autres) ou pour développer de nouvelles applications sur OCI, vous pouvez utiliser le service DevOps afin de simplifier le cycle de vie de distribution des logiciels.
Architecture
Cette architecture de référence décrit deux stratégies de déploiement différentes, la stratégie Blue-Green et la stratégie Canary.
Les stratégies de déploiement sont des modèles et des pratiques qui permettent de modifier ou de mettre à niveau l'application. Elles 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. Les stratégies présentées ici donnent aux clients plus d'options pour effectuer le bon compromis, compte tenu de leurs besoins d'application.
Déploiement bleu-vert
Une stratégie de déploiement bleu-vert permet aux équipes DevOps de publier une nouvelle version de leur application en utilisant deux environnements identiques dans lesquels l'une d'entre elles est active à 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 est disponible pour le débogage des problèmes liés à la version de l'application.
- Il permet des déploiements rapides et sans risque.
- Il offre un mécanisme d'annulation efficace et simple.
- Il s'agit d'un moyen efficace d'orchestrer les tests logiciels A/B.
- Cela nécessite peu ou pas de temps d'arrêt, car la production est toujours assurée par l'un des environnements actifs (contrôlé par un équilibreur de charge).
- L'exécution d'environnements identiques est coûteuse et la maintenance nécessite beaucoup de ressources.
- Lorsque vous gérez une version entre deux environnements identiques, vous devez surveiller étroitement les deux environnements.
- La gestion des dépendances de base de données entre les déploiements peut s'avérer compliquée.
Le schéma suivant illustre une architecture de déploiement bleu-vert :
Description de l'illustration blue-green-deployment.png
Déploiement de 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. Elle permet également d'atténuer les 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.
- Vous pouvez tester deux versions d'application côte à côte avec des utilisateurs réels.
- Aucun temps d'arrêt pour les nouvelles versions.
- Le retour à une version précédente est très facile et présente le moins de risques.
- Le test et la validation d'une nouvelle version à l'échelle peuvent être complexes.
- L'extraction des commentaires des tests des utilisateurs sur une nouvelle version prend beaucoup de temps.
Le schéma suivant illustre une stratégie de déploiement Canary :
Description de l'illustration canary-deployment.png
- 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 requis 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éationLes phases sont des actions individuelles qui ont lieu lors d'une exécution de pipeline. Différentes étapes de construction mentionnées ici sont :
- Etapes de construction gérées : phase de construction gérée permettant de créer et de tester le code source.
- Transmettre la phase d'artefact : phase permettant de propager les sorties de la phase de construction vers différents référentiels, par exemple les images de conteneur vers le référentiel de conteneur ou le 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 le code source avec ces 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. Les étapes de création des déploiements bleu-vert sont les suivantes :
- 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 de déploiement : étape facultative dans laquelle vous pouvez utiliser Functions pour valider les déploiements.
- Contrôle : Approbation : Etape 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 : phase finale, à laquelle le trafic de production passe au dernier environnement déployé.
- Déploiement OKE Canary ou Déploiement de groupe d'instances Canary : phase de déploiement du code mis à jour vers les environnements cible.
- Validation de déploiement : étape facultative dans laquelle vous pouvez utiliser Functions pour valider les déploiements.
- Canary OKE Traffic Shift ou Canary Instance Group Traffic Shift : phase où, en fonction de la limite de rampe (% du trafic à déplacer), vous faites basculer le trafic vers l'environnement Canary.
- Contrôle : Approbation : étape 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, à laquelle le trafic de production passe au 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 les artefacts créés, vous pouvez les télécharger vers ce référentiel. 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
Cet environnement est un ensemble de ressources informatiques dans lesquelles 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.
Recommandations
- Formes de calcul
Cette architecture utilise une image de système d'exploitation Oracle Linux avec une forme flexible E3 ou E4 avec un minimum de ressources pour héberger les hôtes de calcul dans les noeuds de cluster OKE. Si votre application a besoin de plus de mémoire ou de cœurs, vous pouvez choisir une autre forme.
- VCN
Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez de joindre aux sous-réseaux du VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adresses IP privées standard. Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR. Cette architecture utilise un VCN public pour héberger Oracle Container Engine for Kubernetes. Vous pouvez également utiliser un VCN privé. Dans ce cas, utilisez une passerelle NAT pour accorder au cluster l'accès via le réseau Internet public.
- Oracle Container Engine for Kubernetes (OKE)
Cette architecture se déploie sur le cluster OKE en tant qu'environnement cible. Les noeuds de processus actif sont déployés sur un système d'exploitation Oracle Linux E3 ou E4. Cette architecture utilise trois noeuds de processus actif dans le cluster, mais vous pouvez créer jusqu'à 1 000 noeuds sur chaque cluster.
- Groupe d'instances
Si vous choisissez cette architecture à déployer vers un groupe d'instances, une instance Compute avec la forme de votre choix est créée dans la location.
- Registre d'images du conteneur
Cette architecture déploie Registry en tant que registre Docker privé pour une utilisation interne. Les images Docker sont propagées vers et extraites du registre. Vous pouvez également utiliser Registry en tant que registre Docker public pour permettre à tout utilisateur disposant d'un accès Internet et connaissant l'URL appropriée d'extraire des images à partir de référentiels publics dans Oracle Cloud.
- Registre d'artefacts
Cette architecture crée un artefact pour le logiciel et la configuration utilisés par un déploiement de groupe d'instances, OKE et Functions. L'architecture crée un référentiel de registre d'artefacts pour une utilisation interne. Les fichiers binaires logiciels, le texte et les configurations de déploiement sont téléchargés vers et téléchargés à partir du référentiel du registre d'artefacts.
Remarques
Lorsque vous utilisez le service DevOps d'Oracle pour déployer une plate-forme d'intégration et de déploiement continus, tenez compte de ces facteurs.
- Déploiements pris en charge par DevOps
DevOps prend en charge les déploiements vers OKE, les hôtes de calcul et les fonctions. Cette architecture se déploie sur un cluster OKE. Envisagez le déploiement vers d'autres adresses en fonction de vos besoins spécifiques.
- Prise en charge de Linux
Seuls les hôtes Linux sont pris en charge pour les déploiements de groupe d'instances vers les instances Compute.
- artefacts déployés
Les artefacts à déployer avec DevOps doivent se trouver dans un registre d'artefacts OCI ou un référentiel de registre d'images de conteneur.
- Regroupement d'applications
Il est recommandé de regrouper chaque application et tous ses microservices dans un seul projet.
Déployer
Le code Terraform pour cette architecture de référence est disponible sous forme d'exemple de pile dans Oracle Cloud Infrastructure Resource Manager. Vous pouvez également télécharger le code à partir de GitHub et le personnaliser en fonction de vos besoins.
- Déployer à l'aide de l'exemple de pile dans Oracle Cloud Infrastructure Resource Manager :
- Cliquez sur le bouton correspondant à la stratégie de déploiement souhaitée, puis suivez les instructions des étapes 2 à 6 :
Pour... Cliquez... Instances Canary 
Canary OKE Instances bleues-vertes OKE bleu-vert Si vous n'êtes pas encore connecté, entrez les informations d'identification de la location et de l'utilisateur.
- Sélectionnez la région de déploiement de la pile.
- Suivez les invites à l'écran et les instructions pour créer la pile.
- Après avoir créé la pile, cliquez sur Actions Terraform et sélectionnez Plan.
- Attendez que le travail soit terminé et vérifiez le plan.
Pour apporter des modifications, revenez à la page Détails de la pile, cliquez sur Modifier la pile et apportez les modifications requises. Exécutez ensuite à nouveau l'action Plan.
- Si aucune autre modification n'est nécessaire, revenez à la page Détails de la pile, cliquez sur Actions Terraform, puis sélectionnez Appliquer.
- Cliquez sur le bouton correspondant à la stratégie de déploiement souhaitée, puis suivez les instructions des étapes 2 à 6 :
- Effectuer un déploiement à l'aide du code Terraform dans GitHub :
- Accédez à GitHub.
- Clonez ou téléchargez le référentiel sur votre ordinateur local.
- Suivez les instructions du document
README.