28 Nov 2020, 14:00

AWS tombe, l'internet tremble

AWS tombe

Mercredi 25 novembre, plusieurs sites et services sont indisponibles, internet tremble. Les pages de statut virent aux rouges écarlates, les unes après les autres. Très rapidement sur les réseaux sociaux, on voit des situations parfois cocasses être remontées. Je pense notamment à des personnes qui se retrouvent bloquées hors de leurs habitations, la serrure connectée étant totalement dépendante du service en ligne. Des situations qui peuvent prêter à sourire, mais qui peuvent être plus dramatiques quand on les subit surtout avec le nombre d’objets connectés grandissant notamment dans le secteur de la santé.

Panique sur Twitter

Comme vous le savez surement, j’utilise pas mal Twitter (@damyr.fr), et j’ai pu voir en direct beaucoup de réactions avec un peu de tout. Mais je vais revenir plus particulièrement sur un type de réaction, celle des anti-GAFAM. À savoir qu’à titre personnel je suis globalement opposé à beaucoup de choses sur les GAFAMs et opposé à pas mal d’abus. Mais comme à chaque fois, j’ai vu des réactions, notamment de libriste que j’apprécie réagir à coup de : “AWS est down comme quoi ça ne vaut rien”, “Voilà ce qui vous en coutera d’héberger vos données chez AWS”

Alors, qu’on les aime ou pas AWS est surement aujourd’hui le service de cloud le plus au point. Que cela puisse arriver ne prouve rien, et ça arrive aussi aux acteurs locaux, OVH a déjà connu de grosses pannes. Les attaques sur l’aspect technique d’AWS qui a fait ce qui était à faire : informer, isoler et corriger le problème sont hors de propos et ne font que mettre en avant une méconnaissance du sujet. Encore une fois, les GAFAMs posent beaucoup de soucis, mais il ne faut pas se perdre a les attaquer sur des aspects comme ceux-là où, il faut le reconnaitre ils travaillent bien, cela fait juste perdre en crédibilité.

J’ai eu aussi l’occasion de tomber sur 2,3 articles web allant parfois jusqu’à décrire AWS comme le centre d’internet. Même si AWS est un grand acteur, ce n’est pas internet, c’est un bout d’internet, mais il ne représente pas celui-ci. De plus pour rappel, tout AWS n’était pas hors service, une région en particulier (un ensemble de plusieurs datacenters sur une zone géographique) était réellement hors service, le reste fonctionnait sans accro.

Alors oui, AWS est tombé, oui c’est arrivé, ça arrivera encore et vous savez quoi ben c’est normal au fait dans nos métiers.

Everything fails all the time

Oui, cette situation si on paraphrase le CTO d’AWS arrive souvent, ce qui veut dire qu’on doit y être préparée. À l’heure où nos infrastructures sont de plus en plus complexes, pour répondre aux nouveaux défis du web, on augmente assez logiquement le nombre de pannes possible. C’est d’ailleurs aujourd’hui un enjeu de taille, assurer que le service soit toujours disponible, redonder ce qui est possible et prévoir toutes les situations. À tel point que des approches comme le chaos engenering, l’observabilité et les métiers du SRE sont apparues en grande partie résoudre cette problématique.

Donc AWS n’échappe pas à la règle, malgré les efforts colossaux qui sont mis sur cet aspect, rien ne les protège à 100%. D’ailleurs ils en sont très conscients eux-mêmes, et insistent toujours sur cela dans les formations, prévoyez des soucis, créer des infrastructures fonctionnelles sur plusieurs régions si vous souhaitez être résilient. Leurs responsabilités étant prises, c’est aux clients et technique, architecte, opérationnel de prévoir cela dans les infrastructures qu’ils conçoivent. Si votre disponibilité est d’une importance critique, ne vous contentez pas d’une région, voire même d’un fournisseur cloud, créez un plan de continuité d’activité !

Alors, oui cela revient cher on va pas se mentir. Il faut bien comprendre que c’est comme la sécurité, il y a un équilibre à trouver. Vous n’aurez peut-être ni le besoin ni les moyens de vous assurer une redondance parfaite et en soi ce n’est pas un drame. Cela n’est peut-être pas nécessaire à votre business, voire même un risque à prendre. Mais en cas de problème, l’interruption de service sera à assumer, car il résultera de vos choix.

