[.Remarque]##
Note: il s'agit d'une version préliminaire du contenu du guide du navigateur, une offre des ingénieurs des solutions DigitalOcean. L'objectif du livre est d'aider les clients commerciaux à planifier leurs besoins en infrastructure, à fournir des exemples pratiques en cours de route et à inclure des nuances techniques et le «pourquoi» qui permet de prendre certaines décisions mieux que d'autres.
Le livre et le code qui l'accompagne seront accessibles au public dans un référentiel GitHub. Comme il s'agit d'une version anticipée, le livre n'est pas encore terminé et le référentiel n'est pas encore public, mais restez à l'écoute!
La section précédente utilisait Terraform et Ansible pour provisionner des ressources (Droplets, Load Balancers et IP Floating) et déployer votre application WordPress.
Terraform a créé ces ressources à l'aide du fichiermain.tf. Actuellement, toutes les ressources de ce fichier sont répertoriées individuellement. Plus votre environnement devient complexe, plus vous aurez besoin de ressources et plus ce fichier sera long et complexe. Cela rendra votre configuration plus difficile à gérer à long terme.
Dans cette section supplémentaire, nous examinons différentes manières de simplifier cette configuration à l'aide de modules Terraform et d'environnements d'infrastructure distincts. Il n’ya pas de code à exécuter et aucune modification à apporter dans cette section, mais les concepts sont importants lors de la création d’une installation dans le monde réel.
Comprendre les modules Terraform
Pour utiliser la propre description des modules de Terraform:
Les modules dans Terraform sont des packages autonomes de configurations Terraform gérées en tant que groupe. Les modules sont utilisés pour créer des composants réutilisables dans Terraform ainsi que pour l’organisation de code de base.
Les modules créent des blocs d'infrastructure réutilisable pouvant prendre des entrées et fournir des sorties, comme une fonction dans un langage de programmation de haut niveau. Nous pouvons créer des modules acceptant des arguments d'entrée facultatifs pour des éléments similaires de notre infrastructure et définir des valeurs par défaut pour ces paramètres d'entrée. Cela aide à organiser et à simplifier votre configuration. Vous pouvez en savoir plus sur les modules dansTerraform’s module documentation.
Pour un exemple complet, jetez un œil au fichiermain.tf. La dernière section utilise déjà un module Terraform:
module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.6"
...
}Vous pouvez comparer cette section au bloc de ressources pourwp_node vers le haut du fichier, qui a beaucoup plus de lignes de code et est plus difficile à suivre. Vous remarquerez que le module est appelé à l’aide d’un référentiel git distant. Vous pouvez utiliser des chemins de fichiers locaux, ce qui peut permettre un développement et des tests rapides, mais l'utilisation d'un référentiel git distant pousse l'isolement de votre environnement encore plus loin. Ceci est particulièrement utile lorsque vous exécutez plusieurs environnements d'infrastructure, tels que le transfert et la production. Lorsque vous utilisez des chemins de fichiers locaux avec plusieurs environnements d'infrastructure, vous pouvez finir par apporter une modification destinée à n'affecter que le transfert, mais si vous exécutez une application surprod et que le chemin du fichier du module est partagé, vous pouvez terminer casser quelque chose. Si vous avez des répertoires dédiés pour chaque environnement, vous devrez alors conserver deux copies ou plus de vos scripts, et revenir à un état antérieur ne sera pas si facile.
L'utilisation d'un référentiel git distant et la spécification d'un numéro de version pour le module permettent d'éviter ce problème. Comme mentionné précédemment, il est également beaucoup plus facile de revenir à une version de travail connue en cas de problème, ce qui améliore votre capacité à gérer les incidents et les pannes (ce que nous verrons plus en détail au chapitre 9).
Ce module ne se limite pas à créer un seul Droplet. Il crée des balises Droplet, les nœuds du cluster Galera, les équilibreurs de charge et l'adresse IP flottante. Vous pouvez considérer les modules terraform comme un moyen intéressant d’emballer des composants d’un service complet. Cela signifie également que vous pouvez ajouter plus de ressources à un module ou créer des sorties de module pouvant à leur tour être utilisées comme entrées pour d'autres modules que vous êtes en train de développer. Lorsqu'il est judicieux de créer un nouveau module, comme l'ajout d'un nouveau service ou une fonctionnalité que vous souhaitez découpler, vous pouvez absolument créer des sorties dans vos modules et elles seront stockées dans le cadre de votre état. Si vous utilisez un état distant, les sorties de module peuvent s'avérer très utiles lorsque vous souhaitez partager des informations en lecture seule entre différents composants de votre infrastructure ou fournir à un service externe un moyen de récupérer les informations dont il peut avoir besoin.
Pour le dire simplement, si vous considérez les sections de ressources d’un plan Terraform comme des briques Lego, vos modules seront des sections pré-assemblées. C’est bien mieux que de devoir suivre des briques Lego partout et éventuellement de marcher dessus. En plus d'aider à prévenir cette douleur, les modules peuvent également être utilisés pour informer les configurations d'autres modules à mesure que vous ajoutez de la complexité à votre plan d'infrastructure.
Configuration des environnements d'infrastructure
Dans la plupart des projets professionnels, vous travaillerez dans trois environnements différents: développement, mise en scène et production.
Votre environnement de développement est souvent local et vous donne l’espace nécessaire pour bricoler et tester de manière autonome lorsque vous travaillez. D'autre part, vos environnements de transfert et de production se trouveront dans un espace public ou partagé et seront provisionnés à l'aide d'un processus automatisé tel que Terraform.
Commencer par un flux de travail de déploiement réfléchi et planifié contribuera dans une large mesure à prévenir les maux de tête, notamment en isolant les environnements les uns des autres. La fonction d'espace de travail de Terraform maintient les fichiersterraform.tfstate séparés par environnement, mais les modifications apportées aux fichiers terraform décrivant vos ressources ne le sont pas. Ainsi, bien que cette fonctionnalité puisse constituer un moyen rapide d'effectuer des modifications mineures, des tests et un déploiement, elle ne doit pas être utilisée lorsque vous avez un déploiement plus important qui peut nécessiter l'isolement des services les uns des autres, ainsi que des équipes. qui les gère.
Voici un exemple d’arborescence de répertoires décrivant comment configurer l’isolation d’environnement avec des répertoires:
.
├── ansible.cfg
├── bin/
├── environments/
│ ├── config/
│ │ └── cloud-config.yaml
│ │
│ ├── dev/
│ ├── prod/
│ │ ├── config -> ../config
│ │ ├── group_vars
│ │ ├── host_vars
│ │ ├── main.tf
│ │ ├── terraform.tfvars
│ │ ├── terraform-inventory -> ../terraform-inventory
│ │ └── variables.tf
│ │
│ ├── staging/
│ │ ├── config -> ../config
│ │ ├── group_vars
│ │ ├── host_vars
│ │ ├── main.tf
│ │ ├── terraform.tfvars
│ │ ├── terraform-inventory -> ../terraform-inventory
│ │ └── variables.tf
│ │
│ └── terraform-inventory
│
├── site.yml
├── wordpress.yml
│
└── roles/La logique qui sous-tend ce type de présentation est de conserver les fichiers appartenant à des composants similaires dans des environnements distincts les uns des autres.
Par exemple, dans le répertoireenvironments, nous avons un sous-répertoire pour chacun des trois environnements que nous voulons:dev,staging etprod. Cette isolation permet d'éviter l'exécution accidentelle d'un script Ansible ou Terraform au mauvais endroit. Vous pouvez aller plus loin et utiliser une autre couche de sous-répertoires pour stocker des fichiers pour différentes parties de l’infrastructure de chaque environnement.
Il y amany great write-ups about this topic en ligne, dont l'un est en fait devenu le livreTerraform: Up & Running de Yevgeniy Brikman.
Utilisation de la version de module pour les environnements
Les modules Terraform peuvent également vous aider à apporter des modifications sans affecter les autres environnements. Par exemple, regardez ces deux modules.
Un pour un environnement intermédiaire (par exemple,staging/main.tf):
module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.8"
project = "${var.project}"
region = "${var.region}"
keys = "${var.keys}"
private_key_path = "${var.private_key_path}"
ssh_fingerprint = "${var.ssh_fingerprint}"
public_key = "${var.public_key}"
ansible_user = "${var.ansible_user}"
}Et un pour un environnement de production (par exemple,prod/main.tf):
module "sippin_db" {
source = "github.com/cmndrsp0ck/galera-tf-mod.git?ref=v1.0.6"
project = "${var.project}"
region = "${var.region}"
keys = "${var.keys}"
private_key_path = "${var.private_key_path}"
ssh_fingerprint = "${var.ssh_fingerprint}"
public_key = "${var.public_key}"
ansible_user = "${var.ansible_user}"
}La seule différence entre eux est la valeur de la cléref à la fin de la lignesource, qui spécifie la version à déployer. En préparation, c'estv1.0.8, et en production, c'estv1.0.6. L'utilisation du contrôle de version vous permet d'effectuer et de tester des modifications dans le stockage intermédiaire avant le déploiement en production. De telles configurations simplifient la configuration qui le prend en charge.
Pour le moment, la configuration pratique de la section précédente n’utilise pas l’état distant. Dans le chapitre 6, nous traitons de l’utilisation d’un système d’état distant (comme Consul), qui est essentiel lorsque vous travaillez en équipe. Sans backend d'état distant, vous et un autre membre de l'équipe pouvez appliquer simultanément des modifications à l'infrastructure, ce qui peut entraîner des conflits, des pannes ou une corruption du fichier d'état.
Et après?
Une fois que vous avez compris comment simplifier le code de votre infrastructure en le rendant modulaire et comment isoler les environnements pour un développement et un déploiement plus sûr, nous pouvons examiner comment augmenter la rapidité de déploiement en créant des modèles. Le chapitre suivant explique comment automatiser le flux de travail de déploiement à l'aide d'outils de développement continus, ce qui vous aidera à déployer le nouveau code en toute sécurité et rapidement.