Runtime to run provisionning scripts.
2.0K
Les premières versions de PC (jusqu'à v1.2) fonctionnaient à partir de fichiers de données statiques, précalculés. La version 1.3 a introduit un backend GeoServer, pour servir les données spatiales (sous la forme de rasters NetCDF) et un backend Python pour couvrir le reste des besoins (données temporelles, conversion en geotiff, etc).
La version 2 ajoute le support pour plusieurs jeux de données et bien d'autres améliorations.
On clone ce repo à côté de birdhouse-deploy.
On crée le fichier birdhouse-deploy/birdhouse/env.local en suivant les instructions normales de PAVICS, mais en ajoutant aussi:
export EXTRA_CONF_DIRS="/path/absolute/to/portraits_climatiques/pavics-config"
Dans env.local, la variable $DATA_PERSIST_ROOT pointe vers le dossier où toutes les données de PAVICS se retrouvent. Assumons ici que celui-ci correspond à /data.
Dans env.local, ajouter aussi export PC_FRONTEND_HOST='portraits-URL.ouranos.ca' avec une URL qui servira à tester le frontend des portraits. Assurez-vous de commiter vos changements, ou l'auto-deploiement du site staging ne fonctionnera pas!
Si nécessaire on crée /data/pc et /data/datasets/ouranos/. Le dossier netCDF tel que créé par 2_statistics.py est copié vers /data/datasets/ouranos/portraits-clim. Le script 3_gis.py crée les dossiers geotiffs et overlays, qui sont copiés vers /data/pc/geotiffs et /data/pc/overlays. Finalement, le script 4_zip.py crée le dossier zipped qui est copié vers /data/pc/zipped.
On part PAVICS avec ./pavics-compose.sh up -d.
À partir d'ici, les images docker des backends et frontend sont celles poussées sur dockerhub, voir les instructions plus bas.
Si on veut travailler en DEV sans avoir à pousser les images, voir la prochaine section.
On provisionne le geoserver en roulant:
../../portraits-climatiques/pavics-config/provision-geoserver
Pour accéder au frontend, il faut que l'URL ajoutée comme $PC_FRONTEND_HOST soit valide.
La manière la plus propre de faire est expliquée ici.
Si la machine locale est en Linux, on peut aussi tricher en éditant le /etc/hosts pour y faire pointer cette url vers l'IP de la machine de test.
Sur le navigateur local, il faudra probablement ajouter une exception pour le certificat SSL erroné.
Les commandes précédentes font un déploiement qui conserve la configuration docker du geoserver et ne fait qu'ajouter les nouvelles couches. Une mise à jour en profondeur de cette partie se fait ainsi:
docker stop pc-geoserver pc-postgis pc-api
# Remove containers and their data
docker rm pc-geoserver pc-postgis
docker volume rm pc-geoserver-data pc-postgis-data
# On enlève les anciennes données et on remplace par les nouvelles
# Pour aller plus vite, on fait le rsync ailleurs sur la machne avant d'arrêter les images et un mv rendu ici
rm -r /data/pc/geotiffs/*
rm -r /data/pc/overlays/*
rm -r /data/pc/zipped/*
docker exec -it thredds rm -r /pavics-data/ouranos/portraits-clim
DATADIR=???
mv $DATADIR/geotiffs/* /data/pc/geotiffs/
mv $DATADIR/overlays/* /data/pc/overlays/
mv $DATADIR/zipped/* /data/pc/zipped/
mv $DATADIR/netcdf /data/datasets/ouranos/portraits-clim
# Redeploy, mais pas pc-frontend qui roule encore
cd PROJECTS/birdhouse-deploy/birdhouse
./pavics-compose.sh up -d --no-recreate && sleep 60s
# il faut parfois attendre avant de provsionner, le temps que geoserver démarre
../../portraits_climatiques/pavics-config/provision-geoserver
# c'est fait : on redéploie pc-frontend
docker stop pc-frontend
docker rm pc-frontend
./pavics-compose.sh up -d
cp .env.example .env
Mettre les valeurs souhaitées dans le fichier .env. C'est ici que l'on choisit où trouver les données netCDF et les styles, en plus des ports et url des backends.
docker compose --profile development up -d
On attend quelques secondes/minutes, le temps que GeoServer démarre. Ensuite, on provisionne :
docker compose run provision-geoserver
L'application devrait être ensuite être accessible!
Pour réinitialiser les volumes (ceci va effacer toute la configuration Geoserver et PostGIS):
docker compose --profile development down -v
Il y a 4 étapes de génération des données plus une étape bonus pour les découpages.
preparations/region_generation/*.ipynbTrois notebooks qui sont roulés dans l'environnement environment.yml, le plus souvent d'une manière manuelle plutôt qu'automatisées.
Découpages.ipynb : À partir des découpages officiels du gouvernement provincial (à télécharger) et de la forme du Québec data/regions/region_qc.zip, génère les découpages (admin, mrc, coteurb, terreconv). Les territoires autochtones sources sont pour le moment dans un shapefile conservé ici. Le notebook sort les shapefiles non-compressés dans sont dossier de travail. La compression et à la mise à jour dans data/regions est laissée au lecteur.simplify.ipynb : Lit les découpages et génère deux simplifications de ceux-ci (region_{coll}_mid et region_{coll}_simple) pour les besoins du client. Ici aussi, la compression et mise à jour est laissée à la lectrice.Places.ipynb : À partir des statistiques municipales du recensement (2021 pour le moment) et d'un appel à OpenStreetMap, génère une liste de villes et villages à afficher sur la carte de Portraits.Après avoir roulé les notebooks et avant de commiter, il convient de remettre les chemins génériques pour les données téléchargées et de vider les sorties des cellules.
Les collections de régions se retrouvent dans data/regions/ et contiennent au minimum les trois colonnes suivantes:
id : un entier plus grand que 0, l'index de la région dans la collection. 0 est réservé pour la province entière.name : le nom de la région.rss : l'ID (un entier) de la région socio-sanitaire à associer à la région pour les vagues de froid et de chaleur.Finalement, le fichier data/regions/frontieres.zip est simplement une copie renommée et compressée des fichiers munic_l.* issus des découpages officiels du gouvernement provincial.
preparation/1_indicators.pySe fait normalement sur Narval, lancé avec slurm_indicators.sh. Utilise un environnement xscen à jour.
À partir des données quotidiennes d'ESPO ou de reconstructions, calcule les indicateurs qui sont définis dans config/indicators.
Les indicateurs de verglas ne sont pas calculés ici. Pour MRCC5-CMIP5, le calcul était manuel. Pour MRCC5-CMIP6, le calcul fait partie de diagnostics post-simulation que gère SAC.
preparation/2_statistics.pySe fait normalement sur Doris, lancé en au moins deux appels. Utilise l'environnement environment.yml.
À partir des indicateurs calculés en 1 (ou ailleurs), calcule les données que montre Portraits, c'est à dire les statistiques d'ensemble des moyennes temporelles (spatial), régionales (temporal) et ou les deux (summary).
Le script se roule pour une seule source à la fois. Ainsi on fera au minimum:
python 2_statistics.py -c 2_statistics_config.yml --source espog <chemin de PortraitsClimatiquesv2.json> <dossier de sortie>
python 2_statistics.py -c 2_statistics_config.yml --source pins <chemin de PortraitsClimatiquesv2.json> <dossier de sortie>
python 2_statistics.py -c 2_statistics_config.yml --source verglas <chemin de PortraitsClimatiquesv2.json> <dossier de sortie>
Pour accélérer, le script doall.sh réunit les étapes 2 à 4, voir plus bas.
La sortie est décrite dans la FAQ. Ça ressemble à :
netcdf/spatial/{ttype}_{vtype}/{source}/{indicator}.nc : Données spatiale.netcdf/temporal/horiz_abs/{source}/{regioncoll}/{indicator}.nc : Données temporelles.netcdf/summary/{ttype}_{vtype}/{source}/{regioncoll}/{indicator}.nc : Données sommaires.weights/masks_{regioncoll}_{source}.nc : Masques régionaux, pour sélectioner les régions.weights/weights_{regioncoll}_{source}.nc : Poids ESMF pour les moyennes régionales.weights/weights_regrid_{source}.nc : Poids ESMF pour le changement de grille des données spatiales.weights/weights_creep_{source}.nc : Poids pour le "creep fill" des données spatiales.3_gis.pySe fait normalement sur Doris. Utilise l'environnement environment.yml.
Peut faire 4 choses:
-o tiff), qui iront dans geotiffs/{ttype}_{vtype}/{source}_{indicator}/{source}_{indicator}_{season}_{scenario}_{percentile}_{start}-{end}.tiff-o color), qui iront dans geotiffs/colors.csv-o robust), qui iront dans overlays/{ttype}_cons/{source}_{indicator}/{source}_{indicator}_{season}_{scenario}_consensus_{start}-{end}.shp-o cons), qui iront dans overlays/{ttype}_cons/{source}_{indicator}/{source}_{indicator}_{season}_{scenario}_consensus90_{start}-{end}.shpOn peut le lancer pour faire toutes les étapes de prod sur toutes les données générées en 2 avec:
python 3_gis.py -N 12 <dossier de sortie>
Ici -N 12 veut dire qu'on traite 12 fichiers sources à la fois. Si l'option est absente, toute est fait dans le même compute, ce qui génère beaucoup de tâche et demande (par expérience) plus de mémoire que de découper en morceau. Le script est quand même assez efficace, il roule au max de CPU la plupart du temps. Reste que c'est long pareil.
Ce script est inclus dans ./doall.sh, voir plus bas.
Se fait sur doris aussi. Utilise n'importe quel environnement python.
Le script compresse les geotiffs en une archive par dossier, donc par ttype/vtype/source/indicator. Les archives seront accessibles par une simple page html directement sur le site des Portraits.
python 4_zip.py <dossier de sortie>
Ce script est inclus dans ./doall.sh, voir plus bas.
Le script ./doall.sh appelle les 3 étapes de pré-production et permet de paralléliser sur les différents indicateurs pour accélérer le processus. On lance 6 indicateurs à la fois.
./doall.sh <dossier de sortie>
Le site actuel utilise docker pour le frontend, il n'est donc pas nécessaire de faire le build npm manuellement. Cette section décrit la procédure quand même, au cas où.
Les URLs vers les backends GS et Python doivent être configurés par les variables d'environnement:
export VITE_GEOSERVER_URL="<url_vers_geoserver>"
export VITE_EXTRA_URL="<url_vers_python_extra_support>"
Puis le site react est "compilé" et optimisé avec :
cd frontend/
npm run build
mv build html
zip -r pc-dev-build.zip html/
deploy (depuis v2.1)Sur la machine de prod, nous ne déployons pas la branche master mais la branche deploy pour pouvoir controller le déploiement en prod et pouvoir faire des hotfix sur le prod sans amener tous les nouveaux commits de master.
Donc quand master est prêt, merger vers deploy va le déployer en prod.
Dans le cas d'un hotfix, il va falloir s'en souvenir de le merger vers deploy pour fixer le prod mais aussi une 2e fois vers master pour que le fix ne se perd pas la prochaine fois que master sera mergé vers deploy.
Les machines staging devrait déployer la branche master pour attraper les erreurs avant que ça aille en prod.
L'image fait partie de PAVICS. Théoriquement, un git pull est suffisant, l'auto(re)déploiement est activé pour PC.
Si une mise à jour des données est nécessaire, c'est la même procédure qu'expliqué tout en haut.
Le script pavics-config/log_cleaner.sh permet de faire la rotation des logs de portraits climatiques dans le conteneur proxy puis envoie le log au courriel du webmestre de l'instance PAVICS, ou à d'autres courriels configurés dans la variable d'environnement PC_LOG_CLEANER_STATS_RECIPIENT.
Si PC_LOG_CLEANER_NO_ROTATE_LOG a une valeur, le log ne sera pas rotaté ni supprimé de proxy. Si PC_LOG_CLEANER_KEEP_PARSED_LOG a une valeur, le log extrait sera conservé sur PAVICS.
Le script scripts/log_parser.py peut ensuite analyser le journal brut, en faire un CSV plus digeste puis dessiner plusieurs figures de statistiques.
ATTENTION: La commande mailx est utilisée par le script pour envoyé un courriel. Il est attendu que ce soit la version "heirloom", tel que fournie par le paquet "mailx" de Rocky Linux. D'autres distributions pourraient fournir des versions incompatibles. Sur Ubuntu, par exemple, il convient d'utiliser s-nail en faisant un alias mailx=s-nail dans le .bashrc ou ailleurs.
La dernière étape du développement d'une PR est de mettre à jour les images docker puis de fusionner les changements vers la branche voulue. Pour faire un release vers "portraits-staging.ouranos.ca", faites vos pull-request vers la branche master . Si vous voulez que le release soit directement sur "portraits.ouranos.ca", la branche cible doit être deploy. Voir plus bas pour la manière de mettre à jour les tags.
Assurez-vous que la nouvelle image est disponible sur le dockerhub de pavics avant de faire votre merge, sinon l'autodeploy de Pavics pourrait tenter de créer un nouveau build sans que l'image n'existe.
3 images Docker est buildé à partir de ce repo:
https://hub.docker.com/r/pavics/portrait-clim-extra qui vient du fichier backend/Dockerfile
backend/docker-portrait-clim-extra-221103 pour générer automatiquement l'image
Docker pavics/portrait-clim-extra:221103 sur DockerHub.https://hub.docker.com/r/pavics/portrait-clim-scripts qui vient du fichier backend/scripts/Dockerfile
script/Dockerfiledocker-portrait-clim-scripts-221103 pour générer automatiquement l'image
Docker pavics/portrait-clim-scripts:221103 sur DockerHub.https://hub.docker.com/r/pavics/portrait-clim-frontend qui vient du fichier frontend/Dockerfile
frontend/v1.3-RC2. pour générer automatiquement l'image
Docker pavics/portrait-clim-frontend:1.3-RC2 sur DockerHub.Le tag de frontend est aussi la version affichée de Portraits Climatiques. Il peut être automatiquement mis à jour avec:
bump-my-version bump -v pre
Ceci met à jour le dernier chiffre de la version, i.e. le Z dans : X.Y-RCZ. On peut mettre à jour le Y avec "minor" et le X avec "major". Le tag est créé et tout ça est committé.
L'utiliaire bump-my-version est installé dans l'environnement python de préparation des données, environment.yml. L'argument --dry-run peut être bien utile si on a des doûtes.
Lorsqu'on met à jour le tag d'une version "release", on lance plutôt:
bump-my-version bump --new-version X.Y.Z
Si la branche deploy contient des changements qui sont absents du master, cette commande devrait être faite dans la PR qui fusionne master vers deploy.
Il est possible d'injecter des liens vers le backend "extra" avec la balise :extra[text]{to=/chemin/relatif target="..."} dans les snippets et markdowns. La balise est transformée en un <a> d'HTML avec la bonne URL. Cette directive ne peut pas être utilisée dans les définitions ou les notifications.
Le script utils/mugglify.sh permet de transformer tous les textes statique des Portraits en une collection de fichiers DOCX, dans le but de charger ceux-ci sur Office 365 et utiliser les options de suivi pour faire les rondes de révision. On l'appelle comme : mugglify.sh <REPO> <OUT FOLDER> [<HOST>] où REPO est le dossier racine de ce projet, OUT FOLDER est un dossie où mettre les docx. HOST est optionnel et donne l'url de la version courante et en ligne des Portraits. Les liens internes dans les textes seront remplacés par des liens vers cette instance. Par défaut "portraits.ouranos.ca" est utilisé.
Content type
Image
Digest
sha256:231ff4cb2…
Size
645.3 MB
Last updated
2 days ago
docker pull pavics/portrait-clim-scripts