Que retenir de tout ça ?

This is Fine

Être opposé à une technologie ou une entreprise ça arrive, j’ai beaucoup d’entreprises que je n’aime pas, mais garder du recul et un regard juste est important. Réagir brutalement, sans justification ne fera que desservir vous et les causes que vous souhaitez défendre.

Testez vos plans de reprise d’activité (PRA), comme les sauvegardes on y pense rarement, mais si elles ne sont pas testées régulièrement, partez du principe qu’elles ne fonctionneront pas. Si vous être féru d’IoT, assurez-vous d’un fonctionnement minimal hors ligne, même si celui-ci est dégradé afin de ne pas rester bloqué. Exemple très simple, j’ouvre ma voiture avec une carte, mais je dispose d’une clé que je peux utiliser en cas de panne de l’électronique. C’est moins sexy, mais je réduis le risque de rester bloqué.

Quel que soit votre fournisseur, celui-ci peut rencontrer des problèmes, personne n’est à l’abri et ne le sera jamais totalement. Ayez toujours en tête que chaque brique d’une infra peut rencontrer un souci, prévoyez de les rebondir et des modes dégrader afin d’absorber les temps d’incident.

Vous devez aussi prévoir à votre échelle la résilience de vos services et de chaque brique que vous utilisez. Cela passe aussi aux dépendances, notamment JavaScript de vos sites quand elles sont distantes.

Si vous souhaitez en savoir plus et découvrir un autre point de vue notamment sur l’aspect résilience multicloud et gestion de risque, je vous invite à lire le poste de Ted - Arretez internet, AWS ne répond plus ! offrant un autre point de vue sur la situation.

01 Jul 2020, 06:19

Pourquoi AWS, Azure et GCP dominent-ils le cloud public ?

Cloud

Un web décentralisé, entre trois entreprises…

Les clouds US cités sont de bons produits, il serait malhonnête de dire le contraire et je travaille régulièrement avec. Mais l’hégémonie de ces clouds publics me pose un problème, une très grande partie du web repose sur 3 acteurs qui sont de plus des GAFAM. Les chiffres sont assez éloquents : AWS 41,5 %, Azure 29,4 % et GCP 3 % de parts de marché (selon l’infographie de visualcapitalist).

Parts de marché

Le web qui se voulait un exemple de décentralisation de l’information se centralise de plus sur des entreprises qui détiennent déjà beaucoup d’espace numérique. De plus, ils sont tous des géants américains, il n’y a aucune souveraineté au niveau des autres pays en particulier pour l’Europe et la France. Je ne parlerai pas du marché asiatique que je ne connais pas assez.

La souveraineté n’est pas le seul problème, ces plateformes ont la main sur la majorité du web et vont donc pouvoir à terme contrôler l’information au niveau mondial. On en a des exemples précis aujourd’hui, notamment de la part de Microsoft qui par l’intermédiaire de Github aide les autorités espagnoles à enrailler l’organisation des manifestants Source.

Mais il n’y a vraiment pas d’alternative locale à cela ? Oui, il y en a aujourd’hui, par exemple : OVH, Clever Cloud, Outscale, Scaleway ! Alors nous allons parler du sujet qui fâche, pourquoi ne sont-elles pas aussi populaires ?

Cloud francais

Un peu d’historique

Revenons quelques années en arrière tout d’abord. Les grands acteurs du web grossissent à toute allure avec l’explosion d’internet, cela leur demande de revoir leurs organisations et leurs stack techniques. Ils vont littéralement repenser l’informatique en interne, c’est ainsi que certaines bases du DevOps, l’utilisation massive d’API et surtout le cloud (tel qu’on le connaît) vont émerger, il découvre avant tout le monde l’informatique de demain.

On va s’intéresser à l’une de ses grandes entreprises, que vous connaissez forcément, car on y trouve de tout de A à Z (d’où le logo) sur leurs sites ; Amazon. Leurs sites connaissent des pics de charge conséquent et leurs équipes ont un gros besoin de flexibilité sur l’infrastructure, ils vont donc investir massivement dans un système de cloud privé ultramoderne. Ce système va se montrer très efficace et là Amazon va avoir une idée qui va les propulser au sommet des acteurs numériques : “Vendre le fruit de leurs travaux sur une plateforme de cloud publique”. Cette plateforme qui sera nommée Amazon Web Service pose les grandes lignes du cloud public moderne. Amazon va proposer de plus en plus de services entièrement managés par leurs soins, payable à la minute totalement contrôlable par API ! Une révolution dans le secteur où beaucoup vendaient surtout du serveur dédié.

