Ma Stratégie GitOps avec Gitea, Docker, et Ansible

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 :

1. Push de code → Un commit sur main déclenche un workflow dans Gitea.
2. Build → Le runner compile et construit le projet.
3. Test → Les tests unitaires et le linting garantissent la qualité du code.
4. Release → Une image Docker est construite, taguée et stockée.
5. 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 sont supprimés pour éviter de gaspiller de l’espace.
• Secrets → Toutes les informations d’identification sont stockées dans les secrets de Gitea.

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.

Prochaines étapes :

• Ajouter des étapes de test avancées,
• Créer des environnements de staging,
• Améliorer les notifications,
• Mettre en place une CI/CD complète pour mon dépôt Ansible.

Au final, cette pipeline ne se résume pas à gagner du temps. Il s’agit de faire confiance au processus.

Pour aller plus loin

#

• Découvrez un exemple concret avec ce post : Construire une pipeline CI/CD complète : Introduction