Usando Webhooks en lugar de sondeo
Por defecto, SUSE® Rancher Prime Continuous Delivery utiliza sondeo (cada 15 segundos por defecto) para extraer de un repositorio Git. El sondeo funciona bien para instalaciones pequeñas (hasta unas pocas decenas de repositorios).
Para ampliaciones más grandes, configura webhooks para activar la reconciliación cuando lleguen nuevos commits. Esto reduce la demora entre un push de Git y SUSE® Rancher Prime Continuous Delivery el procesamiento del cambio por parte de.
Cuando llegan múltiples commits en rápida sucesión, los controladores de SUSE® Rancher Prime Continuous Delivery los procesan a través del bucle de reconciliación normal al actualizar los recursos correspondientes de GitRepo. Esto ayuda a evitar conflictos de actualización y mejora la fiabilidad en ampliaciones a gran escala.
Para instalaciones con muchos repositorios o cuando deseas reducir la latencia (el tiempo entre un push de Git y la reacción de SUSE® Rancher Prime Continuous Delivery), configura webhooks en lugar de sondeo.
SUSE® Rancher Prime Continuous Delivery actualmente soporta estos proveedores:
-
Azure DevOps
-
GitHub
-
GitLab
-
Bitbucket
-
Bitbucket Server
-
Gogs
1. Configura el Servicio de Webhook
SUSE® Rancher Prime Continuous Delivery utiliza un servicio de gitjob para manejar las solicitudes de webhook.
Crea un Ingress que apunte al servicio de gitjob.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: webhook-ingress
namespace: cattle-fleet-system
spec:
rules:
- host: your.domain.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: gitjob
port:
number: 80Si deseas hacer el webhook disponible usando el mismo nombre de host que Rancher u otro servicio, utiliza el siguiente YAML.
Este ejemplo utiliza el Controlador de Ingress NGINX y expone el webhook en http://your.domain.com/gitjob.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/rewrite-target: /$2
name: webhook-ingress
namespace: cattle-fleet-system
spec:
rules:
- host: your.domain.com
http:
paths:
- path: /gitjob(/|$)(.*)
pathType: ImplementationSpecific
backend:
service:
name: gitjob
port:
number: 80Ingress Nginx será retirado, aquí hay un ejemplo usando Traefik:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
traefik.ingress.kubernetes.io/router.middlewares: cattle-fleet-system-gitjob-stripprefix@kubernetescrd
traefik.ingress.kubernetes.io/router.priority: '100'
name: webhook-ingress
namespace: cattle-fleet-system
spec:
ingressClassName: traefik
rules:
- host: your.domain.com
http:
paths:
- backend:
service:
name: gitjob
port:
number: 80
path: /gitjob(/|$)(.*)
pathType: ImplementationSpecific|
Utiliza la anotación |
Esta configuración requiere un middleware para eliminar la ruta adicional de la URL, ya que gitjob responde directamente desde la ruta raíz. Esto es equivalente a la anotación nginx.ingress.kubernetes.io/rewrite-target en Nginx:
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: gitjob-stripprefix
namespace: cattle-fleet-system
spec:
stripPrefix:
prefixes:
- /gitjobEste enfoque permite una migración fluida de Ingress Nginx a Traefik mientras se mantiene la configuración de la aplicación sin cambios.
|
Puedes configurar TLS en Ingress para una comunicación segura. |
2. Configura la URL de Callback del Webhook
Ve a tu proveedor de Git y configura la URL de callback del webhook. La siguiente imagen muestra un ejemplo de GitHub.
- image
-
../../images/webhook.png[]
Configurar un secreto es opcional. El secreto se utiliza para validar la carga útil del webhook ya que la carga útil no debe ser confiada por defecto.
Si tu endpoint de webhook es accesible públicamente, se recomienda encarecidamente configurar un secreto. Si configuras un secreto, continúa con el paso 3.
|
Solo se admite |
|
Cuando se configura un webhook, el intervalo de sondeo se ajusta automáticamente a una hora. |
3. (Opcional) Configura un Secreto de Webhook
El secreto del webhook valida la carga útil enviada desde tu proveedor de Git. Cada proveedor soportado utiliza un nombre de clave específico en el secreto de Kubernetes.
| Proveedor | Clave del Secreto de Kubernetes |
|---|---|
GitHub |
|
GitLab |
|
Bitbucket |
|
Bitbucket Server |
|
Gogs |
|
Azure DevOps |
|
Azure DevOps |
|
Opción 1: Configurar un secreto a nivel de clúster
En este enfoque, el secreto se aplica a todo el clúster, y todos los GitRepos lo utilizan automáticamente. No necesitas hacer referencia a él en las definiciones individuales de GitRepo.
Cuando se recibe una carga útil, SUSE® Rancher Prime Continuous Delivery verifica si el secreto existe (gitjob-webhook en el espacio de nombres cattle-fleet-system) y utiliza la clave apropiada para la validación.
Para GitHub:
kubectl create secret generic gitjob-webhook \
-n cattle-fleet-system \
--from-literal=github=webhooksecretvaluePara Azure DevOps:
-
Habilita la Autenticación Básica en Azure.
-
Crea un secreto que contenga las credenciales.
kubectl create secret generic gitjob-webhook \
-n cattle-fleet-system \
--from-literal=azure-username=user \
--from-literal=azure-password=pass123Opción 2: Configurar un secreto por GitRepo
Puedes definir un secreto único de webhook para cada GitRepo.
Crea el secreto en el mismo espacio de nombres que el GitRepo y haz referencia a él utilizando el campo webhookSecret en la especificación.
Ejemplo:
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
name: simple
namespace: fleet-local
spec:
repo: "https://github.com/rancher/fleet-examples"
paths:
- simple
disablePolling: true
webhookSecret: webhook-secret-nameSi existen tanto un secreto a nivel de clúster como un secreto por GitRepo, SUSE® Rancher Prime Continuous Delivery utiliza el secreto por GitRepo.