L’expérience qu’ils ont acquise en interne pour héberger Amazon va leur donner une grande longueur d’avance sur beaucoup de gros hébergeurs classiques, qui vont rapidement se retrouver dépassés sur ses sujets et le gros changement de paradigme du cloud public. Microsoft et Google vont emboiter le pas à AWS en utilisant eux aussi leurs expériences historiques. Cela à permis à ses trois acteurs de se placer en position de leader sur le marché du cloud publique.

Il fut compliqué pour les autres acteurs de s’aligner et de proposer des services d’une qualité aussi rapidement sans se ruiner en Recherche et développement. Et même si cela fut possible les autres acteurs ont continué d’investir massivement. Pour vous donner un ordre d’idée de la machine de guerre qu’est la Recherche et développement d’une entreprise comme Amazon, un fait simple : en 2018 Amazon a dépensé 22,6 milliards de dollars en recherche et développement (plus grosse dépense de Recherche et développement au monde), très peu, voir aucun acteur en dehors des GAFAMs ne peut investir de telles sommes.

Recherche et développement

On se retrouve donc avec des acteurs qui ont littéralement des années d’avance. Ce qui nous fait rentrer dans une boucle, leurs avances font venir des clients, donc leur font rentrer de l’argent pour améliorer toujours plus leurs services et attirer de nouveaux clients.

Le virage du PaaS

Comme le dit le fameux adage: le cloud c’est juste l’ordinateur de quelqu’un d’autre. Ce n’est pas nouveau et ça existait depuis pas mal d’années, mais là où les géants on sût disrupter comme disent les jeunes startupeurs, c’est sur le service. À l’époque ou Amazon développe son cloud, la grande majorité des concurrents propose surtout des offres d’infrastructure, c’est-à-dire de la machine virtuelle et du réseau (IaaS), or a cette époque va se démocratiser la notion de service managé PaaS qui va changer profondément le marché.

Plutôt que louer des serveurs qu’il faut gérer au niveau système maintenir et sécuriser notamment, le PaaS va vous proposer directement des Middlewares prêts à l’emploi et gérés par l’hébergeur. Cela peut paraitre très basique, mais ça été un réel changement de paradigme, réduisant la charge de maintenance et en rendant plus accessible à tous beaucoup d’infrastructure. Cela vient d’une approche très business : vous gérez ce sur quoi vous apportez de la valeur ajoutée le reste vous le sous-traitez.

Ce virage a été assez brusque, notamment grâce à des budgets d’innovation démentielle comme je le disais précédemment. Les acteurs alternatifs se sont un peu retrouvés perdus sur ce point et ont tardé à réagir, ce qui avait laissé par mal d’avance sur le marché aux Google, Microsoft et Amazon.

Verrouiller le marché

Donc là vous vous dites ils ont de l’avance c’est tout, mais vous vous doutez bien que ce n’est pas aussi simple. Quand vous êtes leader du marché, votre objectif est bien sûr de le rester, pour ça il faut établir une position de domination sur le long terme. Pour cela il y a des armes destructrices que ces entreprises ont utilisées en masse.

  • Le réseau de partenaires

La plus efficace, les partenariats, rendez-vous dans la majorité des écoles aujourd’hui, elles sont partenaires d’AWS, Azure ou encore GCP, ce qui permet aux étudiants de découvrir ses technologies le plus souvent gratuitement. Mais alors, ces entreprises que je décrivais plutôt comme de méchantes sociétés capitalistes prêtes à tout pour écraser son prochain, sont-elles devenues de belles entreprises bienveillantes œuvrant pour le bien de l’humanité ? La réponse est bien sûr non, le but est là de conditionner les étudiants, si dans leurs formations vous leur apprenez uniquement certaines technologies ils iront naturellement vers ses choix qu’ils connaissent et qui sont rassurant pour eux une fois en entreprise.

