Migration vers Google Cloud : passer des déploiements manuels aux déploiements automatisés en conteneurs

Ce document vous aide à planifier et à concevoir un chemin de migration pour passer des déploiements manuels aux déploiements automatisés en conteneurs dans Google Cloud à l'aide d'outils cloud natifs et de services gérés Google Cloud.

Ce document fait partie d'une série :

Ce document vous sera utile si vous envisagez de moderniser vos processus de déploiement, de passer des processus de déploiement manuels aux déploiements automatisés en conteneurs et à une infrastructure en tant que code (Infrastructure as code, IaC), ou encore si vous souhaitez évaluer l'opportunité de la migration et savoir en quoi elle pourrait consister.

Avant de commencer, vous devez évaluer la portée de la migration et l'état de vos processus de déploiement actuels afin de définir vos attentes et vos objectifs. Vous choisissez votre point de départ en fonction de la méthode actuellement utilisée pour déployer vos charges de travail :

  • Déploiement manuel de vos charges de travail
  • Déploiement de vos charges de travail à l'aide d'outils de gestion de la configuration

Passer directement d'un déploiement manuel à un déploiement entièrement automatisé et en conteneurs est une opération complexe. C'est pourquoi nous vous recommandons plutôt de suivre les étapes de migration proposées ci-dessous :

  1. Déployer à l'aide d'outils d'orchestration de conteneurs
  2. Déployer automatiquement
  3. Déployer en appliquant le modèle IaC

Le diagramme suivant illustre le chemin de migration que nous vous proposons :

Chemin de migration permettant de passer des déploiements manuels aux déploiements automatiques.

À chaque étape du processus de migration, vous suivez les phases définies dans l'article Migration vers Google Cloud : premiers pas :

  1. Évaluer et découvrir vos charges de travail.
  2. Planifier et établir les fondations
  3. Déployer vos charges de travail
  4. Optimiser votre environnement et vos charges de travail

Le diagramme suivant illustre les phases de migration de chaque étape.

Chemin de migration en quatre phases.

Le chemin de migration que nous vous proposons est la méthode idéale. Vous pouvez toutefois vous arrêter plus tôt dans ce processus si les avantages du passage à l'étape suivante dépassent largement les coûts de votre cas particulier. Par exemple, si vous n'envisagez pas d'automatiser le déploiement de vos charges de travail, vous pouvez vous arrêter après le déploiement à l'aide des outils d'orchestration de conteneurs. Vous pourrez consulter ce document ultérieurement, dès que vous serez prêt à poursuivre le parcours.

Lorsque vous passez d'une étape de migration à l'autre, une phase de transition vous permet d'utiliser simultanément différents processus de déploiement. Ainsi, vous n'avez pas à choisir une seule option de déploiement pour l'ensemble de vos charges de travail. Par exemple, vous pourriez très bien disposer d'un environnement hybride dans lequel vous gérez votre infrastructure en appliquant le modèle IaC, tout en continuant de déployer vos charges de travail à l'aide des outils d'orchestration de conteneurs.

Passer aux outils d'orchestration de conteneurs

L'une des premières étapes permettant d'abandonner les déploiements manuels consiste à déployer vos charges de travail à l'aide des outils d'orchestration de conteneurs. Au cours de cette étape, vous concevez et mettez en œuvre un processus de déploiement permettant de gérer les charges de travail en conteneurs. Pour ce faire, vous utilisez des outils d'orchestration de conteneurs, tels que Kubernetes.

Si vos charges de travail ne sont pas déjà conteneurisées, leur conteneurisation nécessitera beaucoup d'efforts de votre part. Par ailleurs, toutes les charges de travail ne sont pas adaptées à la conteneurisation. Si vous déployez une charge de travail qui n'est ni cloud native ni prête pour la conteneurisation, cette opération peut s'avérer inutile. De plus, certaines charges de travail ne sont même pas compatibles avec la conteneurisation pour des raisons techniques ou d'attribution de licence.

Évaluer et découvrir vos charges de travail

Pour définir la portée de votre migration, vous devez tout d'abord créer un inventaire qui répertorie les artefacts que vous produisez et déployez actuellement, ainsi que leurs dépendances à d'autres systèmes et artefacts. Pour cela, vous devez faire appel à l'expertise des équipes qui ont conçu et mis en œuvre vos processus actuels de production et de déploiement d'artefacts. Le document intitulé Migration vers Google Cloud : évaluer et découvrir vos charges de travail explique comment évaluer votre environnement lors d'une migration et comment créer un inventaire d'applications.

