Atelier 2 : CI/CD, stack entrepôt et mise en production

Dans cet atelier, vous branchez le pipeline GitHub Actions sur la VM, vous comprenez l’application d’entrepôt à trois conteneurs, et vous la livrez — en déploiement continu comme en releases versionnées.

Partie 3 sur 4 — Aperçu · Atelier 1 : Provisionner et configurer · Exploitation et dépannage

Phase 3 — Connecter les secrets CI/CD et la cible de déploiement

S’exécute depuis votre machine de contrôle avec gh.

L’entrepôt n’est pas déployé à la main. GitHub Actions (.github/workflows/deploy.yml) construit les images de conteneurs, les pousse vers GHCR, puis se connecte en SSH à la VM pour les récupérer et les redémarrer. Vous devez d’abord donner au pipeline sa cible et ses secrets.

Étape 3.1 — Variables de dépôt (cible de déploiement non secrète)

Elles indiquent au workflow où déployer. Elles remplacent des valeurs autrefois codées en dur.

gh variable set DEPLOY_HOST --body "__DEPLOY_HOST__"        # VM public IP / hostname
gh variable set DEPLOY_USER --body "__DEPLOY_USER__"        # VM SSH user for deploys
gh variable set DEPLOY_PORT --body "__DEPLOY_PORT__"        # SSH port
gh variable set DEPLOY_PATH --body "__DEPLOY_PATH__"        # repo checkout path on the VM
gh variable list                                          # verify

$ gh variable list
NAME          VALUE                UPDATED AT
DEPLOY_HOST   __DEPLOY_HOST__      just now
DEPLOY_USER   __DEPLOY_USER__      just now
DEPLOY_PORT   __DEPLOY_PORT__      just now
DEPLOY_PATH   __DEPLOY_PATH__      just now

Étape 3.2 — Le secret de la clé SSH de déploiement

Générez une clé dédiée, autorisez-la sur la VM, téléversez la moitié privée comme secret :

ssh-keygen -t ed25519 -C "github-actions-deploy" -f ./deploy_key -N ""
 
# Authorize the public key on the VM (match your DEPLOY_* values)
ssh-copy-id -i ./deploy_key.pub -p __DEPLOY_PORT__ __DEPLOY_USER__@__DEPLOY_HOST__
 
# Upload the private key, then destroy the local copies
gh secret set SSH_PRIVATE_KEY < ./deploy_key
rm ./deploy_key ./deploy_key.pub

$ ssh-copy-id -i ./deploy_key.pub -p __DEPLOY_PORT__ __DEPLOY_USER__@__DEPLOY_HOST__
Number of key(s) added: 1

$ gh secret set SSH_PRIVATE_KEY < ./deploy_key
✓ Set Actions secret SSH_PRIVATE_KEY for __GH_OWNER__/mnchtest

GITHUB_TOKEN ne nécessite aucune configuration — GitHub Actions le fournit à chaque run et l’utilise pour pousser/récupérer les images depuis GHCR (ghcr.io).

Étape 3.3 — Secrets applicatifs et de base de données

Le job de déploiement régénère le .env de la VM à chaque exécution à partir de ces secrets du dépôt (cat > .env <<EOF … EOF via SSH). Le .env de la VM est un état généré jetable — ne l’éditez jamais à la main. Définissez chacun avec gh secret set <NAME> --body '<value>' :

Les tags d’images (PREFECT_IMAGE / SUPERSET_IMAGE / DAGSTER_IMAGE) sont exportés en ligne par le job de déploiement à chaque run — vous ne les définissez nulle part. Le .env.example du dépôt applicatif sert uniquement au développement local, pas à la VM.

Étape 3.4 — Visibilité des packages GHCR (première livraison uniquement)

Le premier run crée trois packages : ghcr.io/__GH_OWNER__/mnchtest/{prefect,superset,dagster}. Ils héritent de la visibilité du dépôt, donc GITHUB_TOKEN devrait pousser/récupérer sans problème. Si le pull du job de déploiement rencontre un 401/403, ouvrez Settings → Manage Actions access de chaque package et donnez au dépôt au moins l’accès Write.

Phase 4 — L’application entrepôt

C’est ce qui tourne réellement sur la VM.

Trois conteneurs Docker tournent sur la VM via docker-compose.yml, tous connectés au serveur PostgreSQL externe de la Phase 3.

Topologie d’exécution

Ce que fait chaque conteneur :