Prenons un exemple, une étudiante qui s’appelle Éloise, elle étudie dans une école d’informatique dans le but d’obtenir un master en architecture des systèmes d’information. Dans ses cours, elle a les grandes technologies classiques qui sont utilisées aujourd’hui, mais aussi les nouvelles comme le cloud. Pour le module cloud elle va utiliser Azure, ce qui est parfait vu que son cursus a déjà signé de nombreux partenariats avec Microsoft pour les cours de système. Elle va apprendre Azure et se concentrer dessus pour son examen, elle n’aura pas le temps de s’attarder sur une autre technologie. Elle réussit son examen haut la main, Microsoft l’invite à passer une certification gratuitement, elle la passe et la réussi là encore sans problème. Éloise décroche son master quelques mois plus tard, elle est comme tous les étudiants informatiques débauchés par de nombreuses entreprises, en majorité des ESN. Elle finit par accepter l’une d’entre elle qui lui propose un bon salaire au vu de sa certification et lui propose de passer les niveaux supérieurs. Entre temps elle se rend chez un client qui lui demande conseil dans la mise en place du cloud publique, il n’a pas le temps de traiter le sujet c’est pour cela qu’il fait appel à l’ESN. Éloise qui est dans ça première mission va chercher à ne pas être perdu et donc choisir Azure qu’elle maitrise. De certification en certification de client en client elle deviendra une experte Azure, sans jamais avoir eu le temps ni les moyens d’élargir le champ des choix.

Cette petite histoire est en réalité proche de la réalité et assez courante, et ne blâmons pas Éloise, la grande majorité des personnes dans cette situation se serait rassurée en choisissant un terrain connu. Vous me direz, ben c’est la faute de l’école elle ne doit pas faire ça ! Mais pour avoir travaillé en école, la réalité est bien moins simple. Elles n’ont souvent pas le choix, les technologies évoluent TRÈS rapidement et très souvent il est impossible d’avoir des experts sur les nouvelles technologies ni des cours complets et récents sans dépenser des sommes astronomiques. Alors quand Microsoft se présente devant la porte et propose un pack qui donne des crédits Azure à tous les étudiants et surtout des cours adaptés aux technologies modernes avec des experts le tout gratuitement, les écoles foncent. Cela n’est pas nouveau j’ai connu les cours de Microsoft serveur sponsorisé très largement, les cours d’Oracle et j’en passe. La majorité des étudiants n’auront jamais le recul, ou le temps de tester et d’apprendre des technologies autres d’eux-mêmes.

Big Data is Watching you

Ce principe de partenaire est utilisé à la quasi identique sur les entreprises elles-mêmes qui ont tout un système de certification. Tout en apportant un effet boule de neige, si vous chercher de la main d’oeuvre en prestation ou interne, vous aurez une grande majorité d’expert cloud AWS, Azure ou Google.

  • Le lobbying

Et là arrive l’arme ultime : le lobbying, le grand classique dans lequel je vais parler de pas mal de petites actions qui misent bout à bout ont un impact sur le classement. Le plus frappant est le coup classique pour attirer les nouveaux clients sont les offres d’essais. Demain vous montez un startup pour disrupter un domaine ? Vous pouvez êtes sûr que rapidement vous allez avoir de belles offres de Google, Azure et AWS sans parler de leurs offres d’essai. Vous allez me dire que cela leur coûte cher, mais c’est très lucratif, les clouds sont assez fermés un changement demande de revoir beaucoup de choses, donc une fois l’offre promotionnelle terminée les utilisateurs y reste. D’ailleurs si vous regardez du côté des fameux incubateurs de startup par exemple Station F, ils sont très présents afin d’influencer au maximum ces nouvelles pousses.

Le lobbying ne s’arrête pas aux dernières entreprises de la startup nation, mais s’attaque bien sûr aux bonnes veilles DSI bien velue ! Vous êtes DSI vous n’avez pas suivi le virage du cloud, mais bon il faut que votre entreprise y passe c’est une question d’image vis-à-vis de la direction et des clients. Vous devez faire un choix, vous n’avez pas le temps de demander à l’extérieur, vous faites quoi ? Ben vous choisissez quelque chose que personne ne vous reprochera ! Jamais des dirigeants ne vont reprocher à une personne un choix d’un mastodonde qui a fait ses preuves. Si le projet de migration échoue avec AWS, la faute sera remise sur le temps la gestion ou tout autres élément aléatoire. Par contre, si le même responsable avait fait un choix moins commun comme OVH dès lors que le projet aurait loupé la faute aurait été mise sur ce choix. Le responsable choisit donc le choix politique : Azure, GCP, AWS

  • Le service