Pour chaque artefact, vous devez évaluer la couverture de test actuelle. Avant de passer à l'étape suivante, vous devez disposer d'une couverture de test appropriée pour tous vos artefacts. Si vous devez tester et valider manuellement chaque artefact, vous ne pouvez pas bénéficier de l'automatisation. Il est donc recommandé d'adopter une méthode qui met l'accent sur l'importance des tests, telle que le développement basé sur les tests.

Lorsque vous évaluez vos procédures, tenez compte du nombre de versions différentes de vos artefacts en production. Par exemple, si la dernière version d'un artefact dépasse de plusieurs versions celle des instances que vous devez gérer, il vous faudra concevoir un modèle compatible avec les deux versions.

Pensez également à la stratégie d'embranchement que vous utilisez pour gérer votre codebase. Elle ne constitue qu'une partie du modèle de collaboration à évaluer. En effet, l'évaluation doit également porter sur les processus de collaboration plus larges qui existent aussi bien au sein de vos équipes qu'en dehors. Par exemple, si vous adoptez une stratégie d'embranchement flexible sans toutefois l'adapter au processus de communication, l'efficacité des équipes peut se trouver réduite.

Dans cette phase d'évaluation, vous déterminez également comment procéder pour que les artefacts que vous produisez soient plus efficaces et mieux adaptés à la conteneurisation que vos processus de déploiement actuels. Une façon d'améliorer l'efficacité consiste à évaluer les éléments suivants :

  • Les ressources communes : évaluez les ressources partagées par vos artefacts. Par exemple, si vous disposez de bibliothèques communes et d'autres dépendances d'environnement d'exécution, envisagez de les regrouper dans un seul environnement d'exécution.
  • Les exigences concernant l'environnement d'exécution : déterminez si vous pouvez rationaliser les environnements d'exécution afin de minimiser leur variance. Par exemple, si toutes vos charges de travail s'exécutent dans différents environnements d'exécution, envisagez de partir d'une base commune afin d'alléger les opérations de maintenance.
  • Les composants inutiles : déterminez si vos artefacts contiennent des composants inutiles. Par exemple, il pourrait exister des utilitaires, tels que les outils de débogage et de dépannage, qui ne sont pas strictement nécessaires.
  • L'injection de fichiers de configuration et de secrets : évaluez la configuration de vos artefacts en fonction des exigences de votre environnement d'exécution. Votre système d'injection de fichiers de configuration actuel n'est peut-être pas compatible avec un environnement conteneurisé.
  • Les exigences de sécurité : déterminez si votre modèle de sécurité de conteneur répond à vos exigences. Le modèle de sécurité d'un environnement conteneurisé peut entrer en conflit avec une charge de travail qui nécessite des droits de super-utilisateur, d'accès direct aux ressources système ou de location unique.
  • Les exigences de logique de déploiement : déterminez si vous devez mettre en œuvre des logiques de déploiement enrichies. Si vous devez mettre en œuvre un processus de déploiement canari, vous pourriez déterminer si l'outil d'orchestration de conteneur est compatible avec cette fonctionnalité.

Planifier et établir les fondations

À présent, vous allez provisionner et configurer l'infrastructure et les services Google Cloud pour assurer la compatibilité avec vos processus de déploiement sur Google Cloud. Le document intitulé Migration vers Google Cloud : établir les fondations fournit des conseils sur la façon de procéder.

Lorsque vous créez des organisations, des dossiers et des projets Google Cloud, tenez compte du fait que les processus de déploiement sont partagés entre plusieurs environnements. Nous recommandons une hiérarchie axée sur la fonction ou une hiérarchie axée sur l'accès précis. Les deux vous offrent la flexibilité nécessaire pour gérer vos ressources et la possibilité de disposer de plusieurs environnements de développement et de test.

