Featured image of post L'infrastructure du blog V 1.0

L'infrastructure du blog V 1.0

Gitlab CI/CD + Hugo = <3

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.

Généré avec Hugo
ThÚme Stack conçu par Jimmy