Il faut bien reconnaître les fournisseurs américains ont aussi compris un élément simple, le client est roi. Vous avez fait une erreur et vous avez laissé un cluster de tests allumé dans le vide une semaine ? Le service client d’Amazon vous proposera surement une solution pour le rembourser, ce coût pour eux et en réalité faible, car vous serez satisfait de leurs services, donc pas prêt de partir.

Leurs services très souvent ne sont pas que techniques, quand une grande entreprise fait un appel d’offres il y a des contraintes de conformités et beaucoup d’autres choses. Les acteurs américains ont une démarche très rodée, ils vont fournir tous les documents rapidement et en n’hésitant pas à s’adapter au besoin. Sans compter qu’ils n’hésitent pas à certifier TOUS les services possibles sur leurs clouds aux grands classiques comme les normes ISO ou encore HDS. Pour les grands comptes, c’est un aspect ultra important qui explique que beaucoup de contrats de santé notamment arrivent chez les Google, Amazon, Microsoft plutôt que chez les acteurs français malgré le Cloud Act. Des acteurs alternatifs font certifier les services, mais pour beaucoup cela ne représente que 2 à 3 services de leurs cloud ce qui est souvent insuffisant.

  • Le coût de la migration

C’est un point qui à mon sens est souvent trop cité, mais il est réel. Passer d’un cloud à l’autre aura souvent un très gros coût, entre la réécriture du code, le coût des transferts de données c’est très lourd. Après je pense que quelque soit le cloud, passer de l’un à l’autre aura toujours un coup il n’y a pas de standard assez complet pour fournir un cloud commun, Open Stack est un début, mais ne fournit qu’une petite partie des services managés d’un cloud public en 2020.

Ces techniques ne sont clairement pas nouvelles et ont été éprouvées dans de nombreux autres domaines. J’aurais aussi pu aborder l’effet de mode, mais je pense que celui-ci est venu bien après et il est fortement lié aux points déjà cités. J’en ai surement oublié, et je vous invite à me dire ce que vous en pensez j’ai donné ma vision de consultant technique.

Conclusion

Une lumière au fond du tunnel ?

Je pense qu’il y a beaucoup à apprendre de la parts des géants du web et pas uniquement sur la technique. Aujourd’hui on peut dire qu’on a des alternatives viables comme celle déjà citée : Alibaba cloud, OVH, Clever Cloud, Outscale, Scaleway ! Ils n’ont effectivement pas autant de service managé qu’AWS, mais ils commencent à avoir le minimum de services nécessaires à la plupart des projets à l’heure actuelle : Du Kubernetes managé, du stockage objet, des machines virtuelles, des bases de données managées des équilibreurs de charge efficaces et surtout des outils et APIs fonctionnels (ils ont des providers Terraform adaptés). Un peu de chemin est encore à faire, la gestion des comptes IAM, les réseaux virtuels privés et le FaaS sont encore trop souvent aux abonnés absents, même si je félicite Scaleway pour ses développements récents sur ses sujets.

Alors pourquoi on met tant de temps à rattraper ce retard ? Ces acteurs ont dû se dépasser pour rattraper la recherche et développement et les investissements des grands acteurs Américain et surtout se remettre en question, cela a pris du temps, mais le développement des outils OpenSource comme Kubernetes ou encore OpenStack a permis de mutualiser les efforts et d’avoir des solutions efficaces.

Maintenant que la technique est là il faut passer à l’offensive commerciale qui a déjà commencé, OVH est très présent à Station F, Scaleway a mis en place de belles offres d’essais. En continuant sur cette voie, il se pourrait bien que le marché du cloud public change enfin de visage pour devenir plus varié.

Il faut aussi soutenir l’éducation, nouer des réseaux de partenaires solides ! Et faire certifier les services pour pouvoir attaquer les grand-comptes, on reparlera des certifications et de tout ça dans un prochain article.

Mais pour que ces nouveaux acteurs se démocratisent il faut une chose, que nous les personnes de la technique arrêtions de répéter des patterns, tester ces nouvelles alternatives et les proposer pour pousser vers un web différent est plus diversifié !

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.