Lorsque vous déterminez les identités des utilisateurs et des services, vous devez disposer d'au moins un compte de service pour chaque étape du processus de déploiement. Par exemple, si votre processus exécute les étapes de production d'artefact et de gestion de l'espace de stockage de cet artefact dans un dépôt, vous devez disposer d'au moins deux comptes de service. Si vous souhaitez provisionner et configurer des environnements de développement et de test pour vos processus de déploiement, il vous sera peut-être nécessaire de créer d'autres comptes de service. Si vous disposez d'un ensemble distinct de comptes de service pour chaque environnement, vous devez dissocier les environnements de sorte qu'ils soient indépendants les uns des autres. Bien que cette configuration augmente la complexité de votre infrastructure ainsi que le travail de votre équipe chargée des opérations, elle vous permet de tester et de valider chaque modification des processus de déploiement de manière indépendante.

Vous devez également provisionner et configurer les services et l'infrastructure de sorte qu'ils soient compatibles avec vos charges de travail conteneurisées :

Grâce aux outils d'orchestration de conteneurs, vous n'avez pas à vous soucier du provisionnement de votre infrastructure lorsque vous déployez de nouvelles charges de travail. Vous pouvez, par exemple, vous servir de l'autoscaler de cluster pour redimensionner automatiquement votre cluster GKE si nécessaire.

Déployer vos artefacts à l'aide des outils d'orchestration de conteneurs

Selon les exigences que vous avez déterminées lors des phases d'évaluation et d'établissement des fondations de cette étape, vous pouvez exécuter les tâches suivantes :

  • Conteneuriser vos charges de travail.
  • Mettre en œuvre des procédures de déploiement pour gérer vos charges de travail conteneurisées.

La conteneurisation de vos charges de travail n'est pas une tâche ordinaire. Vous trouverez ci-dessous une liste générale des activités à adapter et à étendre afin de conteneuriser vos charges de travail. L'objectif consiste à répondre à vos propres besoins, par exemple, en termes de mise en réseau, de gestion du trafic, de stockage persistant, d'injection de secrets et de fichiers de configuration, ou encore de tolérance aux pannes. Ce document décrit deux activités : la création d'un ensemble d'images de conteneurs qui vous servira de base et la création d'un ensemble d'images de conteneurs pour vos charges de travail.

Tout d'abord, vous devez automatiser la production d'artefacts pour ne pas avoir à créer manuellement une image pour chaque nouveau déploiement. Le processus de compilation d'artefacts doit se déclencher automatiquement à chaque modification du code source. Ainsi, vous recevrez immédiatement un commentaire sur chaque modification.

Pour chaque image à créer, procédez comme suit :

  1. Créer l'image.
  2. Exécuter la suite de tests.
  3. Stocker l'image dans un registre.

Par exemple, vous pouvez vous servir de Cloud Build pour compiler vos artefacts, les tester en exécutant les suites de tests et, en cas de réussite, stocker les résultats dans Container Registry.

Vous devez également établir des règles et des conventions permettant d'identifier vos artefacts. Lorsque vous créez des images, attribuez-leur un libellé afin que chaque exécution de vos processus soit reproductible. Par exemple, une convention courante consiste à identifier les versions à l'aide de la gestion sémantique des versions. Cette méthode ajoute un tag à vos images de conteneur au moment de la production d'une version. Lorsque vous créez des images que vous devrez encore travailler avant de les publier, vous pouvez les lier, à l'aide d'un identifiant, au point dans le codebase à partir duquel votre processus les a générées. Par exemple, si vous utilisez des dépôts Git, le hachage de commit vous permet d'identifier l'image de conteneur correspondante créée lors de l'envoi du commit à la branche principale de votre dépôt.

Au cours de la phase d'évaluation de cette étape, vous avez recueilli des informations sur vos artefacts, leurs composants communs et leurs exigences d'exécution. Grâce à ces informations, vous pouvez concevoir et créer un ensemble d'images de conteneurs de base ainsi qu'un ensemble d'images supplémentaire pour vos charges de travail. Les images de base vous serviront de point de départ pour créer les images de vos charges de travail. L'ensemble des images de base devrait être étroitement contrôlé et permettre d'éviter la prolifération d'environnements d'exécution non compatibles.

Lorsque vous créez des images de conteneurs à partir d'images de base, pensez à étendre vos suites de tests à chaque image et pas seulement à leurs charges de travail. Des outils tels que InSpec, ServerSpec et RSpec vous permettront d'exécuter des suites de tests de conformité sur vos environnements d'exécution.

