Comment utiliser GitLab et Terraform pour déployer l'Infrastructure as Code : démo
Cette démonstration montre comment suivre une bonne pratique GitOps pour déployer l'Infrastructure as Code en utilisant Terraform pour l'automatisation et GitLab comme source unique de vérité.
L'Infrastructure as Code (IaC) désigne la pratique consistant à gérer et à provisionner l'infrastructure informatique (serveurs, bases de données et réseaux) à l'aide de fichiers de configuration lisibles par machine, plutôt que par des processus manuels. En définissant l'infrastructure dans le code, les équipes peuvent gérer les versions, effectuer des tests et automatiser les déploiements de manière cohérente et reproductible, exactement comme elles le font pour le code applicatif.
L'IaC accélère la livraison, réduit la dérive de configuration et améliore la collaboration entre les équipes de développement, d'exploitation et de sécurité. Associée à des workflows basés sur Git comme GitOps, l'IaC devient le socle d'une automatisation d'infrastructure cloud évolutive et sécurisée.
Lorsque plusieurs équipes utilisent un dépôt Git comme source unique de vérité pour l'ensemble du code d'infrastructure et de déploiement d'applications, elles appliquent une bonne pratique GitOps. Les équipes Infrastructure peuvent collaborer et déployer du code vers plusieurs services cloud en utilisant Terraform pour l'automatisation. Cet article explique comment les équipes peuvent créer un cluster Kubernetes en collaborant avec leurs collègues au sein de GitLab.
Premiers pas
Ce groupe gitops-demo illustre les étapes que les équipes Infrastructure peuvent suivre.
Commencez par vous connecter au groupe où se trouve le projet dans GitLab.
L'étape suivante consiste à ouvrir le fichier README.md, qui présente la structure sous-jacente du groupe gitops-demo. Il existe quelques projets individuels et deux sous-groupes : infrastructure et applications.
Il existe un dépôt distinct pour chaque cloud : Azure, GCP et AWS, ainsi qu'un dépôt pour les templates. Tous les fichiers sont écrits dans Terraform pour automatiser le processus de déploiement, tandis qu'un fichier gitlab-ci.yml est également stocké dans chaque dépôt pour fournir des instructions d'automatisation.
Le fichier backend
L'utilisation du service Terraform Cloud d'HashiCorp comme emplacement distant pour le fichier d'état permet de sécuriser ce dernier et de le placer dans un emplacement central afin qu'il soit accessible par n'importe quel processus.
L'un des avantages de Terraform Cloud est qu'il peut verrouiller l'état pour s'assurer qu'un seul job peut être exécuté à la fois, empêchant ainsi plusieurs jobs d'effectuer des modifications contradictoires. Le code stocke les fichiers d'état de Terraform Cloud dans une organisation appelée gitops-demo dans un espace de travail dénommé aws. Cela permet de conserver l'état d'exécution dans le fournisseur de services cloud, de sorte que n'importe quel membre de l'équipe peut y accéder à tout moment.
terraform {
backend "remote" {
hostname = "app.terraform.io"
organization = "gitops-demo"
workspaces {
name = "aws"
}
}
}
Les blocs de données dans la configuration Terraform permettent de récupérer des informations déjà existantes sur AWS lors de l'exécution du plan.
Le fichier EKS.tf
EKS est un autre fichier Terraform qui exploite le module EKS pour le cluster Terraform. Les équipes peuvent définir des paramètres tels que le type de sous-réseaux (subnets), le nom du cluster (cluster_name) et le nombre de nœuds dans le fichier terraform EKS.
module "eks" {
source = "terraform-aws-modules/eks/aws"
cluster_name = "gitops-demo-eks"
subnets = "${module.vpc.public_subnets}"
write_kubeconfig = "false"
tags = {
Terraform = "true"
Environment = "dev"
}
vpc_id = "${module.vpc.vpc_id}"
worker_groups = [
{
instance_type = "m4.large"
asg_max_size = 5
tags = [{
key = "Terraform"
value = "true"
propagate_at_launch = true
}]
}
]
}
Définir l'administrateur GitLab
Le fournisseur Kubernetes peut être utilisé pour créer un utilisateur administrateur GitLab, configuré automatiquement en tant que code et géré par Terraform.
Enregistrer le cluster avec GitLab
Maintenant qu'un cluster Kubernetes a été créé, il est temps de l'enregistrer auprès de GitLab afin de déployer plus de code sur le cluster à l'avenir. La première étape consiste à utiliser le fournisseur GitLab pour créer un cluster de groupe nommé aws_cluster.
data "gitlab_group" "gitops-demo-apps" {
full_path = "gitops-demo/apps"
}
provider "gitlab" {
alias = "use-pre-release-plugin"
version = "v2.99.0"
}
resource "gitlab_group_cluster" "aws_cluster" {
provider = "gitlab.use-pre-release-plugin"
group = "${data.gitlab_group.gitops-demo-apps.id}"
name = "${module.eks.cluster_id}"
domain = "eks.gitops-demo.com"
environment_scope = "eks/*"
kubernetes_api_url = "${module.eks.cluster_endpoint}"
kubernetes_token = "${data.kubernetes_secret.gitlab-admin-token.data.token}"
kubernetes_ca_cert = "${trimspace(base64decode(module.eks.cluster_certificate_authority_data))}"
}
Le code contient le nom de domaine, la portée de l'environnement et les identifiants Kubernetes.
Après cela, le cluster sera créé dans AWS et automatiquement enregistré dans le groupe gitops-demo/apps.
Template Terraform
Accédez au groupe infra et ouvrez le dossier Templates. En consultant le fichier terraform.gitlab-ci.yml, il est possible de voir comment l’intégration continue fonctionne pour déployer le code d'infrastructure dans le cloud à l'aide de Terraform.
Dans le fichier terraform.gitlab-ci.yml, les équipes peuvent voir un certain nombre d'étapes : valider, planifier, appliquer et détruire. En utilisant l'image de base Terraform d'Hashicorp, les utilisateurs peuvent exécuter différentes tâches.
La première étape consiste à initialiser Terraform.
before_script:
- terraform --version
- terraform init
- apk add --update curl
- curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/bin/linux/amd64/kubectl
- install kubectl /usr/local/bin/ && rm kubectl
- curl -o aws-iam-authenticator https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/bin/linux/amd64/aws-iam-authenticator
- install aws-iam-authenticator /usr/local/bin/ && rm aws-iam-authenticator
L'étape suivante consiste à valider que tout est correct.
validate:
stage: validate
script:
- terraform validate
- terraform fmt -check=true
only:
- branches
Il est important de se rappeler que les bons workflows GitOps intègrent la création d'une merge request pour les modifications.
Ce processus garantit que tout le code et les fichiers Terraform sont validés avant d'être fusionnés, assurant la cohérence et la qualité du déploiement.
merge review:
stage: plan
script:
- terraform plan -out=$PLAN
- echo \`\`\`diff > plan.txt
- terraform show -no-color ${PLAN} | tee -a plan.txt
- echo \`\`\` >> plan.txt
- sed -i -e 's/ +/+/g' plan.txt
- sed -i -e 's/ ~/~/g' plan.txt
- sed -i -e 's/ -/-/g' plan.txt
- MESSAGE=$(cat plan.txt)
- >-
curl -X POST -g -H "PRIVATE-TOKEN: ${GITLAB_TOKEN}"
--data-urlencode "body=${MESSAGE}"
"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests/${CI_MERGE_REQUEST_IID}/discussions"
artifacts:
name: plan
paths:
- $PLAN
only:
- merge_requests
La merge request
La merge request est l'étape la plus importante dans l'approche GitOps. Il s'agit du processus permettant d'examiner toutes les modifications et de voir leur impact. La merge request est également un outil de collaboration où les membres de l'équipe peuvent discuter des modifications et où les parties prenantes peuvent approuver les modifications avant qu’elles ne soient fusionnées dans la branche principale.
La merge request définit ce qui se produira lors de l'exécution de l'Infrastructure as Code. Le plan Terraform est téléchargé vers la merge request, une fois que celle-ci est créée. Quand toutes les modifications ont été examinées et approuvées, le code peut être fusionné dans la branche principale. Une fois les modifications de code fusionnées, toutes les modifications seront déployées en production.
Commencez à livrer des logiciels de meilleure qualité plus rapidement
Découvrez comment la plateforme DevSecOps intelligente
peut aider votre équipe.