Explorer le déploiement d’environnement
Supposez que vous recevez un appel de support d’urgence au milieu de la nuit en raison d’une défaillance de serveur.
Dans ce cas, vous savez combien il est fastidieux d’avoir à chercher dans de multiples classeurs, si ce n’est dans votre mémoire, les étapes à effectuer manuellement pour configurer une nouvelle machine.
À cela s’ajoute la difficulté de maintenir les environnements de développement et de production cohérents entre eux.
Un moyen plus simple d’éliminer le risque d’erreur humaine lors de l’initialisation des machines consiste à utiliser l’infrastructure en tant que code.
Déploiement manuel ou infrastructure en tant que code ?
Une analogie courante pour comprendre les différences entre le déploiement manuel et l’infrastructure en tant que code est la distinction entre le fait d’avoir des animaux domestiques et du bétail.
Lorsque vous avez des animaux domestiques, vous leur donner un nom à chacun et les considérez comme des individus. S’il arrive quelque chose de grave à l’un d’eux, vous serez sans doute très peiné.
Si vous avez un cheptel de bovins, vous leur donnerez peut-être aussi un nom à chacun, mais vous les considérerez comme un cheptel.
En termes d’infrastructure, il peut y avoir des implications graves avec une approche de déploiement manuel si une seule machine tombe en panne et que vous devez la remplacer (pets).
Si vous adoptez l’approche « infrastructure en tant que code », vous pourrez plus facilement provisionner une autre machine sans nuire à l’ensemble de votre infrastructure (cheptel) si une machine tombe en panne.
Implémentation de l’infrastructure en tant que code
Avec l’infrastructure en tant que code, vous capturez votre environnement (ou vos environnements) dans un fichier texte (script ou définition).
Votre fichier peut inclure des réseaux, des serveurs et d’autres ressources de calcul.
Vous pouvez archiver le script ou le fichier de définition dans la gestion de versions, puis l’utiliser comme source pour mettre à jour des environnements existants ou en créer de nouveaux.
Par exemple, vous pouvez ajouter un nouveau serveur en modifiant le fichier texte et en exécutant le pipeline de mise en production au lieu de l’insérer à distance dans l’environnement et de provisionner manuellement un nouveau serveur.
Le tableau suivant liste les différences significatives entre le déploiement manuel et l’infrastructure en tant que code.
| Déploiement manuel | Infrastructure as code |
|---|---|
| Serveurs snowflake. | Un serveur cohérent entre les environnements. |
| Les étapes de déploiement varient selon l’environnement. | Il est facile de créer ou de mettre à l’échelle les environnements. |
| Davantage d’étapes de vérification et des processus manuels plus élaborés. | Création entièrement automatisée des mises à jour de l’environnement. |
| Documentation accrue pour tenir compte des différences. | Transition vers l’infrastructure immuable. |
| Déploiement les week-ends pour permettre la récupération après des erreurs. | Utiliser des déploiements bleus/verts. |
| Cadence de mise en production plus lente pour réduire les difficultés et les longs week-ends. | Traitement des serveurs comme du bétail, et non des animaux domestiques. |
Avantages de l’infrastructure en tant que code
La liste suivante présente les avantages de l’infrastructure en tant que code :
- Favorise l’audit en facilitant le suivi de ce qui a été déployé, quand et comment. (En d’autres termes, améliore la traçabilité).
- Fournit des environnements cohérents d’une mise en production à l’autre
- Cohérence accrue entre les environnements de développement, de test et de production
- Automatise les processus de scale-up et scale-out
- Autorise la gestion de version des configurations
- Fournit des fonctionnalités de révision du code et de test unitaire pour faciliter la gestion des modifications de l’infrastructure
- Utilise des processus de service immuables, ce qui signifie que si une modification est nécessaire pour un environnement, un nouveau service est déployé et l’ancien est retiré sans être mis à jour.
- Autorise les déploiements bleus/verts. Cette méthodologie de mise en production réduit le temps d’arrêt lors desquels deux environnements identiques existent : l’un est actif et l’autre ne l’est pas. Les mises à jour sont appliquées au serveur qui n’est pas en ligne. Une fois les tests vérifiés et terminés, le serveur est échangé avec les différents serveurs actifs. Il devient le nouvel environnement actif, et l’environnement actif précédent n’est plus en ligne.
- Traite l’infrastructure comme une ressource flexible qui peut être provisionnée, déprovisionnée et reprovisionnée en fonction des besoins