Gitlab est un formidable gestionnaire de répertoires Git. Sa communauté très active en a fait l’outil libre et ouvert le plus complet de sa catégorie. Son installation est très simple et sa mise en place l’est tout autant grâce à son fichier unifié de configuration.

Documentation

Toutefois, lorsque l’on sort un peu des sentiers battus, il s’avère que la documentation vient à manquer. C’est le cas par exemple du connecteur de sauvegarde distante backup_upload_connection qui est documenté uniquement pour S3, le célèbre service de stockage objet d’Amazon Web Service.

Pour diverses raisons, nous voulions utiliser le service similaire de Cloudwatt qui implémente une API différente basée sur Swift, un des tous premiers projet d’Openstack.

La documentation ne parle pas directement d’intégration de Gitlab avec Openstack. En revanche, Gitlab utilise la gem ruby fog. Cette librairie tente de créer une interface ruby unifiée pour les différents fournisseurs de Cloud tels que Amazon, Rackspace, Openstack, Google, etc. La piste est donc encourageante, mettons cela en place.

Mise en place

Premièrement, vous allez devoir récupérer vos accès à l’API Cloudwatt sur la console web. Pour cela, connectez-vous simplement votre interface de gestion. Dans la barre de navigation en haut, cliquez sur Accès API. Vous devriez avoir un fenêtre contextuelle vous communiquant vos accès ainsi que l’URL d’authentification. Cloudwatt assure la compatibilité de leur Cloud avec l’API S3 et l’API Swift. C’est cette dernière que nous allons utiliser et c’est les informations à gauche qui vont nous servir.

api-access-cloudwattAttention, le fonctionnement actuel de Cloudwatt ne permettant pas de générer des tokens pour vos accès, vous allez devoir saisir en clair votre mot de passe dans le fichier de configuration de Gitlab. La solution temporaire est donc de créer un autre utilisateur lié au même tenant qui servira uniquement à uploader les sauvegardes sur le stockage objet.

Via la console Cloudwatt ou via les outils en ligne de commande, créez un conteneur (équivalent du bucket dans S3) dans Object Store et nommez-le de façon claire. En effet, tous les conteneurs objets du même tenant sont visibles depuis l’interface, ce qui peut vite devenir ingérable.

Le fichier de configuration de Gitlab se trouve dans /etc/gitlab/gitlab.rb sous Debian Wheezy. Ouvrez le fichier avec votre éditeur favori, décommentez et renseignez les paramètres suivants:

gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
gitlab_rails['backup_keep_time'] = 604800 # garde 7 jours de sauvegardes
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'OpenStack',
  'openstack_auth_url' => 'https://identity.fr1.cloudwatt.com/v2.0/tokens',
  'openstack_username' => 'USER_NAME', # L'email du compte
  'openstack_api_key' => 'PASSWORD', # Le mot de passe du compte
  'openstack_tenant' => 'TENANT_NAME' # Le nom du tenant
}
gitlab_rails['backup_upload_remote_directory'] = 'CONTAINER_NAME' # Le nom de votre conteneur

Attention à bien ajouter /tokens à la fin de l’URL d’authentification.

Maintenant, il ne reste plus qu’à compiler la configuration.

sudo gitlab-ctl reconfigure 

Testons si la sauvegarde est bien envoyée sur le conteneur.

cloud@neoxia-git:~$ sudo gitlab-rake gitlab:backup:create
Dumping database ...
Dumping PostgreSQL database gitlabhq_production ... [DONE]
done
Dumping repositories ...
done
Dumping uploads ...
done
Creating backup archive: 1421776186_gitlab_backup.tar ... done
Uploading backup archive to remote storage container_name ... done
Deleting tmp directories ... done
Deleting old backups ... done. (0 removed)

Si aucune erreur n’apparaît c’est que l’envoi a bien fonctionné.


Versions utilisées:

Gitlab: gitlab_7.6.2-omnibus.5.3.0.ci.1-1_amd64
Debian: Weezy 7.8