DevOps style !

Ce que beaucoup qualifiaient de mode s’installe de plus en plus durablement dans l’entreprise, 2020 n’échappe pas à la règle. Le nombre d’entreprises qui souhaite adopter le DevOps augmente de manière constante.

Mais déjà, mettons-nous d’accord sur le DevOps: un métier ? Une organisation ? Une culture ? Je soutiens que le DevOps est une culture de la collaboration afin de réduire les frictions entre les équipes par divers moyens (en particulier les Dev et les Ops) afin de réduire le time to market.

On parle d’ailleurs souvent des 5 piliers C.A.L.M.S pour Culture, Automatisation, Learn, Mesure et Solidarity, qui à mon sens couvrent assez bien les principes du DevOps. Cela ne doit néanmoins pas permettre de simplifier le DevOps à l’automatisation, comme je le voie trop souvent. On automatise depuis bien plus longtemps que celui-ci n’existe ! Si vous voulez plus d’informations, je parlais du DevOps l’année dernière par ici.

DevOps, DevSecOps, DataOps, DevQAOps, qui est le prochain ?

Ces derniers mois, voir années nous avons vu fleurir les différentes déclinaisons de l’abréviation DevOps, plus ou moins farfelues. Mais ces abréviations sont-elles que des mots en l’air ?

Alors oui et non, souvent ils sont utilisés pour créer un effet de “buzz words”, une technique de plus en plus présente dans nos métiers malheureusement. Il suffit de naviguer quelques minutes sur Linkedin pour s’en rendre compte. Mais passons au-delà de cela, le DevOps a bien évolué. D’ailleurs, j’aime voir la culture DevOps étant elle même itérative. En effet, pour moi c’est avant tout se retrouver autour d’une table, qu’on pourrait matérialiser par la chaine de déploiement continue, et au fur et à mesure des années, nous avons ajouté toutes les équipes nécessaires à cette table, la Quality assurance (les testeurs), la sécurité, la Data, etc.

Donc au final c’est une évolution logique, mais pour autant le terme doit-il évoluer ? Personnellement, je ne pense pas que ça soit pertinent de sortir de nouvelles abréviations chaque fois que l’on invite une nouvelle personne à sa table. De plus cela doit rester agile, chaque projet ne nécessite pas d’impliquer pleinement un ingénieur donné, il faut rester pragmatique. Il serait ridicule à mon avis de mettre tout dans une abréviation.

Néanmoins il y a deux termes qui me semblent plus pertinents dans cette liste. DevSecOps tout d’abord qui à mon sens doit plus traduire une vraie compréhension des nouveaux paradigmes et une implication dans le DevOps de la part des équipes sécurités ce qui est encore trop rare. Il y a aussi GitOps, qui est très à la mode est de ce que j’en voie se définit simplement par le fait d’avoir son dépôt Git en unique source de vérité. Rien de transcendant là encore des années maintenant que l’on centralise un maximum de chose dans le versionning y compris côté infrastructure.

Niveau technologie, Kubernetes gagne par K.O

Le nombre de technologies augmente constamment comme on peut le voir sur cette cartographie de la Cloud Native Foundation Landscape.

Malgré cela j’ai l’impression que globalement le marché se polarise autour de solutions qui deviennent des standards. On peut voir des technologies comme Terraform, Packer, Vault et bien sûr Kubernetes être devenues des standards dans la grande majorité des projets. Cela traduit à mon sens une certaine maturité de ses technologies.

Ces différents outils ne sont pas pour autant parfaits et sont souvent utilisés dans des situations où d’autres feraient surement mieux. Nous sommes donc en droit de se demander pourquoi un tel succès. La raison est plutôt simple la maintenance et le suivi, il sera toujours bien plus difficile de trouver de la compétence sur une technologie pointue de niche que pour une solution générique comme Kubernetes. Ajoutez à cela la loi du marché et les difficultés à trouver des modèles rentables, beaucoup de concurrents ont simplement disparu. Et ne nous mentons pas même si ces outils ne demeurent pas parfaits, ils comportent tout de même pas mal de qualités non négligeables.

Le DevOps enfin mature ?

La maturité est avant tout un état de stabilité et je pense que nous avons atteint une certaine maturité. Le DevOps est bien implanté aujourd’hui dans nos métiers et les paradigmes qui l’accompagnent aussi (Pet vs Cattle, Infra As Code…). Néanmoins, il faut avoir conscience qu’une grande partie des entreprises en est encore très loin et n’y passera peut-être jamais.

On pourrai être tenté de définir la maturité du DevOps par son taux d’adoption. Sur ce point j’émets énormément de réserve. Une grande partie des entreprises n’aura jamais le besoin de passer au DevOps. Et surtout parce que le DevOps n’est pas une magie, pour que la démarche soit efficace il faut investir et se remettre en question. Ce n’est pas donné à toutes les organisations.

Cette maturité ne signifie pas que le DevOps ne va pas changer et évoluer, mais cela va se faire moins brutalement et restera une évolution naturelle.

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.

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.

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 !

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.

Pourquoi cette idée ?

