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
services:services_upgrade [2019/04/10 10:51]
dheninli
services:services_upgrade [2019/06/18 18:55] (Version actuelle)
gdamiens [Comment appliquer ce patch ?]
Ligne 1: Ligne 1:
-====== Procédure de mise à jour des services ======+====== Procédure ​d'​ajout ou de mise à jour des services ====== 
 + 
 +Cette procédure vaut pour mettre un jour n'​importe quel service, que ce soit un service interne ou un service externe (exemple : Traefik, Mattermost, Etherpad...). 
 + 
 +La page est organisée est plusieurs sections. 
 + 
 +  * La première est le **canevas général** applicables à tous les services. C'est ce canevas qui doit être suivi lors de tous les déploiements de nouveaux services ou lors des mises à jour. 
 +  * La deuxième liste les **cas particuliers**,​ qui ajoutent des étapes au canevas. Ces étapes passées, il faut revenir au canevas.
  
 ===== Préparation ===== ===== Préparation =====
-Pour déployer une nouvelle version d'un service, on se rend maintenant ​sur la machine de production qui fait tourner le service (''​pica01''​ ou ''​pica02''​). Bien entendu, on ne fait pas une mise à jour n'​importe comment, il faut s'​assurer :  +Pour déployer une nouvelle version d'un service, après les tests, on se rend sur la machine de production qui fait tourner le service (''​pica01''​ ou ''​pica02''​). Bien entendu, on ne fait pas une mise à jour n'​importe comment, il faut s'​assurer :  
-  * que l'on a une backup récente de la potentielle base de données. +  * Que l'on a une backup récente de la potentielle base de données. 
-  * que le service n'est pas trop utilisé. On ne fait pas un déploiement à 19H, la coupure va déranger tout le monde; +  * Que le service n'est pas trop utilisé. On ne fait pas un déploiement à 19H, la coupure va déranger tout le monde; 
-  * que les autres bénévoles sont au courant de la mise à jour. Même si la coupure de service est courte, un⋅e sysadmin qui voit que le service est tombé va s'​affoler pour rien :)+  * Que les autres bénévoles sont au courant de la mise à jour. Même si la coupure de service est courte, un⋅e sysadmin qui voit que le service est tombé va s'​affoler pour rien :)
  
 ====== Principe général ====== ====== Principe général ======
  
-Afin de mettre une jour un service, plusieurs étapes sont nécessaires ​ +Afin de mettre une jour un service, plusieurs étapes sont nécessaires
-  ​* ​Tout d'​abord,​ il faut des images : deux cas de figure se présentent alors. ​Soit ces images doivent être récupérées d'un registry externedans ce cas il faut se baser directement dessus dans le docker-composeSinon il faut builder ces images à partir d'​un ​dockerfile/​docker-composeUn git clone du repository (GitLabGitHub...) permet d'​avoir les fichiers nécessaires que l'on build ensuite+ 
-  * Les images ​sont maintenant ​sur le serveur ou sont récupérées directement d'​un ​registry externe. Il n'est pas nécessaire de stocker toutes les images sur celui Picasoft : en effet il est inutile de surcharger ​ce registry ​avec des copies conformes à celles d'​autres registry. Seules les images ​compilées ​depuis un dockerfile ​ont vocation à l'​être ​: une fois l'​image ​construiteil faut la pousser ​sur le registry ​de Picasoft+Tout d'​abord,​ il faut des images ​Docker ​trois cas de figure se présentent alors 
-  ​* ​La dernière étape est la mise en production. Il faut se rendre sur la machine dans laquelle se trouve le service en question, arrêter les conteneurs concernés et en lancer avec les nouvelles images.+  * Construction de l'​image directement sur la machineC'est la procédure classique pour les tests**fortement déconseillée** en production. 
 +  * Récupération de l'image déjà construite depuis ​un *registre* externeSauf cas particulieret hors tests**déconseillé** pour des raisons de sécurité (on ne maîtrise pas l'image)
 +  * Construction des images ​et push sur un registre privé appartenant à Picasoft. Ainsi, n'importe quelle machine de Picasoft pourra utiliser ces images. 
 + 
 +La [[adminsys:​mise_en_place_d_un_registry_docker|première section de cet article]] détaille ​un peu plus ces trois possibilités. 
 + 
 +Il n'est pas nécessaire de stocker toutes les images sur le registre de Picasoft : en effet il est inutile de le  ​surcharger avec des copies conformes à celles d'​autres registry. Seules les images ​construites ​depuis un Dockerfile ​ont vocation à l'​être
 + 
 +L'avant dernière étape est le test de la nouvelle ​image, sur la machine ​de test
 + 
 +La dernière étape est la mise en production. Il faut se rendre sur la machine dans laquelle se trouve le service en question, arrêter les conteneurs concernés et en lancer avec les nouvelles images. 
 ====== Cas général ====== ====== Cas général ======
