Importer une infrastructure existante dans Terraform

Note de la rédaction : cet article a d’abord été publié sur CloudSkiff.com. CloudSkiff a rejoint Snyk en octobre 2021.

Vous avez parfois besoin d’importer une infrastructure existante dans Terraform. Les raisons sont nombreuses. Certaines personnes débutent tout juste et doivent migrer des infrastructures existantes pour en tirer une nouvelle base de code. Parfois, même si vous êtes un expert, vous devez simplement passer d’une preuve de concept (POC) rapidement créée en cliquant dans votre console à un projet en production qui doit être stable.

Supposons que vous disposiez déjà d’une infrastructure en production, créée depuis la console de votre fournisseur cloud… Comment en extraire du code Terraform et, surtout, comment le faire fonctionner ?

Dans cet article, nous passons rapidement en revue les principales méthodes pour générer automatiquement du code d’infrastructure à partir d’un environnement existant : cloner un environnement, le faire fonctionner et s’assurer qu’il est reproductible.

Importer une infrastructure existante dans Terraform avec Terraform import

Si vous n’avez qu’un petit nombre de ressources à convertir en code et que vous disposez des compétences nécessaires, vous pouvez simplement réécrire le code. Mais vous devez bien sûr savoir exactement comment ces ressources sont configurées.

Si vous disposez déjà d’une base de code Terraform, une fois le code écrit, vous devrez y exécuter terraform import. terraform import est une sous-commande de Terraform. Comme ce code correspondra parfaitement aux ressources existantes dans le compte de votre fournisseur cloud, vous obtiendrez une parfaite cohérence entre votre code, vos ressources existantes et votre fichier TFState.

Importer une infrastructure existante dans Terraform avec un outil d’importation

La méthode que nous venons de mentionner peut convenir pour un petit nombre de ressources, mais elle peut devenir redoutable dans les environnements de grande taille. Il existe sur le marché différents outils d’importation, de conversion, d’analyse et de génération Terraform pour vous aider.

L’un d’eux, Terraformer, a été créé par l’équipe SRE de Waze à Tel Aviv.

Une fois vos identifiants fournis, Terraformer analyse le compte de votre fournisseur cloud à la recherche de ressources. Lorsqu’il en trouve une, il la convertit en code Terraform adapté, accompagné d’un fichier d’état fonctionnel.

Le code obtenu n’est pas très propre, et encore moins DRY, mais il fait 80 % du travail. Vous pouvez ensuite vous en servir comme point de départ.

Étapes clés pour convertir vos infrastructures importées en code Terraform fonctionnel

Une fois vos ressources existantes importées dans Terraform, il est essentiel de suivre quelques étapes supplémentaires pour que tout fonctionne. En effet, à ce stade, le code n’est ni propre ni optimisé.

Vérifiez que tout utilise des variables et que celles-ci sont harmonisées.

Imaginons que vous ayez un réseau VPC nommé VPC. Cela peut poser problème si un seul nom de VPC est autorisé par région. C’est le cas des buckets Amazon S3 : par exemple, vous ne pouvez avoir qu’un seul bucket S3 dans le monde, commun à tous les clients.

Renommer les ressources vous prendra un peu de temps. Mais en vous assurant, grâce aux variables, que les noms utilisés sont uniques, vous aurez la certitude que le code pourra être réutilisé dans une autre région.

Déclarez explicitement vos dépendances.

L’un des problèmes liés à l’importation automatique de ressources dans du code Terraform est que les liens entre ces ressources ne sont souvent pas créés. Vous verrez des ressources qui forment un ensemble cohérent, mais dont les dépendances ne sont pas explicitement déclarées. Elles peuvent aussi être déclarées, mais pas au moyen de variables.

Par exemple, vous pouvez avoir une règle de groupe de sécurité déclarée et associée à l’ID de ce groupe de sécurité, et l’ensemble fonctionne correctement. Mais en l’absence de lien interne — ou, plus précisément, de dépendance dans le code —, lors de votre prochain déploiement dans une autre région, vous risquez de déployer des règles et un groupe de sécurité qui ne sont pas liés.

Enfin, assurez la reproductibilité grâce à l’aléatoire

Dernière étape clé : assurer la reproductibilité grâce à l’aléatoire. Pour cela, il suffit généralement de rendre les noms aléatoires en y ajoutant quelques caractères.

Pour ma part, j’utilise une chaîne aléatoire en suffixe. Cela génère une chaîne aléatoire très simple de huit caractères (sans caractères spéciaux, car vous ne voulez pas de caractères inhabituels dans vos noms). Je crée simplement des variables locales.

Pour mes environnements de production et de préproduction, je les ajoute simplement en suffixe. Ainsi, que je sois en production ou en préproduction, j’obtiens un nom unique et aléatoire. Et je peux très facilement créer un autre environnement de test par simple copier-coller.

1# cluster name needs to be unique
2resource "random_string" "suffix" {
3  length  = 8
4  special = false
5}
6locals {
7  production_cluster_name = "eks-production-${random_string.suffix.result}"
8  staging_cluster_name    = "eks-staging-${random_string.suffix.result}"
9}
10# Production Cluster
11module "production_cluster" {
12  source          = "terraform-aws-modules/eks/aws"
13  version         = "7.0.1"
14  cluster_name    = local.production_cluster_name
15  cluster_version = var.kubernetes_version
16  manage_aws_auth = true
17  worker_ami_name_filter = "amazon-eks-node-1.14-v20200312"
18  subnets = module.vpc.private_subnets
19  vpc_id = module.vpc.vpc_id
20  map_users = var.map_users
21  workers_additional_policies          = [aws_iam_policy.allow_ecr.arn]
22  worker_additional_security_group_ids = [aws_security_group.management.id]
23  worker_groups = [
24    {
25      name                 = "production-1.14-wg-small"
26      instance_type        = "t3.small"
27      asg_max_size         = 2
28      asg_desired_capacity = 1
29    },
30    {
31      name                 = "production-1.14-wg-medium"
32      instance_type        = "t3.medium"
33      asg_max_size         = 3
34      asg_desired_capacity = 2
35      asg_min_size         = 2
36    }
37  ]
38  tags = {
39    environment = "production"
40    Terraform   = "true"
41  }
42  workers_group_defaults = {
43    key_name = aws_key_pair.admin.key_name
44  }
45}

En résumé

L’importation de vos ressources n’est que la première étape et suffit rarement à elle seule.

Pour rendre votre code opérationnel, vous devez ensuite :

• Vérifier que tout utilise des variables

• Vérifier que toutes les variables sont harmonisées

• Déclarer vos dépendances et les relier

• Rendre les variables aléatoires pour générer des noms uniques

Sécuriser votre code Terraform

Snyk IaC sécurise vos configurations Terraform (ainsi que vos modèles Kubernetes, CloudFormation et ARM !) au fil du développement, avec des corrections guidées pour vous permettre de fusionner vos modifications et de passer à la suite. Testez votre code au fur et à mesure, surveillez les changements dans vos dépôts Git et automatisez les tests dans vos pipelines de build avant le déploiement. La mise en route avec une offre gratuite ne prend que quelques minutes, tandis qu’une violation liée à une mauvaise configuration IaC peut causer des dégâts irréversibles. Inscrivez-vous ci-dessous pour commencer à sécuriser vos configurations.