Transfert du site de production sur OVH

Lors d'une précédente panne du réseau INRAE, le site a été transféré manuellement vers le serveur OVH.

Il faut maintenant adapter le processus de déploiement automatique lors d'une release pour publier vers OVH à la place du serveur Inrae.

changed milestone to %Version 4.15.0

added To Do bug pieuvre mécanique labels

assigned to @francois.grand

By Dorchies David on 2022-03-15T17:24:31 (imported from GitLab)

Utiliser les variables d'environnement suivantes pour la connexion au serveur: OVH_SFTP, OVH_LOGIN, OVH_PASS

Voir https://gitlab.irstea.fr/in-wop/airGRiwrm/-/blob/dev/.gitlab-ci.yml#L55 pour un exemple de rsync qui fonctionne sur OVH (si sshpass est dans l'image docker le sudo apt-get install sshpass n'est pas nécessaire).

By Dorchies David on 2022-03-16T16:10:17 (imported from GitLab)

gitlab-ci :

• deploy : copie dist sur push/tag/web vers aubes/cassiopee
• deploy-stable :
  • copie dist sur tag "stable" vers aubes/cassiopee-production
  • modif index.html
• releases-nightly :
  • génère sur schedule les artéfacts d'install
  • copie sur schedule les artéfacts d'install vers aubes
• releases-version : appel sur tag xx.yy.zz de release-version.sh
  • dir=aubes:/var/www/cassiopee-production/cassiopee-releases
  • fichier release=aubes:/var/www/cassiopee-production/cassiopee-releases/releases.json

release-version.sh :

• MAJ de serveur/releases.json
• génère les artéfacts d'install
• copie les artéfacts d'install vers serveur
• MAJ des liens "xx-latest.[exe|deb|...]" sur serveur

Propositions :