-Dans la majorité ​des cas, il faudra récupérer les images officielles déjà construitesElles sont disponibles via des registry ​(exemple ​quay.io pour wekan)Pour stocker ces images sur le serveur, la commande ​''​docker pull'' ​doit être utilisée ​+===== Récupération ​des images ===== 
 + 
 +La première étape consiste à obtenir l'​image que l'on souhaite déployer. Deux cas se présentent alorscomme évoqué. 
 + 
 +==== Cas 1 : construction ​des images ==== 
 + 
 +Cas d'​utilisation : on a nous même écrit un Dockerfile ​(stocké sur [[https://gitlab.utc.fr/​picasoft/​dockerfiles|le dépôt des Dockerfiles maintenus par Picasoft]]) ou on récupère un Dockerfile déjà écrit par quelqu'un d'autre. C'est le cas des images Mattermost, que l'on construit nous même à partir du Dockerfile présent sur [[https://​github.com/​mattermost/​mattermost-docker|le dépôt officiel]]. 
 + 
 +Exemple ​:
 <code bash> <code bash>
-docker pull externalRegistry/​folder/​image:​tag +$ git clone <dépot où se trouve le Dockerfile>​ 
-docker ​pull imageFromPicasoftRegistry:​tag2+$ cd <dossier où se trouve le Dockerfile>​ 
 +docker ​build -t <nom à donner à l'​image>​ .
 </​code>​ </​code>​
-pour respectivement une image venant d'un registry externe et d'une image venant du registry de Picasoft. 
  