Je me suis souvent demandé quand peut-on considérer être mature au niveau de notre chaîne CI / CD. Beaucoup de réponses existent, le nombre de déploiement, le ratio de succès etc… Mais bon, les KPIs (key performance indicator) c’est pas la solution la plus fun. J’ai donc cherché une autre solution, moins conventionnelle. Et je me suis dit que mettre un bouton physique au milieu du bureau permettant à n’importe qui de déclencher un pipeline de déploiement, était une preuve suffisante et assez fun pour être mise en place sur mon blog. Vous vous en doutez si vous lisez ces lignes, je vais expliquer comment j’ai fait et comment faire la même chose !

L’heure des choix

La première tâche fut de trouver un bouton physique me permettant de déclencher une action et répondant à quelques caractéristiques, être indépendant de mon téléphone ou ordinateur, coûter moins de 50€. J’ai fait quelques recherches et au vu de la stack de mon blog (AWS et Gitlab), j’ai très rapidement décidé d’acheter la solution d’AWS : AWS IoT Entreprise. Peu cher, il est totalement compatible avec la solution IoT Internet of Things d’AWS, il nécessite uniquement une connexion wifi. Le seul gros défaut étant la pile qui n’est pas remplaçable, mais assez endurante pour que je passe à l’achat (~3000 clics).

Voilà une petite photo du bouton (avec le guide plus que sommaire qui vous renvoie vers la documentation d’AWS) :

Passage à l’action

Pour le fonctionnement ça va être assez simple, le bouton va en 1 clic déclencher l’API AWS IoT qui va executer une Lambda afin de lancer la pipeline Gitlab CI (grâce à l'API REST). Globalement on peut schématiser cela comme ci-dessous :

La mise en place est rapide et bien documentée (Documentation Amazon). Mais je vais vous la détailler globalement.

Une fois que vous avez reçu votre bouton, la première étape est de le configurer afin qu’il accède au wifi afin d’interagir avec l’API AWS. Le plus simple pour ça est d’utiliser l’application Android / Appel 1-Click. Il suffira ensuite de vous connecter sur l’application et de scanner le code barre présent sur la boite, ensuite vous aurez juste à ajouter l’appareil et lui donner les informations du wifi. C’est aussi à partir de cette application que vous pouvez mettre à jour le firmware du bouton.

Une fois le bouton paramétré il faudra l’associer à votre compte AWS (à partir de là l’application n’est plus nécessaire). Il faudra juste vous rendre dans le service managé “IoT 1-Click” et entrer le numéro de série du bouton, il vous sera demandé de cliquer une fois sur le bouton pour valider l’association. Celui-ci va ensuite apparaitre dans l’interface AWS, en désactivé dans un premier temps il ne restera qu’à le sélectionner et faire activer.

Une fois le bouton enregistré, j’ai créé le token REST permettant de lancer le pipeline de déploiement Gitlab. Pour cela dans le projet Gitlab, je me suis rendu dans : “Settings => CI / CD => Pipeline triggers” et il a suffit de donner un nom et d’ajouter ce nouveau déclencheur. Il vous donne ensuite un token qu’il vous faut conserver pour déclencher la pipeline et quelques exemples.

Ensuite j’ai créé une fonction Lambda, il s’agit d’un service permettant d’executer un code donné à la volé. L’execution de celui-ci peut-être déclenchée par d’autres services AWS ou encore par l’API. Le code est assez simple et a uniquement pour but d’effectuer une requète POST sur API Gitlab. Pour cela j’ai écrit le code suivant (en Python 3) :

import urllib.request, urllib.parse, os

def lambda_handler(event, context):

    data = {
        'token' : os.environ['TOKEN'],
        'ref' : os.environ['REF']
    }

    data = bytes( urllib.parse.urlencode( data ).encode() )
    handler = urllib.request.urlopen( 'https://gitlab_URL.com/api/v4/projects/5/trigger/pipeline', data );

Le code est relativement simple, il récupère le token (généré précédemment) et la ref (tag ou branche) qui ont été placées dans des variables d’environnement avant de les envoyer au travers d’une requête POST à mon instance Gitlab. A ce stade on a notre bouton enregistré sur AWS, une Lambda qui peut à la demande déclencher une pipeline Gitlab à l’aide de l’API REST. Il ne reste qu’à faire le lien et pour cela nous allons retourner sur AWS IoT 1-Click.

Il vous suffit alors dans le service de créer un nouveau projet, de le nommer et ensuite il vous demandera ce que vous souhaitez déclencher au clic, vous avez plusieurs choix : envoyer un SMS, un mail ou lancer une Lambda. L’on choisi donc d’executer la Lambda précédemment créée.

Et voilà c’est tout ! À chaque clic désormais le bouton va exécuter la Lambda qui va lancer une pipeline Gitlab afin de déployer le blog DamyR.fr

Inutile donc indispensable ?

Au-delà du côté fun du projet, je pense que c’est une bonne introduction à l’IoT avec le cloud AWS. Et bon on va pas se le cacher, mais déployer à tout moment son site d’un clic de bouton sur son bureau c’est assez classe ;)