Lorsque vous avez conteneurisé vos charges de travail et mis en œuvre des procédures de génération automatique d'images de conteneurs, vous devez mettre en œuvre les procédures de déploiement. Au cours de la phase d'évaluation, vous concevez des procédures de déploiement enrichies en vous appuyant sur les informations recueillies concernant les exigences de logique de déploiement. Les outils d'orchestration de conteneurs vous permettent de vous concentrer sur la composition de la logique de déploiement à l'aide des mécanismes fournis plutôt que sur leur mise en œuvre manuelle.

Lorsque vous concevez et mettez en œuvre des procédures de déploiement, pensez à déterminer comment injecter des fichiers de configuration et des secrets dans vos charges de travail, et comment gérer les données des charges de travail avec état. L'injection de fichiers de configuration et de secrets est essentielle à la production d'artefacts immuables. Le déploiement d'artefacts immuables vous permet d'effectuer les opérations suivantes :

  • Par exemple, vous pouvez commencer par déployer vos artefacts dans votre environnement de développement. Puis, après les avoir testés et validés, vous les déplacez vers votre environnement d'assurance qualité. Enfin, vous pouvez les déplacez vers l'environnement de production.
  • Cela vous permet de minimiser le risque de rencontrer des problèmes dans vos environnements de production étant donné que le même artefact a fait l'objet de plusieurs opérations de test et de validation.

Si vous déployez des charges de travail avec état, nous vous recommandons de provisionner et de configurer un espace de stockage persistant approprié aux données. Pour ce faire, Google Cloud, vous offre plusieurs options :

Une fois en mesure de produire automatiquement les artefacts à déployer, vous pouvez configurer les environnements d'exécution des outils utilisés pour déployer vos charges de travail. Pour contrôler l'environnement d'exécution de ces outils, vous pouvez le configurer en tant que compilation dans Cloud Build et l'utiliser comme seul moyen de déployer les artefacts dans vos environnements. Grâce à Cloud Build, il n'est pas nécessaire que chaque opérateur configure un environnement d'exécution sur ses machines. Vous pouvez immédiatement auditer la procédure qui crée l'environnement d'exécution et son contenu en inspectant le code source de la configuration de compilation.

Optimiser votre environnement

Après avoir mis en œuvre votre processus de déploiement, vous pouvez commencer à l'optimiser à l'aide des outils d'orchestration de conteneurs. Le document intitulé Migration vers Google Cloud : premiers pas fournit des conseils sur la façon de procéder.

L'itération d'optimisation requiert les tâches suivantes :

  • Étendre le système de surveillance si nécessaire.
  • Étendre la couverture de test.
  • Renforcer la sécurité de votre environnement.

Vous devez étendre le système de surveillance de sorte qu'il couvre la production de nouveaux artefacts, vos procédures de déploiement, ainsi que tous vos nouveaux environnements d'exécution.

Si vous souhaitez surveiller, automatiser et codifier vos processus aussi efficacement que possible, nous vous recommandons d'élargir la couverture de vos tests. Lors de la phase d'évaluation, vous avez vérifié que vous disposez au minimum d'une couverture de test de bout en bout. Au cours de la phase d'optimisation, vous êtes en mesure d'étendre vos suites de tests afin de couvrir davantage de cas d'utilisation.

Enfin, si vous souhaitez renforcer la sécurité de vos environnements, vous pouvez configurer l'autorisation binaire afin d'autoriser le déploiement d'un ensemble d'images signées dans vos clusters. Vous pouvez également activer la fonctionnalité Container Analysis afin de rechercher les failles éventuelles des images de conteneurs stockées dans Container Registry.

Passer aux déploiements automatiques

Après être passé aux outils d'orchestration de conteneurs, vous êtes en mesure d'automatiser tous vos déploiements, y compris vos charges de travail en étendant les procédures de production et de déploiement des artefacts.

Évaluer et découvrir vos charges de travail

En vous appuyant sur l'évaluation précédente, vous pouvez maintenant vous concentrer sur les exigences de vos processus de déploiement :

  • Procédures d'approbation manuelle : déterminez si vous devez prévoir des étapes manuelles dans vos procédures de déploiement.
  • Unités de déploiement par heure : déterminez le nombre d'unités de déploiement par heure dont vous avez besoin.
  • Facteurs déclencheurs de déploiement : identifiez les systèmes externes qui interagissent avec vos procédures de déploiement.

