Développeurs/Déploiements et variables

Déploiements, variables et journaux

Les exemples utilisent la fonction hw et $API du démarrage rapide, et $APP est un uuid d’application.

Variables d’environnement#

Les variables parviennent à votre app comme variables d’environnement à l’exécution, et au moment du build sauf si vous le désactivez.

hw -X PATCH $API/applications/$APP/envs/bulk -d '{"data": [
  {"key": "LOG_LEVEL", "value": "info"},
  {"key": "STRIPE_KEY", "value": "sk_live_…", "is_shown_once": true},
  {"key": "GREETING", "value": "Hello $USER", "is_literal": true}
]}'

• is_shown_once : la valeur ne peut plus jamais être relue, ni dans la console ni par l’API.
• is_literal : les $NAMES dans la valeur sont gardés tels quels au lieu d’être remplacés.
• is_multiline : pour des valeurs comme les clés PEM.
• is_buildtime / is_runtime : quand la variable est disponible (les deux par défaut).

Les variables partagées sont définies une fois et utilisées par plusieurs apps : {{team.KEY}}, {{project.KEY}} ou {{environment.KEY}} dans la valeur d’une variable d’app. Gérez-les avec /team/envs, /projects/{uuid}/envs et /projects/{uuid}/environments/{env}/envs.

Déployer#

hw -X POST $API/applications/$APP/start            # build and start
hw -X POST "$API/applications/$APP/start?force=true" # rebuild without the build cache
hw -X POST $API/applications/$APP/restart          # restart without rebuilding
hw -X POST $API/applications/$APP/stop             # take it offline

start répond {"message": "Deployment request queued.", "deployment_uuid": "…"}. Un déploiement passe par queued → in_progress → finished, ou se termine en failed ou cancelled-by-user. Si un build échoue, la version précédente continue de tourner. Avec un contrôle de santé activé (health_check_enabled, health_check_path), une nouvelle version ne prend le relais qu’une fois qu’elle répond.

Le SDK propose deployAndWait(appUuid) et deployments.wait(deploymentUuid), qui interrogent l’API pour vous et lèvent une erreur avec la fin du journal de build quand un déploiement échoue.

Journaux#

Les journaux de build font partie du déploiement. logs est une liste de lignes encodée en JSON ; les lignes marquées hidden sont des commandes de build internes :

hw $API/deployments/$DEPLOYMENT | jq -r '.logs | fromjson | map(select(.hidden | not) | .output) | .[-50:][]'

Les journaux d’exécution sont la sortie du conteneur en cours d’exécution (nécessite Lecture des données sensibles) :

hw "$API/applications/$APP/logs?lines=200&show_timestamps=true" | jq -r .logs

Une app arrêtée répond 400 Application is not running. Pour l’historique du CPU et de la mémoire, utilisez GET /applications/{uuid}/metrics?minutes=60.

Retour arrière#

hw $API/applications/$APP/rollback-images | jq        # images you can go back to
hw -X POST $API/applications/$APP/rollback -d '{"tag": ""}'

Un retour arrière redéploie une image précédente sans refaire le build.

Déploiements par push#

Pour déployer à chaque git push, utilisez l’une de ces méthodes :

• GitHub App (recommandée pour GitHub) : connectez-la dans la console sous Sources, puis créez des apps à partir de ses dépôts (POST /applications/private-github-app). Les push sur la branche de l’app déclenchent un déploiement automatique ; aucun webhook à configurer.
• Webhook de dépôt (tout dépôt public ou avec clé de déploiement sur GitHub, GitLab, Bitbucket ou Gitea) : définissez un secret sur l’app, puis ajoutez un webhook dans votre dépôt.

SECRET=$(openssl rand -hex 24)
hw -X PATCH $API/applications/$APP -d "{\"manual_webhook_secret_github\": \"$SECRET\"}"

Dans GitHub, ouvrez Settings → Webhooks → Add webhook sur le dépôt :

Pour les autres hébergeurs, utilisez manual_webhook_secret_gitlab, _bitbucket ou _gitea et l’URL /webhooks/source/<host>/events/manual correspondante. L’onglet Webhooks de l’app dans la console affiche aussi les URL. Les secrets doivent comporter au moins 16 caractères. Seuls les push sur la git_branch de l’app la déploient ; watch_paths (par ex. "src/**") limite les déploiements aux modifications dans ces chemins.

Déployer depuis la CI#

Appelez l’endpoint de déploiement une fois vos tests réussis. Un jeton avec seulement les permissions Déploiement et Lecture suffit :

curl -fsS -X POST "https://console.app.hostwolf.net/api/v1/deploy?uuid=$APP_UUID" \
  -H "Authorization: Bearer $HOSTWOLF_APPS_TOKEN"

Dans GitHub Actions, enregistrez le jeton comme secret du dépôt :

# .github/workflows/deploy.yml
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Hostwolf Apps
        run: |
          curl -fsS -X POST "https://console.app.hostwolf.net/api/v1/deploy?uuid=${{ vars.HOSTWOLF_APP }}" \
            -H "Authorization: Bearer ${{ secrets.HOSTWOLF_APPS_TOKEN }}"

Pour déployer une image déjà construite par votre pipeline, créez l’app à partir de cette image (POST /applications/dockerimage) et passez docker_tag à /deploy.