guide_utilisateur_ci.md

Utilisation de la chaîne d'intégration

Introduction

Ce dépôt utilise la chaîne d'intégration de Gitlab, ou CI, pour automatiser certaines tâches dès lors que des changements ont lieu sur le dépôt. L'idée est en particulier d'automatiser la construction des images Docker et les analyses de sécurité, ce qui permet d'améliorer la sécurité de l'infrastructure, d'unifier les procédures, de garder un historique clair des modifications et de synchroniser l'état des services sur les machines avec l'état de ce dépôt.

La CI est déclenchée dès lors qu'une modification est susceptible d'altérer un service est détectée.

Elle va effectuer les opérations suivantes, partiellement ou complètement selon le contexte :

• Détection de l'image modifiée,
• Construction de l'image Docker et push vers le registre de test,
• Analyses de sécurité,
• Push vers le registre de production.

Chaque étape peut échouer et bloquer les étapes ultérieures. Il faudra régler les problèmes et mettre à jour le dépôt afin de relancer la CI le cas échéant.

Mettre à jour un service

On peut vouloir mettre à jour :

• Le service (e.g. changer un numéro de version dans le Dockerfile),
• La configuration (éditer un fichier quelconque),
• La configuration des volumes (e.g. changer le point de montage du Docker Compose),
• etc.

En principe, il suffit de récupérer ce dépôt, de faire les mises à jour souhaitées, de commit les changements et de les pousser pour que l'image soit construite si besoin. Le cas échéant, pour des services "maisons", il est de bon ton de mettre à jour un fichier CHANGELOG.md pour résumer les modifications.

Si vous mettez à jour un fichier de configuration qui nécessite de reconstruire l'image, il faudra lancer la CI manuellement depuis la page Pipelines. Si vous mettez à jour un fichier de configuration qui est monté dans le conteneur via Docker Compose, aucune action de la CI n'est nécessaire, même pas l'action push-prod.

Notez que le nom final de l'image construite est celui que vous indiquez dans le docker-compose.yml. Si vous mettez à jour un service en lui-même (option 1 de la liste ci-dessus), il faut impérativement modifier la version de l'image construite dans ce fichier dans le docker-compose.yml.

Attention, la CI se déclenche en regardant les modifications apportées lors du dernier commit. Si vous modifiez le Dockerfile dans un commit, puis le README dans un autre, et que vous poussez le tout, la construction ne se déclenchera pas automatiquement.

Vous pouvez suivre les différentes étapes de la CI sur la page Pipelines, et il est recommandé de lire les logs des différentes étapes en cliquant sur chacune d'entre elles. Si la construction et les analyses de sécurité se passent bien, tous les voyants sont au vert (sauf la dernière étape, qui doit être déclenchée manuellement). Sinon, référez-vous à la section Troubleshooting.

Enfin, il est de bon ton de vérifier que les CVE whitelistées dans le fichier clair-whitelist.yml sont toujours détectées dans le scan de Clair (étape clair). Si non, on pourra les enlever de la liste.

On peut ensuite déployer le service.

Exemple de mise à jour

On veut mettre à jour Mattermost de la version 5.18.0 à la version 5.19.0. On fait les modifications dans le Dockerfile et on pousse le commit. Les modifications dépendent évidemment du service, on peut voir le commit 472e0d72 pour l'exemple.

Le pipeline se lance automatiquement. Je suis les logs des jobs un par un pour vérifier que tout se passe bien.