Si vous devez prévoir des étapes de déploiement manuel, cela ne signifie pas pour autant que votre procédure ne peut pas être automatisée. Dans ce cas, vous automatisez chaque étape de la procédure en plaçant des points d'approbation manuelle là où cela est nécessaire.

La gestion de plusieurs déploiements par jour ou par heure est plus complexe que lorsque vous effectuez quelques déploiements par mois ou par an. Toutefois, une fréquence de déploiement peu élevée risque de réduire votre agilité et votre capacité à réagir aux problèmes et à intégrer de nouvelles fonctionnalités dans vos charges de travail. C'est pourquoi il est judicieux de définir vos attentes et vos objectifs avant de concevoir et de mettre en œuvre une procédure de déploiement entièrement automatisée.

Par ailleurs, vous devez également déterminer les facteurs qui déclenchent un nouveau déploiement dans vos environnements d'exécution. Par exemple, vous pourriez déployer chaque nouvelle version dans votre environnement de développement, mais déployer une version dans votre environnement d'assurance qualité uniquement si elle répond à certains critères.

Planifier et établir les fondations

Pour étendre les fondations établies à l'étape précédente, vous pouvez provisionner et configurer des services compatibles avec vos procédures de déploiement automatisé.

Pour chacun de vos environnements d'exécution, configurez une infrastructure compatible avec vos procédures de déploiement. Par exemple, si vous souhaitez avoir la possibilité de tester librement les modifications apportées à vos procédures de déploiement, vous pouvez les provisionner et les configurer dans vos environnements de développement, d'assurance qualité, de préproduction et de production. D'un autre côté, si vous déployez vos environnements d'exécution dans une infrastructure unique, il sera plus facile de les gérer, mais vous perdrez en flexibilité lorsque vous devrez modifier les procédures.

Lorsque vous provisionnez les comptes de service et les rôles, pensez à isoler vos environnements et vos charges de travail les uns des autres en créant des comptes de service dédiés avec des responsabilités distinctes. Par exemple, ne réutilisez pas les mêmes comptes de service pour vos différents environnements d'exécution.

Déployer vos artefacts à l'aide de procédures entièrement automatisées

Au cours de cette phase, vous configurez vos procédures de façon à déployer vos artefacts sans aucune intervention manuelle, excepté aux étapes d'approbation.

Des outils tels que Spinnaker vous permettront de mettre en œuvre vos procédures de déploiement automatisées en fonction des besoins que vous avez déterminés à la phase d'évaluation de cette étape du processus de migration.

Pour chaque artefact donné, chaque procédure de déploiement doit exécuter les tâches suivantes :

  1. Déployer l'artefact dans l'environnement d'exécution cible.
  2. Injecter des fichiers de configuration et des secrets dans l'artefact déployé.
  3. Exécuter la suite de tests de conformité sur l'artefact nouvellement déployé.
  4. Promouvoir l'artefact dans l'environnement de production.

Assurez-vous d'intégrer à vos procédures de déploiement des interfaces permettant de déclencher de nouveaux déploiements en fonction de vos besoins.

Lorsque vous mettez en œuvre des procédures de déploiement automatisées, l'examen du code est une étape nécessaire en raison de la courte boucle de rétroaction inhérente à leur conception. Si vous déployez des modifications dans votre environnement de production sans examiner le code, vous risquez d'affecter la stabilité et la fiabilité de votre environnement de production. Une modification non examinée, non valide ou malveillante peut entraîner une interruption du service.

Optimiser votre environnement

Une fois vos procédures de déploiement automatisées, vous pouvez effectuer une autre itération d'optimisation. Cette itération requiert les tâches suivantes :

  • Étendre le système de surveillance à l'infrastructure qui gère vos procédures de déploiement automatisées.
  • Mettre en œuvre des modèles de déploiement plus avancés.
  • Mettre en œuvre une procédure bris de glace.

Un système de surveillance efficace vous permet de planifier des optimisations supplémentaires pour votre environnement. Lorsque vous évaluez le comportement de votre environnement, vous pouvez identifier les goulots d'étranglement qui nuisent à vos performances, ainsi que d'autres problèmes tels que les accès ou les exploitations non autorisés ou accidentels. Par exemple, vous pouvez configurer votre environnement de manière à recevoir des alertes lorsque la consommation de certaines ressources atteint un seuil prédéfini.

