![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>Terraform est une application dite “stateful”. C’est-\u00e0-dire que toutes les modifications apport\u00e9es \u00e0 votre infrastructure via cet outil sont stock\u00e9es dans un fichier State (\u00e9tat) au format json nomm\u00e9 terraform.tfstate<\/em>. Ce fichier est cr\u00e9\u00e9 lors de la premi\u00e8re ex\u00e9cution de votre code terraform et par d\u00e9faut positionn\u00e9 localement au m\u00eame endroit que votre code terraform.<\/p>\n A chaque ex\u00e9cution suivante via un terraform apply<\/em> par exemple, le fichier terraform.tfstate<\/em> repr\u00e9sentant alors l’\u00e9tat dans lequel doit se trouver votre infrastructure est compar\u00e9 \u00e0 votre code terraform afin d’en d\u00e9duire les ajouts (to add<\/em>), changements (to change<\/em>), suppression (to destroy<\/em>) \u00e0 apporter et donc d’\u00e9tablir son plan. Terraform positionnera une sauvegarde de l’\u00e9tat pr\u00e9c\u00e9dent dans un fichier nomm\u00e9 cette fois-\u00e7i terraform.tfstate.backup<\/em> avant d’apporter les modifications au fichier d’\u00e9tat courant terraform.tfstate.<\/em><\/span><\/p>\n Cet \u00e9tat est donc tr\u00e8s important et nous allons voir dans cet article comment l’externaliser sur un bucket (compartiment) S3 via la notion de remote backend <\/em>afin de le rendre disponible \u00e0 chacun tout en le pr\u00e9servant d’une perte accidentelle. Nous utiliserons \u00e9galement une table DynamoDB qui <\/em>servira \u00e0 verrouiller le fichier en \u00e9criture afin d’\u00e9viter un acc\u00e8s concurrentiel; c’est-\u00e0-dire que plusieurs process\/personnes ne puissent pas apporter des modifications au m\u00eame moment \u00e0 votre infrastructure. En effet il est vital avant chaque ex\u00e9cution, de s’assurer de bien disposer des derni\u00e8res donn\u00e9es d’\u00e9tat et d’\u00eatre le seul \u00e0 y apporter des modifications \u00e0 l’instant T. C’est pourquoi le stockage centralis\u00e9 s’impose et choisir le service AWS S3 offre plusieurs fonctionnalit\u00e9s int\u00e9ressantes.<\/p>\n A noter qu’en environnement DevOps il est primordial d’\u00e9viter tant que faire se peut la d\u00e9duplication de son code, l’on va donc s’int\u00e9resser \u00e0 la fonctionnalit\u00e9 des Workspaces<\/em>.<\/p>\n Notre objectif ici est de proposer une solution permettant d’automatiser la cr\u00e9ation\\mise \u00e0 jour\\suppression d’une instance EC2 dans un environnement bac \u00e0 sable AWS. Les objets de type VPC, subnet, security group seront d\u00e9j\u00e0 provisionn\u00e9s.\u00a0 Pour l’instant cela reste simple et votre code terraform pourrait alors ressembler \u00e0 ceci:<\/p>\n On d\u00e9finit notre provider AWS, et l’on renseigne nos param\u00e8tres d’identification (inutile si vous avez d\u00e9ploy\u00e9 AWS CLI et fait un aws configure ou mieux que vous utilisiez un r\u00f4le IAM). Ensuite on d\u00e9fini une ressource de type “aws_instance” (=EC2) que l’on nommera pour terraform “mon_ec2”<\/p>\n On constate qu’un certain nombre de param\u00e8tres sont naturellement variabilis\u00e9s via les fichiers variables.tf et terraform.auto.tfvars<\/em>. Notamment pour l’identifiant de l’AMI \u00e0 utiliser, le type d’instance (ex:T2.micro) ainsi que la g\u00e9n\u00e9ration de certains tags etc. Il n’y a plus qu’\u00e0 ex\u00e9cuter notre code terraform via les commandes terraform plan<\/em> pour afficher dans un premier temps le plan d’action puis un terraform apply<\/em> pour cr\u00e9er la ressource de type instance EC2 sur notre environnement AWS.<\/p>\n Sans surprise notre EC2 a bien \u00e9t\u00e9 cr\u00e9\u00e9e.<\/p>\n Les jours passent et je voudrais \u00e0 nouveau cr\u00e9er une EC2 de la m\u00eame mani\u00e8re mais \u00e0 partir d’une nouvelle AMI. J’effectue alors quelques modifications au niveau de mes variables pour changer la valeur de var.AMI (ami-09155d2e27d9fb18c) ainsi que var.Name (EC2_TESTLPRTERRAFORM_EC2_2<\/strong>) puis j’ex\u00e9cute \u00e0 nouveau mon code en esp\u00e9rant avoir une deuxi\u00e8me EC2 !<\/p>\n Et l\u00e0 vous l’aurez compris terraform \u00e9tant stateful, il d\u00e9tecte qu’il a d\u00e9j\u00e0 cr\u00e9\u00e9 une ressource nomm\u00e9e dans le code terraform “aws_instance” “mon_ec2”<\/strong> via son fichier terraform.tfstate<\/em> et me propose de la d\u00e9truire <\/strong>(1 to destroy) pour en ajouter une nouvelle<\/strong> (1 to add) \u00e0 partir cette fois d’une autre image AMI et de changer le tag Name<\/em> au passage (c’est bien le changement d’AMI qui explique la destruction puis recr\u00e9ation et pas le changement de tag Name)<\/em> !<\/p>\n Ce comportement est tout \u00e0 fait normal car c’est la philosophie m\u00eame de Terraform. Malheureusement nous ne souhaitons en aucun cas supprimer l’EC2 pr\u00e9c\u00e9demment cr\u00e9\u00e9e. A noter qu’il est inutile d’essayer de variabiliser le nom de la ressource Terraform afin d’esp\u00e9rer arriver \u00e0 vos fins, ce n’est pas possible.<\/p>\n L’une des approches nous permettant de r\u00e9ex\u00e9cuter exactement l<\/strong>e m\u00eame code Terraform<\/strong> (moyennant naturellement le changement de nos variables) pour g\u00e9rer des ressources diff\u00e9rentes est d’utiliser la fonctionnalit\u00e9 Workspaces <\/em>de Terraform. Petite apart\u00e9:<\/strong> Attention toutefois la documentation Terraform est assez claire \u00e0 ce sujet:<\/span><\/em><\/span><\/strong><\/p>\n https:\/\/developer.hashicorp.com\/terraform\/language\/state\/workspaces<\/a> Hashicorp nous explique alors qu’opter pour la fonctionnalit\u00e9 Workspaces <\/em>pour g\u00e9rer nos diff\u00e9rents environnements Production \/ Qualification \/ D\u00e9veloppement peut poser un probl\u00e8me “d’isolation”. En effet utiliser le m\u00eame code terraform au sein de diff\u00e9rents Workspaces<\/em> implique de n’utiliser qu’un seul backend S3<\/em> (= bucket S3).<\/em> Au niveau du sch\u00e9ma “IV] Architecture cible”, on constate bien que l’int\u00e9gralit\u00e9 de nos fichiers terraform.tfstate<\/em> correspondant \u00e0 chacun de nos Workspaces<\/em> (=environnements de production, qualification et d\u00e9veloppement) vont se retrouver au m\u00eame endroit. Il n’y a donc aucune s\u00e9paration au niveau stockage S3.<\/p>\n Si vos contraintes en terme de s\u00e9curit\u00e9 ne sont pas trop \u00e9lev\u00e9es cela me semble tout \u00e0 fait jouable sinon il faudra se pencher sur une gestion via par exemple l’utilisation de diff\u00e9rentes branches GIT<\/em>\u00a0 (avec malheureusement d\u00e9duplication de votre code qui devra \u00eatre maintenu \u00e0 jour entre les diff\u00e9rentes branches…) ou alors \u00e9ventuellement utiliser un autre outil nomm\u00e9 Terragrunt <\/em><\/a>(wrapper pour terraform) \u00e9vitant justement la d\u00e9duplication de code.<\/p>\n Passons \u00e0 la mise en \u0153uvre afin d’illustrer le concept:<\/p>\n Terraform aura besoin des droits suivants sur le bucket S3 (cf S3 Bucket Permissions<\/a>): A noter qu’il est possible en environnement critique d’activer la r\u00e9plication de votre bucket S3: Terraform aura besoin des droits suivants table DynamoDB (cf DynamoDB Table Permissions<\/a>): Comme vu un peu plus haut nous disposons d’un dossier nomm\u00e9 c:\\temp\\ProjectCreateEC2 avec les fichiers suivants:<\/p>\n Je n’aborderai pas en d\u00e9tail le contenu des autres fichiers mais sachez que: Une fois la modification effectu\u00e9e il faut r\u00e9initialiser notre dossier de travail Terraform ProjectCreateEC2 afin qu’il puisse prendre en compte notre remote backend, sinon vous obtiendrai l’erreur suivante:<\/p>\n En effet un terraform init <\/em>est obligatoire \u00e0 chaque changement au niveau du provider, backend ou modules. Vous pouvez \u00e9galement vous contentez de faire du m\u00e9nage dans le dossier c:\\temp\\ProjectCreateEC2 en supprimant le dossier .terraform qui contient les informations d’initialisation ainsi qu’en supprimant le fichier .terraform.lock.hcl. Ce dernier permet justement \u00e0 Terraform de suivre les modifications apport\u00e9es au provider, backend et ou modules afin de demander une r\u00e9initialisation lors de la prochaine ex\u00e9cution. Une fois le m\u00e9nage effectu\u00e9, je lance donc une nouvelle initialisation de mon dossier c:\\temp\\ProjectCreateEC2 (cette manipulation \u00e9quivaut donc \u00e0 la commande terraform init -reconfigure<\/em>):<\/p>\n L’initialisation est termin\u00e9e et notre dossier ressemble d\u00e9sormais \u00e0 cela:<\/p>\nII] Contexte:<\/strong><\/em><\/span><\/span><\/h2>\n
terraform {\r\n required_providers {\r\n aws = {\r\n source = "hashicorp\/aws"\r\n version = "~> 4.0"\r\n }\r\n }\r\n}\r\nprovider "aws" {\r\n region = var.AWS_REGION\r\n access_key = var.AWS_ACCESS_KEY\r\n secret_key = var.AWS_SECRET_KEY\r\n}\r\n\r\nresource "aws_instance" "mon_ec2"{ # Nom que l'on donne \u00e0 notre ressource pour terraform (\u00e0 ne pas confondre avec le tag Name de l'EC2)\r\n ami = var.AMI\r\n instance_type = var.INSTANCE_TYPE\r\n tags = {\r\n Name = "${var.TAG_NAME}"\r\n AUTEUR = "${var.TAG_AUTEUR}"\r\n DESCRIPTION = "${var.TAG_DESCRIPTION}"\r\n ENVIRONNEMENT = "${var.TAG_ENVIRONNEMENT}"\r\n }\r\n key_name = var.KEY_NAME\r\n subnet_id = var.SUBNET_ID\r\n vpc_security_group_ids = var.VPC_SECURITY_GROUP_IDS\r\n disable_api_termination = true\r\n}\r\n\r\n<\/pre>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/03\/01TerraformApply.jpg\")
<\/a><\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/03\/02TerraformApply.jpg\")
<\/a><\/p>\n
\nLa question est donc de trouver le moyen de r\u00e9ex\u00e9cuter ce m\u00eame code <\/strong>(un nombre ind\u00e9fini de fois d’ailleurs) pour obtenir une nouvelle EC2 \u00e0 chaque fois mais sans toucher aux autres pr\u00e9c\u00e9demment cr\u00e9\u00e9es et tout en garantissant l’int\u00e9grit\u00e9 du fichier terraform.tfstate<\/em> qui pour l’instant est stock\u00e9 en local.<\/p>\n\r\n# Ne fonctionne pas !\r\nresource "aws_instance" "${var.RESOURCE_NAME}" {\r\n [...]\r\n}<\/pre>\nIII] Pr\u00e9requis:<\/strong><\/em><\/span><\/span><\/h2>\n
\n
IV] “Arborescence” Terraform actuelle:<\/strong><\/em><\/span><\/span><\/h2>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/03\/Arborescence-Actuelle.jpg\")
<\/a><\/p>\nIV] “Arborescence” Terraform cible:<\/strong><\/em><\/span><\/span><\/h2>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/03\/Arborescence-cible.jpg\")
<\/a><\/p>\n
\n<\/em>Ces derniers permettent en effet de g\u00e9n\u00e9rer des fichiers d’\u00e9tats (terraform.tfstate<\/em>) diff\u00e9rents pour un m\u00eame code d’ex\u00e9cution Terraform en les rangeant par Workspaces<\/em>. C’est-\u00e0-dire qu’il suffira avant chaque ex\u00e9cution de notre m\u00eame code de se positionner sur un nouveau Workspace<\/em> afin d’obtenir des fichiers d’\u00e9tat distinctes. De cette mani\u00e8re Terraform pourra g\u00e9rer plusieurs ensembles de ressources qui n’interf\u00e8rent pas entre elles. C’est exactement ce qu’on l’on souhaite faire. Une m\u00eame configuration Terraform pour “n” fichiers d’\u00e9tats !<\/p>\n
\nDans mes lectures j’ai souvent constat\u00e9 que cette fonctionnalit\u00e9 \u00e9tait utilis\u00e9e pour dupliquer des environnements. Par exemple un m\u00eame fichier main.tf pouvant \u00eatre jou\u00e9 dans un Workspace <\/em>nomm\u00e9 “Developpement” afin de r\u00e9aliser des tests puis ensuite jou\u00e9 dans un autre Workspace<\/em> nomm\u00e9 cette fois “Production”. Passer d’un Workspace<\/em> \u00e0 l’autre tout en jouant sur nos variables permet alors d’obtenir deux environnements diff\u00e9rents mais \u00e0 partir du m\u00eame code<\/span> terraform. En effet un seul fichier main.tf<\/em> sera utilis\u00e9 pour g\u00e9n\u00e9rer ici deux fichiers terraform.tfstate<\/em>, un pour chacun des Workspaces<\/em>.<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/03\/Using-Workspace.jpg\")
<\/a><\/p>\n
\nhttps:\/\/developer.hashicorp.com\/terraform\/cli\/workspaces#use-cases<\/a><\/p>\nV] Mise en oeuvre:<\/strong><\/em><\/span><\/h2>\n
A- Commen\u00e7ons par cr\u00e9er notre bucket S3<\/em> qui va h\u00e9berger l’ensemble de nos fichiers d’\u00e9tats (terraform.tfstate<\/em>):<\/span><\/h3>\n
# Consultation de l'aide de la commande create-bucket\r\nC:\\Users\\lprou>aws s3api create-bucket help\r\n\r\n# Cr\u00e9ation du compartiment S3\r\nC:\\Users\\lprou>aws s3api create-bucket --bucket capdata-tfstate --region eu-west-3 --create-bucket-configuration LocationConstraint=eu-west-3 --acl private\r\n\r\n# D\u00e9sactivation de l'acc\u00e8s publique\r\nC:\\Users\\lprou>aws s3api put-public-access-block --bucket capdata-tfstate --public-access-block-configuration \"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true\"\r\n\r\n# Activation du chiffrage\r\nC:\\Users\\lprou>aws s3api put-bucket-encryption --bucket capdata-tfstate --server-side-encryption-configuration \"{\\\"Rules\\\": [{\\\"ApplyServerSideEncryptionByDefault\\\":{\\\"SSEAlgorithm\\\": \\\"AES256\\\"}}]}\"\r\n\r\n# Activation du versionning afin de conserver un historique de nos fichiers terraform.tfstate\r\nC:\\Users\\lprou>aws s3api put-bucket-versioning --bucket capdata-tfstate --versioning-configuration MFADelete=Disabled,Status=Enabled\r\n<\/pre>\n
\ns3:ListBucket
\ns3:GetObject
\ns3:PutObject
\ns3:DeleteObject<\/p>\n
\nhttps:\/\/docs.aws.amazon.com\/fr_fr\/AmazonS3\/latest\/userguide\/replication.html<\/a>
\nEt \u00e9galement de mettre en place une r\u00e8gle de cycle de vie pour faire du m\u00e9nage concernant les anciennes versions de vos fichiers terraform.tstate: https:\/\/docs.aws.amazon.com\/fr_fr\/AmazonS3\/latest\/userguide\/object-lifecycle-mgmt.html<\/a><\/p>\nB- Continuons par cr\u00e9er notre table DynamoDB qui h\u00e9bergera les informations de verrouillage des fichiers terraform.tfstate:<\/span><\/h3>\n
# Consultation de l'aide de la commande create-table\r\nC:\\Users\\lprou>aws dynamodb create-table help\r\n\r\n# Cr\u00e9ation d'une table DynamoDB\r\nC:\\Users\\lprou>aws dynamodb create-table --table-name capdata-terraform-tfstate --attribute-definitions AttributeName=LockID,AttributeType=S --key-schema AttributeName=LockID,KeyType=HASH --provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1 --table-class STANDARD\r\n\r\n# Configuration des capacit\u00e9s d'autoscaling en \u00e9criture\r\nC:\\Users\\lprou>aws application-autoscaling register-scalable-target --service-namespace dynamodb --scalable-dimension dynamodb:table:WriteCapacityUnits --resource-id table\/capdata-terraform-tfstate --min-capacity 1 --max-capacity 10\r\n\r\n# Configuration des capacit\u00e9s d'autoscaling en lecture\r\nC:\\Users\\lprou>aws application-autoscaling register-scalable-target --service-namespace dynamodb --scalable-dimension dynamodb:table:ReadCapacityUnits --resource-id table\/capdata-terraform-tfstate --min-capacity 1 --max-capacity 10<\/pre>\n
\ndynamodb:DescribeTable
\ndynamodb:GetItem
\ndynamodb:PutItem
\ndynamodb:DeleteItem<\/p>\nC- Cr\u00e9ation de notre environnement terraform dans notre dossier “ProjectCreateEC2”:<\/span><\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/03\/tree.jpg\")
<\/a><\/p>\n<\/div>\n<\/div>\nLa premi\u00e8re chose \u00e0 faire par rapport \u00e0 notre fichier main.tf initial (vu dans la partie II] Contexte) est d’ajouter notre remote backend pour le faire pointer sur notre bucket S3 pr\u00e9c\u00e9demment cr\u00e9\u00e9 et utiliser notre table DynamoDB. Ce qui donne ceci:<\/div>\n<\/div>\n\nterraform {\r\n required_providers {\r\n aws = {\r\n source = "hashicorp\/aws"\r\n version = "~> 4.0"\r\n }\r\n }\r\n}\r\n\r\nprovider "aws" {\r\n region = var.AWS_REGION\r\n access_key = var.AWS_ACCESS_KEY\r\n secret_key = var.AWS_SECRET_KEY\r\n }\r\n\r\nterraform {\r\n backend "s3" {\r\n bucket = "capdata-tfstate" # nom de notre bucket S3\r\n key = "terraform.tfstate" # nom \u00e0 utiliser pour les fichiers d'\u00e9tats\r\n region = "eu-west-3"\r\n encrypt = true # param\u00e8tre optionnel et je pense inutile ici puisque l'encryption \u00e0 d\u00e9j\u00e0 \u00e9t\u00e9 positionn\u00e9 sur notre bucket \r\n dynamodb_table = "capdata-terraform-tfstate" # nom de notre table DynamoDB\r\n }\r\n}\r\n\r\nresource "aws_instance" "mon_ec2" {\r\n ami = var.AMI\r\n instance_type = var.INSTANCE_TYPE\r\n tags = {\r\n Name = "${var.TAG_NAME}"\r\n AUTEUR = "${var.TAG_AUTEUR}"\r\n DESCRIPTION = "${var.TAG_DESCRIPTION}"\r\n ENVIRONNEMENT = "${var.TAG_ENVIRONNEMENT}"\r\n }\r\n key_name = var.KEY_NAME\r\n subnet_id = var.SUBNET_ID\r\n vpc_security_group_ids = var.VPC_SECURITY_GROUP_IDS\r\n disable_api_termination = true\r\n}<\/pre>\n<\/div>\n
\n– terraform.auto.tfvars contient les identifiants AWS
\n– variables.tf contient les autres variables
\n– output.tf sert \u00e0 renvoyer des param\u00e8tres de sortie (ex: Adresse IP de l’EC2 cr\u00e9\u00e9e…)suite \u00e0 l’ex\u00e9cution de notre code Terraform. Nous avons ainsi la possibilit\u00e9 d’interroger les valeurs d’output pr\u00e9sentes dans notre tfstate<\/em> via la commande:<\/p>\n\r\n# Affiche l'aide concernant la commande output\r\nC:\\temp\\ProjectCreateEC2>terraform output --help \r\n\r\n# R\u00e9cup\u00e8re uniquement la valeur de l'output nomm\u00e9 private_ip\r\nC:\\temp\\ProjectCreateEC2>terraform output -raw private_ip \r\n172.44.2.118\r\n\r\n# R\u00e9cup\u00e8re tout l'output au format json\r\nC:\\temp\\ProjectCreateEC2>terraform output -json \r\n{\r\n "ami": {\r\n "sensitive": false,\r\n "type": "string",\r\n "value": "ami-01e9b120b1e5c5004"\r\n },\r\n "id": {\r\n "sensitive": false,\r\n "type": "string",\r\n "value": "i-0a572194708a33c46"\r\n }, [...]<\/pre>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/03\/InitRequired.jpg\")
<\/a><\/p>\n
\nIl nous explique alors qu’il est possible de jouer avec la commande terraform init -reconfigure<\/em> ou -migrate-state<\/em>.<\/p>\n
\nJe vous invite vivement \u00e0 parcourir ce dossier et ouvrir les fichiers qu’il contient afin de comprendre le fonctionnement interne de Terraform ;).<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/03\/init.jpg\")
<\/a><\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/03\/tree2.jpg\")
<\/a><\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/03\/EC2_1.jpg\")
<\/a><\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/03\/S3_1.jpg\")
<\/p>\n