03 Apr 2020, 12:21

Faire son premier module Terraform

Aujourd’hui on va parler d’Infrastructure as Code (IaC), plus exactement comment créer un module Terraform, mais avant de faire tout ça on va redéfinir tous ses termes et leurs intérêts.

Header Article Terraform

Coder l’infrastructure ?

Je pars du postulat que vous connaissez voir pratiquez Terraform, et au moins les bases et l’infrastructure as code. Mais avant de se jeter dans le code, on va revoir pourquoi en est-on arrivé là.

Si vous remontez il y a une petite décénnie dans la vie d’un administrateur système, celui-ci vous parlera sûrement de son dada favori : l’industrialisation, aussi appelé gestion de configuration. Cela lui permet de déployer et de versionner efficacement toutes les configurations des systèmes d’exploitation et des middlewares avec des solutions comme Puppet, Chef, Ansible ou autres.

Mais avec le DevOps mais aussi surtout avec le cloud, on a eu besoin de gérer plus efficacement et avec plus de flexibilité la couche inférieure, c’est-à-dire les machines. De plus avec le cloud public, il est devenu de plus en plus courant avec les services administrés de gérer des configurations de middlewares au niveau infrastructure. La boucle étant bouclée, après avoir codé les configurations on a donc codé l’infrastructure.

Bon ok on a fait l’historique du truc, mais revenons à nos moutons, pourquoi fait-on de l’infrastructure as code ? Globalement pour les 4 raisons suivantes :

  • Possibilité de gestion des versions, aussi appelé GitOps : en décrivant l’infrastructure au travers de code on peut facilement tracer les évolutions, revenir en arrière en coupellant le code à un outil tel que Git. À mon avis, c’est le plus gros point il permet une véritable collaboration sur la partie infrastructure, c’est très important dans le cadre DevOps.
  • Auditabilité : l’infrastructure étant du code centralisé, on peut rapidement à un même endroit vérifier toute la configuration des machines.
  • Reproductibilité : Si demain vous devez faire 3 environnements, vous n’aurez pas à refaire 3 codes si vous l’avez bien codé, évidemment.
  • Automatisation : C’est bien plus simple d’automatiser un processus reposant sur du code que des clics sur une interface graphique. Et cela ne s’arrête pas là, on peut aussi automatiser certains des points précédents grâce à ça.

Fais ton premier module

J’ai fini mon blabla historique, mais c’est toujours plus simple quand les enjeux et le but sont définis. Revenons à un sujet plus technique, comment faire son premier module Terraform. Si vous ne connaissez pas, les modules Terraform permettent de faire des ensembles de ressources packagés. Globalement, si vous êtes plus à l’aise avec le monde sur développement, cela équivaut à faire une librairie pour éviter de redévelopper la même chose à chaque projet.

Terraform n’est pas magique, on peut faire du mauvais code Terraform qui va complexifier l’exploitation alors que le but est totalement l’inverse. Pour cela il est important de faire un code clair, variabilisé et respectant un minimum les bonnes pratiques, certaines se retrouvent sur le site officiel. Une des bonnes pratiques est notamment de ne pas ré-écrire de code et de bien organiser celui-ci, pour cela Terraform vous propose de faire des modules ! Mais ce n’est pas forcément simple de débuter sur cette nouvelle notion, surtout si vous n’avez pas l’habitude de développer. C’est pour cette raison que nous allons le faire ensemble !

Pour faire notre premier module, je pense que le mieux est de prendre un exemple simple et d’en faire un module, réutilisable et efficace. Un exemple qui me semble parlant et simple est de faire un module permettant la création d’un site statique, comme ce blog.

Schéma module

On commence par le coeur de notre infrastructure : le bucket S3, c’est lui qui va héberger nos fichiers. On va donc créer 3 fichiers pour commencer : variables.tf, outputs.tf et main.tf. Nous allons y mettre le code de notre S3, en variabilisant ce qui est nécessaire. Voici ce que cela donne :

  • main.tf