Lorsque vous êtes en mesure d'orchestrer efficacement les conteneurs, vous pouvez mettre en œuvre des modèles de déploiement avancés en fonction de vos besoins. Par exemple, pour améliorer la fiabilité de votre environnement et minimiser l'impact sur vos utilisateurs, vous pouvez effectuer des déploiements Canary et des déploiements bleu-vert.

Compte tenu de la nature entièrement automatisée du processus de déploiement, nous vous recommandons de concevoir et de mettre en œuvre une procédure dite "bris de glace". Cela vous permet d'interagir avec vos environnements d'exécution sans passer par les procédures de déploiement habituelles. Toutefois, cette procédure ne doit être appliquée que dans des circonstances exceptionnelles et à condition d'avoir été préapprouvée par les responsables de votre équipe. Dans le cas où un problème lié à votre procédure de déploiement vous interdit l'accès à votre environnement, la procédure "bris de glace" vous permet d'annuler la modification à l'origine du problème.

Adopter l'infrastructure en tant que code

Maintenant que vos équipes savent tirer parti de Google Cloud, vous pouvez appliquer le modèle IaC (Infrastructure en tant que code). L'IaC est un processus qui vous permet d'appréhender le provisionnement des ressources dans un environnement d'exécution de la même façon que la gestion du code source de vos charges de travail.

Évaluer et découvrir votre infrastructure

Au cours de cette phase d'évaluation, vous obtenez des informations détaillées sur l'infrastructure provisionnée aux étapes précédentes du processus de migration, par exemple :

  • Les ressources Google Cloud que vous avez configurées dans le cadre de votre infrastructure
  • Les processus de gestion du changement actuellement mis en œuvre
  • Les membres de votre organisation autorisés à modifier votre infrastructure

Pour adopter le modèle IaC, il est essentiel de disposer d'un inventaire des ressources actuellement utilisées dans votre infrastructure, car cette étape de migration consiste à les décrire avec du code.

De plus, un processus de gestion du changement est essentiel pour gérer l'évolution de votre infrastructure. Si vous disposez d'un tel processus, vous devez l'adapter pour gérer l'IaC. Dans le cas contraire, vous aurez l'occasion d'en concevoir un et de le mettre en œuvre dans cette phase. Un processus de gestion du changement doit tout au moins inclure une phase d'examen au cours de laquelle vous analysez les modifications proposées. Cette analyse, ainsi que l'évaluation des membres de l'équipe autorisés à modifier votre infrastructure, est nécessaire pour réduire les risques de temps d'arrêt ou de facturation de frais imprévus.

Planifier et établir les fondations

En vous appuyant sur les fondations établies à l'étape précédente, vous devez provisionner et configurer l'infrastructure de façon à permettre l'adoption de l'IaC.

Tout d'abord, vous devez choisir les outils que vous allez adopter. Vous trouverez ci-dessous quelques-uns des outils couramment utilisés sur Google Cloud :

  • Deployment Manager : un service géré entièrement compatible avec toutes les ressources Google Cloud.
  • Terraform : un outil de gestion des comptes Open Source compatible avec Google Cloud et les autres fournisseurs cloud.
  • Chef, Puppet et Ansible : des outils de configuration Open Source compatibles avec Google Cloud.

Une fois que vous avez choisi vos outils IaC, vous devez provisionner et configurer toute l'infrastructure nécessaire à leur gestion. Pour ce faire, vous devez tout au moins disposer des éléments suivants :

  • Dépôts de code source pour gérer les descripteurs de vos ressources ainsi que leurs versions
  • Outil d'analyse de code permettant d'examiner et d'approuver chaque modification avant qu'elle ne prenne effet
  • Environnement d'exécution permettant d'exécuter l'outil IaC une fois les modifications approuvées par vos équipes au terme de leur examen

Certains outils IaC nécessitent des services pour gérer votre infrastructure. Par exemple, si vous souhaitez gérer votre infrastructure en collaboration avec d'autres membres de votre organisation, Terraform requiert un espace de stockage de données à distance.

