technique:docker:picasoft:test

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision		 Révision précédente
technique:docker:picasoft:test [2020/10/07 20:05] – qduchemitechnique:docker:picasoft:test [2022/09/23 10:16] (Version actuelle) – modification externe 127.0.0.1
Ligne 1: Ligne 1:
 {{indexmenu_n>40}} {{indexmenu_n>40}}
 # Tester une modification sur un service # Tester une modification sur un service
 +
 +<bootnote warning>
 +Prérequis : les articles de [[technique:docker:general:start|cette section]].
 +</bootnote>
 +
 +## 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. 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.
  
 <bootnote>On suppose pour la suite que <bootnote>On suppose pour la suite que
-   * Vous êtes connecté à la machine de test (`pica01-test.picasoft.net`) +   * Vous êtes connecté à la machine de test (`pica01-test.picasoft.net`), 
-   * Vous vous trouvez dans le clone du dépôt `dockerfiles` (voir [[technique:docker:picasoft:dockerfiles|gestion des services]]); +   * Vous vous trouvez dans le clone du bon dépôt (voir [[technique:docker:picasoft:dockerfiles|gestion des services]]), 
-   * Que le dépôt est à jour (`git pull`),+   * Que les modifications à tester sont "actives" (récupérées du dépôt ou faites directement sur la machine),
    * Que vous êtes que votre branche de travail (ou `master` si vous n'en avez pas créée).    * 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é.
 </bootnote> </bootnote>
  
 <bootnote warning>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.</bootnote> <bootnote warning>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.</bootnote>
  
-### Automatiquement +## Tester manuellement
- +
-Le script [docker_test.sh](../docker_test.sh) 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 : +
- +
-```bash +
-$ ./docker_test.sh <nom du dossier, e.g. pica-mattermost> +
-``` +
- +
-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). +
- +
-### 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 : 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 :
 +On suppose que le fichier Compose est déjà à jour (modifié sur la machine ou récupéré via un `git pull`).
  
-#### Synchronisation +### Remise à zéro
- +
-Synchronisez vous **exactement** avec le dépôt : +
- +
-```bash +
-# master ou votre branche perso +
-git checkout <votre branche> +
-git pull +
-``` +
- +
-#### Remise à zéro+
  
 Si le service était déjà lancé sur la machine de test, éteignez-le et remettez les volumes à 0 : Si le service était déjà lancé sur la machine de test, éteignez-le et remettez les volumes à 0 :
Ligne 53: Ligne 39:
 ``` ```
  
-#### Construction des images+### 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 : Si le service utilise des images "maison", il faut les construire. Si le fichier Compose est bien fait, il suffit de lancer :
Ligne 67: Ligne 53:
 ``` ```
  
-* Si le `Dockerfile` a un nom différent, on utilise le switch `-f` +* Si le `Dockerfile` a un nom différent, on utilise le switch `-f`. 
-* `<image>` doit avoir rigoureusement la valeur de la directive `image` du fichier Compose+* `<image>` doit avoir rigoureusement la valeur de la directive `image` 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). * `<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+### Remplacement des URLs
  
 Si nécessaire. Certains services ne sont pas accessibles depuis Internet. Si nécessaire. Certains services ne sont pas accessibles depuis Internet.
Ligne 77: Ligne 63:
 Remplacez les URL de production (`.picasoft.net`) par des URL de tests (`.test.picasoft.net`), sauf dans le nom de l'image : 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>.loadbalancer.server.port` dans le fichier Compose+* 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... * Si le service utilise des fichiers de configuration, remplacez les références aux URL...
  
-### Créer les fichiers d'example+### Créer les fichiers de secrets
  
-Copier tous les `.secrets.example` en `.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+### Récupérer les nouvelles images
  
 Si le service utilise des images officielles, on s'assure qu'elles sont bien à jour avec la commande : Si le service utilise des images officielles, on s'assure qu'elles sont bien à jour avec la commande :
Ligne 92: Ligne 78:
 ``` ```
  
-#### Lancer le service+### Lancer le service
  
 ```bash ```bash
Ligne 98: Ligne 84:
 ``` ```
  
-#### Vérifier que tout fonctionne bien+### Vérifier que tout fonctionne bien
  
 ```bash ```bash
Ligne 106: Ligne 92:
 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. 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+## En cas de problème
  
-À 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.+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. Si jamais les modifications ont permis de résoudre le problème, on les commit et on les synchronise avec le dépôt.
  
-### Revenir à l'état initial+<bootnote warning>Attention, on fait attention de ne pas pousser les modifications des URL de test ou toute autre modification faite uniquement à des fins de test.</bootnote>
  
-On se resynchronise avec l'état du dépôt en enlevant toutes les modifications induites par les tests. +## Revenir à l'état initial 
-```bash + 
-git reset --hard +On enlève toutes les modifications induites par les tests, notamment le remplacement des URL. Ensuite, si on avait fait les modifications directement sur la machine de test, on peut commit et push.
-```+
  
 ## Que faire après les tests ? ## Que faire après les tests ?
  
-Une fois qu'on est convaincu que la nouvelle version du service fonctionne bien, on peut le mettre en production.+Si on a construit une nouvelle image, il faut aussi pousser la nouvelle version de l'image sur le [[technique:docker:general:mise_en_place_d_un_registry_docker|registre de production]]. Pour ce faire, il suffit de lancer :
  
-Au préalable, si le service utilise des images maison, on les pousse sur le registre de production. Pour ce faire, vous devez connecté au registre de production : on s'assure de bien avoir exécuté la commande `docker login registry.picasoft.net`. Les identifiants sont sur le [pass](https://gitlab.utc.fr/picasoft/interne/pass).+<bootnote>Cette commande est à lancer depuis le sous-dossier du service concerné.</bootnote>
  
 ```bash ```bash
-docker-compose push+$ docker-compose push
 ``` ```
  
-Cette commande pratique indique à Docker Compose de pousser toutes les images du fichier.+<bootnote warning>Attention, cette opération nécessite d'être connecté au registre de production. Les identifiants se trouvent dans le [[asso:tuto:vaultwarden|vaultwarden]].</bootnote>
  
 On peut aussi le faire manuellement, pour chaque image maison (*i.e.* dont le nom commence par `registry.picasoft.net`) : On peut aussi le faire manuellement, pour chaque image maison (*i.e.* dont le nom commence par `registry.picasoft.net`) :
Ligne 140: Ligne 127:
 ``` ```
  
-Une fois les images poussées, on se rend sur la machine de production et on [lance le service](./launch_service.md).+Une fois les images poussées, on peut se rendre sur la machine de production et lancer le service (voir [[technique:docker:picasoft:admin|administration des services]]).
  • technique/docker/picasoft/test.1602093934.txt.gz
  • de qduchemi