Usando webhooks em vez de polling
Por padrão, SUSE® Rancher Prime Continuous Delivery usa polling (a cada 15 segundos por padrão) para buscar de um repositório Git. Polling funciona bem para pequenas instalações (até algumas dezenas de repositórios).
Para implantações maiores, configure webhooks para acionar a reconciliação quando novos commits chegarem. Isso reduz a demora entre um push no Git e o SUSE® Rancher Prime Continuous Delivery processando a mudança.
Quando múltiplos commits chegam em rápida sucessão, os controladores do SUSE® Rancher Prime Continuous Delivery os processam através do loop de reconciliação normal ao atualizar os recursos correspondentes GitRepo. Isso ajuda a evitar conflitos de atualização e melhora a confiabilidade em implantações em grande escala.
Para instalações com muitos repositórios ou quando você deseja reduzir a latência (o tempo entre um push no Git e o SUSE® Rancher Prime Continuous Delivery reagindo a ele), configure webhooks em vez de polling.
SUSE® Rancher Prime Continuous Delivery atualmente suporta esses provedores:
-
Azure DevOps
-
GitHub
-
GitLab
-
Bitbucket
-
Bitbucket Server
-
Gogs
1. Configure o Serviço de Webhook
SUSE® Rancher Prime Continuous Delivery usa um serviço gitjob para lidar com solicitações de webhook.
Crie um Ingress que aponte para o gitjob serviço.
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: 80Se você quiser tornar o webhook disponível usando o mesmo nome de host que o Rancher ou outro serviço, use o seguinte YAML.
Este exemplo usa o NGINX Ingress Controller e expõe o webhook em 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á descontinuado, aqui está um exemplo 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|
Use a anotação |
Esta configuração requer um middleware para remover o caminho adicional da URL, uma vez que gitjob responde diretamente do caminho raiz. Isto é equivalente à anotação nginx.ingress.kubernetes.io/rewrite-target no Nginx:
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: gitjob-stripprefix
namespace: cattle-fleet-system
spec:
stripPrefix:
prefixes:
- /gitjobEsta abordagem permite uma migração suave do Ingress Nginx para o Traefik, mantendo a configuração do aplicativo inalterada.
|
Você pode configurar TLS no Ingress para comunicação segura. |
2. Configure a URL de Callback do Webhook
Vá para o seu provedor Git e configure a URL de Callback do webhook. A imagem a seguir mostra um exemplo do GitHub.
- image
-
../../images/webhook.png[]
Configurar um segredo é opcional. O segredo é usado para validar a carga útil do webhook, uma vez que a carga útil não deve ser confiável por padrão.
Se o seu endpoint de webhook for acessível publicamente, é fortemente recomendado configurar um segredo. Se você configurar um segredo, continue com a etapa 3.
|
Apenas |
|
Quando um webhook é configurado, o intervalo de polling se ajusta automaticamente para uma hora. |
3. (Opcional) Configure um Segredo de Webhook
O segredo do webhook valida a carga útil enviada pelo seu provedor Git. Cada provedor suportado usa um nome de chave específico no segredo do Kubernetes.
| Fornecedor | Chave Secreta do Kubernetes |
|---|---|
GitHub |
|
GitLab |
|
Bitbucket |
|
Bitbucket Server |
|
Gogs |
|
Azure DevOps |
|
Azure DevOps |
|
Opção 1: Configurar um segredo de cluster
Nesta abordagem, o segredo se aplica a todo o cluster, e todos os GitRepos o utilizam automaticamente. Você não precisa referenciá-lo nas definições individuais de GitRepo.
Quando um payload é recebido, SUSE® Rancher Prime Continuous Delivery verifica se o segredo existe (gitjob-webhook no namespace cattle-fleet-system) e utiliza a chave apropriada para validação.
Para GitHub:
kubectl create secret generic gitjob-webhook \
-n cattle-fleet-system \
--from-literal=github=webhooksecretvaluePara Azure DevOps:
-
Ative a Autenticação Básica no Azure.
-
Crie um segredo contendo as credenciais.
kubectl create secret generic gitjob-webhook \
-n cattle-fleet-system \
--from-literal=azure-username=user \
--from-literal=azure-password=pass123Opção 2: Configure um segredo por GitRepo
Você pode definir um segredo de webhook único para cada GitRepo.
Crie o segredo no mesmo namespace que o GitRepo e referencie-o usando o campo webhookSecret na especificação.
Exemplo:
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-nameSe existir um segredo de cluster e um segredo por GitRepo, SUSE® Rancher Prime Continuous Delivery utiliza o segredo por GitRepo.