Si vous choisissez de gérer ces fondations à l'aide d'un outil IaC, nous vous recommandons d'effectuer des sauvegardes afin d'éviter toute perturbation lors de l'application des modifications. En effet, ces perturbations peuvent entraîner des temps d'arrêt prolongés et des pertes de données irréversibles. Si vous supprimez accidentellement les dépôts de code source dans lesquels vous stockez vos descripteurs d'infrastructure, vous risquez de perdre des données que vous ne pourrez pas récupérer. Par ailleurs, des outils tels que les liens vous permettent d'empêcher la suppression de projets.

Provisionner des ressources Google Cloud avec l'IaC

Lorsque l'environnement Google Cloud est prêt, vous pouvez adopter l'IaC pour gérer les ressources de votre environnement :

  • Décrire vos ressources existantes avec du code.
  • Provisionner de nouvelles ressources avec l'IaC.

Lors des précédentes étapes de migration, vous avez provisionné des ressources Google Cloud à l'aide de Cloud Console, du SDK Cloud ou des API Cloud. Au cours de cette phase, vous allez décrire ces ressources avec du code, en suivant la syntaxe et les conventions de l'outil IaC que vous avez choisi.

Pour que l'outil IaC puisse identifier vos ressources et instances actuelles, vous devrez peut-être les importer dans son inventaire. L'outil IaC que vous choisissez ne contient aucune information sur leur état. Vous devez donc soit importer les ressources, soit les détruire manuellement et laisser l'outil IaC les créer de nouveau. L'outil Terraform, entre autres, peut importer votre infrastructure existante.

Si vous devez définir de nouveaux composants dans votre infrastructure, vous les décrivez directement avec du code, sans passer par d'autres procédures de provisionnement.

Optimiser votre environnement

Après avoir adopté l'IaC, vous pouvez exécuter une autre itération d'optimisation. Cette itération requiert les tâches suivantes :

  • Étendre le système de surveillance si nécessaire.
  • Étendre les suites de test pour couvrir votre infrastructure.
  • Automatiser le provisionnement et la configuration de votre infrastructure.
  • Étendre la procédure bris de glace pour couvrir votre infrastructure.

En vous appuyant sur les actions effectuées à la phase de déploiement précédente et à la phase d'optimisation de l'étape de migration précédente, étendez la surveillance à l'infrastructure permettant l'adoption de l'IaC. Ainsi, vous pouvez surveiller tous les environnements d'exécution dans lesquels vos outils IaC s'exécutent et consigner précisément chaque exécution afin de créer une piste d'audit que vous pourrez consulter ultérieurement.

Vous pouvez étendre vos suites de tests de façon à couvrir l'infrastructure, et pas seulement vos charges de travail et vos images de conteneurs. Des outils tels que InSpec, ServerSpec et RSpec permettent d'exécuter des suites de tests de conformité pour les environnements d'exécution. Vous avez également la possibilité de protéger votre infrastructure contre les modifications manuelles ou externes de votre pipeline IaC. L'exécution continue des suites de tests sur votre infrastructure vous permet de détecter les modifications non autorisées et de corriger la situation.

Une fois certain d'avoir correctement mis en oeuvre l'IaC, vous pouvez envisager d'automatiser le provisionnement de votre infrastructure en concevant et en mettant en œuvre de nouvelles procédures. Ces nouvelles procédures de provisionnement de l'infrastructure diffèrent considérablement de celles que vous utilisez pour produire et déployer vos artefacts. En effet, elles sont conçues pour gérer les modifications apportées à votre infrastructure, et non à votre application. C'est pour cette raison qu'elles résolvent des problèmes différents et que le rayon d'action et l'impact des erreurs diffèrent de ceux des procédures de production et de déploiement d'artefacts. En cas d'échec d'un élément de votre infrastructure, l'impact d'une erreur est décrit par un rayon d'action. Ainsi, si vous déployez un artefact défectueux, vous risquez de provoquer une interruption de service qui affectera un ou plusieurs cas d'utilisation. De même, si vous provisionnez un composant d'infrastructure défectueux, l'interruption de service potentielle risque d'affecter plusieurs services de votre environnement, si ce n'est tous.

Obtenir de l'aide

Google Cloud fournit les ressources d'assistance suivantes :

D'autres ressources pouvant vous aider dans la migration des charges de travail vers Google Cloud sont proposées dans le centre de migration Google Cloud.

Pour en savoir plus sur ces ressources, consultez la section Obtenir de l'aide de l'article Migration vers Google Cloud : premiers pas.

Étapes suivantes