Automatiser l'infrastructureAccélérer l'innovation

données de démoTélémétrie simulée, générée dans votre navigateur

• Kubernetes
• kubeadm
• RHEL
• containerd
• Calico
• Ansible
• Three.js

• Installer un cluster Kubernetes, expliqué en 3D

  edem38/cluster-kubernetes-3d

  Voir sur GitLab

  Le dépôt du parcours interactif présenté juste au-dessus : une page autonome, sans build ni dépendance à installer, qui rejoue en 3D les 14 étapes d'une installation kubeadm sur RHEL 9. Un control plane, trois workers, containerd comme runtime et Calico pour le réseau de pods. Chaque étape montre la commande, ce qu'elle change sur le cluster et pourquoi, jusqu'à l'ajout d'un nœud à chaud et au diagnostic des pannes classiques.

  • Page statique autonome : un index.html et Three.js en local, rien d'autre
  • 14 étapes, de la préparation de l'OS au cluster qui répond
  • Volet entreprise : Terraform pour les machines, Ansible et Kubespray pour le cluster
  • Troubleshooting : nœud NotReady, CNI absent, certificats expirés, etcd
  • HTML 100.0 %
  mainmaj 01 octobre 2026

• API Node déployée sur EKS par une pipeline complète

  projet_final3/morning_news_backend

  Voir sur GitLab

  Le backend du projet de fin de formation : une API Express qui agrège des articles depuis newsapi.org et gère comptes et favoris dans MongoDB. L'intérêt du dépôt est surtout la chaîne autour : chaque push déclenche lint, tests Jest, analyse SonarQube et test de charge Locust, puis construit l'image Docker et la pousse sur le registry GitLab. Le Terraform provisionne la partie AWS — rôles IAM, cluster EKS et groupes de sécurité — et les manifestes Kubernetes déploient l'image.

  • Pipeline en quatre étapes : build, test, update, deploy, déclenchées selon la branche
  • Qualité bloquante : lint, Jest, quality gate SonarQube, charge Locust à 3000 utilisateurs
  • Terraform pour les rôles IAM, le cluster EKS et les security groups
  • Déploiement Kubernetes avec image tirée du registry privé GitLab
  • JavaScript 46.9 %
  • HCL 38.0 %
  • Shell 8.4 %
  • Dockerfile 4.1 %
  • HTML 1.1 %
  • deploy/ · 2
  • racine · 1
  • terraformfiles/ · 1
  prod4 fichiers .tfmaj 30 septembre 2026

• Socle AWS multi-tier, construit étape par étape

  edem38/aws-multitiers

  Voir sur GitLab

  Une infra AWS montée proprement depuis zéro, où le state Terraform est traité comme la ressource la plus critique. Une stack bootstrap, lancée une seule fois en state local, crée le bucket S3 qui hébergera tout le reste : versionné, chiffré, accès public bloqué, destruction interdite, avec une alerte budget. Ensuite chaque environnement pointe sur ce bucket via son propre backend.hcl, et un Makefile enveloppe init, plan et apply pour qu'on ne puisse pas appliquer dev avec les variables de prod.

  • Bootstrap séparé : résout le problème de la poule et de l'œuf du remote state
  • Un backend.hcl et un tfvars par environnement, dev et prod isolés
  • Variable env validée par Terraform : seules les valeurs dev et prod passent
  • Étape en cours : backend et verrou validés par une ressource à coût zéro, les modules réseau, compute et base arrivent ensuite
  • HCL 90.7 %
  • Makefile 9.3 %
  • bootstrap/ · 4
  • racine · 3
  • envs/dev/ · 1
  • envs/prod/ · 1
  main9 fichiers .tfmaj 25 septembre 2026