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:tech_team:etherpad [2021/12/19 19:39] qduchemitechnique:tech_team:etherpad [2021/12/19 22:34] (Version actuelle) qduchemi
Ligne 16: Ligne 16:
 </bootnote> </bootnote>
  
-Derrière un service il y a un logiciel qui fonctionne grâce à du code fait par des humains, les humains et donc les logiciels ne sont pas parfaits ou sont perfectibles. On peut choisir d’ajouter des fonctionnalités, changer la manière de faire, optimiser, corriger des comportements jugés anormaux ou encore corriger des failles de sécurité plus ou moins importantes. En ce sens, même si cette tâche est rébarbative, il est important de mettre à jour les services.+Derrière un service il y a un logiciel qui fonctionne grâce à du code fait par des humains, les humains et donc les logiciels ne sont pas parfaits. On peut choisir d’ajouter des fonctionnalités, changer la manière de faire, optimiser, corriger des comportements jugés anormaux ou encore corriger des failles de sécurité plus ou moins importantes. En ce sens, même si cette tâche est rébarbative, il est important de mettre à jour les services.
  
 <bootnote question> <bootnote question>
Ligne 33: Ligne 33:
  
 <bootnote web> <bootnote web>
-Tous les services Picasoft sont gérés sur Gitlab, une **forge** Git, à cette adresse : https://gitlab.utc.fr/picasoft/projets/services+Tous les services Picasoft sont gérés sur **Gitlab** à cette adresse : https://gitlab.utc.fr/picasoft/projets/services
  
 Vas y faire un tour ! :-D Vas y faire un tour ! :-D
Ligne 42: Ligne 42:
 <bootnote> <bootnote>
  
-Gitlab est une **forge** Git : un endroit où on stocke des documents, conçu pour la collaboration. L'idée est de donner des outils aux adminsys/développeur·ses/écrivain·es de collaborer en se basant sur Git.+Gitlab est une **forge** Git : un endroit où on stocke des documents, conçu pour la collaboration. L'idée est de donner des outils aux adminsys/développeur·ses/écrivain·es/etc pour collaborer en se basant sur Git.
  
 * Git permet de travailler à plusieurs sur des fichiers et d'en maintenir un **historique des modifications**. * Git permet de travailler à plusieurs sur des fichiers et d'en maintenir un **historique des modifications**.
Ligne 55: Ligne 55:
 Comment tu peux le constater, il y a un « dossier » par service : Comment tu peux le constater, il y a un « dossier » par service :
  
-* Chaque dossier est appelé **dépôt** : c'est une entité indépendante qui se manipule comme un tout+* Chaque dossier est appelé **dépôt**. Chaque dépôt est complètement **indépendant** des autres.
 * Chaque dépôt contient les fichiers nécessaires pour lancer le service en question. * Chaque dépôt contient les fichiers nécessaires pour lancer le service en question.
-* Les dépôts peuvent être **clonés** sur les machines. Cloné, ça veut dire copié en gardant en lien vers le serveur.+* Les dépôts peuvent être **clonés** sur les machines. Cloné, ça veut dire copié en gardant un lien vers Gitlab.
  
 Alors concrètement, pour Traefik qui tourne sur toutes les machines, ça ressemble à quoi ? Alors concrètement, pour Traefik qui tourne sur toutes les machines, ça ressemble à quoi ?
Ligne 68: Ligne 68:
  
 <bootnote important> <bootnote important>
