Los cambios de monitoreo se despliegan a través del workflow de GitHub Actions
Better Stack Terraform (.github/workflows/betterstack-terraform.yml). Tiene dos carriles
claramente separados: un carril de validación estático que se ejecuta automáticamente en los pull
requests, y un carril de plan/apply que solo se ejecuta cuando un humano lo lanza.Dos carriles de un vistazo
Carril de validación — automático, seguro por construcción
Se dispara en cada pull request amaster, release o develop que toca
infra/betterstack/**, el script del runner, o el propio archivo del workflow. Se ejecuta
con sin secretos y sin estado, así que físicamente no puede cambiar Better Stack.
Este es el carril que ves ponerse verde en un PR de monitoreo. Prueba que la config está
bien formada; no se comunica con Better Stack.
Carril de plan/apply — manual, protegido, por entorno
Este carril se ejecuta víaworkflow_dispatch (pestaña Actions → Run
workflow) o como la etapa final del orquestador Release Train
(.github/workflows/release-train.yml). Toma dos entradas — el environment
objetivo (una lista fija: development, certification, production) y la
action (plan o apply) — más una cadena de confirmación.
Las ejecuciones manuales son solo desde tags: elige un tag CalVer de
release en “Use workflow from”. La guarda compartida
(.github/scripts/validate-release-tag.sh) rechaza refs de branch y aplica la
matriz de canales (alpha → development, rc → development + certification,
estable → los tres), y exige que el tag tenga un GitHub Release.
La compuerta de confirmación
El jobgate se ejecuta primero. Si action = apply y la entrada confirm_apply no
es exactamente APPLY, falla antes de que algo toque la infraestructura. plan
no necesita confirmación — es de solo lectura. Cuando el workflow es invocado
por el Release Train, la única confirmación RELEASE del train reemplaza el
APPLY tipeado (vía una entrada confirmed exclusiva de workflow_call que
los dispatch manuales no pueden establecer). La compuerta valida además el tag
de release con la guarda compartida.
Aislamiento de entorno y secretos
El jobterraform se ejecuta dentro del GitHub Environment seleccionado, de modo que las
reglas de protección de ese entorno (revisores requeridos, temporizadores de espera) y sus
secretos con alcance se aplican automáticamente.
Secretos por entorno
BETTERSTACK_UPTIME_API_TOKEN, HEALTH_MONITOR_TOKEN, y el opcional
LOGTAIL_API_TOKEN. Definidos en cada uno de development, certification y
production.Secretos del repositorio (estado remoto)
TF_BACKEND_OVERRIDE (el bloque backend "s3" completo), TF_STATE_ACCESS_KEY
y TF_STATE_SECRET_KEY. Compartidos entre entornos; el estado permanece aislado
por workspace.Fail-fast ante estado remoto ausente
Antes deinit, el job verifica que TF_BACKEND_OVERRIDE exista. Si no lo hace,
falla de inmediato — CI nunca debe planear contra un estado local vacío,
lo que intentaría recrear cada recurso. Cuando está presente, el bloque se escribe
en backend_override.tf y terraform init toma el backend remoto.
Bloqueo de concurrencia
Un grupo de concurrencia con clave por entorno (betterstack-terraform-<environment>) con cancel-in-progress: false
garantiza que dos operaciones nunca se ejecuten contra el mismo entorno a la vez; una
segunda ejecución se encola detrás de la primera.
Outputs
Enapply, el paso final añade terraform output al resumen del job para que los
status_page_resources_json y uptime_heartbeat_ids resultantes sean visibles
sin volver a ejecutar nada.
Cómo ejecutarlo
1
Abre el workflow
GitHub → Actions → Better Stack Terraform → Run workflow, y
elige el tag de release en “Use workflow from” (los refs de branch son
rechazados).
2
Ejecuta primero un plan
Elige el
environment objetivo, establece action = plan, y ejecuta. Lee el diff
en el log del job. Un plan 0 to add, 0 to change, 0 to destroy significa que no hay drift.3
Aplica cuando el plan sea lo que esperas
Ejecuta de nuevo con
action = apply y escribe APPLY en confirm_apply. La compuerta
pasa, el job se ejecuta dentro del entorno, y se publica el resumen de outputs.4
Confirma la convergencia
Ejecuta un
plan más — debería reportar que no hay cambios.Decisiones de seguridad
Por qué el apply nunca es automático
Por qué el apply nunca es automático
Los cambios de monitoreo afectan la página de estado pública y pueden paginar a los ingenieros
de guardia. Un humano debe leer el plan y escribir explícitamente
APPLY, para que un
cambio de infraestructura sea siempre una acción deliberada y revisada — nunca un efecto
secundario de hacer merge.Por qué CI se niega a ejecutarse sin estado remoto
Por qué CI se niega a ejecutarse sin estado remoto
Terraform rastrea los ids de los recursos en su estado. Ejecutar contra un estado local
vacío haría que Terraform crea que nada existe y recreara cada
monitor, duplicando recursos en la página de estado. Requerir
TF_BACKEND_OVERRIDE hace que ese fallo sea imposible.Por qué un grupo de concurrencia por entorno
Por qué un grupo de concurrencia por entorno
Dos applies solapados contra el mismo estado pueden corromperlo o generar una race en la
API de Better Stack. El bloqueo por entorno serializa las operaciones mientras aún
permite que distintos entornos se ejecuten en paralelo.
Por qué el carril de validación no tiene secretos
Por qué el carril de validación no tiene secretos
La validación de PR debería ser segura de ejecutar en cualquier cambio, incluyendo desde forks. Al
usar
init -backend=false y sin tokens, el carril puede verificar la corrección
sin ninguna capacidad de alcanzar o mutar Better Stack.Código relacionado
- Workflow:
.github/workflows/betterstack-terraform.yml - Runner:
scripts/status-monitoring/terraform-apply.sh - Template del backend:
infra/betterstack/backend_override.tf.example