**Ceci est une ancienne révision du document !**
Tester une modification sur un service
Préambule
Avant de mettre en production un service, il faut s’assurer que la mise à jour n’a rien cassé. Même si vous avez testé la nouvelle image sur votre machine, il faut également la tester sur l’infrastructure de Picasoft, en particulier parce que les services ont souvent besoin de Traefik pour fonctionner.
Note:
On suppose pour la suite que
- Vous êtes connecté à la machine de test (
pica01-test.picasoft.net
), - Vous vous trouvez dans le clone du dépôt
dockerfiles
(voir gestion des services), - Que le dépôt est à jour (
git pull
), - Que vous êtes que votre branche de travail (ou
master
si vous n’en avez pas créée). - Que vous vous trouvez dans le sous-dossier du servir concerné.
Attention:
Si le service est accessible via Traefik et qu’un HEALTHCHECK
est configuré sur le conteneur, tant qu’il n’est pas noté healthy
, Traefik ne route pas vers le service. On vérifiera que le conteneur est noté healthy
dans la sortie de docker ps
avant de paniquer.
Automatisation du test
Le script docker_test.sh
, situé à la racine du dépôt, permet d’automatiser toutes les étapes pour tester un service et s’assurer qu’il fonctionne bien indépendamment des données précédentes, qui auraient été conservées dans un volume, par exemple. Il permet aussi de remplacer toutes les URL de production par des URL de test.
Il a le désavantage qu’on comprend moins ce que l’on fait. Pour s’en servir, lancez :
- snippet.bash
$ ./docker_test.sh <nom du dossier, e.g. pica-mattermost>
Attention:
Attention, cette commande écrase les modifications faites au sous-dossier par l’état courant du dépôt Git.
Vérifiez que les logs ne produisent aucune erreur et que le service fonctionne bien sur l’infrastructure de test, en y accédant via son URL par exemple (attention : remplacer picasoft.net
par test.picasoft.net
dans votre navigateur).
Si tout se passe bien, stoppez les logs avec Ctrl+C
puis aller dans le dossier du service. Ensuite, passer à l’étape revenir à l'état initial.
Tester manuellement
Si vous voulez tester le service “à la main”, ou que le script ne fonctionne pas pour vous, ou pour toute autre raison, suivez ces étapes :
Récupérer les modifications
- snippet.bash
git pull cd <sous-dossier, e.g. pica-mattermost> git checkout -- .
Remise à zéro
Si le service était déjà lancé sur la machine de test, éteignez-le et remettez les volumes à 0 :
- snippet.bash
docker-compose down -v
Si des volumes sont déclarés comme external
dans le fichier Compose, supprimez-les manuellement :
- snippet.bash
docker volume rm <volume>
Construction des images
Si le service utilise des images “maison”, il faut les construire. Si le fichier Compose est bien fait, il suffit de lancer :
- snippet.bash
docker-compose build
Sinon, il faut construire les images à la main. À répéter pour chaque image maison du service concerné :
- snippet.bash
docker build [-f <Dockerfile>] -t <image> <context>
- Si le
Dockerfile
a un nom différent, on utilise le switch-f
. <image>
doit avoir rigoureusement la valeur de la directiveimage
du fichier Compose.<context>
est le contexte que reçoit Docker pour construire l’image (base pour copier les fichiers). En général, c’est le dossier du service (donc.
, puisqu’on est dedans).
Remplacement des URLs
Si nécessaire. Certains services ne sont pas accessibles depuis Internet.
Remplacez les URL de production (.picasoft.net
) par des URL de tests (.test.picasoft.net
), sauf dans le nom de l’image :
- Si le service utilise Traefik, voir du côté de
traefik.http.services.<service>.rule
dans le fichier Compose - Si le service utilise des fichiers de configuration, remplacez les références aux URL…
Créer les fichiers de secrets
Dans le dossier secrets
, copier tous les .secrets.example
en .secrets
. S’assurer qu’ils contiennent des valeurs d’exemple.
Récupérer les nouvelles images
Si le service utilise des images officielles, on s’assure qu’elles sont bien à jour avec la commande :
- snippet.bash
docker-compose pull
Lancer le service
- snippet.bash
docker-compose up -d
Vérifier que tout fonctionne bien
- snippet.bash
docker-compose logs -f
On constate l’absence d’erreurs dans les logs, et si le service est accessible via Internet, on regarde que tout fonctionne bien depuis l’URL de test.
En cas de problème
Que les étapes de test aient été faites automatiquement ou manuellement, s’il y a un problème, on peut essayer de le régler directement sur la machine de test.
À partir de là, c’est carte blanche : on peut modifier la configuration, le Dockerfile
, reconstruire les images, etc. L’infrastructure de test est un bac à sable.
Si jamais les modifications ont permis de résoudre le problème, on les commit et on les synchronise avec le dépôt.
Attention:
Attention, on fait attention de ne pas pousser les modifications des URL de test ou toute autre modification faite uniquement à des fins de test.
Revenir à l'état initial
On se resynchronise avec l’état du dépôt en enlevant toutes les modifications induites par les tests.
- snippet.bash
# <sous-dossier> vaudra . si vous êtes déjà dedans git checkout --source=HEAD --staged --worktree -- <sous-dossier> # Si on était sur une autre branche git checkout master
Que faire après les tests ?
Si on a construit une nouvelle image, il faut aussi pousser la nouvelle version de l’image sur le registre de production. Pour ce faire, il suffit de lancer :
Note:
Cette commande est à lancer depuis le sous-dossier du service concerné.
- snippet.bash
$ docker-compose push
Attention:
Attention, cette opération nécessite d’être connecté au registre de production. Les identifiants se trouvent dans le pass.
On peut aussi le faire manuellement, pour chaque image maison (i.e. dont le nom commence par registry.picasoft.net
) :
- snippet.bash
# <image> doit correspondre exactement # à la directive image du fichier Compose # et commencer par registry.picasoft.net docker push <image>
Une fois les images poussées, on peut se rendre sur la machine de production et lancer le service (voir administration des services).