Mon infrastructure

Vue d’ensemble

Quand j’ai commencé à développer des projets web, j’ai investit dans des raspberry pi pour les faire tourner. Au début, je me débrouillait avec quelques services systemctl, et en les rangeant dans des dossier, mais les pipelines gitlab devenaient lourdes pour mettre à jour automatiquement, la charge n’était pas équilibré, le débuggage extrêment ardu. C’est alors que, par hasard, j’ai découvert Kubernetes, et j’ai installé l’opérateur de conteneurs sur mes raspberry pi. Depuis, je l’ai fait évoluer avec de nombreux services, tels que Certmanager pour gérer les certificats https, les Gateways API pour gérer le routing de manière moderne, avec Nginx, Prometheus pour surveiller les métrics (avec Grafana pour les afficher), ainsi que Ory pour gérer l’authentification à travers mes projets, et Fluxcd pour GitOps

Fonctionnalités

• Grâce à Kubernetes, le cluster est résilent au pannes de noeuds (machines), au crash des pods etc.
• Avec Fluxcd, j’écris les manifests de mes ressources dans un repository git, et ça synchronise l’état du cluster, de plus, ça met automatiquement les applications à jour quand un nouveau tag est détecté dans l’image.
• Avec gitlab, dès que je push sur une application, elle est automatiquement versionnée et buildée, avant d’être ajouté au cluster grâce à Fluxcd
• J’ai grâce à Ory Kratos, Ory Oathkeeper, Ory Hydra et Ory Keto un système d’authentification centralisé complet, depuis la création d’identité jusqu’à la vérification d’accès, en passant par un gestionnaire d’ACL fin et l’oauth 2.0
• Prometheus récole des données à travers tout le cluster, sur toutes les applications, celles-ci sont disponible dans l’interface Grafana
• Chaque application utilise les Gateway API pour définir des HttpRoute, qui décrivent quel trafic doit être récupérer et où il doit aller. Si c’est une application restreinte, comme un dashboard admin, il est alors envoyé dans Ory Oauthkeeper qui à l’aide de Rules et d’appels à Ory Kratos, pour vérifier l’identité, et Ory Keto, pour vérifier les droits, va autoriser ou nom l’accès à la ressource
• Les données persitantes structurées sont stockées à travers les applications dans un cluster de bases de données PostgreSQl, CNPG (Cloud Native Postgres)
• Les données persistantes (DB et fichiers) sont tous stockés sur un nas accessible en NFS depuis le cluster
• Pour éviter la redondance des manifestes, le “template” de manifestes d’une application est définit via Helm, et chaque application se contente d’utiliser ce template en modifiant ses valeurs
• Pour simplifier les différents étapes de déploiement, j’ai créé dess templates de pipelines Gitlab.
• De plus, certains fichiers sont très redondant dans chaque app comme la configuration de semantic release pour le versionnement ou les Dockerfile, j’ai donc également conçu quelques snippets.
• Pour manager le cluster, j’utilise donc Fluxcd, mais également majoritairement (surtout pour débugger), l’outil en ligne de commandes kubectl, et l’interface OpenLens