-Dans d'autres casil faut construire nous-mêmes ces images depuis un docker-compose ​ou un dockerfilegrâce ​à la commande ''​docker-compose build'' par exemple. Elle permet, depuis un dockerfile, de construire les images spécifiées dans le fichier ​docker-compose.ymlDans le dossier dans lequel se trouve le fichier ​docker-compose.yml ​:+==== Cas 2 : récupération ​d'une image existante ==== 
 + 
 +Cas d'​utilisation : une image existe déjàsur notre registre privé ​ou sur un registre public : 
 +  * Cas A : on fait des testset dans ce cas on est autorisé ​à récupérer une image sur un registre public (qu'on ne maîtrise pas), par exemple le [[https://​hub.docker.com/|Hub officiel Docker par défaut]]. 
 +  * Cas B : on a déjà construit et poussé une image sur notre registre privé, que l'on récupère sur la machine cible. 
 + 
 +Pour télécharger ces images sur le serveur, la commande ''​docker ​pull''​ doit être utilisée ​
 <code bash> <code bash>
-docker-compose build+# Cas A : on télécharge l'​image depuis un registre extérieur. Exemple pour l'​image officielle de WeKan : 
 +docker ​pull quay.io/​wekan/​wekan:​v1.07 
 +# Cas B : on télécharge l'​image depuis le registre de Picasoft. Exemple pour l'​image Mattermost que l'on a construit nous-même à partir du Dockerfile officiel : 
 +docker pull registry.picasoft.net/​mattermost:​5.11.0
 </​code>​ </​code>​
  
-Il faut ensuite ​tag les images, c'​est-à-dire leur donner un nom. ''​docker tag''​ est utilisée+===== Étiquetage et registre ===== 
 + 
 +Cette section n'est valable que pour les images que l'on souhaite pousser sur notre registre privé. Une image importée d'un registre public à des fins de tests n'a pas vocation à terminer sur notre registre privé, comme expliqué plus haut. 
 + 
 +Il faut ensuite ​étiqueter ​les images, c'​est-à-dire leur donner un nom et une étiquetteLe nom est unique, les étiquettes peuvent être multiples. Une bonne pratique est d'utiliser la **version** du service comme étiquette. 
 + 
 +Par défaut, lorsqu'une image est construite, elle utilise l'​étiquette *latest*, qui est à proscrire, pour des raisons [[https://​vsupalov.com/​docker-latest-tag/​|détaillées ici]]. 
 + 
 +Le nommage et l'étiquette des images utilisent la commande ​''​docker tag''​. Le nom de l'​image finale ​est arbitraire et devrait rester court et simple. 
 <code bash> <code bash>
-docker tag externalRegistry/​folder/image:tag extImage:​new_tag +# Le nom de l'​image locale est accessible avec la commande "​docker images"​. 
-docker tag imageFromPicasoftRegistry:​tag PicaImage:new_tag2+docker tag <image locale> registry.picasoft.net/<nom souhaité pour le registre>:<​étiquette (version)>​ 
 +# Exemple, si docker images m'​informe qu'​une ​image se nomme mattermost_docker_web ​
 +docker tag mattermost_docker_web registry.picasoft.net/​mattermost-web:5.11.0
 </​code>​ </​code>​
  
 +Les nouveaux alias des images doivent à présent être visibles via un ''​docker images''​. En reprenant l'​exemple ci-dessus, on aura à la fois l'​image locale et l'​étiquette que l'on vient de créer.
 +<code bash>
 +# Les images ne sont pas dupliquées : ce ne sont que des alias.
 +$ docker images
 +REPOSITORY ​                                ​TAG ​        ​CREATED ​            SIZE
 +mattermost_docker_web ​                     latest ​     2 days ago          700MB
 +registry.picasoft.net/​mattermost-web ​      ​5.11.0 ​     2 days ago          700MB
 +</​code>​
 +
 +Il faut pousser l'​image sur le registre privé de Picasoft avant le déploiement,​ car les images sont régulièrement nettoyées sur les machines, tandis que les images du registre sont plus pérennes. Ceci se fait grâce à la commande ''​docker push''​.
  
-Les images doivent à présent être visibles via un ''​docker images''​ ou ''​docker image ls''​ 
 <code bash> <code bash>
-gdamiens@pica01-test:~$ docker images +# En reprenant l'​exemple donné plus haut : 
-REPOSITORY ​                  ​TAG ​        ​CREATED ​             SIZE +docker push registry.picasoft.net/​mattermost-web:5.11.0
-extImage ​                    ​new_tag ​    3 days ago          700MB +
-PicaImage ​                   new_tag2 ​   6 days ago          425MB+
 </​code>​ </​code>​
  
-Si ces actions ont été faites depuis un autre serveur ​que le serveur ​de productionl'​étape ​suivante ​est nécessaire avant le déploiement. ​Afin que ces images soient accessibles via un autre environnementnous devons ​les pousser sur le registry de Picasoft, ​grâce ​à la commande ​''​ docker ​push''​+Il est possible ​que vous obteniez une erreur d'​autorisation. En effet, ​le registre privé ​de Picasoft nécessite de s'​identifierce qui est possible avec la commande ​''​docker login''​. La gestion des identifiants est [[https://​gitlab.utc.fr/​picasoft/​interne/​pass|détaillée ici]]. Si vous n'y avez pas accès, rapprochez vous de la [[https://​team.picasoft.net/​picasoft/​channels/​team-technique|team technique sur Mattermost]]. 
 + 
 +===== Déploiement ===== 
 + 
 +La dernière ​étape est celle du déploiement, à effectuer **d'​abord** sur l'​environnement de test, puis sur l'​environnement de productionLa procédure est similaire pour les deux environnements. 
 + 
 +Maintenant ​que l'​image est accessible depuis toutes les machines, on commence par mettre à jour le ''​docker-compose.yml''​ situé dans ''/​DATA/​docker''​ : 
 +  * Remplacement du nom et/ou du tag de l'​ancienne image  
 +  * Ajout de nouveaux paramètres de configuration 
 +  * ... 
 + 
 +Docker Compose est un système d'​orchestration et de gestion des services. Si vous n'​êtes pas familiers avec[[https://​docs.docker.com/​compose/​|jetez un œil ici]]. 
 + 
 +**Attention !! On utilise uniquement ​les images ayant pour //​tag// ​le numéro d'une version.** 
 + 
 +Pour la suite des commandes, on utilise **le nom des services** du ''​docker-compose.yml'',​ et **pas** le nom des images ni des conteneurs. 
 + 
 +Prenons l'​exemple suivant : 
 + 
 +<code yaml> 
 +# '​app'​ est le nom du service, 'registry.picasoft.net/​pica_app:​5.9.0'​ est le nom de l'​image. 
 +app: 
 +    image: registry.picasoft.net/​pica_app:​5.9.0 
 +    container_name:​ app_container 
 +</​code>​ 
 + 
 +Supposons que l'on vienne de passer ''​app''​ en version ''​5.10.0'',​ et qu'on l'a poussée sur le registre privé ​de Picasoft ​avec le tag ''​5.10.0''​. La section du docker-compose devient : 
 + 
 +<code yaml> 
 +app: 
 +    image: registry.picasoft.net/​pica_app:​5.10.0 
 +    container_name:​ app_container 
 +</​code>​ 
 + 
 +*Note : si l'on est sur la machine de test et que l'​image n'est pas sur le registre privéon ajoutera simplement un service avec le nom de l'​image sur le registre public.* 
 + 
 +Si l'on ajoute un nouveau service, on peut passer cette étape. 
 + 
 +Les conteneurs ​à mettre à jour doivent tout d'​abord être stoppés (''​docker-compose stop app''​) avant d'​être effacés (''​docker-compose rm app''​).
 <code bash> <code bash>
-docker push registry.picasoft.net/extImage:​new_tag +cd /DATA/​docker/ ​&& docker-compose stop -t 60 app && docker-compose rm app
-docker ​push registry.picasoft.net/PicaImage:​new_tag2+
 </​code>​ </​code>​
  
-Il existe des particuliers ​pour certains services : se référer à la partie Cas particuliers.+Il est important de stopper les conteneurs avant de les effacer ​pour minimiser les risque de corruption. L'​option ''​-t 60''​ indique un timeout de 60 secondes, pour laisser le temps aux conteneurs de faire les sauvegardes nécessaires dans les éventuels volumes
  
-Déploiementà effectuer ​dans l'​environnement ​de production : +En particulier, dans le cas de conteneurs ​qui gèrent une base de données, il est **indispensable** de laisser un délai de 60 secondes avant l'arrêt du conteneur. Dans le cas d'un couple application/​base de données, il est également préférable de ne lancer le conteneur applicatif qu'après avoir laissé un peu de temps à la base de données de se lancer. 
-Les conteneurs ​à mettre à jour doivent tout d'abord être stoppés (''​docker stop''​) avant d'être effacés (''​docker rm''​)Puisrelancer ​créer les nouveaux conteneurs avec ''​docker-compose up -d''​ :+ 
 +Enfinil faut créer les nouveaux conteneurs avec ''​docker-compose up -d app''​ :
 <code bash> <code bash>
-cd /​DATA/​docker/​ && docker stop old-app && docker stop -t 60 old-app2 \ +docker-compose up -d app
-&& docker rm old-app && docker rm old-app2 \ +
-&& ​docker-compose up -d new-app2 && sleep 5 && docker-compose up -d new-app+
 </​code>​ </​code>​
 +===== Épilogue =====
  
-Il est important de stopper ​les conteneurs ​avant de les effacerpour éteindre correctement ​la base de données et minimiser ​le risque de corruptionL'​option ​''​-t 60'' ​indique un timeout ​de 60 secondes+On s'​assurera que les conteneurs ​sont bien déployés : 
 +  - Si le ''​docker-compose.yml''​ précise un ''​healthcheck''​on pourra s'​assurer que le conteneur tourne bien en regardant son statut avec la commande ''​docker container ls''​. Si le conteneur n'est pas listé, alors il a probablement crashé, ce qui est une mauvaise nouvelle. 
 +  - La commande ​''​docker-compose logs -f <​service>​'' ​permet ​de lire les logs envoyés sur ''​stdout''​ depuis le conteneur, et de suivre les nouvelles entrées. On peut voir si tout se passe bien au moment du lancement.
  
-Attention : Dans le cas de conteneurs qui contiennent une base de donnéesil est préférable ​de laisser un délai ​de 60 secondes avant l'arrêt du conteneurPrécédemment,​ le duo old-app2/new-app2 est une base de donnéesIl est également préférable ​de ne lancer ​le conteneur applicatif qu'après avoir laissé un peu de temps à la base de données de se lancer (ici sleep 5)+Une fois que l'on a vérifié que la nouvelle version du service tourne correctementon peut nettoyer les anciennes images ​de la machine ​de production pour gagner de la place (commande ​''​docker image rm''​)Avec notre exemple précédent : 
 + 
 +<code bash> 
 +$ docker image rm registry.picasoft.net/pica_app:5.9.0 
 +</​code>​ 
 + 
 +===== En cas de problème ===== 
 + 
 +Si le déploiement n'a pas fonctionné,​ il est important ​de revenir rapidement ​à la dernière version fonctionnelle. Pour ce faire, on déroule la procédure en sens inverse : 
 + 
 +  * Changement du numéro ​de version dans le `docker-compose.yml` 
 +  * Extinction des conteneurs 
 +  * Création des conteneurs avec l'​ancienne version
  
 ====== Cas particuliers ====== ====== Cas particuliers ======
  
-===== Cas Mattermost =====+===== Wekan et Tellform ===== 
 +Lors de la mise à jour de Tellform et de Wekan, il faut faire attention à la validité du patch pour Tellform et du sed pour Wekan. De plus, faute de procédure d'​installation du Wekan, le Dockerfile pica-wekan est presque identique à l'​original (dernière update v2.75) à l'​exception des premiers RUN. Il faut faire attention s'il y a eu une quelconque modification. 
 + 
 +Pour Tellform, le patch se trouve dans les [[https://​gitlab.utc.fr/​picasoft/​projets/​dockerfiles|Dockerfiles]],​ dans le dossier pica-tellform et se nomme tellform-patch.patch.  
 + 
 +==== Comment créer un patch ? ==== 
 +  * Liste à puceDans un répertoire externe au serveur Picasoft (typiquement une machine personnelle),​ cloner le service en question : 
 +<​code>​ git clone https://​github.com/​service_en_question/​service_en_question.git </​code>​ 
 +  * Créer une copie de ce répertoire,​ qui contiendra les modifications que nous voulons appliquer au service. 
 +<​code>​ cp -a service_en_question service_en_question_modif </​code>​ 
 +  * Faire les modifications nécessaires dans les fichiers appropriés,​ dans le dossier ```service_en_question_modif``` 
 +  * Retourner dans le dossier contenant ```service_en_question``` et ```service_en_question_modif``` 
 +  * Appliquer le patch. Attention, l'​ordre des paramètres est très important. 
 +<​code>​ diff -Naur service_en_question service_en_question_modif > nom_du_service.patch </​code>​ 
 + 
 +Le fichier contenant le patch est créé, il ne reste plus qu'à l'​appliquer dans le Dockerfile, après avoir cloné le service que l'on souhaite modifier.  
 + 
 +==== Comment appliquer ce patch ? ==== 
 + 
 +  * Dans le Dockerfile, intégrer le patch en le copier dans le même répertoire où il sera appliqué (/opt dans cet exemple) 
 + 
 +<​code>​ COPY nom_du_service.patch /opt </​code>​ 
 +  * Appliquer le patch 
 + 
 +<​code>​ patch -p0 < nom_du_service.patch </​code>​ 
 +===== Mattermost =====
 ==== Images Docker ==== ==== Images Docker ====
 Pour déployer Mattermost, Picasoft utilise 2 images Docker : une image pour l'​application (que l'on appellera ''​app''​) et une image pour la base de données PostgreSQL (que l'on appellera ''​db''​). Pour déployer Mattermost, Picasoft utilise 2 images Docker : une image pour l'​application (que l'on appellera ''​app''​) et une image pour la base de données PostgreSQL (que l'on appellera ''​db''​).
  
 === Récupération du code mis à jour === === Récupération du code mis à jour ===
-Pour //builder// et pousser les images, on va récupérer ​le //​repository// ​Git qui pointe sur [[https://​github.com/​mattermost/​mattermost-docker|l'​upstream maintenue par Mattermost]]. \\ +On va récupère ​le dépôt ​Git qui pointe sur [[https://​github.com/​mattermost/​mattermost-docker|l'​upstream maintenue par Mattermost]]. ​
-On clone le repository et on se place dans le dossier.+
  
-Il faut ensuite modifier ​fichier ''​docker-compose.yml''​ du //​repository//​ pour permettre de //builder// la version libre de Mattermost. Normalement,​ les lignes suivantes ne doivent pas être commentées :+On modifie le fichier ''​docker-compose.yml''​ du //​repository//​ pour permettre de //builder// la version libre de Mattermost. Normalement,​ les lignes suivantes ne doivent pas être commentées :
 <code yaml> <code yaml>
 [...] [...]
Ligne 89: Ligne 217:
 === Build et tag des images === === Build et tag des images ===
  
-Le //build// peut durer un certain temps, une fois terminé on obtient trois images ​''​mattermost_app''​''​mattermost_db'' ​et ''​mattermost_web''​. On peut les voir à l'aide de la commande ​''​docker images'' : +Le //build// peut durer un certain temps, une fois terminé on obtient trois images ​(visibles avec ''​docker images''​) : 
-<code bash> +  * ''​mattermost\_app''​ 
-kyane@laptop:​~ docker images +  * ''​mattermost\_db''​ 
-REPOSITORY ​                                     TAG                 IMAGE ID            CREATED ​            ​SIZE +  * ''​mattermost\_web''​ 
-mattermost_web ​                                 latest ​             bd616f47c38b ​       3 seconds ago       ​109MB + 
-mattermost_app ​                                 latest ​             e0bdbeb94060 ​       3 seconds ago       ​303MB +On ignore l'​image ''​mattermost\_web'',​ nous ne l'​utilisons pas pour Picasoft car nous avons notre propre reverse-proxy (Traefik). On peut la supprimer avec ''​docker rmi mattermost_web''​.
-mattermost_db ​                                  ​latest ​             724ed4c6030a ​       3 seconds ago       451MB +
-</​code>​ +
-On ignore l'​image ''​mattermost_web'',​ nous ne l'​utilisons pas pour Picasoft car nous avons notre propre reverse-proxy (Traefik). On peut la supprimer avec ''​docker rmi mattermost_web''​.+
  
 ==== Déploiement ==== ==== Déploiement ====
-=== Préparation === 
-Pour déployer notre nouvelle version, on se rend maintenant sur la machine de production qui fait tourner Mattermost (normalement,​ ''​pica01''​). Bien entendu, on ne fait pas une mise à jour n'​importe comment, il faut s'​assurer :  
-  * que l'on a une backup récente de la base de données. C'est normalement le cas puisqu'​elles sont automatiques;​ 
-  * que Mattermost n'est pas trop utilisé. On ne fait pas un déploiement à 19H, la coupure va déranger tout le monde; 
-  * que les autres bénévoles sont au courant de la mise à jour. Même si la coupure de service est courte, un⋅e sysadmin qui voit que le service est tombé va s'​affoler pour rien :) 
  
-Bref on ne se lance que lorsque ​l'on est prêt. Pour commencer il faut modifier les images Docker qui sont utilisées par les conteneurs de Mattermost ​et de sa base de données. ​Cela se passe dans le fichier ''/​DATA/​docker/​docker-compose.yml''​ de la machine, dans les services ​''​mattermost''​ et ''​mattermost-db''​. Il suffit simplement de changer le numéro de version de l'image.+On va simplement couper le conteneur de l'application ​Mattermost, puis de sa base de données. ​On relance ensuite directement ​les deux services ​(dans l'ordre inverse).
  
-**Attention !! On utilise uniquement les images ayant pour //tag// le numéro d'une versionOn utilise JAMAIS ''​latest''​ pour éviter ​de tout casseret en plus c'est plus clair comme cela.**+On peut vérifier rapidement que tout s'est bien passé en se connectant sur le [[https://team.picasoft.net|Mattermost ​de Picasoft]]que ça tourne bien. Dans le menu, l'onglet "À Propos"​ permet de vérifier la version du serveur
  
-Lorsque c'est prêt, on //​pull// ​les nouvelles images Docker sur la machineOn n'est pas obligé de le faire manuellement,​ ''​docker-compose''​ se chargera de le faire au redémarrage des conteneurs. Cependant ​cela permet de réduire le downtimepuisque l'​image sera déjà en local au moment du redémarrage (on économise le temps de //pull//).+En cas de soucis, on relance ​les dernières versions fonctionnellesSi cela crash toujours, on fait un rollback de la base de données.
  
-=== Bascule en production === +Si tout va bien, on fait un petit message ​sur le channel Général pour annoncer que la MAJ s'est bien passée, en ajoutant un petit lien vers le [[https://​docs.mattermost.com/​administration/​changelog.html|changelog ​de Mattermost]]
-Lorsque ​tout est bien prêt et que l'on a prévu les collègues, on peut enfin opérer à la bascule ​sur la nouvelle versionEn pratique, on va simplement couper les conteneurs ​de l'​application ​Mattermost, puis de sa base de données. On relance ensuite directement les deux services (dans l'​ordre inverse), qui vont donc démarrer sur les nouvelles images.+
  
-Il est important ​de stopper les conteneurs avant de les effacer, pour éteindre correctement ​la base de données et minimiser le risque de corruption. L'​option ''​-t 60''​ indique un timeout de 60 secondes ([[https://​docs.docker.com/​compose/​reference/​stop/​|par défaut]] c'est 10 secondes).+==== Réindexation ​de la base de donnée ====
  
-Normalement tout s'​enchaine bien et les services repartent sur les nouvelles images. On peut vérifier rapidement en se connectant sur le [[https://​team.picasoft.net|Mattermost de Picasoft]], que ça tourne bien. Dans le menu, l'​onglet "À Propos"​ permet de vérifier la version du serveur. \\ 
-Il est **fortement recommandé** de regarder les //logs// des conteneurs (''​docker logs mattermost-app''​ et ''​docker logs mattermost-db''​) pour regarder si il n'y a pas de grosse erreur pouvant indiquer un dysfonctionnement. 
- 
-En cas de soucis, on remet les anciennes images dans le ''​docker-compose.yml''​ puis on relance la commande ci-dessus pour revenir en arrière. Si cela crash toujours, on fait un rollback de la base de données. \\ 
-Si tout va bien, on fait un petit message sur le channel Général pour annoncer que la MAJ s'est bien passée, en ajoutant un petit lien vers le [[https://​docs.mattermost.com/​administration/​changelog.html|changelog de Mattermost]]. On pense aussi à nettoyer les anciennes images Docker de la machine ''​pica01''​. 
- 
-==== Réindexation de la base de donnée ==== 
 Il est arrivé qu'​après une procédure d'​upgrade "​violente",​ la base de données Postgresql ne conserve plus ses propriétés intrinsèques. La base se retrouve corrompue et les contraintes d'​intégrités ne sont plus respectées. Cela donne lieu à des problèmes de connexions au sein de Mattermost. ​ Il est arrivé qu'​après une procédure d'​upgrade "​violente",​ la base de données Postgresql ne conserve plus ses propriétés intrinsèques. La base se retrouve corrompue et les contraintes d'​intégrités ne sont plus respectées. Cela donne lieu à des problèmes de connexions au sein de Mattermost. ​
  
Ligne 131: Ligne 243:
  
 <code bash> <code bash>
-root@pica01:​~#​ docker ​exec -it mattermost-db bash+root@pica01:​~#​ docker-compose exec  ​mattermost-db bash
 bash-4.3# psql -U postgres bash-4.3# psql -U postgres
 psql (9.4.15) psql (9.4.15)
Ligne 139: Ligne 251:
 mattermost=#​ reindex DATABASE mattermost; mattermost=#​ reindex DATABASE mattermost;
 NOTICE: ​ table "​pg_catalog.pg_class"​ was reindexed NOTICE: ​ table "​pg_catalog.pg_class"​ was reindexed
-NOTICE: ​ table "​pg_catalog.pg_statistic"​ was reindexed +[...]
-NOTICE: ​ table "​pg_catalog.pg_type"​ was reindexed +
-NOTICE: ​ table "​public.oauthaccessdata"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_authid"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_attribute"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_proc"​ was reindexed +
-NOTICE: ​ table "​public.audits"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_user_mapping"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_attrdef"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_constraint"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_index"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_operator"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_opfamily"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_opclass"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_am"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_amop"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_amproc"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_language"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_database"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_aggregate"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_rewrite"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_trigger"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_event_trigger"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_description"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_cast"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_enum"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_namespace"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_conversion"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_depend"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_db_role_setting"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_tablespace"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_pltemplate"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_auth_members"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_shdepend"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_shdescription"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_ts_config"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_ts_config_map"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_ts_dict"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_ts_parser"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_ts_template"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_extension"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_foreign_data_wrapper"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_foreign_server"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_foreign_table"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_default_acl"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_seclabel"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_shseclabel"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_collation"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_range"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_largeobject"​ was reindexed +
-NOTICE: ​ table "​public.channelmembers"​ was reindexed +
-NOTICE: ​ table "​information_schema.sql_implementation_info"​ was reindexed +
-NOTICE: ​ table "​information_schema.sql_languages"​ was reindexed +
-NOTICE: ​ table "​information_schema.sql_packages"​ was reindexed +
-NOTICE: ​ table "​information_schema.sql_sizing"​ was reindexed +
-NOTICE: ​ table "​information_schema.sql_sizing_profiles"​ was reindexed +
-NOTICE: ​ table "​public.channels"​ was reindexed +
-NOTICE: ​ table "​public.commands"​ was reindexed +
-NOTICE: ​ table "​public.compliances"​ was reindexed +
-NOTICE: ​ table "​public.emoji"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_largeobject_metadata"​ was reindexed +
-NOTICE: ​ table "​public.fileinfo"​ was reindexed +
-NOTICE: ​ table "​pg_catalog.pg_inherits"​ was reindexed +
-NOTICE: ​ table "​public.licenses"​ was reindexed +
-NOTICE: ​ table "​public.oauthapps"​ was reindexed +
-NOTICE: ​ table "​information_schema.sql_features"​ was reindexed +
-NOTICE: ​ table "​information_schema.sql_parts"​ was reindexed +
-NOTICE: ​ table "​public.oauthauthdata"​ was reindexed +
-NOTICE: ​ table "​public.outgoingwebhooks"​ was reindexed +
-NOTICE: ​ table "​public.posts"​ was reindexed +
-NOTICE: ​ table "​public.preferences"​ was reindexed +
-NOTICE: ​ table "​public.reactions"​ was reindexed +
-NOTICE: ​ table "​public.sessions"​ was reindexed +
-NOTICE: ​ table "​public.status"​ was reindexed +
-NOTICE: ​ table "​public.systems"​ was reindexed +
-NOTICE: ​ table "​public.teammembers"​ was reindexed +
-NOTICE: ​ table "​public.teams"​ was reindexed +
-NOTICE: ​ table "​public.tokens"​ was reindexed +
-NOTICE: ​ table "​public.users"​ was reindexed +
-NOTICE: ​ table "​public.clusterdiscovery"​ was reindexed +
-NOTICE: ​ table "​public.jobs"​ was reindexed +
-NOTICE: ​ table "​public.commandwebhooks"​ was reindexed +
-NOTICE: ​ table "​public.useraccesstokens"​ was reindexed +
-NOTICE: ​ table "​public.channelmemberhistory"​ was reindexed +
-NOTICE: ​ table "​public.pluginkeyvaluestore"​ was reindexed +
-NOTICE: ​ table "​public.incomingwebhooks"​ was reindexed+
 REINDEX REINDEX
 mattermost=#​ <ctrl d> mattermost=#​ <ctrl d>
  • services/services_upgrade.1554893473.txt.gz
  • Dernière modification: 2019/05/13 15:40
  • (modification externe)