C’est bien beau de sauvegarder ses fichiers persos sur un serveur distant. Mais lorsqu’il s’agit d’un dépôt git, cela peut s’avérer beaucoup plus fastidieux.

En effet, utiliser les mécanismes de backups classiques nécessite de cloner le dépôt (et donc prendre de la place en local), de le mettre à jour régulièrement et de l’envoyer sur le serveur distant.

Une autre méthode, plus simple, peut être de créer un miroir de son dépôt sur lequel sera envoyé automatiquement toutes les modifications.

L’avantage principal de cette méthode est que si votre serveur tombe, vous disposez immédiatement d’un dépôt de backup, sans rien avoir à remettre en place.

Mise en place

Ce que l’on veut exactement, c’est que lorsque l’on effectue une action sur notre dépôt , celle-ci soit automatiquement répercuté sur un dépôt distant, qui servira de backup.

Depuis la version 8.2 Edition Entreprise de Gitlab, deux sortes de mirroring sont possibles : push et pull.

Pour toutes les personnes s’y connaissant un minimum en git, cela devrait vous parler. La méthode push envoie toutes les modifications sur un dépôt distant, alors que la méthode pull demande à votre dépôt de rapatrier toutes les modifications.

La méthode que nous utiliserons dans notre cas est push.

Création du dépôt de backup

La première étape est de créer un nouveau dépôt, sur un serveur distant, qui servira de backup.

De notre côté, nous avons utilisé gitlab.com, mais il existe d’autres, comme framagit. Vous pouvez également créer votre propre serveur quelque part…

Ici, je vais prendre l’exemple de gitlab.com, mais la création d’un dépôt est la même pour tous les serveurs utilisant gitlab.

Tout d’abord, il faut s’enregistrer (ou se créer un compte) et une fois enregistré, il suffit de cliquer sur le bouton New Project, afin de créer un nouveau dépôt.

Les données demandées pour la création du projet sont :

• Project name : le nom de votre dépôt
• Project URL : l’URL de votre dépôt. Par défaut, généré automatiquement grâce au nom du projet.
• Description : si vous voulez décrire votre projet.
• Visibility level : niveau de visibilité.
  • Private : ne permet l’accès qu’aux utilisateurs autorisés,
  • Internal : permet l’accès aux utilisateurs connectés,
  • Public : le projet est visible par tous,
• Initialize repository with a README : permet d’initialiser votre repo avec un fichier readme.

Appuyez sur Create project, et c’est tout bon, votre projet est créé.

Configuration

Maintenant, passons à la configuration du mirroring. Pour cela, il faut se rendre sur le dépôt que l’on cherche à sauvegarder et utiliser l’interface web de gitlab.

Dans le menu du projet, il faut choisir Settings > Repository, ou encore Paramètres > Dépôt pour ceux qui comme moi ont mis l’interface en français.

Dans les menus qui sont proposés, il faut choisir Mirroring Repositories (ou « Dépôts miroir ») et Expand (« étendre »), afin de pouvoir accéder à la partie configuration.

Vous aurez alors accès à un formulaire permettant de configurer le mirroring.

Les données demandées sont :

• URL : l’URL du repo distant sur lequel seront envoyées toutes les modifications.
• Sens du miroir : push. Pour que toutes les modifications dans notre dépôt soient pushées vers le dépôt miroir
• Méthode d’authentification : Vous pouvez utiliser un mot de passe ou une clef ssh.

Une fois que la configuration est bonne, il suffit d’appuyer sur mirror repository afin de valider. Votre dépôt distant apparaitra alors dans la liste juste en dessous.

Pour aller plus loin

Sécurité

Contrairement à duplicity, qui permettait de chiffrer les données envoyées, les données sauvegardées de cette manière se retrouvent en claires sur le serveur distant.

Dans le cas de certains de nos projets, nous avons un dépôt chez nous, sur lequel nous faisons nos modifications, et un dépôt distant, chez gitlab, car nous voulions que le code soit librement accessible sans exposer notre propre instance gitlab.

Pour que byte overflow soit disponible sur Google Play, il faut qu’il soit signé par notre certificat. Et comme la signature est faite automatiquement par l’intégration continue dans notre gitlab, il serait dangereux de stocker les clés dans le dépôt…

La solution est donc de mettre les données dans les variables secrètes dans la CI.

On trouve ces variables dans le menu Paramètres > Intégration et livraison continue, dans la partie Environment variables (en anglais, même chez moi…).

Pour résumer, puisque les données envoyées ne sont pas chiffrées, il ne faut en aucun cas laisser dans vos dépôts les moindres identifiants ou certificats.

Limitations

Les dépôts chez gitlab.com ont une taille limitée. La taille max d’un repo est officiellement de 10GB. A prendre en compte avant de vouloir backuper son dépôt.

Cela ne semble pas être toujours le cas… Dans de nombreux forums, la limite de taille de gitlab semble être un sujet épineux de discussion. Toujours est-il qu’officiellement, elle est de 10GB.