DesarrolladoresDespliegues y variables

Despliegues, variables y registros

Los ejemplos usan el atajo hw y $API del inicio rápido, y $APP es el uuid de una aplicación.

Variables de entorno#

Las variables llegan a tu app como variables de entorno en tiempo de ejecución, y también durante el build salvo que lo desactives.

LlamadaQué hace
GET /applications/{uuid}/envsLístalas. Los valores son null salvo que el token tenga Lectura de datos sensibles.
PATCH /applications/{uuid}/envs/bulkCrea o actualiza varias a la vez: {"data": [{"key", "value"}, …]}
POST /applications/{uuid}/envsCrea una (409 si la clave existe)
PATCH /applications/{uuid}/envsActualiza una por key
DELETE /applications/{uuid}/envs/{env_uuid}Elimina una
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: el valor no se puede volver a leer nunca, ni en la consola ni en la API.
  • is_literal: los $NAMES dentro del valor se mantienen como texto en lugar de expandirse.
  • is_multiline: para valores como claves PEM.
  • is_buildtime / is_runtime: cuándo está disponible la variable (en ambos casos por defecto).

Las variables compartidas se definen una vez y las usan muchas apps: {{team.KEY}}, {{project.KEY}} o {{environment.KEY}} en el valor de una variable de la app. Gestiónalas con /team/envs, /projects/{uuid}/envs y /projects/{uuid}/environments/{env}/envs.

Los contenedores en ejecución mantienen las variables con las que arrancaron. Despliega la app (abajo) después de cambiarlas.

Desplegar#

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 responde {"message": "Deployment request queued.", "deployment_uuid": "…"}. Un despliegue pasa por queued → in_progress → finished, o termina como failed o cancelled-by-user. Si un build falla, la versión anterior sigue funcionando. Con un health check activado (health_check_enabled, health_check_path), una versión nueva solo toma el relevo cuando responde.

LlamadaQué hace
GET /deployments/{uuid}Estado de un despliegue, con su registro de build en logs
GET /deployments/applications/{uuid}?skip=0&take=10Los despliegues de una app, los más recientes primero: {count, deployments}
GET /deploymentsDespliegues en cola o en curso en este momento, en todo el equipo
POST /deployments/{uuid}/cancelCancela un despliegue en cola o en curso
POST /deploy?uuid=a,b o ?tag=webDespliega varias apps a la vez, por uuid o etiqueta

El SDK tiene deployAndWait(appUuid) y deployments.wait(deploymentUuid), que consultan el estado por ti y lanzan un error con el final del registro de build cuando falla un despliegue.

Registros#

Los registros de build forman parte del despliegue. logs es una lista de líneas codificada en JSON; las líneas marcadas como hidden son comandos internos del build:

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

Los registros de ejecución son la salida del contenedor en marcha (necesitan Lectura de datos sensibles):

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

Una app detenida responde 400 Application is not running. Para CPU y memoria a lo largo del tiempo, usa GET /applications/{uuid}/metrics?minutes=60.

Rollback#

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

Un rollback vuelve a desplegar una imagen anterior sin volver a hacer el build.

Despliegues por push#

Para desplegar en cada git push, usa una de estas opciones:

  • GitHub App (recomendada para GitHub): conéctala en la consola en Fuentes y luego crea apps desde sus repositorios (POST /applications/private-github-app). Los push a la rama de la app se despliegan automáticamente; no hay que configurar ningún webhook.
  • Webhook del repositorio (cualquier repositorio público o con clave de despliegue en GitHub, GitLab, Bitbucket o Gitea): define un secreto en la app y luego añade un webhook en tu repositorio.
SECRET=$(openssl rand -hex 24)
hw -X PATCH $API/applications/$APP -d "{\"manual_webhook_secret_github\": \"$SECRET\"}"

En GitHub, abre Settings → Webhooks → Add webhook en el repositorio:

CampoValor
Payload URLhttps://console.app.hostwolf.net/webhooks/source/github/events/manual
Tipo de contenidoapplication/json
Secretoel $SECRET de arriba
EventosSolo el evento push

Para los demás servicios, usa manual_webhook_secret_gitlab, _bitbucket o _gitea y la URL /webhooks/source/<host>/events/manual correspondiente. La pestaña Webhooks de la app en la consola también muestra las URLs. Los secretos necesitan al menos 16 caracteres. Solo los push a la git_branch de la app la despliegan; watch_paths (p. ej. "src/**") limita los despliegues a cambios en esas rutas.

Desplegar desde CI#

Llama al endpoint de despliegue cuando pasen tus tests. Basta con un token que solo tenga los permisos Despliegue y Lectura:

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

En GitHub Actions, guarda el token como secreto del repositorio:

# .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 }}"

Para desplegar una imagen que tu pipeline ya construyó, crea la app a partir de esa imagen (POST /applications/dockerimage) y pasa docker_tag a /deploy.

¿Atascado, o te falta un endpoint? Escríbenos en app.hostwolf.net/contact o a [email protected].