• Prefect — exécute le serveur Prefect (API + UI) et un worker dans un même conteneur. Le worker exécute environ 60 déploiements d’ingestion (depuis .prefect/prefect.yaml) selon des planifications cron, en écrivant dans le schéma landing de l’entrepôt. Commande de démarrage, dans l’ordre : démarrer le serveur → interroger /api/health jusqu’à disponibilité → créer le work-pool de processus default → deploy --all → démarrer le worker (au premier plan).
• Dagster — exécute dagster-webserver (UI, port 3000) + dagster-daemon (planifications/capteurs). Il charge le projet dbt/ comme assets Dagster et les matérialise (dbt build) selon la dbt_daily_schedule (0 9 * * * Africa/Kigali, après la fenêtre d’ingestion nocturne). Cette planification est définie avec default_status=RUNNING — critique, car les planifications Dagster démarrent arrêtées par défaut. Le projet dbt/ est intégré à l’image au moment du build, donc une modification de .sql part automatiquement au prochain build CI — aucun dbt run manuel en production. Démarrage : dbt parse (nécessite les identifiants de base au runtime, d’où son exécution au démarrage du conteneur) → dagster-daemon (en arrière-plan) → dagster-webserver (au premier plan).
• Superset — lit les marts construits par dbt pour restituer les tableaux de bord ; stocke son propre état dans superset_db. Démarrage : superset db upgrade → création de admin (ignorée après le premier run) → superset init → superset run sur 8088. Nécessite le montage de volume ./.superset:/app/pythonpath pour superset_config.py, sans quoi il se rabat silencieusement sur un stockage de métadonnées SQLite.

Carte des ports

Ce sont les ports vers lesquels votre reverse proxy (Étape 1.5 / playbook 02) transfère.

Modèle de données dbt

• dbt/models
  • staging — 9 modèles, nettoient les données brutes de landing
  • intermediate — 11 modèles, logique métier et indicateurs
  • marts
    • shared — dim_facilities, fct_hmis_aggregate
    • ebuzima_dq — 22 modèles de qualité des données + consolidated_dq

La qualité des données est mesurée selon six dimensions : exactitude, complétude, cohérence, actualité, unicité, validité.

Sources de données :

• eBuzima (EMR basé sur ERPNext) — dossiers individuels ANC/maternité/nouveau-né, ingérés quotidiennement.
• HMIS/DHIS2 — agrégats mensuels au niveau des établissements, ingérés le 20 de chaque mois.

Phase 5 — Déployer et livrer

Avec les Phases 1–2 et la Phase 3 terminées, le déploiement se déclenche depuis GitHub — aucun build n’a jamais lieu sur la VM.

Déploiement continu (push sur main)

Un simple push sur main construit les images :latest, les pousse vers GHCR, puis se connecte en SSH à la VM pour :

1. git pull origin main (rafraîchir le code des flows/dbt/config sur la VM),
2. régénérer le .env à partir des secrets GitHub (Étape 3.3),
3. docker compose pull && docker compose up -d --remove-orphans.

Publier une release versionnée

Les releases sont déclenchées par la publication d’une GitHub Release, pas par le push direct d’un tag :

gh release create v1.0.0 --generate-notes

Cela construit et pousse ghcr.io/__GH_OWNER__/mnchtest/{prefect,superset,dagster}:v1.0.0 (et met à jour :latest), puis déploie cette version épinglée sur la VM.

Suivez la progression :

gh run watch

$ gh run watch
✓ deploy in 1m42s (ID 123456789)

Vérification locale avant de pousser

cp .env.example .env      # fill in real values (local dev only)
docker compose config     # confirms env-var interpolation resolves
docker compose up -d --build

$ docker compose up -d --build
[+] Running 3/3
 ✔ Container mnchtest-prefect-1   Started
 ✔ Container mnchtest-dagster-1   Started
 ✔ Container mnchtest-superset-1  Started

Accéder aux services en fonctionnement

Les secrets GitHub Actions sont en écriture seule — il n’existe aucune commande gh pour les relire. Pour retrouver le mot de passe Superset actuel, connectez-vous en SSH à la VM et faites cat .env, ou consultez le registre de secrets de votre équipe.

Exécuter dbt manuellement (développement)

En production, dbt s’exécute automatiquement via la planification quotidienne de Dagster. Pour l’exécuter manuellement pendant le développement :

cd dbt
dbt run
dbt test

Ou dans l’UI Dagster (port 13000) : Assets → sélectionner les assets dbt → Materialize.

Déployer les flows Prefect manuellement

cd .prefect
prefect deploy --all

Nettoyage

Démontage complet de tout ce que cet atelier a déployé :

# arrêter et supprimer les conteneurs en cours d’exécution sur la VM
ssh __DEPLOY_USER__@__DEPLOY_HOST__ -p __DEPLOY_PORT__ "cd __DEPLOY_PATH__ && docker compose down"
 
# supprimer les packages GHCR si les images ne sont plus nécessaires
gh api -X DELETE /orgs/__GH_OWNER__/packages/container/mnchtest%2Fprefect
gh api -X DELETE /orgs/__GH_OWNER__/packages/container/mnchtest%2Fsuperset
gh api -X DELETE /orgs/__GH_OWNER__/packages/container/mnchtest%2Fdagster
 
# effacer les secrets et variables du dépôt définis en Phase 3
gh secret list | awk '{print $1}' | xargs -n1 gh secret delete
gh variable list | awk '{print $1}' | xargs -n1 gh variable delete
 
docker compose down    # arrêter la stack de vérification locale, si vous en avez démarré une

La suite

La stack est en service. Terminez avec Exploitation, dépannage et glossaire pour les tâches du deuxième jour — rotation des identifiants, renouvellement TLS, snapshots — et la table de dépannage transversale aux couches.