-Git permet de **réutiliser le travail**. D'une part, le fait de centraliser la configuration sur un dépôt public permet à des gens extérieurs à Picasoft de s'inspirer (plutôt que d'avoir les fichiers de configuration uniquement sur les machines), et d'autre part de **partager** les fichiers de configuration entre les machines plutôt que de **dupliquer** plusieurs fois le travail.</bootnote>+Git permet de **réutiliser le travail**. D'une part, le fait de centraliser la configuration sur un dépôt public permet à des gens extérieurs à Picasoft de s'inspirer (plutôt que d'avoir les fichiers de configuration uniquement sur les machines), et d'autre part de **partager** les fichiers de configuration entre les machines plutôt que de **refaire** plusieurs fois le travail.</bootnote>
  
 Un exemple ? Un exemple ?
  
-Imagine que je mette à jour Traefik dans une nouvelle version sur `pica01`. Super, j'ai modifié les fichiers de configuration, je suis donc en **avance** par rapport aux fichiers qui se trouvent sur Gitlab et les autres machines.+Imagine que je mette à jour Traefik dans une nouvelle version sur `pica01`. Super, j'ai modifié des fichiers (au moins le fichier Compose, pour indiquer d'utiliser une nouvelle version de l'image), je suis donc en **avance** par rapport aux fichiers qui se trouvent sur Gitlab et les autres machines.
  
 {{ :technique:tech_team:git_clones_2.png |}} {{ :technique:tech_team:git_clones_2.png |}}
Ligne 90: Ligne 90:
 C'est un **conflit** : quelle version choisir au moment d'envoyer sur Gitlab ? Et bien Git est équipé pour résoudre ce genre de problèmes. Mais on en a déjà trop dit !  C'est un **conflit** : quelle version choisir au moment d'envoyer sur Gitlab ? Et bien Git est équipé pour résoudre ce genre de problèmes. Mais on en a déjà trop dit ! 
  
-Bon, dans la pratique on s'amuse pas à faire des mises à jour simultanées sur les machines de production. Si tu as vaguement compris l'intérêt de Git jusque ici, on va voir maintenant en pratique comment ça marche !+Si tu as vaguement compris l'intérêt de Git jusque ici, on va voir maintenant en pratique comment l'utiliser pour les mises à jour.
  
 ### C'est quoi les étapes pour mettre à jour Etherpad ? ### C'est quoi les étapes pour mettre à jour Etherpad ?
Ligne 96: Ligne 96:
 <bootnote web>Le dépôt Gitlab pour Etherpad est ici : https://gitlab.utc.fr/picasoft/projets/services/etherpad-yearly</bootnote> <bootnote web>Le dépôt Gitlab pour Etherpad est ici : https://gitlab.utc.fr/picasoft/projets/services/etherpad-yearly</bootnote>
  
-1. On va sur la machine de test.+1. On va sur la **machine de test**.
 2. On va dans `/DATA/docker/services` et on se synchronise avec le dépôt : si la copie locale n'existe pas, on **clone** le dépôt, sinon, on **tire** les modifications (s'il y en a). 2. On va dans `/DATA/docker/services` et on se synchronise avec le dépôt : si la copie locale n'existe pas, on **clone** le dépôt, sinon, on **tire** les modifications (s'il y en a).
 3. On fait nos modifications et on teste que ça marche bien. 3. On fait nos modifications et on teste que ça marche bien.
 4. On les **pousse** sur le dépôt Gitlab : « tout le monde » peut en profiter. 4. On les **pousse** sur le dépôt Gitlab : « tout le monde » peut en profiter.
-5. On va sur la machine de production. +5. On va sur la **machine de production**
-6. Toujours dans `/DATA/docker/services/<dossier etherpad>`, on **tire** les modifications.+6. Dans `/DATA/docker/services`, on **tire** les modifications que l'on vient de pousser.
 7. Et on lance le service! :-D 7. Et on lance le service! :-D
  
 <bootnote important> <bootnote important>
-La partie `3` dépend de chaque serviceet est expliquée dans le `README` du dépôt du service. Mais pour l'exemple, on va tout détailler ici.+La partie `3` dépend de chaque service et les opérations spécifiques sont détaillées dans la description Gitlab du service en questionIci, on explique tout pour Etherpad!
 </bootnote> </bootnote>
  
Ligne 139: Ligne 139:
 </bootnote> </bootnote>
  
-Et là, première commande Git pour être sûr qu'on a la dernière version (qui est sur Gitlab:+Et là, première commande Git pour être sûr qu'on a la dernière versionqui est sur Gitlab - on **tire** les modifications :
  
 ``` ```
Ligne 196: Ligne 196:
 Pour cela il faut modifier le tag de l’image (ce qui correspond au fait à un numéro de version dans notre cas) dans le fichier `docker-compose.yml`. C'est dans l'extrait qui suit : Pour cela il faut modifier le tag de l’image (ce qui correspond au fait à un numéro de version dans notre cas) dans le fichier `docker-compose.yml`. C'est dans l'extrait qui suit :
  
-``` +```yaml 
-  app: +app: 
-    image: registry.picasoft.net/pica-etherpad:1.8.14 +  image: registry.picasoft.net/pica-etherpad:1.8.14 
-    build: . +  build: . 
-    container_name: etherpad_app+  container_name: etherpad_app
 ``` ```
  
Ligne 242: Ligne 242:
 $ docker login registry.picasoft.net $ docker login registry.picasoft.net
 ``` ```
 +
 +Utilise les mêmes identifiants sur sur les machines.
 </bootnote> </bootnote>
  
Ligne 273: Ligne 275:
 </bootnote> </bootnote>
  
-Pour finir, tu peux pousser ces modifications sur Gitlab :+Pour finir, tu peux pousser ces modifications sur Gitlab (les identifiants qu'on te demande sont ceux de l'UTC !) :
  
 ``` ```
Ligne 295: Ligne 297:
 L'expérience. ^_^ L'expérience. ^_^
  
-Mais tu peux aussi regarder sur les [graphes des services](https://wiki.picasoft.net/doku.php?id=technique:graph_services)...+Mais tu peux aussi regarder sur les [[technique:graph_services|graphes des services]]...
  
 #### On tire les modifications #### On tire les modifications
  • technique/tech_team/etherpad.1639939185.txt.gz
  • de qduchemi