Ma Stratégie GitOps avec Gitea, Docker, et Ansible
Plutôt que de dépendre de GitHub ou GitLab, j’ai choisi de construire ma propre chaîne CI/CD. Voici comment j’ai automatisé tout le processus, du push au déploiement, en utilisant uniquement des outils auto-hébergés.
Introduction
Avant d’automatiser avec la CI/CD et le GitOps, je réalisais des builds manuels, copiais des fichiers à la main ou me connectais en SSH sur les serveurs juste pour redémarrer un service. Ça fonctionne, mais c’est répétitif, source d’erreurs, et franchement ennuyeux.
Avec ma pipeline GitOps dans mon homelab, mon objectif est simple :
- Automatiser tout ce qui peut l’être
- Apprendre le fonctionnement des pipelines et des opérations DevOps
- Éviter de dépendre de GitHub ou de services externes
- Garder un contrôle total sur les déploiements
Puisque j’utilise déjà Gitea, Docker et Ansible, ces outils sont devenus la base de mon workflow GitOps.
Diagramme
graph TD
A[[Push de code]] -->|déclenche| B[Tâche de build]
B -->|compilation| C[Tâche de test]
C -->|validation| D[Tâche de release]
D -->|création de l'image| E[Tâche de déploiement]
E -->|ansible-playbook| F[[Déployé]]
1. Mon environnement et mes outils
- Gitea : Un service Git auto-hébergé qui remplace GitHub. Rapide, léger, et sous mon contrôle.
- Gitea Runner : Exécute les workflows (comme GitHub Actions, mais en local).
- Docker : Build mes applications dans des images.
- Ansible : Automatise les déploiements sur mes serveurs.
- Semaphore : Une interface pour Ansible qui permet de déclencher facilement des playbooks, soit manuellement soit depuis les pipelines via des webhooks.
2. Conception de la pipeline
Voici comment mon workflow fonctionne en pratique :
- Push de code → Un commit sur
maindéclenche un workflow dans Gitea. - Build → Le runner compile et construit le projet.
- Test → Les tests et le linting garantissent la qualité du code, si nécessaire.
- Release → Une image Docker est construite, taguée et stockée (sur gitea).
- Déploiement → Semaphore déclenche des playbooks Ansible qui récupèrent la nouvelle image et redémarrent les services dans mon homelab.
Chaque commit suit le même cycle de vie, sans étape manuelle.
3. Détails d’implémentation
Quelques détails qui rendent la pipeline fluide :
- Logs de déploiement → Semaphore garde une trace de chaque déploiement.
- Notifications → Des webhooks Discord m’alertent après chaque tâche.
- Nettoyage → Les anciens packages peuvent être supprimés automatiquement pour éviter de gaspiller de l’espace.
- Secrets → Toutes les informations d’identification sont stockées dans des secrets Gitea ou un vault Ansible.
Conclusion
Construire ma propre pipeline CI/CD m’a appris énormément sur l’automatisation et les pratiques DevOps. Plus important encore, cela m’a donné un workflow en lequel j’ai confiance : simple, reproductible et entièrement sous mon contrôle.
Au final, cette pipeline ne se résume pas à gagner du temps. Il s’agit de faire confiance au processus.