← Volver al listado de tecnologías ← Índice de Portainer

GitOps y webhooks

Por: Artiko
portainergitopswebhooksci-cdautomatizacion

GitOps y webhooks

Portainer no es un sistema de CI/CD completo, pero sí cierra el último tramo del despliegue: mantener tus entornos sincronizados con Git y permitir que tu pipeline dispare actualizaciones. Esto es GitOps ligero y es una de las funciones más útiles para equipos.

El patrón GitOps

La idea: la definición de tu aplicación vive en Git (el Compose o el manifiesto), y Portainer se encarga de que el entorno refleje siempre lo que dice el repo. Tu fuente de verdad es el repositorio, no clics en la UI.

flowchart LR
    Dev["Dev hace push"] --> Git["Repositorio Git<br/>(compose.yaml)"]
    Git -->|"polling cada N min"| P["Portainer"]
    Git -->|"webhook al hacer push"| P
    P --> Deploy["Redeploy del stack"]

Auto-update de stacks desde Git

Cuando creás un stack desde un repositorio (capítulo 6), activás automatic updates con dos mecanismos:

Polling

Portainer revisa el repo cada N minutos. Si el commit de la rama cambió, hace pull del Compose actualizado y redeploya el stack. Simple y sin configurar nada en el lado del repo. Costo: un retardo de hasta N minutos y consultas periódicas.

Webhook (GitOps reactivo)

Portainer genera una URL de webhook para el stack. Configurás esa URL en tu repositorio (GitHub/GitLab) como webhook de push. Al hacer push, el repo llama a Portainer y este redeploya al instante. Sin polling, sin retardo.

Re-pull de imágenes: además de actualizar el Compose, podés pedir que el redeploy haga re-pull de las imágenes. Así, si tu CI publicó una imagen nueva con el mismo tag (ej. :latest o :staging), el redeploy la baja.

Webhooks de servicio/contenedor

Más allá de los stacks, Portainer expone webhooks de actualización para un service (Swarm) o contenedor:

  1. En el detalle del recurso, activás Webhook y copiás la URL.
  2. Al final de tu pipeline de CI (tras docker push), hacés un POST a esa URL.
  3. Portainer re-pullea la imagen y recrea el recurso con la versión nueva.
# último paso del pipeline de CI, tras publicar la imagen
curl -X POST https://portainer.midominio.com/api/webhooks/<uuid-del-webhook>

Este es el puente más directo entre tu CI/CD y Portainer: el pipeline construye y publica la imagen, y el webhook dispara el despliegue.

Patrón completo CI → Portainer

sequenceDiagram
    participant Dev
    participant CI as CI (build/test)
    participant Reg as Registry
    participant Port as Portainer
    Dev->>CI: git push
    CI->>CI: build + test
    CI->>Reg: docker push imagen:tag
    CI->>Port: POST webhook
    Port->>Reg: re-pull imagen:tag
    Port->>Port: recrear service/stack

GitOps en Kubernetes

El mismo patrón aplica a K8s: un despliegue Create from manifest → Repository con auto-update por polling o webhook mantiene el cluster sincronizado con los manifiestos del repo.

Buenas prácticas

Anterior → Capítulo 12: Usuarios, equipos y RBAC · Siguiente → Capítulo 14: Operación y seguridad

← Volver al listado de tecnologías ← Índice de Portainer