ressource "aws_s3_bucket" "this" {
  bucket = var.name
  acl    = "public-read"

  cors_rule {
    allowed_headers = ["*"]
    allowed_methods = ["PUT", "POST"]
    allowed_origins = ["*"]
    expose_headers  = ["ETag"]
    max_age_seconds = 3000
  }

  policy = <<EOF
{
  "Id": "bucket_policy_site",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "bucket_policy_site_main",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::${var.name}/*",
      "Principal": "*"
    }
  ]
}
EOF
  website {
    index_document = var.index
    error_document = var.error
  }

  tags = {
    name = var.name
  }
}

  • variables.tf
variable "mame" {
  description = "The name of the S3 bucket"
  type        = string
  default     = "static-blog"
}

variable "index" {
  description = "The name of website index files"
  type        = string
  default     = "index.html"
}

variable "error" {
  description = "The name of website error files"
  type        = string
  default     = "error.html"
}

  • outputs.tf

output "name" {
  description = "The name of S3 bucket"
  value       = var.name
}

J’ai volontairement mis uniquement le code des ressources, si vous souhaitez tester à cette étape, ajoutez votre provider AWS.

Comme vous pouvez l’observer, la structure est assez classique. On définit d’abord les paramètres dans le fichier variables.tf puis les sorties dans le fichier outputs.tf et pour finir le code principal du module dans le fichier main.tf.

Moduleception

Notre module va contenir plusieurs composants Cloudfront, S3 et ACM. Nous souhaitons garder un code propre et évolutif facilement donc nous allons déjà tout réorganiser. Ne vous inquiétez pas ça va être simple et efficace.

Revenons d’abord sur la notion de module dans Terraform. Ils peuvent avoir deux périmètres :

  • Locaux vous placez votre module directement dans un répertoire de votre projet et il sera réutilisable de l’extérieur, mais le versioning sera dépendant du projet courant. Il est donc préférable de réserver l’utilisation de ceux-ci au projet courant afin de structurer le code pour le rendre plus facilement maintenable et réutilisable. On pourrait comparer ceci avec les fonctions en développement. Pour appeler ce module, vous donnerez le chemin relatif de votre module.
  • Générique, votre module est conçu pour être utilisé par divers projets. Il sera indépendant du projet qui l’appelle. Pour appeler ce module, vous donnerez en général le répertoire Git de celui-ci. Je vous conseille fortement, en plus des bonnes pratiques d’utilisation de Git, d’apporter une grande importance au tagging des versions pour ce type de module. Cela permet de partager des parties de codes en les standardisant pour les utiliser dans plusieurs projets. En cas de mise à jour de Terraform ou du module, cela vous permettra de gérer aux mieux les différentes versions.

Pour vous donner l’exemple le plus complet possible, nous allons faire un projet générique que vous pourrez appeler à partir de votre propre projet Terraform. Pour organiser au mieux ce code, nous allons le découper lui-même en 3 modules locaux.

À vos claviers, CODEZ !

Voici l’arborescence que nous allons créer :

├── main.tf
├── variables.tf
├── outputs.tf
├── README.md
└── modules
    ├── cloudfront
    │   ├── main.tf
    │   ├── outputs.tf
    │   ├── README.md
    │   └── variables.tf
    ├── redirect
    │   ├── main.tf
    │   ├── outputs.tf
    │   ├── README.md
    │   └── variables.tf
    └── s3
        ├── main.tf
        ├── outputs.tf
        ├── README.md
        └── variables.tf

On remarque les 4 modules locaux, placés dans le dossier local du projet modules. Nous allons déplacer le code précédemment réalisé dans le module S3 afin d’organiser le code.

Dans le fichier main.tf principal, nous appellerons ce nouveau module comme il suit. Vous noterez la source qui est locale et relative au projet:

module "s3" {
  source  = "./modules/s3"

  name  = var.domain
  index = var.index
  error = var.error
}

On note aussi les paramètres permettant de passer des variables afin de rendre le code le plus générique et le plus réutilisable au possible.

Bien sûr, pour un exemple aussi simple il n’est pas recommandé de découper le code en autant de modules locaux, encore une fois cela est plus donné à titre d’exemple.

Vous pourrez ensuite placer ce code dans un répertoire Git et l’appeler à partir d’autre projet comme ceux-ci. Dans cet exemple on précise même un tag : source = "git@github.com:damyrfr/module-static-web.git?version=v1.2.0"

C’est aussi simple que cela. Je ne vais pas vous passer les différents modules en revue, il s’agit des mêmes principes. Si vous êtes intéressé, voici le lien du projet mod-terraform-static-site contenant l’ensemble du code présent sur mon GitHub DamyrFr. Celui-ci n’est pas parfait, n’hésitez donc pas à l’améliorer !

À retenir !

Conclusion Article Terraform

Comme vous l’avez vu, le principe des modules sous Terraform est assez simple. Je pense que leur utilisation est primordiale pour organiser son code et surtout favoriser la réutilisation de celui-ci. Néanmoins, même si la notion de module est simple il est nécessaire de bien variabiliser et standardiser celui-ci pour être efficace.

Je profite de cet article pour vous donner quelques petites habitudes qui me semblent importantes dans le cadre de développement Terraform :

  • Avant de commit son code toujours faire un petit terraform fmt, cela permet automatiquement de formater proprement le code.
  • Varibiliser votre code, sans cela vous aller souvent être amené à refaire des choses plusieurs fois, tout l’inverse de ce que l’on souhaite.
  • Documenter votre code, globalement, son utilisation et les entrées / sorties. Pour cela je vous invite à consulter la page du projet terraform-docs.
  • Placez votre code sur Git et surtout collaborez, travaillez sur des branches, faites des merges requests et des revues de code.
  • La plupart de ses actions peuvent être automatisées à partir de pre-hook-git, veuillez noter que le répertoire Git en contiens un. Pour cela je vous invite a lire cet article: Le Blog WeScale - Vers l’Infrastructure Craftsmanship avec les Git Hooks

Comme pour beaucoup de choses en informatique la meilleure solution pour progresser, c’est la pratique. Faites des modules, lisez les sources d’autres, proposez des merges requests.

09 Apr 2019, 22:14

DevOps ou pas DevOps telle est la question

Le DevOps en 2019 ? Toujours à la mode ?

Hé oui, même si le mouvement a clairement bénéficié d’un gros effet de mode, il a su démontrer son utilité et efficacité ces dernières années. Étant un sujet que j’apprécie beaucoup, je trouvais intéressant de faire un état de l’art de celui-ci maintenant qu’il a atteint une certaine maturité.

Mais avant tout revenons à la base, qu’est ce que le DevOps ? Pour beaucoup en cette année 2019, cette question parait triviale mais j’ai remarqué que ce n’est pas toujours très clair et simple à comprendre.

DevOps késako ?

Je suis toujours surpris d’entendre des gens penser que le DevOps a pour vocation de remplacer les métiers de développeur et d’administrateur système par un unique métier générique. Cette confusion est encore assez régulière (notamment à cause de la composition du terme), surtout chez les personnes qui ne sont pas du métier (dirigeants, managers, commerciaux). J’aime donc utiliser cette métaphore, après tout un boulanger et un boucher font tout deux de la nourriture, mais ce n’est pas pour ça qu’un boucher saura vous réaliser une baguette. Alors, pour bien comprendre ce qu’est le DevOps, revenons quelques années en arrière.

      Il était une fois ….

Aux alentours de 2007, le marché du web s’est transformé et surtout il est devenu hyper concurrentiel. Il faut développer les nouvelles fonctionnalités plus rapidement que le concurrent pour s’adapter au marché afin de gagner plus de clientèle. Pour cela les méthodes Agile et particulièrement Scrum ont permises de s’adapter et de créer de manière itérative sur des durées réduites (sprints) des fonctionnalités et donc répondre aux besoins de développement rapides. Malheureusement cela ne répondais que partiellement au problème, les fonctionnalitées développées n'étant pas livrées au rythme des sprints. Les équipes d’administration système (ops) étant sur des cycles longs (comme le cycle en V) et pas assez outillés pour faire preuve d’agilité sur les déploiements applicatifs. Le temps entre l’imagination d’une fonctionnalité et son passage en production, aussi appelé Time to Market était resté élevé.

Infrastructure

Il faut bien comprendre que dans un marché aussi versatile que le web moderne, le Time to market est essentiel à la survie. Prenons un exemple, celui des sites de rencontre. C’est un modèle qui n’a dans un premier temps que peu évolué, les acteurs étant stables sur le marché et les sites similaires. Mais il y a quelques années un acteur est venu casser le marché, vous le connaissez au moins de nom Tinder, l’acteur à débarqué sur le marché des acteurs classiques avec un modèle très différent qui lui a permis de capter un grand nombre de client rapidement. Pour cela les sites de rencontre historiques, ont dû s’adapter rapidement pour continuer de fonctionner.

C’est pour répondre à ce problème que la culture DevOps s’est développée. Elle va promouvoir principalement deux choses, le rapprochement entre Dev et Ops afin d'échanger et de travailler ensemble et l’automatisation d’un maximum de tâches afin de pouvoir multiplier les déploiements. Pour faire cela, de nombreux outils vont apparaître comme Gitlab, Jenkins, Docker, Terraform, le cloud public, etc. et gagner en popularité. Les paradigmes comme par exemple l’Infra As Code ou encore le pet vs cattle vont eux aussi connaitre un fort succès.

      …tl dr

Le DevOps ce n’est pas une personne qui va remplacer vos développeurs et vos administrateurs par un métier générique, ni un moyen de réduire les coûts de projet. Le DevOps demande un coût plus important, notamment lors la mise en place des outils.

Alors qu’est-ce que le DevOps ? C’est une culture, un ‘mind-set’ qui vise à promouvoir le travail collaboratif entre les différentes équipes et l’automatisation maximum du cycle de déploiement afin de livrer régulièrement avec le moins de douleur possible.

DevOps quoi de neuf à l’horizon

      L'équipe s’agrandit !

Aujourd’hui le DevOps a un peu plus de 10 ans et il a beaucoup évolué durant ces années. On peut donc se demander si on a fait le tour des possibilités que le domaine offre. Comme nous l’avons vu dans la définition du DevOps, il s’agit de passer l’agilité à toutes les équipes (développeur et administrateur). Mais déployer régulièrement du code tout en conservant un certain niveau de qualité impacte d’autres équipes. Ces équipes notamment les équipes de test (QA) et les équipes de sécurité sont aujourd’hui en train de rejoindre cette démarche et de s’intégrer dans ce fonctionnement. Il est de plus en plus recommandé de penser à ces aspects dès le début et de les intégrer directement au processus de déploiement. Je conseil d’ailleurs fortement de mettre en place dans votre chaine CI des tests aussi bien unitaires, que end to end mais aussi, des scans de sécurité et d’autres automatismes.

      Ne parlez plus monitoring

Le DevOps a changé pas mal la manière de concevoir les applications les plus complexes. Rapidement l’approche microservice est apparue afin gérer des applicatifs avec un grand nombre d’interactions. Cela pose pas mal de problèmes notamment dans le monitoring où il ne suffit plus de se contenter du “bon vieux Nagios” qui va vérifier les ressources du système et nous dire si son état est “OK” ou “KO”. Pour cela il ne faut plus penser monitoring mais, observabilité. On ne va plus remonter l'état binaire d’un service mais, des métriques qui vont refléter son état. Par exemple, on peut relever sur un site commerçant le nombre de ventes ou de visites par minutes ce qui nous permettra de déduire le taux de transformation (visites converties en achats). Toutes ces métriques vont aussi nous permettre de déduire la santé du fonctionnement du système de manière plus précise ainsi que le temps de réponse des différents sevices.

Grafana

      Toi aussi optimise les coûts !

Le cloud a apporté beaucoup de flexibilité dans la gestion des ressources, il est aujourd’hui très simple de permettre à une infrastructure de se mettre à niveau en fonction de la demande. Cela permet de s’adapter au trafic à coût moindre. Mais aujourd’hui les factures des infrastructures sont très rapidement importantes, un nouvel aspect du métier est donc apparu, le FinOps. Son but est simple, faire autant ou plus pour moins en utilisant la flexibilité du cloud et donc optimiser la facture. L’un des exemples les plus connu est l’optimisation des environnements de préproduction, il est intéressant de les stopper en heure non ouvrées et d’utiliser des instances à bas coût sur AWS (instance Spot). Des optimisations de ce genre mises bout à bout à l'échelle d’un projet peuvent rapidement offrir de belles réductions qui sont très appréciées des entreprises.

That’s it ?

Le DevOps est aujourd’hui un sujet très complet et très diversifié aussi bien dans le nombre d’approches que dans les outils. Je suis loin d’en avoir fait le tour et un très grand nombre de pratiques n’ont pas été abordées. La plupart sont connues et déjà abordé par les grands groupes (Google, Amazon, Netflix etc…) qui mettent des moyens colossaux dans la R&D pour répondre à ces problématiques. Or aujourd’hui, il y a un réel enjeu à adapter cela sur d’autres entreprises et les accompagner sur cette transformation. Il s’agit bien sur une vision personnelle de ce domaine qui m’intéresse beaucoup et que je souhaitais partager avec vous.

31 Oct 2018, 18:42

L'infrastructure du blog V 1.0

Maintenant que le blog est bien en place et qu’il est techniquement fonctionnel, je me suis dit qu’il serait intéressant de faire un petit point sur l’infrastructure que celui-ci utilise :) Le but n’est pas de vous donner un tutoriel pour chaque composant, beaucoup étant existant et très bons. Mais de vous expliquer mes choix et vous donner mon ressenti sur les solutions mises en place.

Infrastructure et choix

Les choix effectués sont très orientés nsa compliant cloud public, même si j’avoue préférer les solutions de cloud privé, notamment pour des raisons de confidentialité. Malgré cela 3 points m’ont orienté vers les solutions cloud public :
- Le rapport qualité / coût pour un hébergement de site statique. Les services utilisés (S3 et Cloudfront) permettent d’obtenir une disponibilité de près de 99,99%. Tout cela avec des performances franchement sympa, merci le CDN. Le tarif est relativement faible (entre 1 et 2 € par mois).
- Le cloud public offre pas mal de possibilités assez sympa que je souhaite tester pour augmenter mes compétences (notamment pour ma vie professionnelle).
- Le côté infra as a code très facile d’accès avec Terraform

Avant de commencer, voyons un petit schéma pour avoir une vue d’ensemble (c’est relativement simple) :

Infrastructure

On y retrouve :
- Un bucket S3 qui va être utilisé pour stocker les sources du site générées par Hugo, mais j’y reviendrai plus tard.
- Une distribution Cloudfront, qui est un CDN (système de cache à l'échelle mondiale).
- Un Gitlab CI avec les runners qui vont biens pour versionner les sources et permettre de déployer automatiquement.

Le socle d’infrastructure (Terraform / AWS)

Amazon Web Service, plus communément appelé AWS est le service de public cloud d’Amazon. Il s’agit de l’un voire du service cloud public le plus connu. Il propose de nombreux services server-less managés. Ce qui permet de rapidement mettre en place des services sans se préoccuper de leurs installations, mises à jour et maintenance. C’est plutôt performant, pratique et uniquement facturé à la consommation. Après cela reste du cloud public, on n’a pas de vision sur ce qui se passe dans le datacenter et une fois chez eux on est assez dépendant de leurs services.

Mais ce qui est intéressant c’est que tout ça permet de créer et scaler à la volée tout ce qui est nécessaire dans une infrastructure, par exemple pour un site. C’est donc assez alléchant. En quelques minutes et quelques clics, il est donc possible de créer tout le nécessaire pour créer le blog, le stockage des sources (bucket S3), la distribution (CDN Cloudfront) et la génération de certificat. Mais bon on est pas encore tout à fait DevOps là, il reste pas mal d’actions manuelles qu’il serait très chronophage de reproduire.

Pour régler le problème, a émergé ce qu’on appel l’infra as a code, qui a pour but de provisionner son infrastructure avec du code. Pour cela plusieurs outils existent il est même possible de le faire à partir de logiciel d’industrialisation comme Saltstack ou encore Ansible. L’un des outils les plus connu et utilisé pour faire de la provision sur le cloud public reste Terraform. C’est un outil Open Source en Go édité par HasiCorp (comme Vault, Vagrant etc…). Il utilise des connecteurs lui permettant de s’adapter à divers providers, comme AWS, Azure, Vsphere ou encore OVH liste complète. Une fois celui-ci configuré, vous n’avez qu'à décrire les diverses ressources que vous souhaitez créer.

Voici un exemple très simple de code Terraform utilisé par le blog :

variable "bucket_site" {
	default = "static-blog-tge"
}

resource "aws_s3_bucket" "static_blog" {
    bucket = "${var.bucket_site}"
    acl = "public-read"

    cors_rule {
    	allowed_headers = ["*"]
    	allowed_methods = ["PUT","POST"]
    	allowed_origins = ["*"]
    	expose_headers = ["ETag"]
    	max_age_seconds = 3000
    }
}

Dans cet extrait, on déclare une variable “bucket_site”, qui va contenir le nom du bucket. Ensuite on décalre une ressource, c’est à dire un objet AWS S3 dans notre cas en utilisant la variable créée précédemment.

Si vous souhaitez tester, le guide de démarrage du site officiel est assez clair Lien.

La génération du site statique (Hugo / Markdown)

Je voulais un blog qui me demanderait que peu d’entretien, pas avoir besoin de mettre à jour dans l’urgence régulièrement (même si cela aurait pu être automatisé), pas de problème de plugin, de performance, etc. Le plus simple pour ça étant de créer un blog statique. Par statique, comprenez qu’il s’agit uniquement de pages web déposés dans un buket accessible de l’extérieur. Le contenu est donc directement dans des pages HTML et n’est pas stocké dans une base de données.

Cela ne veut pas dire que nous allons écrire toutes les balises et les pages à la main (même si cela est possible). Il est en général conseillé d’utiliser un générateur de site statique. Globalement deux générateurs de site statiques sont actuellement très populaires, il s’agit de Jekyll et Hugo. J’ai choisi Hugo assez rapidement, même s’il ne supporte pas les plugins contrairement à son concurrent. Il est plus facile à prendre en main et il permet de générer des sites très performants rapidement (génération en quelques secondes).

Hugo s’utilise directement en CLI (un paquet est disponible dans les dépôts Debian). Il est ensuite assez simple de générer des articles qu’il faudra rédiger en Markdown. Si vous souhaitez voir comment ça fonctionne, voici un petit guide de base assez bien fait Lien

La CD (Gitlab CI)

Donc nous avons notre belle infra cloud qui est provisionnée par du code, c’est bien est plutôt sympa. Mais bon maintenant qu’on a tout ça et qu’on a tout mis sur git, ça serais encore plus sympa si à chaque push Gitlab testait les modifications et les déployait à notre place non ?

C’est là qu’arrive la partie que je trouve la plus fun, le déploiement continue (Continuous Delivery) ! On peut dire que c’est le but final de la majorité des DevOps, arriver à tout automatiser afin que le workflow s’enchaine automatiquement du test à la prod. Cela fait gagner beaucoup de temps, mais pour cela il est vital de passer assez de temps pour prévoir des tests automatiques robustes. C’est bien beau de déployer automatiquement, mais si cela crée des régressions ou bien des problèmes de sécurité c’est déjà moins sympa.

Pour mettre en place du déploiement continue sur ce site j’ai utilisé Gitlab CI. Le grand avantage est qu’il est très facile de passer d’un simple Gitlab à Gitlab CI, il suffit de configurer des “runners” qui vont exéctuer les étapes de la CD (que je fais fonctionner dans des Dockers) et ensuite de créer un fichier .gitlab-ci.yml dans le root du projet. C’est le fichier .gitlab-ci.yml qui va contenir tout votre enchaînement d’étapes, quoi faire (compiler, générer, tester, etc.), quand (automatiquement, si le job précédent est valide, manuellement, etc.) , où (sur quel runner).

Au final pour le site, j’ai décomposé ça en 2 projets git différents, donc 2 workflows de CD différents :

  • L’infrastructure, qui contient tous les fichiers Terraform permettant de provisionner l’infrastructure. Ici ce n’est pas totalement automatisé dans la mesure où, il fait un différentiel pour voir les modifications apportées (Terraform plan) à l’infrastructure et ensuite il faut valider pour appliquer les modifications (Terraform apply).
  • Les sources, qui lui contient les fichiers Markdown permettant de générer le site avec Hugo. La mise à jour est totalement automatique, si je push sur git des modifications automatiquement il va le déployer en suivant 3 étapes. Il génère tout d’abord le site avec le client Hugo. Il teste ensuite que les fichiers sont bien générés. Et si tout est bon il déploie les nouveaux fichiers sur le bucket S3 et invalide la cache pour mettre à jour le CDN.

Voici un exemple d'étape utilisée par ma CI :

apply:
  stage: apply
  environment:
    name: production
  script:
    - terraform apply -input=false $PLAN
  dependencies:
    - plan
  when: manual

Il s’agit de l'étape finale de la CI Terraform qui a pour but d’appliquer les modifications qui ont été faites sur Terraform. Vous pouvez reconnaître le format yaml, qui est le format utilisé par le fichier .gitlab-ci.yml. Ce morceau de code définit une étape qui s’appelle “apply” qui va effectuer un terraform apply sur l’environnement de production. Elle doit-être déclenchée à la main (cf when) et uniquement sur réussite de l'étape “plan”.

Si vous souhaitez en apprendre plus sur le fonctionnement de Gitlab et Gitlab Ci je vous conseille fortement la documentation officielle qui est très complète Lien.

Mon avis sur la stack

Voici donc la petite stack utilisée pour mon blog actuellement. Dans l’ensemble, je la trouve assez solide est assez agréable à maintenir notamment grâce à la CI / CD. Elle m’a aussi permis de mettre en pratique pas mal d’outils comme Terraform, Gitlab ou encore AWS. Le résultat obtenu correspond à ce que je recherchais, un blog simple, nécessitant peu de maintenance et performant à moindre coût. Je suis donc assez satisfait du résultat. J’ai notamment beaucoup apprécié l'écosystème offert par Gitlab que j’ai trouvé très fonctionnel et complet, il est dommage que cette expérience de Gitlab soit dégradée suite aux fuites mémoires régulières de celui-ci.

Après il me reste pas mal de choses à améliorer pour que cela soit encore plus obtimal. Notamment en ajoutant du monitoring, qui est pour l’instant inexistant. Je pense mettre en place du monitoring actif à terme, qui pourrait redéployer le site en cas d’erreur sur celui-ci. Le workflow CI du déploiement du site pourrait lui aussi être amélioré, en ajoutant notamment un test de perfomances et une étape de correction automatique d’orthographe.

Je pense que cela donne un bon exemple simple démontrant les possibilités qu’offres ces différentes technologies. Je vous tiendrai au courant des futures améliorations de ce site.