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:update [2020/10/07 19:55] qduchemitechnique:docker:picasoft:update [2022/05/24 20:15] (Version actuelle) ppom
Ligne 1: Ligne 1:
 {{indexmenu_n>35}} {{indexmenu_n>35}}
 # Mettre à jour un service ou sa configuration # Mettre à jour un service ou sa configuration
 +
 +<bootnote warning>
 +Prérequis : les articles de [[technique:docker:general:start|cette section]].
 +</bootnote>
  
 <bootnote>Ces explications ne valent que pour un service qui est déjà en production et que l'on souhaite mettre à jour.</bootnote>  <bootnote>Ces explications ne valent que pour un service qui est déjà en production et que l'on souhaite mettre à jour.</bootnote> 
  
-Tous les fichiers permettant de paramétrer les conteneurs Docker et les services sont versionnés sur le dépôt [dockerfiles](https://gitlab.utc.fr/picasoft/dockerfiles) (voir [[technique:docker:picasoft:dockerfiles|gestion des services]]).+Tous les fichiers permettant de paramétrer les conteneurs Docker d'un service sont versionnés sur son dépôt[ici(https://gitlab.utc.fr/picasoft/projets/services) (voir [[technique:docker:picasoft:dockerfiles|gestion des services]]).
  
 On peut vouloir mettre à jour : On peut vouloir mettre à jour :
Ligne 19: Ligne 23:
 ## Comment mettre à jour un service ? ## Comment mettre à jour un service ?
  
-Il est pertinent de créer une branche avant chaque mise à jour où vous n'êtes pas sûr des modifications, et ne de fusionner dans `master` que lorsque les tests ont été effectués.+Il pourrait être pertinent de créer une branche avant chaque mise à jour où vous n'êtes pas sûr des modifications, et ne de fusionner dans `master` que lorsque les tests ont été effectués. 
 + 
 +<bootnote critical> 
 +Les instructions spécifiques  de mise à jour de chaque service se trouvent dans le README de chaque dossier. Pensez à y jeter un coup d'oeil. 
 +</bootnote>
  
 ### Mise à jour de la configuration ### Mise à jour de la configuration
Ligne 25: Ligne 33:
 On appelle **configuration** tout ce qui ne nécessite pas de reconstruire l'image Docker, par exemple : On appelle **configuration** tout ce qui ne nécessite pas de reconstruire l'image Docker, par exemple :
  
-* Modification du `docker-compose.yml` (environnement, point de montage, changement du tag d'une image officielle...). Par exemple, Wekan est mis à jour uniquement en changeant le [numéro de version dans le fichier Compose](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/master/pica-wekan/docker-compose.yml), car il utilise une image déjà construite. +* Modification du `docker-compose.yml` (environnement, point de montage, changement du tag d'une image officielle...). Par exemple, Wekan est mis à jour uniquement en changeant le [numéro de version dans le fichier Compose](https://gitlab.utc.fr/picasoft/projets/services/wekan/-/blob/master/docker-compose.yml), car il utilise une image déjà construite. 
-* Modification d'un fichier de configuration monté dans le conteneur. Par exemple, Etherpad utilise un fichier [settings.json](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/master/pica-etherpad/settings.json) qui est monté dans l'image à chaque démarrage.+* Modification d'un fichier de configuration monté dans le conteneur. Par exemple, Etherpad utilise un fichier [settings.json](https://gitlab.utc.fr/picasoft/projets/services/etherpad-yearly/-/blob/master/settings.json) qui est monté dans l'image à chaque démarrage.
 * etc. * etc.
  
Ligne 39: Ligne 47:
 Certaines modifications nécessitent de reconstruire l'image, par exemple : Certaines modifications nécessitent de reconstruire l'image, par exemple :
  
-* Changement d'un numéro de version dans une archive téléchargée dans le `Dockerfile`. Par exemple, Mattermost indique le numéro de version de la *release* à téléchargement [directement dans le Dockerfile](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/master/pica-mattermost/Dockerfile). +* Changement d'un numéro de version dans une archive téléchargée dans le `Dockerfile`. Par exemple, Mattermost indique le numéro de version de la *release* à téléchargement [directement dans le Dockerfile](https://gitlab.utc.fr/picasoft/projets/services/mattermost/-/blob/master/Dockerfile). 
-* Ajout d'un paquet. Par exemple, on pourrait avoir besoin de rajouter un module PHP pour une nouvelle extension [directement dans le Dockerfile](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/master/pica-dokuwiki/Dockerfile). +* Ajout d'un paquet. Par exemple, on pourrait avoir besoin de rajouter un module PHP pour une nouvelle extension [directement dans le Dockerfile](https://gitlab.utc.fr/picasoft/projets/services/dokuwiki/-/blob/master/Dockerfile). 
-* Changement d'un script d'initialisation copié dans le Dockerfile. Par exemple, le [script d'initialisation de Plume](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/master/pica-plume/entrypoint.sh) effectue diverses opérations que l'on pourrait vouloir compléter, et ce script est copié [directement dans le Dockerfile](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/master/pica-plume/Dockerfile).+* Changement d'un script d'initialisation copié dans le Dockerfile. Par exemple, le [script d'initialisation de Plume](hhttps://gitlab.utc.fr/picasoft/projets/services/plume/-/blob/master/entrypoint.sh) effectue diverses opérations que l'on pourrait vouloir compléter, et ce script est copié [directement dans le Dockerfile](https://gitlab.utc.fr/picasoft/projets/services/plume/-/blob/master/Dockerfile).
 * etc. * etc.
- 
-<bootnote warning>Si le code du service à copier dans l'image est intégré au dépôt par un submodule (par exemple avec [pica-metrics-bot](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/pica-metrics-bot)), on lancera la commande suivante pour le mettre à jour à la dernière version. Voir la documentation des submodules pour utiliser un tag ou une branche spécifique. 
-``` 
-git submodule update --recursive --remote <dossier du service> 
-```</bootnote> 
  
 Vous pouvez travailler en local et tester l'image sur votre machine si vous voulez. Il y a quelques modifications supplémentaires à apporter. Comme on construit une nouvelle version de l'image, il faut modifier le tag dans le fichier Compose pour que l'image construite soit différenciée des précédentes. Vous pouvez travailler en local et tester l'image sur votre machine si vous voulez. Il y a quelques modifications supplémentaires à apporter. Comme on construit une nouvelle version de l'image, il faut modifier le tag dans le fichier Compose pour que l'image construite soit différenciée des précédentes.
  
 * Si on met à jour un service (version X → version Y), on passera le tag du fichier Compose de X à Y. * Si on met à jour un service (version X → version Y), on passera le tag du fichier Compose de X à Y.
-* Si on met juste à jour un fichier "maison" ou une configuration intégrée dans l'image, mais qu'on ne change pas la version du logiciel, on pourra ajouter au tag quelque chose comme `-Z`, de sorte que le tag deviennent `registry.picasoft.net/pica-<service>:vX-Y`+* Si on met juste à jour un fichier "maison" ou une configuration intégrée dans l'image, mais qu'on ne change pas la version du logiciel, on pourra ajouter au tag quelque chose comme `-Z`, de sorte que le tag deviennent `registry.picasoft.net/pica-<service>:vX-Z`.
  
 Dans tous les cas, on modifiera ou on créera le fichier `CHANGELOG.md` pour décrire les modifications apportées à l'image. Dans tous les cas, on modifiera ou on créera le fichier `CHANGELOG.md` pour décrire les modifications apportées à l'image.
 +## Que faire ensuite ?
  
-Une fois que toutes ces modifications sont poussées sur le dépôt, 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]]. +Une fois arrivé à ce stade, votre nouvelle version du service est prête à être déployée depuis n'importe quelle machine de Picasoft. La prochaine étape est [[technique:docker:picasoft:test|de tester la modification]] que vous avez apportée, sauf si elle est vraiment minime (exemple : changement marginal d'un paramètre de configuration).
- +
-Le plus simple est de se rendre sur la machine de test (qui est sans doute plus puissante que votre machine et se trouve sur le même réseau que le registre de production), de se synchroniser avec le dépôt, de construire l'image, et de la pousser. Ça ressemble à ça : +
- +
-```bash +
-$ ssh login@pica01-test.picasoft.net +
-$ cd /DATA/docker/dockerfiles +
-$ git pull +
-# Si vous avez travaillé sur une branche spécifique +
-$ git checkout <votre branche> +
-$ cd pica-<service> +
-# Construire la nouvelle image et la tagger +
-# avec le nom indiqué dans le fichier Compsoe +
-$ docker-compose build +
-# Pousser l'image construite sur registry.picasoft.net +
-$ docker-compose push +
-``` +
- +
-<bootnote warning>Attention, cette opération nécessite d'être connecté au registre de production. Les identifiants se trouvent dans le [pass](https://gitlab.utc.fr/picasoft/interne/pass).</bootnote> +
- +
-## Conclusion +
- +
-Une fois arrivé à ce stade, votre nouvelle version du service est prête à être déployée depuis n'importe quelle machine de Picasoft. La prochaine étape est de tester la modification que vous avez apportée, sauf si elle est vraiment minime (exemple : changement marginal d'un paramètre de configuration).+
  • technique/docker/picasoft/update.1602093320.txt.gz
  • de qduchemi