Installer un serveur Git auto-hébergé change profondément la manière dont une équipe contrôle son code et ses accès. Gitea offre une alternative légère aux solutions plus lourdes, pratique pour les petites équipes et les environnements sur serveurs Debian ou Ubuntu.
La mise en place demande une préparation réseau, des droits système et une configuration de base de données fiable pour la production. Les éléments clés utiles à l’installation suivent, A retenir :
A retenir :
- Instance légère pour dépôts privés et équipes réduites
- Configuration minimale : Git, MariaDB, Nginx ou Traefik
- Sécurité par SSH et certificats Let’s Encrypt
- Sauvegardes régulières de base de données et données
Installation de Gitea sur Ubuntu LTS : préparation et paquets
Suite aux points essentiels listés, la première étape consiste à préparer le système et installer les paquets requis. Selon la documentation officielle d’Ubuntu, il faut mettre à jour le cache APT et appliquer les correctifs avant d’installer des services en production.
Préparer le système et installer dépendances
Cette étape pose les fondations en assurant sécurité et mises à jour du système avec des règles de pare-feu simples. Selon la documentation officielle de Gitea, les dépendances essentielles incluent git, un serveur de base de données et un serveur web comme Nginx.
Un exemple concret d’actions comprend l’installation de git, mariadb-server, nginx et certbot, puis l’activation d’UFW pour SSH et HTTP. Ces étapes préparent le terrain avant de télécharger le binaire Gitea et de créer l’utilisateur système dédié.
Paquets essentiels système :
- git
- mariadb-server
- nginx
- certbot (Let’s Encrypt)
Paquet
Rôle
Port concerné
git
Contrôle de version local
–
mariadb-server
Base de données pour Gitea
3306
nginx
Reverse proxy HTTP/HTTPS
80/443
certbot
Obtention de certificats SSL
–
« J’ai déployé Gitea sur Ubuntu 22.04 pour une petite équipe, et le service démarre rapidement après configuration des paquets »
Alice D.
Créer l’utilisateur système, répertoires et binaire
Cette phase installe le binaire Gitea, crée l’utilisateur système et prépare les chemins de données et de configuration. Selon les bonnes pratiques, le binaire se place sous /usr/local/bin et les dépôts sous /var/lib/gitea pour isoler les fichiers applicatifs.
Préférences chemins système :
- /usr/local/bin/gitea pour le binaire
- /etc/gitea pour la configuration
- /var/lib/gitea pour données et dépôts
- /var/lib/gitea/log pour les journaux
Élément
Emplacement par défaut
Commentaire
Binary Gitea
/usr/local/bin/gitea
Exécutable principal
Config
/etc/gitea/app.ini
Paramètres applicatifs
Repositories
/var/lib/gitea/data/gitea-repositories
Stockage des dépôts
Logs
/var/lib/gitea/log
Traçage et dépannage
Configuration réseau, base de données et reverse proxy sécurisé
Enchaînant sur l’installation de base, la configuration réseau et la base de données garantissent disponibilité et sécurité de l’instance. Selon la documentation de MariaDB, créer une base en utf8mb4 évite les problèmes d’encodage avec les messages et les fichiers LFS.
Configurer MariaDB/MySQL pour Gitea
Cette configuration comprend la création d’une base gitea, d’un utilisateur dédié et l’octroi des privilèges nécessaires pour les opérations. Selon la documentation officielle de Gitea, les paramètres DB_TYPE et CHARSET doivent correspondre à utf8mb4 pour une compatibilité maximale.
Étapes création base :
- Créer la base de données gitea
- Créer l’utilisateur gitea@localhost
- Accorder tous les privilèges sur gitea.*
- Exécuter FLUSH PRIVILEGES
« J’ai automatisé la création de la base via un script Ansible, ce qui a réduit les erreurs de configuration »
Marc L.
Reverse proxy Nginx, SSL et DNS
Cette étape place Gitea derrière Nginx ou Traefik pour gérer SSL et hôtes virtuels, améliorant la sécurité. Selon Certbot, l’obtention d’un certificat Let’s Encrypt demande un nom de domaine valide pointant vers l’IP publique du serveur.
Paramètres reverse proxy :
- Redirection HTTP vers HTTPS
- Proxy pass vers localhost:3000
- En-têtes X-Forwarded ajoutés
- client_max_body_size augmenté pour LFS
« Après la configuration Nginx et Let’s Encrypt, nos clones git sont passés en HTTPS sans perte d’accès »
Claire R.
Utilisation quotidienne, CI/CD avec runners et stratégies de sauvegarde
Pour passer à l’exploitation, il faut maîtriser l’accès SSH, les workflows CI et la politique de sauvegarde des données. Selon la documentation des runners Gitea Actions, il est recommandé de dédier un ou plusieurs runners pour les workflows gourmands en ressources.
Accès SSH, clonage et gestion des dépôts
Cette partie traite de l’ajout de clés SSH, du clonage des dépôts et des permissions pour les équipes et organisations. Les utilisateurs ajoutent leur clé publique dans leur profil Gitea pour cloner via SSH et éviter la saisie répétée de mots de passe.
Bonnes pratiques SSH :
- Utiliser ed25519 pour les nouvelles clés
- Nommer clairement chaque clé pour l’audit
- Gérer les accès par équipes et par dépôts
- Activer la double authentification si possible
« Notre équipe utilise Docker pour runner des jobs, et Jenkins pour certaines intégrations anciennes »
Paul N.
CI/CD, sauvegardes et mises à jour
Cette section aborde la mise en place de runners, la planification des sauvegardes et la gestion des mises à jour de l’instance. Les sauvegardes doivent inclure la base de données, le répertoire des dépôts et le fichier /etc/gitea/app.ini pour restaurations complètes.
Checklist opérations courantes :
- Dump régulier de la base via mysqldump
- Sync des données Gitea avec rsync
- Mise à jour contrôlée du binaire Gitea
- Vérification périodique des logs
Tâche
Commande indicative
Fréquence recommandée
Backup DB
mysqldump -u root -p gitea > gitea-db.sql
Quotidienne ou selon l’activité
Backup données
rsync -a /var/lib/gitea/ /backup/gitea/
Quotidienne
Update binaire
remplacer /usr/local/bin/gitea et redémarrer
Après validation
Vérif. logs
journalctl -u gitea ou /var/lib/gitea/log
Hebdomadaire
« Adopter Gitea a réduit nos coûts d’hébergement tout en conservant l’intégration avec Docker et Jenkins »
Antoine B.