• en modifiant release-version.sh pour ne pas mettre à jour releases.json si la version est "nightly", on peut l'utiliser pour release-nightly
• créer un script deploy-version.sh avec comme paramètres le serveur destination et la version (modif d'index.html seulement si version==stable)
  • l'utiliser pour deploy (serveur=aubes, version=commit-ref_name)
  • l'utiliser 2 fois pour deploy-stable (aubes, OVH, version=stable)

By Grand Francois on 2022-04-15T08:40:05 (imported from GitLab)

Si je résume les opérations qui sont effectuées par /scripts/deploy-new-stable-version.sh x.y.z et ses conséquences:

D'abord pour jalhyd:

• Dans ../jalhyd checkout master
• MAJ de la version de package.json de jalhyd à "x.y.z" et commit de la modif
• git tag x.y.z. PUIS git tag stable

Ensuite pour nghyd:

• Dans ../nghyd checkout master
• npm install et vérification qu'aucune MAJ de dépendance n'est intervenu
• MAJ de la version de package.json de jalhyd à "x.y.z" et commit de la modif
• git tag stable PUIS git tag x.y.z.

Du côté de gitlab-ci:

Les deux git tag sur nghyd lance les jobs suivant:

• jalhyd
• install
• test
• build
• deploy: déploiement sur aubes dans $DEPLOY_URL/$CI_COMMIT_REF_NAME (cassiopee/tag)
• deploy-stable (seulement sur git tag stable): déploiement sur $DEPLOY_STABLE_URL (cassiopee.g-eau.fr)
• releases-version (seulement sur git tag x.y.z.): déploiement des exe sur $DEPLOY_STABLE_URL/cassiopee-releases (cassiopee.g-eau.fr/cassiopee-releases)

En complément le scheduled pipeline lance le job releases-nightly qui déploie aussi les exe nightly sur $DEPLOY_STABLE_URL/cassiopee-releases (cassiopee.g-eau.fr/cassiopee-releases).

By Dorchies David on 2022-04-15T09:08:01 (imported from GitLab)

Propositions :

• en modifiant release-version.sh pour ne pas mettre à jour releases.json si la version est "nightly", on peut l'utiliser pour release-nightly

Oui en appelant: release-version.sh nightly et en ne mettant pas à jour releases.json pour $1 == nightly

• créer un script deploy-version.sh avec comme paramètres le serveur destination et la version (modif d'index.html seulement si version==stable)
• l'utiliser pour deploy (serveur=aubes, version=commit-ref_name)

OK

• l'utiliser 2 fois pour deploy-stable (aubes, OVH, version=stable)

Non, ce n'est pas nécessaire. Le déploiement sur aubes/cassiopee/stable a déjà été effectué par le job deploy.

By Dorchies David on 2022-04-15T09:26:13 (imported from GitLab)

Les variables d'environnement suivantes sont disponibles: $OVH_LOGIN, $OVH_PASS, $OVH_HOST, et $OVH_PATH

Le serveur de production http://cassiopee.g-eau.fr est hébergé sur OVH.

Le serveur de développement http://hydraulique.g-eau.fr/cassiopee est herbergé sur Aubes.

J'ai créé un dossier cassiopee-dev et un sous domaine http://cassiopee-dev.g-eau.fr sur OVH pour faire les tests.

By Dorchies David on 2022-04-15T10:13:10 (imported from GitLab)

La ligne de commande pour copier le site de prod devrait être:

sshpass -p "${OVH_PASS}" rsync -a -e "ssh -o StrictHostKeyChecking=no" dist/ ${OVH_LOGIN}@${OVH_HOST}:/home/${OVH_LOGIN}/${OVH_PATH}/

By Dorchies David on 2022-04-15T09:53:16 (imported from GitLab)

created merge request !128 (merged) to address this issue

By Grand Francois on 2022-04-15T10:06:40 (imported from GitLab)

mentioned in merge request !128 (merged)

By Grand Francois on 2022-04-15T10:06:41 (imported from GitLab)

Les jobs sont actuellement nommés en fonction de la condition qui les déclenche et non en fonction de ce qu'ils font. Pour éviter la confusion, on peut renommer les jobs: deploy en deploy-dev et deploy-stable en deploy-prod

By Dorchies David on 2022-04-15T10:16:52 (imported from GitLab)

mentioned in commit f71050db

By Grand Francois on 2022-04-19T13:52:41 (imported from GitLab)

mentioned in commit 4dee5035

By Grand Francois on 2022-04-19T13:52:41 (imported from GitLab)

mentioned in commit 09f1f8fe

By Grand Francois on 2022-04-19T13:52:41 (imported from GitLab)

mentioned in commit 48b5b2a9

By Grand Francois on 2022-04-19T13:52:41 (imported from GitLab)

mentioned in commit fc6d4f14

By Grand Francois on 2022-04-19T13:52:41 (imported from GitLab)

mentioned in commit 60cdd204

By Grand Francois on 2022-04-19T14:34:30 (imported from GitLab)

mentioned in commit 19e64e87

By Grand Francois on 2022-04-19T14:53:19 (imported from GitLab)

mentioned in commit 9c51acce

By Grand Francois on 2022-04-19T15:11:26 (imported from GitLab)

mentioned in commit 7852e00a

By Grand Francois on 2022-04-19T15:37:36 (imported from GitLab)

mentioned in commit e6a5a31e

By Grand Francois on 2022-04-19T17:04:38 (imported from GitLab)

mentioned in commit 7711f216

By Grand Francois on 2022-04-20T08:35:55 (imported from GitLab)

mentioned in commit ef3a3ee7

By Grand Francois on 2022-04-20T09:07:15 (imported from GitLab)

mentioned in commit 8a41d14c

By Grand Francois on 2022-04-20T09:36:29 (imported from GitLab)

mentioned in commit f3c1b508

By Grand Francois on 2022-04-20T10:14:50 (imported from GitLab)

mentioned in commit 12d62bb9

By Grand Francois on 2022-04-20T10:35:10 (imported from GitLab)

mentioned in commit 9c1f11d1

By Grand Francois on 2022-04-20T12:07:24 (imported from GitLab)

mentioned in commit c7e4bc5b

By Grand Francois on 2022-04-21T10:09:19 (imported from GitLab)

mentioned in commit b8992d46

By Grand Francois on 2022-04-21T10:09:19 (imported from GitLab)

mentioned in commit b0f44338

By Grand Francois on 2022-04-21T10:09:19 (imported from GitLab)

mentioned in commit de8af88c

By Grand Francois on 2022-04-21T10:09:19 (imported from GitLab)

mentioned in commit 7978fd22

By Grand Francois on 2022-04-21T10:09:19 (imported from GitLab)

mentioned in commit 04444556

By Grand Francois on 2022-04-22T16:38:31 (imported from GitLab)

closed

@francois.grand le job de release des exécutables pour la version plante à :

$ ./scripts/release-version.sh $CI_COMMIT_REF_NAME $PROD_LOGIN $PROD_HOST $RELEASES_PATH
args 4.15.0 /cassiopee-releases
usage: ./scripts/release-version.sh <X.Y.Z|nightly> <login> <server> <releases dir>

Le nombre d'argument à l'appel du script est bon, le problème vient du fait que le job est exécuté dans le pipeline du tag "stable".

Je suppose que si on déplace le job dans le tag de version x.y.z. cela résoudra le problème.

By Dorchies David on 2022-05-05T08:16:04 (imported from GitLab)

Ah, ben non, je dis une connerie, c'est bon le pipeline "x.y.z" qui lance ce job.

By Dorchies David on 2022-05-05T08:16:04 (imported from GitLab)

Ça y est je l'ai!

La ligne args 4.15.0 /cassiopee-releases indique que les variables $PROD_LOGIN $PROD_HOST sont vides. C'est parce qu'elles sont protégées et que le tag n'est pas "protected".

https://docs.gitlab.com/ee/user/project/protected_tags.html

By Dorchies David on 2022-05-05T08:21:50 (imported from GitLab)

J'ai eu cette erreur pour la release:

remote: GitLab: Protected tags cannot be updated.
To gitlab-ssh.irstea.fr:cassiopee/nghyd.git
 ! [remote rejected]   4.15.0 -> 4.15.0 (pre-receive hook declined)
 ! [remote rejected]   stable -> stable (pre-receive hook declined)
error: failed to push some refs to 'git@gitlab-ssh.irstea.fr:cassiopee/nghyd.git'

Comme les variables d'environnement sensibles qui concernent la publication sur OVH sont "protected", les tags doivent aussi être "protected" pour que les variables soient accessibles dans le job.

La définition des "protected" tags se fait via un wildcard et le seul moyen de protéger les tags "x.y.z" est d'utiliser le wildcard "*" soit: tous les tags.

Les "protected" tags ne peuvent être ni supprimés, modifiés (on comprend l'esprit de "protected"), or cela pose deux problèmes:

• Quid de la situation actuelle où je dois republier le tag 4.15.0 ?
• Mais surtout quid de la mise à jour du tag "stable" qui se retrouve "protected" à cause d'un wildcard insuffisamment paramétrable ?

La seule solution que j'ai trouvé est de supprimer la protection des variables d'environnement et de ne pas protéger les tags.

By Dorchies David on 2022-05-05T12:28:19 (imported from GitLab)