Faire son portefolio DevOPS en 2h

Hello,

Cette semaine on voit une façon de transformer son portfolio Dev en incluant du DevOPS

Tout ça, pour se différencier dans ce monde rempli de portfolio…

Le cas d'école : J'ai un site statique
Je souhaite le publier sur hébergement
Et pousser les modifs automatiquement

---

Si ce n'est pas déjà fait, tu peux : 

• Découvrir notre formation sur le DevOps 

• Lire toutes les éditions précédentes de la newsletter 

---

Au programme :

• Le tuto complet

---

Aller on y va

On part du portfolio statique de Code Garage (https://code-garage.fr/blog/un-template-de-site-portfolio-minimaliste-pour-developpeur/)

Je configure mon Gitlab de façon standard :

• Nouveau dépôt

• Je clone sur mon poste

• Je fais l'import initial du code

Jusque là tout va bien

 

Deuxième étape.

Faire héberger mon site statique.

En faisant des recherches rapides, je vois qu'AWS permet d'héberger des sites statiques avec S3.
Ça tombe bien, je ne connais pas bien les deux, c'est l'occasion d'apprendre

Je me crée un compte gratuit sur AWS.

Je suis le premier tuto qui me montre comment le faire :

• Créer une bucket S3

• Activer "Hébergement de site Web statique"

• J'upload mes fichiers à la main

Ok, je peux me connecter à ma page. Tout fonctionne !

 

Troisième étape.

Comment je peux faire tout ça, en ligne de commande.
On oublie pas notre objectif est de tout faire en automatique, donc ma CICD ne saura pas faire des cliques sur une interface web

Je cherche un peu comment faire. Je vois que AWS possède un outil en ligne de commande.
Et je vois aussi que Terraform permet de gérer AWS.

Hum... c'est peut-être l'occasion de mettre la main dans Terraform

Je supprime totalement la bucket que j'ai créée à la main pour tout refaire en ligne de commande.

J'installe Terraform sur mon poste.

Et je regarde comment faire pour créer une bucket S3 automatiquement

La doc terraform me montre, c'est simple. J'applique. Et hop ma bucket est bien créé sur AWS.

 

Pour vérifier que tout fonctionne, j'upload mes fichiers à la main. Je dois avoir le même résultat que tout à l'heure.

Et là, cata ... ça ne marche pas. En me connectant sur le site : Accès non autorisé à cet objet.

Je fouille un peu internet et là je me rends compte d'une chose :
Quand j'ai fait à la main, j'ai activé "Hébergement de site Web statique"
Hors la doc de terraform ne m'en a parlé.
Ah ben oui, j'ai juste fait la création d'une bucket sans aucune configuration.

Rebelote, je cherche. Et là je trouve la conf qu'il me manquait :

resource "aws_s3_bucket_website_configuration"

Ok. Je resteste en lançant terraform depuis mon poste.
Ça semble ok. Je reteste le site. Toujours pas bon.

Je re re fouille internet. Et là, je vois qu'il faut que les objets soient accessibles en lecture sur internet.

Ah ouais ? c'est quoi ce binz.. je continue. En fait, on doit gérer les droits pour dire qui peut voir quoi sur ma bucket.
Pour des raisons de sécurité.
Et là je vois qu'il faut mettre "aws_s3_bucket_acl" pour donner les droits "public-read"

 

Ok. Je recommence, ça semble ok maintenant.

J'arrive depuis la ligne de commande à créer et configurer ma bucket.

 

Quatrième partie

Je veux pouvoir uploader mes fichiers en ligne de commande dans ma bucket.

On fouille sur internet. Et là, on voit que pour un fichier, c'est simple, mais quand tu as des dossiers et tout, c'est pas pareil

Et la solution qui revient, c'est d'utiliser la ligne de commande AWS.

Je l'installe sur mon poste et je lance la commande :

aws s3 sync ./code s3://nomdemabucket

Bon, un problème de droit, je dois passer les token de connexion

AWS_ACCESS_KEY_ID=aaaaaa AWS_SECRET_ACCESS_KEY=bbbbb aws s3 sync ./code s3://nomdemabucket

Ah c'est mieux. Je vérifie dans la console, AWS, je vois bien mes fichiers.

Je reteste mon site... re cata. De nouveau des problèmes de droits.
Je cherche un peu... en fait, je me rends compte que quand on upload le fichier dans la bucket, on doit aussi spécifier les droits qu'on attribue aux fichiers.
Je regarde la doc de la ligne de commande aws et je vois qu'il y a un argument --acl que je mets à public-read

Je reteste. Ça fonctionne

Je rajoute des fichiers dans mon code. Je relance la commande. Tout est ok, mes fichiers sont bien uploadés sur la bucket.

Je supprime ces fichiers en trop et je relance la commande. Et là, les fichiers ne sont pas supprimés sur la bucket.
Je fouille la doc AWS cli et je vois qu'il me manque un paramètre --delete pour garder synchro ma bucket avec ce qu'il y a exactement dans mon dossier code.
Je reteste et là tout est bon.

Pour pinailler un peu, j'aimerais que cette commande soit lancée par terraform directement.
Je vois qu'on peut utiliser local-exec. Je configure. Je lance terraform. Ça fonctionne.

 

Je modifie quelques fichiers pour voir. Je relance terraform. Et là, re merdouille. Il ne relance pas la commande.
Il l'a fait une seule fois et depuis il ne veut plus la lancer.
Je fouille et là je comprend que du point de vue de terraform, il a réussi à exécuter la commande la 1ere fois, donc pour lui tout est ok. Il n'y pas plus de modif à faire même si je change les fichiers.
Il manque un "trigger" pour lui dire de toujours exécuter la commande. Je trouve la doc et je rajoute. Et là, ca fonctionne.

 

Ok. À ce stade, j'ai tout automatisé sur mon poste.

Cinquième étape.

Maintenant, il faut pouvoir déclencher tout ça, dès qu'un commit est fait dans ma branch main sur gitlab

Et là, on rentre dans la partie CICD.

Je crée mon fichier .gitlab-ci.yml

 

J’ai juste mis les commandes que je faisais sur mon poste.

J'ai installé terraform et aws cli sur mon poste ! Comment je fais ça sur gitlab ???

Comme d'hab on fouille et là on voit qu'une solution et de créer soit même son image docker.

Trop cool. Je vais être obligé de faire un peu de docker. Encore une occasion de progresser.

Dans cette image on installe terraform et aws cli

 

Puis on pousse l'image sur notre dépôt gitlab

 

On dit à la CI d'utiliser notre image qu'on vient de créer

 

On commit sur main !

Et on observe la magie s'opérer.

 

Je modifie un fichier dans mon code et la CICD pousse le tout automatiquement !!!

(bon modulo, la gestion d’un state remote dans terraform :p )

Woaahhh

À partir de là, on peut continuer à enrichir notre CICD pour faire tout ce que l'on veut :

• réduire la taille des CSS/JS

• N'exécuter l'upload dans le S3 que quand le code source a été modifié

Si je résume

En voulant juste mettre en ligne mon portfolio, j'aurais pu prendre un netlify/vercel/heroku et hop en 30 sec, c'est en ligne.

Mais en se compliquant la vie en intégrant du DevOPS qu'est ce que j'ai eu ?

Un super sujet de conversation en entretien d'embauche.

Je peux dire que j'ai mis la main dans AWS, terraform et docker
Que j'ai eu tel et tel problème. Que j'ai pu me débrouiller pour les résoudre et j'ai fait preuve d'autonomie.
Que j'ai compris quelques challenges du DevOPS
Que même en tant que DevJunior, je sais faire autre chose que du code pure
Que donc, je saurais m'intégrer parfaitement dans une équipe
Que je pourrais être force de proposition

Et tout ça en le prouvant avec mon portfolio !

---

Tes cadeaux pour te remercier de partager la newsletter

Pour rappel, si tu recommandes la newsletter à d’autres personnes, voici les récompenses que tu peux gagner :

• 25 recommandation → On met en avant ton profil dans un article

• 50 recommandations → Une visio de 20 min de mentoring DevSecOps avec nous

• 100 recommandations → Une de nos formations aux choix offertes

Il te suffit de cliquer sur le bouton juste en dessous pour obtenir ton lien personnalisé :

---

Voilà, c’est tout pour aujourd’hui.

On est curieux d’avoir tes retours.

1. Partage nous tes réactions en répondant à ce mail.

2. Si tu as aimé cet article, n’oublie pas de mettre un petit like ! Ça nous aide à comprendre quels sujets on dois creuser.

Passe une excellente journée et à la prochaine.