Utilisation de GitLab et Terraform pour déployer l'Infrastructure as Code : démo

Lorsque plusieurs équipes utilisent un dépôt Git comme source unique de vérité pour toutes les infrastructures et le code de déploiement d'application, elles exécutent une bonne pratique GitOps. Les équipes Infrastructure peuvent collaborer et déployer du code sur plusieurs services cloud en utilisant Terraform pour l'automatisation. Cet article montre comment les équipes peuvent créer un cluster Kubernetes en collaborant avec leurs collègues au sein de GitLab.

Cette démo 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é et CI.

Premiers pas

Ce groupe gitops-demo illustre les étapes que les équipes infra 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 modèles.
Des fichiers similaires peuvent être trouvés dans les trois dépôts du cloud. 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 le dépôt pour fournir des instructions pour l'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. Les équipes peuvent définir des paramètres tels que le type de sous-réseaux 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é cluster AWS.

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.

Modèle Terraform

Retournez dans le groupe d'infrastructure et ouvrez le dossier Modèles. En regardant le fichier terraform.gitlab-ci.yml, il est possible de voir comment le CI fonctionne pour déployer le code de l'infrastructure dans le cloud à l'aide de Terraform.

À l'intérieur du fichier CI, les équipes peuvent voir certaines des différentes étapes : valider, planifier, appliquer et détruire. En utilisant l'image de base Terraform de 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.

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(MR) est l'étape la plus importante dans 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 la fusion finale dans la branche principale.

La merge request définit ce qui se passera 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.

• Que signifie Infrastructure as Code ?
• Qu'est-ce que GitOps ?
• Découvrez comment GitLab rationalise les workflows GitOps
• Découvrez l'avenir de GitOps auprès des leaders de l'industrie
• Lisez le guide du débutant sur GitOps