blog.bressure.net

La registry est un dépôt d’images docker. Son utilisation est centrale dans l’architecture que je veux metttre en place comme indiqué dans Docker – un pas vers la registry. Il restait le choix d’utiliser Gitlab en tant que Registry ou bien l’implementation conteneur registry de docker même.

Sauvegarde et sécurité

Le registry sera un élément de l’infrastructure et en tant que tel il devra être sauvegardé. Or le service Gitlab est déjà defini avec un mapping vers le systèmes de fichier hôte. Sauvegarder ce montage permet de sauvegarder toutes les données de Gitlab: sources et registry !

De plus l’utilisation du registery impose de s’y connecter en HTTPS. Le client docker (docker CLI) est configuré ainsi par défaut. Je vais garder ce paramétrage qui sera fort utile dans le cas où je voudrais déplacer mon registry ailleur que sur localhost.

Il faut donc mettre en place un frontal pour faire le TLS, or mon service gitlab est déjà dernier un proxy SSL.

Enfin mon besoin de limiter les droits des accès de la production et de la préprod en lecture au registry et dépôt de source est déjà pris en charge par des mécanismes de clé et de jeton de déploiement.

Toutes ces considérations me font choisir l’utilisation du registry intégré à Gitlab.

Mise en oeuvre

Sa mise en oeuvre est très simple. Le fichier docker-compose.yml devient:

version: "3.7"
services:

 web:
   image: 'gitlab/gitlab-ce:latest'
   restart: always
   hostname: 'gitlab.bressure.net'
   environment:
     GITLAB_OMNIBUS_CONFIG: |
       external_url 'https://gitlab.bressure.net'
       nginx['listen_port'] = 80
       nginx['listen_https'] = false

       registry_external_url 'https://registry.bressure.net'
       registry_nginx['listen_portex'] = 80
       registry_nginx['listen_https'] = false
       # Add any other gitlab.rb configuration here, each on its own line

       gitlab_rails['gitlab_shell_ssh_port'] = 2222
   ports:
      - '8080:80'    
      - '2222:22'
      
   volumes:
     - '/srv/gitlab/config:/etc/gitlab'
     - '/srv/gitlab/logs:/var/log/gitlab'
     - '/srv/gitlab/data:/var/opt/gitlab'

Il suffit déclarer l’url externe du registry pour que gitlab affiche le lien dans l’interface du projet. Voici le schéma d’architecture :

Il permet l’utilisation suivante:

1. sur la machine hôte on développe avec un éditeur
2. COMMIT en local
3. exécute en local et dans le cas particulier qui me concerne on lance un conteneur dit de DEV en local
4. on verifie le fonctionnement attendu (test)
5. on pousse les source sur GitLab par un PUSH
6. on pousse eventulement l’image dans le registry

On remarque la mise à disposition de la preprod et à la prod des livrables se fait par 2 biais selon le type de livrable:

• repository Git (Gitlab) pour les applications afin d’obtenir leur composition en terme de services ie en terme d’images. Il s’agit concrètement récupérer les fichiers docker-compose.yml
• registry docker (Gitlab) pour les images. Je fais finir par y arriver quand les images actuelles ne me suffiront plus…

CI /CD

On remarque que les étapes 3,4 et 6 pourraient être effectuées par l’Integration Continue (IC). En effet une fois poussée sur Gitlab, le code doit passer des tests. Si ces derniers sont concluants, un livrable doit être produit (jar, ear, image docker….) et dans la cas d’application on peut même déployer directement en preprod.

Cela ouvre la voie vers l’exploration de la construction.

A suivre dans le prochain billet