L'expression "Infrastructure as Code" a été mentionnée à plusieurs reprises au cours des deux dernières semaines dans différents contextes. Qu'est-ce que cela signifie concrètement dans la pratique d'avoir Infrastructure comme code?
TL; DR : Infrastructure as Code est un moyen d'automatiser et de sauvegarder votre environnement. Dans le cas idéal, après une catastrophe, vous pouvez restaurer votre infrastructure entièrement et automatiquement en provisionnant de nouvelles ressources, en restaurant la configuration à partir du référentiel de codes et en récupérant les données de la sauvegarde.
L'infrastructure en tant que code repose sur trois concepts principaux:
L'automatisation de la gestion de la configuration , appelée automatisation de la configuration continue, un domaine lancé par le prof. Mark Burgess
Référentiel de code pour les modifications apportées à l'infrastructure, où les modifications sont d'abord validées, documentées, examinées, testées puis déployées via l'automatisation.
Provisioning de l' infrastructure gérée . Infrastructure en tant que service (IaaS). Soit par le cloud computing , le cloud privé ou géré ou les services de centre de données géré
La gestion de la configuration en est à sa 3e génération d'outils. S'appuyant sur CFEngine, un nouvel ensemble d'outils pour la gestion automatisée de la configuration est actuellement largement déployé. Les plus populaires par ordre alphabétique sont Ansible, CFEngine, Chef, Puppet, PowerShell DSC et SaltStack . Chacun aura un langage pour décrire l'état de votre infrastructure, des modules de code pour appliquer ces modifications et offriront la possibilité d'étendre les outils, un agent pour les exécuter sur les serveurs et un référentiel central d'informations.
Ils fonctionneront généralement en mode push ou pull, soit en se connectant aux serveurs à partir d'un emplacement central et en exécutant les modifications à distance ou en s'exécutant sur chaque serveur et en tirant des informations sur l'état à partir de l'emplacement central et cela soit dans le modèle client / serveur ou dans un modèle distribué. façon.
Le concept important est que l'administrateur système ou l'ingénieur de la fiabilité du site ne modifie pas directement l'infrastructure, mais laisse l'automatisation effectuer les modifications. Tout ce qui est fait manuellement par un être humain doit être considéré comme périssable, corrigé rapidement par l'automatisation ou sous une forme plus stricte violant l'intégrité de l'infrastructure et déclenchant la destruction et la reconstruction des composants affectés.
Le référentiel de code, idéalement séparé du logiciel contenant le référentiel, serait utilisé pour gérer toutes les modifications apportées à l'infrastructure et à l'automatisation connexe. Il doit contenir des fichiers et des modèles de configuration, des Playbooks (Cookbooks) décrivant le processus de modifications à examiner, du code étendant les outils d'automatisation CM, des configurations d'approvisionnement, des tests et alertes d'infrastructure, des tests de déploiement / déploiement, de la documentation, du manuel (pas encore automatisé) Descriptions des processus .
Le concept important est d'instituer des examens par les pairs pour les changements, d'avoir un enregistrement de tous les changements et la capacité de revenir automatiquement à l'état précédent en cas de problèmes imprévisibles et / ou non testés, la capacité de se déployer dans un environnement intermédiaire et de tester les changements de configuration et la capacité de se déployer automatiquement changements sans variation causés par une erreur humaine.
La gestion de l'infrastructure physique est une tâche réelle qui va au-delà des logiciels et nécessite un ensemble de compétences très différent. En étant en mesure d'abstraire cette couche via le Cloud Computing ou un centre de données géré, votre équipe se concentre sur la partie de la gestion de l'infrastructure qui ajoute de la valeur commerciale.
Alors que le Cloud Computing offre un moyen de démarrer et d'évoluer rapidement à un stade ultérieur, les entreprises réalisent souvent certains avantages et même des économies importantes en déplaçant des parties de l'infrastructure dans leurs propres centres de données pour un modèle hybride. Posséder ou louer le matériel ne signifie pas que vous devez également employer les personnes qui le manipulent. À cette échelle, vous avez besoin de centres de données répartis géographiquement dans le monde entier et disposer de personnes possédant toutes les compétences requises dans tous les endroits serait très coûteux. Les faire voyager dans le monde entier ajoute une latence élevée à tout changement et un niveau supplémentaire d'inefficacité opérationnelle, ce qui est une autre raison d'externaliser la gestion du centre de données.
Le point important à retenir est que l' infrastructure physique gérée est souvent un concept oublié ou négligé , mais tout aussi important. Même si vous avez tout automatisé, toute la configuration stockée dans un référentiel de code sauvegardé, sauf si vous avez un moyen de provisionner rapidement , vous avez un énorme goulot d'étranglement , qui pourrait facilement effacer tous les avantages que vous avez obtenus par les deux autres étapes .
Avant d'expliquer ce que c'est exactement, permettez-moi de citer une très belle définition, directement de Wikipedia :
Infrastructure as Code (IaC) est le processus de gestion et d'approvisionnement de l'infrastructure informatique (processus, serveurs bare-metal, serveurs virtuels, etc.) et leur configuration via des fichiers de définition pouvant être traités par machine, plutôt que la configuration matérielle physique ou l'utilisation d'une configuration interactive outils.
Bon, regardons maintenant un tel outil IaC, Terraform pour mieux comprendre le concept: https://www.terraform.io/
C'est aussi ce que Terraform dit de lui-même:
Terraform vous permet de créer, de modifier et d'améliorer en toute sécurité et de manière prévisible l'infrastructure de production. Il s'agit d'un outil open source qui codifie les API en fichiers de configuration déclaratifs qui peuvent être partagés entre les membres de l'équipe, traités comme du code, modifiés, révisés et versionnés.
Cela signifie que l'on peut coder l'intégralité de l'infra. qui comprend la création de ressources cloud (/ infra) comme les instances de serveur, les équilibreurs de charge, etc., ainsi que les configurations complètes (qui incluent les réglages de base, les paramètres de sécurité, les régions, etc.) sous forme de code, qui peut être modifiable, versionnable et bien sûr, révisable.
Voici un exemple de code Terraform pour le provisionnement des ressources AWS:
resource "aws_elb" "frontend" {
name = "frontend-load-balancer"
listener {
instance_port = 8000
instance_protocol = "http"
lb_port = 80
lb_protocol = "http"
}
instances = ["${aws_instance.app.*.id}"]
}
resource "aws_instance" "app" {
count = 5
ami = "ami-408c7f28"
instance_type = "t1.micro"
}
Bonus PS : En outre, il faut comprendre les différences entre les outils de provisionnement et d' orchestration . Les développeurs confondent très souvent les uns les autres et ont tendance à faire l'erreur d'essayer de modifier et d'utiliser un outil pour ce à quoi il n'est pas destiné.