DEV Community: Paulo Ponciano

Blue/Green e Canary no Kubernetes com Argo Rollouts [Lab Session]

Paulo Ponciano — Sun, 10 Aug 2025 11:41:43 +0000

O que é o Argo Rollouts?

Argo Rollouts é um controlador para Kubernetes e um conjunto de CRDs que oferecem capacidades avançadas de deploy, como blue-green, canary, análise de canary, experimentação e recursos de entrega progressiva para o Kubernetes.

O Argo Rollouts pode se integrar (opcionalmente) com controladores de ingress e service meshes, aproveitando suas habilidades de manipulação de tráfego para direcionar gradualmente o tráfego para a nova versão durante uma atualização. Além disso, o Rollouts pode consultar e interpretar métricas de diversos provedores para verificar KPIs importantes e automatizar a promoção ou o rollback durante uma atualização.

Fonte: https://argoproj.github.io/rollouts/

Repositórios

https://github.com/paulofponciano/lab-argo-rollouts

Diversas seções dos manifestos presentes no repositório acima foram portadas ou inspiradas a partir do repositório msc-research-stuff, do Matheus Fidelis. Se você leva Engenharia a sério, recomendo fortemente que veja https://fidelissauro.dev/.

https://github.com/paulofponciano/EKS-Istio-Karpenter-ArgoCD

Este outro repositório pode te ajudar a provisionar, com Terraform, um cluster EKS funcional com a maior parte dos componentes utilizados no lab.

Componentes do cluster

Para esse lab, foram utilizados essencialmente os componentes abaixo em um cluster EKS:

ArgoCD

Argo Rollouts

Kube-prometheus-stack

Istio (base, istiod e gateway)

Projects e Applications no ArgoCD

Foram criados dois Projects e quatro Applications, uma para cada cenário explorado:

Project	Application
lab-apps-blue-green	lab-apps-blue-green-simple
lab-apps-blue-green	lab-apps-blue-green-automated
lab-apps-canary	lab-apps-canary-simple
lab-apps-canary	lab-apps-canary-metrics

Exemplo de um manifesto de AppProject e Application no ArgoCD:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: lab-apps-canary
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  description: Lab Apps with Argo Rollouts
  sourceRepos:
    - 'https://github.com/paulofponciano/lab-argo-rollouts'
    - 'oci://registry-1.docker.io/paulofponciano'
    - 'registry-1.docker.io/paulofponciano'
  destinations:
    - namespace: '*'
      server: 'https://kubernetes.default.svc'
      name: 'in-cluster'
  clusterResourceWhitelist:
    - group: '*'
      kind: '*'
  namespaceResourceWhitelist:
    - group: '*'
      kind: '*'
  orphanedResources:
    warn: false
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: lab-apps-canary-simple
  namespace: argocd
  labels:
    type: application
spec:
  project: lab-apps-canary
  source:
    repoURL: https://github.com/paulofponciano/lab-argo-rollouts
    path: argo-apps/canary/simple
    targetRevision: HEAD
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Cenário com Blue/Green simples

Usamos uma app demo bem simples que já possui um helm chart criado. Com um ApplicationSet do Argo, passamos alguns valores para configuração:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: demo-ms-2
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - cluster: https://kubernetes.default.svc
  template:
    metadata:
      name: demo-ms-2
    spec:
      project: lab-apps-blue-green
      source:
        repoURL: 'registry-1.docker.io/paulofponciano'
        chart: demo-ms-intercomunicacao
        targetRevision: 0.1.18
        helm:
          valuesObject:
            # ...omitted for brevity...
            strategy:
              type: blueGreen
              blueGreen:
                activeService: demo-ms-2
                previewService: demo-ms-2-green
                autoPromotionEnabled: false
            # ...omitted for brevity...
      destination:
        server: '{{ cluster }}'
        namespace: argocd
      syncPolicy:
        automated: {}

No manifesto acima, veja que informamos dois services para a estratégia Blue/Green: activeService e previewService. Enquanto não existir uma réplica green, ambos os services direcionam o tráfego para a réplica estável (blue). No entanto, o tráfego de "produção" chegará através do Virtual Service do Istio, que por sua vez roteia apenas para o activeService:

Recursos criados pelo ApplicationSet:

No pod que, atualmente, é a réplica estável, podemos ver que existe uma label rollouts-pod-template-hash: 667677c457 (além da label app):

Essa label é utilizada como selector tanto no activeService quanto no previewService. Isso é controlado pelo Argo Rollouts:

Como mencionado anteriormente, o Virtual Service do Istio possui uma rota com destination apenas para demo-ms-2.demo.svc.cluster.local, que é o activeService:

Enviando requisições para o endpoint /version tanto pelo activeService (que passa pelo VS do Istio) quanto pelo previewService, vemos que a resposta é a mesma, pois estamos acessando a mesma réplica (blue):

while true; do curl http://demo-ms-2.demo.svc.cluster.local:5000/version; done
while true; do curl http://demo-ms-2-green.demo.svc.cluster.local:5000/version; done

No ApplicationSet, alteramos a APP_VERSION de "0.1.1" para "0.1.2", essa alteração vai gerar um Blue/Green para essa app:

Agora com duas réplicas, uma continua sendo a estável (blue) recebendo tráfego de produção e a outra green com a nova versão da app. O Argo Rollouts altera o selector no previewService para que o endpoint seja a réplica green:

Com isso, temos a chance de validar se a nova versão está se comportando como o esperado antes de enviar tráfego de produção. Em alguns casos, é interessante também para aplicações que possuem particularidades em relação a warm-up:

Uma vez que decidimos que está tudo certo com a nova versão (green), podemos promovê-la. No Rollout, selecionamos 'Promote-Full':

Desta vez, o selector do activeService é alterado para que o endpoint seja a réplica da nova versão rollouts-pod-template-hash: 65dcC64c86 (que agora passa a ser blue):

Voltamos ao cenário inicial, mas desta vez com a nova versão "0.1.2" já recebendo tráfego de produção. A réplica que antes era blue na versão "0.1.1" é terminada:

Cenário com Blue/Green automatizado

Para aumentar a confiabilidade, no processo de rollout podemos incluir testes automatizados na réplica green, tornando a promoção da nova versão condicionada ao sucesso desses testes. Ainda assim, neste cenário, o parâmetro autoPromotionEnabled permanece configurado como false, o que significa que a promoção completa (Promote-Full) continuará sendo realizada manualmente, assim como no cenário anterior. Essa abordagem é uma escolha para manter maior controle sobre o processo.

No ApplicationSet adicionamos os templates de prePromotionAnalysis bem como values para o Helm renderizar esses templates:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: demo-ms-4
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - cluster: https://kubernetes.default.svc
  template:
    metadata:
      name: demo-ms-4
    spec:
      project: lab-apps-blue-green
      source:
        repoURL: 'registry-1.docker.io/paulofponciano'
        chart: demo-ms-intercomunicacao
        targetRevision: 0.1.18
        helm:
          valuesObject:
            # ...omitted for brevity...
            strategy:
              type: blueGreen
              blueGreen:
                activeService: demo-ms-4
                previewService: demo-ms-4-green
                autoPromotionEnabled: false
                prePromotionAnalysis:
                  templates:
                  - templateName: demo-ms-4-http-bench-analysis
                  - templateName: demo-ms-4-check-success
            analysisTemplates:
              - name: demo-ms-4-http-bench-analysis
                spec:
                  metrics:
                  - name: http-bench-analysis
                    failureLimit: 1
                    provider:
                      job:
                        spec:
                          backoffLimit: 1
                          template:
                            metadata:
                              labels:
                                istio-injection: disabled
                                sidecar.istio.io/inject: "false"
                            spec:
                              containers:
                              - name: http-bench-analysis
                                image: rogerw/cassowary:v0.14.0
                                command: ["cassowary"]
                                args: ["run", "-u", "http://demo-ms-4-green.demo.svc.cluster.local:5000/healthz", "-c", "3", "-n", "1000"]
                              restartPolicy: Never
                  count: 1
              - name: demo-ms-4-check-success
                spec:
                  metrics:
                  - name: success-rate
                    interval: 1m
                    successCondition: result[0] >= 0.95
                    failureLimit: 1
                    provider:
                      prometheus:
                        address: http://kube-prometheus-stack-prometheus.o11y.svc.cluster.local:9090
                        query: |
                          sum(irate(
                            istio_requests_total{destination_service=~"demo-ms-4-green.demo.svc.cluster.local",response_code!~"5.*"}[1m]
                          )) /
                          sum(irate(
                            istio_requests_total{destination_service=~"demo-ms-4-green.demo.svc.cluster.local"}[1m]
                          ))
                    count: 1
            # ...omitted for brevity...
      destination:
        server: '{{ cluster }}'
        namespace: argocd
      syncPolicy:
        automated: {}

Para gerar o Blue/Green alteramos no ApplicationSet a APP_VERSION de "0.1.3" para "0.1.4":

Testes http-bench-analysis (Job) e success-rate com métricas do Prometheus:

Como os testes passaram com sucesso, a réplica green fica disponível para ser promovida:

while true; do curl http://demo-ms-4.demo.svc.cluster.local:5000/version; done
while true; do curl http://demo-ms-4-green.demo.svc.cluster.local:5000/version; done

A forma como o Argo Rollouts manipula o selector tanto no activeService quanto no previewService é a mesma do cenário anterior, e o Virtual Service do Istio continua apenas com uma rota, tendo como destination o activeService.

Após o 'Promote-Full', a réplica com a versão "0.1.3" é removida e a nova versão "0.1.4" agora é a blue:

Cenário com Canary simples

Com a estratégia de canary releases, podemos realizar um rollout gradual em ambiente de produção, avaliando a "aceitação estruturada do usuário". Caso sejam identificados problemas ou a aceitação não seja satisfatória, é fundamental que seja possível realizar um rollback (Abort) imediato para a versão anterior.

Nesse cenário, a progressão do rollout será manual entre os steps. Os values para o helm são informados no ApplicationSet:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: demo-ms-7
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - cluster: https://kubernetes.default.svc
  template:
    metadata:
      name: demo-ms-7
    spec:
      project: lab-apps-canary
      source:
        repoURL: 'registry-1.docker.io/paulofponciano'
        chart: demo-ms-intercomunicacao
        targetRevision: 0.1.18
        helm:
          valuesObject:
            # ...omitted for brevity...
            strategy:
              type: canary
              canary:
                steps:
                  - setWeight: 0
                  - pause: {}
                  - setWeight: 10
                  - pause: {}
                  - setWeight: 20
                  - pause: {}
                  - setWeight: 40
                  - pause: {}
                  - setWeight: 80
                  - pause: {}
                  - setWeight: 100
            # ...omitted for brevity...
      destination:
        server: '{{ cluster }}'
        namespace: argocd
      syncPolicy:
        automated: {}

Para iniciar o processo, alteramos no ApplicationSet a APP_VERSION de "0.1.5" para "0.1.6". Como o primeiro step é setWeight: 0, nada acontecerá até avançarmos manualmente o canary:

while true; do curl http://demo-ms-7.demo.svc.cluster.local:5000/version; done
while true; do curl http://demo-ms-7-canary.demo.svc.cluster.local:5000/version; done

Semelhante ao que vimos nos cenários de Blue/Green, aqui os dois services estão com o selector na mesma réplica (réplica estável):

No entanto, o Virtual Service do Istio possui uma rota com dois destination e com pesos (weight) distintos. Como ainda não avançamos para o próximo step, o peso para a versão canary é 0, ou seja, sem tráfego (até mesmo porque não existe ainda uma réplica canary):

Seguindo, podemos selecionar 'Resume' no rollout e avançar para o segundo step:

Agora a réplica canary é criada:

O Argo Rollouts modifica o selector do canaryService para selecionar a réplica criada:

No Virtual Service do Istio, o peso no destination do canary é alterado para atender o step setWeight: 10:

Exemplo visual do canaryService e stableService:

Podemos ver que as requisições enviadas para o Virtual Service do Istio, que responde pelo host do stableService (demo-ms-7.demo.svc.cluster.local) já estão sendo direcionadas também para a versão canary, seguindo o setWeight: 10 até que avancemos mais um step manualmente:

Com apoio visual do Kiali, vemos a distribuição do tráfego:

Já com o canary mais avançado, no step setWeight: 80:

Manualmente, iremos progredir o canary até que o tráfego seja totalmente direcionado para a nova versão, no step setWeight: 100. Depois disso, o Argo Rollouts ajustará o selector do stableService para que o endpoint seja a réplica com a versão "0.1.6" e no Virtual Service do Istio os pesos serão ajustados para os valores que vimos inicialmente, ou seja, 100 para a réplica estável e 0 para a réplica canary (do próximo rollout no caso).

Cenário com Canary automatizado

Neste cenário, vamos deixar a progressão do canary condicionada ao sucesso dos testes automatizados. Assim como no cenário anterior, cada step irá direcionar uma parcela maior do tráfego de produção para a réplica canary, até que seja totalmente concluído o rollout.

No ApplicationSet, adicionamos o template de análise na seção analysis de cada step:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: demo-ms-10
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - cluster: https://kubernetes.default.svc
  template:
    metadata:
      name: demo-ms-10
    spec:
      project: lab-apps-canary
      source:
        repoURL: 'registry-1.docker.io/paulofponciano'
        chart: demo-ms-intercomunicacao
        targetRevision: 0.1.18
        helm:
          valuesObject:
            # ...omitted for brevity...
            strategy:
              type: canary
              canary:
                steps:
                  - setWeight: 10
                  - pause: { duration: 30s }
                  - analysis:
                      templates:
                        - templateName: demo-ms-10-check-success
                  - setWeight: 20
                  - pause: { duration: 1m }
                  - analysis:
                      templates:
                        - templateName: demo-ms-10-check-success
                  - setWeight: 40
                  - pause: { duration: 1m }
                  - analysis:
                      templates:
                        - templateName: demo-ms-10-check-success
                  - setWeight: 80
                  - pause: { duration: 1m }
                  - analysis:
                      templates:
                        - templateName: demo-ms-10-check-success
                  - setWeight: 100
            analysisTemplates:
              - name: demo-ms-10-check-success
                spec:
                  metrics:
                    - name: success-rate
                      interval: 1m
                      successCondition: result[0] >= 0.95
                      failureLimit: 1
                      provider:
                        prometheus:
                          address: http://kube-prometheus-stack-prometheus.o11y.svc.cluster.local:9090
                          query: |
                            sum(irate(
                              istio_requests_total{destination_service=~"demo-ms-10.demo.svc.cluster.local",response_code!~"5.*"}[1m]
                            )) /
                            sum(irate(
                              istio_requests_total{destination_service=~"demo-ms-10.demo.svc.cluster.local"}[1m]
                            ))
                      count: 1
            # ...omitted for brevity...
      destination:
        server: '{{ cluster }}'
        namespace: argocd
      syncPolicy:
        automated: {}

Para iniciar o processo, alteramos no ApplicationSet a APP_VERSION de "0.1.7" para "0.1.8". Depois disso, não esperamos mais nenhuma ação "manual", ficamos aguardando os testes acontecerem em cada step e o canary progredir:

Argo Rollouts ajustando os pesos (weight) no Virtual Service do Istio:

while true; do curl http://demo-ms-10.demo.svc.cluster.local:5000/version; done
while true; do curl http://demo-ms-10-canary.demo.svc.cluster.local:5000/version; done

Conclusão do rollout e remoção da réplica com a versão "0.1.7":

Os pesos são reajustados para os valores iniciais, 100 para a réplica estável:

Importante!

Utilizar Canary releases e Blue/Green deployments é sensacional. Mas não devemos esquecer do que pode (e muitas vezes vai) inviabilizar esse tipo de estratégia (e outros tipos também): a CAMADA DE DADOS. É necessário investir um esforço de Engenharia considerável nesse ponto.

Referências e recomendações:

DIA 4 - CLOUD #SEMANADEVOPS LINUXtips - Track com Matheus Fidelis

Keep shipping! 🐳

Auto-Instrumentação com OpenTelemetry no EKS [Lab Session]

Paulo Ponciano — Sun, 05 Jan 2025 19:53:56 +0000

OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.

Source: https://opentelemetry.io/

Otel Diagram

Source: https://opentelemetry.io/docs/

Cenários para auto-instrumentação (Zero-code Instrumentation)

Alguns cenários podem nos levar a recorrer à instrumentação automática de aplicações. São eles:

Não ter acesso ao código fonte;
Falta de sponsors para um refatoramento, por não ser viável ao negócio;
Não ser o "dono" da aplicação;
A aplicação já executada há tempos, ninguém tem mais o contexto e o desenvolvimento foi descontinuado.

Mesmo se você se encontrar em um dos motivadores acima (ou mais de um), ainda pode haver a necessidade de observar essas aplicações.
É importante lembrar que essa abordagem de auto-instrumentação traz algumas ressalvas, como, por exemplo, o excesso de telemetria gerado pela aplicação instrumentada.
Quando temos um cenário de uma aplicação greenfield (do zero), será mais interessante já pensar na instrumentação como parte do desenvolvimento, sendo chamada de instrumentação manual e não auto-instrumentação.

Arquitetura do Lab

Nesse lab, vamos explorar a auto-instrumentação com OpenTelemetry Operator para Kubernetes.

Repositórios:

Terraform: https://github.com/paulofponciano/EKS-Istio-Karpenter
Stack observabilidade: https://github.com/paulofponciano/o11y-lab-prom-otel-loki-tempo

O provisionamento da infraestrutura e seus componentes, como: Cluster EKS, Istio ingress, karpenter e também a stack de observabilidade que contempla o Grafana Tempo, pode ser feito seguindo esse outro Lab - o11y: OpenTelemetry, Prometheus, Loki e Tempo no EKS [Lab Session]. Portanto, partiremos do ponto em que o EKS já está configurado e com o Grafana Tempo em execução.

Deploy do OpenTelemetry Operator

Componentes já em execução no cluster:

Kube-prometheus-stack
Promtail
Grafana Loki (distributed)
Grafana Tempo (distributed)

O que vamos usar aqui é o Grafana Tempo e o Grafana que faz parte da stack do Prometheus. No Grafana, já há um datasource do Tempo configurado.

Deploy do operator usando Helm:

git clone https://github.com/paulofponciano/o11y-lab-prom-otel-loki-tempo.git
cd o11y-lab-prom-otel-loki-tempo/opentelemetry/auto-instrumentation/operator

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

helm install opentelemetry-operator open-telemetry/opentelemetry-operator \
--namespace opentelemetry-operator-system \
--create-namespace \
--set "manager.collectorImage.repository=otel/opentelemetry-collector-k8s" \
--set admissionWebhooks.certManager.enabled=false \
--set admissionWebhooks.autoGenerateCert.enabled=true

Logs iniciais do OpenTelemetry Operator:

Deploy Otel collector

Podemos agora fazer o deploy de um custom resource que é o OpenTelemetryCollector. Basicamente, ele receberá os traces (receivers) e os enviará (exporters) para o Grafana Tempo, onde poderão ser visualizados.

kubectl apply -f otel-collector.yaml

Manifesto do collector:

apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: otelcol
  namespace: o11y
spec:
  config:
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318
    processors:
      memory_limiter:
        check_interval: 1s
        limit_percentage: 75
        spike_limit_percentage: 15
      batch:
        send_batch_size: 10000
        timeout: 10s

    exporters:
      debug: {}
      otlp:
        endpoint: tempo-distributor.o11y.svc.cluster.local:4317
        tls:
          insecure: true

    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [debug, otlp]

Logs iniciais do otel collector:

Exemplo Java e Otel Instrumentation

Mais um custom resource que faremos o deploy é o Instrumentation. Dentre outras configurações, nele definiremos quem será o otel collector, no caso, será o que acabamos de criar.

kubectl apply -f java-auto-instrumentation.yaml

Manifesto de instrumentation:

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: java-auto-instrumentation
  namespace: o11y
spec:
  exporter:
    endpoint: http://otelcol-collector.o11y.svc.cluster.local:4318
  propagators:
    - tracecontext
    - baggage
  sampler:
    type: parentbased_traceidratio
    argument: "1"

kubectl get instrumentation -n o11y

Agora podemos fazer o deploy de uma aplicação de exemplo em java (vertx-create-span):

kubectl create ns sample-api-java
kubectl apply -f java-service-with-auto-instrumentation.yaml

Importante notar a annotation que devemos informar no manifesto, onde é definida a instrumentation que usaremos:

# Part of the complete manifest:
template:
  metadata:
    labels:
      app: operator-e2e-tests
    annotations:
      instrumentation.opentelemetry.io/inject-java: "o11y/java-auto-instrumentation"
# ...

Executando kubectl describe pod no pod da aplicação que acabou de subir, vemos que foi injetado um initContainer para auto-instrumentação:

Dentro do container:

Simulando tráfego de entrada na aplicação java:

Logs da aplicação e do otel collector:

No Grafana, visualizamos os traces recebidos através do datasource plugin do Grafana Tempo:

Exemplo Python e Otel Instrumentation

Faremos o mesmo processo de deploy, mas agora para uma app demo que simula a comunicação de microsserviços. Primeiro o apply do manifesto de instrumentation - Embora fosse possível reutilizar a Instrumentation já criada, optamos por criar uma específica para cada caso:

kubectl apply -f python-auto-instrumentation.yaml

kubectl get instrumentation -n o11y

Deploy app demo python:

kubectl create ns sample-api-python
kubectl apply -f python-service-with-auto-instrumentation.yaml

Annotation referenciando a Instrumentation:

# Part of the complete manifest:
template:
    metadata:
      annotations:
        instrumentation.opentelemetry.io/inject-python: "o11y/python-auto-instrumentation"
      labels:
        app: microservice-1
# ...

Com kubectl describe pod novamente vemos o initContainer da auto-instrumentação, agora para python:

Gerando tráfego de entrada:

No Grafana:

Podemos simular uma latência maior entre as chamadas, aumentando o 'RESPONSE_TIME' no manifesto de deploy, e reaplicar:

# Part of the complete manifest:
spec:
  containers:
  - name: app
    image: paulofponciano/demo-ms-intercomunicacao:latest
    ports:
    - containerPort: 5000
    env:
    - name: TITLE
      value: "Microservice 2"
    - name: RESPONSE_TIME
      value: "3500" # bottleneck
    - name: EXTERNAL_CALL_URL
      value: "http://microservice-3.sample-api-python.svc.cluster.local:5000"
    - name: EXTERNAL_CALL_METHOD
      value: "GET"
# ...

Comparando com o trace anterior (antes da alteração no RESPONSE_TIME), o ponto de gargalo fica visível:

Referências:

Keep shipping! 🐳

ECS Blue/Green com CodePipeline - Provisionado com Terraform

Paulo Ponciano — Sat, 30 Nov 2024 10:13:05 +0000

Arquitetura do Lab

Repositórios:

Terraform: https://github.com/paulofponciano/ecs-with-fargate-and-cicd.git
Demo app: https://github.com/paulofponciano/webapp-color.git

O que usamos como app para demo é um fork de kodekloudhub/webapp-color. No fork foram adicionados os arquivos necessários para o lab com ECS e CodePipeline.

Repositório App demo

No repositório webapp-color, existem arquivos importantes para a execução no CodePipeline, são eles:

Além, é claro, do próprio código da app demo e o Dockerfile que será utilizado no build. Faça um fork do repositório com esses arquivos.

Deploy da infra

git clone https://github.com/paulofponciano/ecs-with-fargate-and-cicd.git

Em variables.tfvars, é importante notar os valores abaixo e alterar antes do apply. Levando em conta que o domínio público já existe no Route 53:

# Trechos extraídos do tfvars
...
site_domain = "myapp.sevira.cloud"
...
github_repo   = "paulofponciano/webapp-color"
github_branch = "master"
...

Agora executamos o terraform para criar toda a estrutura:

tofu init
tofu plan --var-file variables.tfvars
tofu apply --var-file variables.tfvars

Output:

Checando na Console

Integração CodeStar x GitHub

No serviço CodePipeline, vamos até Settings > Connections. É necessário aqui finalizar o setup dessa conexão do CodeStar com GitHub. Selecione a conexão e depois 'Update pending connection':

Selecione 'Install a new app' caso ainda não tenha. Será necessário fazer login no GitHub através da integração e um app será criado. Selecione o app e siga em frente (Connect):

Conexão 'Available':

Primeira execução da pipeline

No CodePipeline, vemos que a execução inicial falhou no stage de Source. Após o setup anterior da conexão CodeStar x GitHub, podemos executar 'Release change' para que a pipeline seja executada novamente:

Dessa vez com a conexão 'Available', a pipeline é executada com sucesso:

Artefatos do CodePipeline no S3:

Agora a aplicação demo está disponível e executando no ECS:

Se olharmos as tasks em execução no ECS, vemos que existem duas (definido em variables.tfvars), com a Task definition na revisão 32:

Em Listener rules do Load balancer, a regra que faz o forward para o Target group no momento está direcionando o tráfego para o Target group 'green'. Iniciamos com essa configuração em 'blue' (feito pelo terraform), mas a pipeline já foi executada com sucesso uma vez.

Subindo uma nova versão da app demo

Na app utilizada para demo, fazemos uma alteração em templates/hello.html, na sequência, enviamos as alterações para o GitHub (git push):

Isso irá acionar novamente a pipeline nos stages de Source, Build e Deploy:

Entendendo os stages

No stage de Source, basicamente o CodePipeline será acionado quando um push for realizado na branch 'master' do repositório que foi definido no setup via terraform. O código é clonado para ser utilizado na pipeline.

O stage de Build (CodeBuild) irá utilizar o arquivo buildspec.yaml do repositório da app demo como receita para o build, onde é gerada uma docker image e feito o push para o ECR.

Imagem no ECR:

No stage final, o de Deploy (CodeDeploy), podemos acompanhar o progresso através do deployment gerado, onde primeiro novas tasks serão criadas no ECS com a nova versão da app demo baseada em uma nova revisão da Task definition (taskdef.json).

Deployment:

Novas tasks executando, com revisão 33. Até esse momento, essas tasks não estão recebendo tráfego do Load balancer:

Nesse próximo step, o CodeDeploy faz um shift do tráfego para as novas tasks, isso através de uma alteração nos Target groups do Load balancer como vimos na primeira execução da pipeline:

Target group após o shift:

Lembrando que o Load balancer estava enviando tráfego para o Target group 'green'. No Target group 'blue', temos as novas tasks (revisão 33) registradas.

Após o período de 5 minutos, as tasks antigas (revisão 32) são colocadas em 'Stopped' e o stage de Deploy é concluído com sucesso:

Todos os stages concluídos:

Checando nova versão da app demo

Acessando novamente, podemos ver que a nova versão da app demo foi entregue e está recebendo tráfego:

Olhando tudo até aqui, vemos que as próximas ações serão focadas em desenvolver a aplicação e enviar o código para o repositório. O restante da entrega ficará por conta do CodePipeline, é assim que deve ser.

E claro, essa pipeline está implementando em um único ambiente (env) ECS, é um lab! Na 'vida real' veremos outros stages como: deploy em dev/qas, testes, aprovações manuais para Production, etc.

Keep shipping! 🐳

Cilium no EKS [Lab Session]

Paulo Ponciano — Sun, 07 Jul 2024 10:54:21 +0000

eBPF-based Networking, Observability, Security
Cilium is an open source, cloud native solution for providing, securing, and observing network connectivity between workloads, fueled by the revolutionary Kernel technology eBPF

Source: https://cilium.io/

Network & Service Mesh (sidecarless)

Source: https://cilium.io/

Arquitetura do Lab

Repositórios:

EKS: https://github.com/paulofponciano/EKS-Cilium
App Microsserviços: https://github.com/msfidelis/nutrition-overengineering

Deploy da infra

git clone https://github.com/paulofponciano/EKS-Cilium.git
cd EKS-Cilium

Altere as variáveis necessárias para o seu lab em variables.tfvars

tofu init
tofu plan --var-file variables.tfvars
tofu apply --var-file variables.tfvars

Por padrão, o EKS vai subir com Amazon VPC CNI, podemos ver o DaemonSet 'aws-node'. No cenário desse lab, removemos esse DaemonSet e fazemos a reciclagem dos nodes - Executando um Terminate nos nodes atuais. Com isso, o EKS vai subir novos nodes para o replace. Como CNI, utilizamos o Cilium.

kubectl get ds -A
kubectl delete ds aws-node -n kube-system

O Terminate dos nodes iniciais pode ser feito na console ou CLI. ⚠️ É importante tomar cuidado nessa ação para não afetar nenhum outro recurso que não seja do lab.

Após a reciclagem dos nodes, podemos ver que está tudo certo no namespace 'kube-system':

Usando o cilium-cli, podemos ver o status do Cilium neste cluster:

cilium status

Se conectarmos diretamente em um node, podemos ver a conflist do Cilium CNI:

Deploy da app

Utilizamos uma app baseada em microsserviços, do grande Matheus Fidelis @fidelissauro. Essa app utiliza gRPC em sua comunicação interna.

git clone https://github.com/msfidelis/nutrition-overengineering.git
cd nutrition-overengineering/samples/cilium

Ajuste o 'host' no manifesto de ingress da health-api se necessário. Aqui ficou assim:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: health-api
  namespace: health-api
spec:
  ingressClassName: cilium
  rules:
  - host: health-api.pauloponciano.digital
    http:
      paths:
      - backend:
          service:
            name: health-api
            port:
              number: 8080
        path: /
        pathType: Prefix

Foi criado manualmente um registro no DNS público apontando o host para o CNAME do Network Load Balancer.

Apply dos manifestos:

kubectl apply -f .

Podemos fazer um teste rápido e ver o retorno da api:

for i in {1..3}
do
  curl --location --request POST 'http://health-api.pauloponciano.digital/calculator' \
  --header 'Content-Type: application/json' \
  --data-raw '{
     "age": 26,
     "weight": 90.0,
     "height": 1.77,
     "gender": "M",
     "activity_intensity": "very_active"
  }' --silent | jq .
done

Hubble UI e Prometheus

Da mesma forma que foi criado o registro no DNS público para a health-api, também foram criados registros para acesso ao hubble-ui e o grafana (o grafana faz parte do kube-prometheus-stack).

Vamos aumentar o volume na health-api utilizando o k6 com o script abaixo:

import http from 'k6/http';

export default function () {
  const url = 'http://health-api.pauloponciano.digital/calculator';
  const payload = JSON.stringify({
    age: 26,
    weight: 90.0,
    height: 1.77,
    gender: 'M',
    activity_intensity: 'very_active',
  });

  const params = {
    headers: {
      'Content-Type': 'application/json',
    },
  };

  const response = http.post(url, payload, params);
  console.log(response.body);
}

k6 run http_k6.js --vus=200 --duration=60m

Agora podemos ver no Hubble as interações entre os serviços muito próximo do real time:

Como ele é interativo, é possível ver mais detalhes das conexões focando em cada componente:

Agora vamos dar uma olhada no Grafana. Quando foi feito o deploy do kube-prometheus-stack via Helm na execução de terraform, também foram importados dois dashboards:

Acessando o dashboard Hubble L7 HTTP Metrics by Workload, podemos ver algumas métricas dos microsserviços.

health-api:

recommendations-grpc:

imc-grpc:

Tetragon e Loki

O Tetragon também é executado como um DaemonSet. Com ele podemos ver as Syscalls que estão acontecendo no ambiente e ele tem a capacidade de fazer enforce. No lab, foi feito deploy do Promtail + Loki, com eles, guardamos esses eventos do Tetragon em um bucket do S3 e podemos visualizar no Grafana.

Tetragon Events dashboard:

Executando aleatoriamente alguns comandos de 'kubectl exec', e com as queries do Loki já configuradas, pegamos alguns eventos que podem ser considerados maliciosos. Isso graças à quantidade de informações que o Tetragon gera:

Recomendo de verdade que assistam à talk do Matheus Fidelis na LINUXtips, mostrando isso ao vivo e com as explicações sobre o poder e as possibilidades que o eBPF proporciona para tecnologias como o Cilium.

Keep shipping! 🐳

Multi-Cluster com Karmada [Lab Session]

Paulo Ponciano — Wed, 15 May 2024 00:46:05 +0000

What is Karmada?

Karmada (Kubernetes Armada) is a Kubernetes management system that enables you to run your cloud-native applications across multiple Kubernetes clusters and clouds, with no changes to your applications. By speaking Kubernetes-native APIs and providing advanced scheduling capabilities, Karmada enables truly open, multi-cloud Kubernetes.

Karmada aims to provide turnkey automation for multi-cluster application management in multi-cloud and hybrid cloud scenarios, with key features such as centralized multi-cloud management, high availability, failure recovery, and traffic scheduling.

Architecture

Source: https://karmada.io

Arquitetura do Lab

Deploy da infra

Cluster 1 ou pegasus:

git clone https://github.com/paulofponciano/EKS-Istio-Karpenter-ArgoCD.git

Altere os valores em variables.tfvars se for necessário.
No arquivo nlb.tf, estamos informando um certificado do ACM. Altere para o seu certificado ou remova comentando as linhas 38, 39, 40 e descomentando a linha 37.

Com certificado:

resource "aws_lb_listener" "ingress_443" {
  load_balancer_arn = aws_lb.istio_ingress.arn
  port              = "443"
  #protocol          = "TCP"
  protocol        = "TLS"
  certificate_arn = "arn:aws:acm:us-east-2:ACCOUNTID:certificate/bfbfe3ce-d347-4c42-8986-f45e95e04ca1"
  alpn_policy     = "HTTP2Preferred"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.https.arn
  }
}

Sem certificado:

resource "aws_lb_listener" "ingress_443" {
  load_balancer_arn = aws_lb.istio_ingress.arn
  port              = "443"
  protocol          = "TCP"
  # protocol        = "TLS"
  # certificate_arn = "arn:aws:acm:us-east-2:ACCOUNTID:certificate/bfbfe3ce-d347-4c42-8986-f45e95e04ca1"
  # alpn_policy     = "HTTP2Preferred"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.https.arn
  }
}

tofu init
tofu plan --var-file variables.tfvars
tofu apply --var-file variables.tfvars

Cluster 2 ou pegasus-2:

git clone https://github.com/paulofponciano/EKS-Istio-Karpenter.git

Altere os valores em variables.tfvars se for necessário.

tofu init
tofu plan --var-file variables.tfvars
tofu apply --var-file variables.tfvars

Deploy do karmada

git clone https://github.com/paulofponciano/karmada.git
cd karmada

Entrando no contexto do cluster pegasus:

aws eks update-kubeconfig --region us-east-2 --name pegasus

Os comandos a seguir serão executados no cluster pegasus (Cluster 1), onde temos o Argo rodando.

helm repo add karmada-charts https://raw.githubusercontent.com/karmada-io/karmada/master/charts
helm repo update
helm --namespace karmada-system upgrade -i karmada karmada-charts/karmada --create-namespace

Verificando o deployment:

kubectl get pods -n karmada-system

Agora já temos o controlplane do karmada rodando no cluster pegasus.

Com o deploy, é gerado um secret com o kubeconfig necessário para conectarmos no controlplane do karmada:

kubectl get secrets -n karmada-system | grep karmada-kubeconfig

kubectl get secret -n karmada-system karmada-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 --decode

Criando IRSA (Iam Role for Service Account)

Altere os valores de ACCOUNTID na iam-policy-irsa-karmada.json e no comando eksctl abaixo.

Isso refletirá em uma Service Account dentro do cluster pegasus, usaremos ela montando em um pod do ubuntu como ponto de acesso temporário ao controlplane do karmada.

aws iam create-policy --policy-name ubuntu-admin-karmada \
  --policy-document file://iam-policy-irsa-karmada.json

eksctl create iamserviceaccount --name ubuntu-admin-karmada \
  --namespace karmada-system \
  --cluster pegasus \
  --attach-policy-arn arn:aws:iam::ACCOUNTID:policy/ubuntu-admin-karmada \
  --region us-east-2 \
  --profile default \
  --approve

No lado AWS, isso reflete em uma IAM role que podemos adicionar nos dois clusters EKS.

EKS IAM - Console (pegasus-2):

Faça o mesmo para o cluster pegasus, onde o karmada controlplane está rodando.

Acessando Karmada API-Server

Vamos subir agora aquele pod do ubuntu-admin no cluster pegasus. No manifesto já está tudo definido para utilizar a Service Account que criamos mais acima.

kubectl apply -f https://raw.githubusercontent.com/paulofponciano/karmada/main/ubuntu-admin-karmada.yaml
kubectl get pods -n karmada-system | grep ubuntu

Nesse momento, vamos entrar no container do ubuntu, que está rodando no cluster pegasus:

kubectl exec -it ubuntu-admin-karmada -n karmada-system -- /bin/bash

Instalando o kubectl karmada:

curl -s https://raw.githubusercontent.com/karmada-io/karmada/master/hack/install-cli.sh | bash -s kubectl-karmada

Entrando no contexto do cluster pegasus-2:

aws eks update-kubeconfig --region us-west-2 --name pegasus-2 --kubeconfig $HOME/.kube/pegasus-2.config
kubectl get nodes --kubeconfig $HOME/.kube/pegasus-2.config

Vamos fazer o mesmo para o cluster pegasus:

aws eks update-kubeconfig --region us-east-2 --name pegasus --kubeconfig $HOME/.kube/pegasus.config
kubectl get nodes --kubeconfig $HOME/.kube/pegasus.config

Checando acesso ao karmada apiserver:

kubectl get all -A --kubeconfig /etc/karmada-kubeconfig/kubeconfig

Join do pegasus-2 no karmada:

kubectl karmada --kubeconfig /etc/karmada-kubeconfig/kubeconfig join pegasus-2 --cluster-kubeconfig=$HOME/.kube/pegasus-2.config

Join do pegasus no karmada:

kubectl karmada --kubeconfig /etc/karmada-kubeconfig/kubeconfig join pegasus --cluster-kubeconfig=$HOME/.kube/pegasus.config

Checando status dos clusters adicionados:

kubectl --kubeconfig /etc/karmada-kubeconfig/kubeconfig get clusters

Instalando CLI do ArgoCD:

curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
rm argocd-linux-amd64

Recuperando o secret / password do Argo server e fazendo login:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

argocd login argocd-server.argocd.svc.cluster.local:80 --username admin

Adicionando o karmada como cluster no ArgoCD:

argocd cluster add karmada-apiserver --kubeconfig /etc/karmada-kubeconfig/kubeconfig --name karmada-controlplane

Deploy com ArgoCD

Se acessarmos a UI do Argo, que está rodando no cluster pegasus, veremos que o karmada está registrado como um cluster onde é possível o Argo fazer deploy:

Podemos agora aplicar um manifesto que irá definir uma nova fonte para o Argo buscar por deploys. Nesse caso, essa fonte é um repositório no GitHub:

kubectl apply -f karmada-argo-app.yaml

Como já temos manifestos nesse repositório (no path /app-manifests), o Argo já faz o sync entregando essas aplicações no controlplane do karmada e o karmada, por sua vez, entrega nos dois clusters de acordo com o que for definido nos manifestos de PropagationPolicy:

No cluster pegasus podemos ver:

kubectl get pods -o wide | grep redis

Cluster pegasus-2:

kubectl get pods -o wide | grep nginx

No caso do deploy do RabbitMQ, podemos ver que existem réplicas rodando nos dois clusters; quando olharmos os arquivos de PropagationPolicy poderemos entender.

kubectl get pods -o wide --context arn:aws:eks:us-east-2:ACCOUNTID:cluster/pegasus | grep rabbitmq

kubectl get pods -o wide --context arn:aws:eks:us-west-2:ACCOUNTID:cluster/pegasus-2 | grep rabbitmq

Karmada OverridePolicy e PropagationPolicy

No repositório que o Argo está monitorando, podemos ver os manifestos do karmada e também os manifestos de deployment que usamos como exemplo.

Exemplo Redis

Regras de override e selector do deployment onde será aplicado, no caso 'redis':

apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
metadata:
  name: redis-op
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: redis
  overrideRules:
    - targetCluster:
        clusterNames:
          - pegasus-2
      overriders:
        labelsOverrider:
          - operator: add
            value:
              env: skoala-dev
          - operator: add
            value:
              env-stat: skoala-stage
          - operator: remove
            value:
              for: for
          - operator: replace
            value:
              bar: test
    - targetCluster:
        clusterNames:
          - pegasus
      overriders:
        annotationsOverrider:
          - operator: add
            value:
              env: skoala-stage
          - operator: remove
            value:
              bom: bom
          - operator: replace
            value:
              emma: sophia

Regras de propagação, selector do deployment e target cluster. Nesse caso de failover, esse deployment deve ser migrado para o cluster pegasus-2 caso o cluster pegasus entre em falha:

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: redis-propagation
spec:
  propagateDeps: true
  failover:
    application:
      decisionConditions:
        tolerationSeconds: 120
      purgeMode: Never
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: redis
  placement:
    clusterAffinity:
      clusterNames:
        - pegasus
        - pegasus-2
    spreadConstraints:
      - maxGroups: 1
        minGroups: 1
        spreadByField: cluster

Exemplo Nginx

apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
metadata:
  name: nginx-op
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  overrideRules:
    - targetCluster:
        clusterNames:
          - pegasus-2
      overriders:
        labelsOverrider:
          - operator: add
            value:
              env: skoala-dev
          - operator: add
            value:
              env-stat: skoala-stage
          - operator: remove
            value:
              for: for
          - operator: replace
            value:
              bar: test

Neste caso, apenas o cluster pegasus-2 foi definido em 'targetCluster':

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - pegasus-2
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
          - targetCluster:
              clusterNames:
                - pegasus-2
            weight: 1

Exemplo RabbitMQ

apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
metadata:
  name: rabbitmq-op
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: rabbitmq
  overrideRules:
    - targetCluster:
        clusterNames:
          - pegasus-2
      overriders:
        labelsOverrider:
          - operator: add
            value:
              env: skoala-dev
          - operator: add
            value:
              env-stat: skoala-stage
          - operator: remove
            value:
              for: for
          - operator: replace
            value:
              bar: test
    - targetCluster:
        clusterNames:
          - pegasus
      overriders:
        annotationsOverrider:
          - operator: add
            value:
              env: skoala-stage
          - operator: remove
            value:
              bom: bom
          - operator: replace
            value:
              emma: sophia

Aqui temos algo diferente, onde os dois clusters são definidos em 'targetCluster', porém com pesos (weights) diferentes, fazendo com que o karmada entregue as réplicas de acordo com o peso de cada cluster:

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: rabbitmq-propagation
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: rabbitmq
  placement:
    clusterAffinity:
      clusterNames:
        - pegasus
        - pegasus-2
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
          - targetCluster:
              clusterNames:
                - pegasus
            weight: 2
          - targetCluster:
              clusterNames:
                - pegasus-2
            weight: 1

Remover ubuntu-admin e IRSA

Podemos deletar o pod ubuntu que usamos para setup do karmada, e também a IRSA:

kubectl delete -f ubuntu-admin-karmada.yaml

eksctl delete iamserviceaccount --name ubuntu-admin-karmada \
  --namespace karmada-system \
  --cluster pegasus \
  --region us-east-2 \
  --profile default

Keep shipping!

Keda com SQS e HTTP Scaler no EKS [Lab Session]

Paulo Ponciano — Tue, 13 Feb 2024 20:13:24 +0000

KEDA is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.
KEDA is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the Horizontal Pod Autoscaler and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.
https://keda.sh/

Keda Architecture

Repositórios

Lab architecture

Deploy do EKS

git clone https://github.com/paulofponciano/EKS-Istio-Karpenter.git
cd EKS-Istio-Karpenter
tofu init
tofu plan --var-file variables.tfvars
tofu apply --var-file variables.tfvars

Utilizando SQS Scaler

Criar fila SQS e IAM policy:

aws sqs create-queue --queue-name keda-sqs --region REGION

aws iam create-policy --policy-name keda-sqs-policy \
  --policy-document file://policy-sqs.json

Criar IAM role para service account (IRSA):

eksctl create iamserviceaccount --name keda-operator \
  --namespace keda \
  --cluster pegasus \
  --attach-policy-arn arn:aws:iam::ACCOUNTID:policy/keda-sqs-policy \
  --region REGION \
  --profile default \
  --approve

kubectl describe sa keda-operator -n keda

Keda deploy via helm:

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda \
  --set serviceAccount.create=false \
  --set serviceAccount.name=keda-operator

Veja que definimos 'create service account' como false, pois já criamos anteriormente e iremos utilizar aquela.

kubectl get pods -n keda

Deployment de teste e ScaledObject:

kubectl apply -f deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment
spec:
  replicas: 0
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx

kubectl apply -f scaledobject.yaml

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: aws-sqs-queue-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    name: nginx-deployment
  minReplicaCount: 0
  maxReplicaCount: 5
  pollingInterval: 5
  cooldownPeriod:  25
  triggers:
  - type: aws-sqs-queue
    metadata:
      queueURL: https://sqs.REGION.amazonaws.com/ACCOUNTID/keda-sqs
      queueLength: "15"
      awsRegion: "REGION"
      identityOwner: operator

Podemos ver que ainda não existe nenhum pod criado pelo deployment que fizemos. Isso porque o número de réplicas é definido em '0' e a fila SQS está vazia, assim o keda não irá acionar a criação:

kubectl get pods | grep nginx

Colocando mensagens na fila SQS:

for i in `seq 35`; do
  aws sqs send-message --queue-url 'https://sqs.REGION.amazonaws.com/ACCOUNTID/keda-queue' \
    --message-body "testmessage" \
    --region REGION \
    --no-cli-pager \
    --output text
done

Agora temos mensagens na fila. No parâmetro 'queueLength' do ScaledObject está definido '15', assim o keda já deve escalar nosso deployment:

kubectl get pods | grep nginx

Assim temos o keda trabalhando no kubernetes de acordo com a demanda na fila SQS.

Utilizando HTTP Scaler

Deploy addon http:

helm install http-add-on kedacore/keda-add-ons-http --namespace keda
kubectl get pods -n keda

Deployment de teste com ingress e ScaledObject:

kubectl apply -f deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-2
  name: nginx-deployment-2
spec:
  replicas: 0
  selector:
    matchLabels:
      app: nginx-2
  template:
    metadata:
      labels:
        app: nginx-2
    spec:
      containers:
      - image: nginx
        name: nginx-2
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service-2
  labels:
    app: nginx-2
    service: nginx-service-2
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: nginx-2
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: nginx-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 443
      name: http
      protocol: HTTP
    hosts:
    - "demo-ingress.pauloponciano.digital"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx
spec:
  hosts:
  - "demo-ingress.pauloponciano.digital"
  gateways:
  - nginx-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: keda-add-ons-http-interceptor-proxy.keda.svc.cluster.local
        port:
          number: 8080

kubectl apply -f http_scaledobject.yaml

kind: HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
metadata:
    name: nginx-http-scaledobject
spec:
    hosts:
    - demo-ingress.pauloponciano.digital
    targetPendingRequests: 1
    scaleTargetRef:
        deployment: nginx-deployment-2
        service: nginx-service-2
        port: 80
    replicas:
        min: 0
        max: 5

Gerando requests com k6:

request.js

import { check } from 'k6';
import http from 'k6/http';

export const options = {
  scenarios: {
    constant_request_rate: {
      executor: 'constant-arrival-rate',
      rate: 100,
      timeUnit: '1s', // 100 iterations per second, i.e. 100 RPS
      duration: '120s',
      preAllocatedVUs: 100, // how large the initial pool of VUs would be
      maxVUs: 100, // if the preAllocatedVUs are not enough, we can initialize more
    },
  },
};

export function test(params) {
  const res = http.get('http://demo-ingress.pauloponciano.digital');
  check(res, {
    'is status 200': (r) => r.status === 200,
  });
}

export default function () {
  test();
}

Executamos o script e podemos observar o keda fazendo o scaling do nosso deployment de acordo com as requisições e com o que foi definido no ScaledObject:

k6 run request.js --vus=1000 --duration=60m

Happy building!

o11y: OpenTelemetry, Prometheus, Loki e Tempo no EKS [Lab Session]

Paulo Ponciano — Thu, 01 Feb 2024 13:20:27 +0000

Loki overview

Grafana Loki documentation

Tempo architecture

Tempo documentation

Lab architecture

Deploy do EKS

tofu init
tofu plan --var-file variables.tfvars
tofu apply --var-file variables.tfvars

IAM Role para Loki e Tempo

Para que o Loki e o Tempo consigam gravar os dados coletados em um bucket S3, é necessário criar uma role contendo a policy com as permissões necessárias. Essa role será acionada via AssumeRole através de uma annotation que definimos nos arquivos values.yaml do loki e do tempo no deploy via helm chart.

Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowLokiandTempoBucketonK8s",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:AbortMultipartUpload",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:GetObjectVersion",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::<loki-bucket-name>/*",
                "arn:aws:s3:::<loki-bucket-name>",
                "arn:aws:s3:::<tempo-bucket-name>/*",
                "arn:aws:s3:::<tempo-bucket-name>"
            ]
        }
    ]
}

Coletando OIDC provider para utilizar na role

aws iam list-open-id-connect-providers

Role

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<ACCOUNT>:oidc-provider/oidc.eks.<REGION>.amazonaws.com/id/<ID>"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.<REGION>.amazonaws.com/id/<ID>:sub": [
                        "system:serviceaccount:o11y:loki-sa",
                        "system:serviceaccount:o11y:tempo-sa"
                    ]
                }
            }
        }
    ]
}

Bucket S3

Conectar no EKS

aws eks update-kubeconfig --region us-east-2 --name pegasus

Agora no repositório da stack de o11y, podemos iniciar os deploys com Helm.

Criar namespace

kubectl create namespace o11y

Deploy promtail

cd promtail
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm upgrade --install promtail grafana/promtail --values values.yaml -n o11y

Deploy Loki

cd loki
helm upgrade --install loki grafana/loki-distributed --values values.yaml -n o11y

Deploy Tempo

cd tempo
helm upgrade --install tempo grafana/tempo-distributed --values values.yaml -n o11y

Deploy Prometheus

cd prometheus-grafana
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm upgrade --install kube-prometheus-stack prometheus-community/kube-prometheus-stack --values values.yaml -n o11y
kubectl apply -f istio-ingress-prometheus.yaml
kubectl apply -f istio-ingress-grafana.yaml

Neste caso, criamos também o ingress para o Prometheus e o Grafana.

Temos agora tudo rodando no cluster:

kubectl get nodes
kubectl get pods -n o11y

Registros no DNS (Route 53)

No DNS externo, criamos alguns registros direcionando para o NLB público, que utilizamos como entrada. Para o Prometheus, Grafana e os apps que vamos utilizar para gerar dados.

Deploy API de exemplo

cd fastapi-observability
kubectl apply -f mono_manifest.yaml

Essa API está utilizando a biblioteca do OpenTelemetry para gerar os spans das operações que compõem os traces.

Prometheus targets

Podemos ver na interface do prometheus que ele já está coletando as métricas que a API de exemplo expõe no /metrics. Lembrando que temos a annotation no manifesto de deployment da API:

annotations:
  prometheus.io/scrape: "true"
  prometheus.io/path: "/metrics"
  prometheus.io/port: "8000"

Grafana

Acessando o grafana, fazemos o import do dashboard que iremos utilizar. user: admin, password: prom-operator. O json do dashboard está em: fastapi-observability/etc/fastapi-dashboard.json

Dashboard importado

Data sources

Esses data sources são criados no momento do deploy da stack prometheus, os valores são informados no values.yaml do helm chart, em 'additionalDataSources'.

Gerando dados com K6

Utilizando o K6, podemos gerar requests na API de exemplo para que os dados sejam gerados e métricas capturadas para visualizarmos.

request.js

import { check } from 'k6';
import http from 'k6/http';

export const options = {
  scenarios: {
    constant_request_rate: {
      executor: 'constant-arrival-rate',
      rate: 100,
      timeUnit: '1s', // 100 iterations per second, i.e. 100 RPS
      duration: '120s',
      preAllocatedVUs: 100, // how large the initial pool of VUs would be
      maxVUs: 100, // if the preAllocatedVUs are not enough, we can initialize more
    },
  },
};

export function test(params) {
  const res = http.get('https://app-a.pauloponciano.digital');
  check(res, {
    'is status 200': (r) => r.status === 200,
  });
}

export default function () {
  test();
}

k6 run request.js --vus=200 --duration=60m

Visualização

Ainda no grafana, no dashboard FastAPI Observability vamos visualizar as métricas, traces e logs da API de exemplo.

References:

Happy building!

Backstage, App template e Crossplane no Amazon EKS [Lab Session]

Paulo Ponciano — Tue, 30 Jan 2024 14:08:06 +0000

Seguindo em mais um lab praticando #platformengineering junto com meu amigo Gabriel Portela, dessa vez explorando mais o Backstage combinado com GitHub Actions, Crossplane, ArgoCD. E claro, rodando no kubernetes.

An open platform for building developer portals
Powered by a centralized software catalog, Backstage restores order to your infrastructure and enables your product teams to ship high-quality code quickly — without compromising autonomy.
https://backstage.io/

Considerações:
Todos os recursos que rodam no kubernetes estão no mesmo cluster para esse lab. O post Serverless com Crossplane composition no EKS + GitOps [Lab Session] pode ajudar no setup do cluster EKS já com ArgoCD e Crossplane. E claro, é possível rodar em qualquer cluster kubernetes.

Nova app backstage

Inicialmente, criamos a app backstage localmente para inicializar o repositório git com a estrutura necessária e criar a primeira imagem docker que, posteriormente, entregaremos no kubernetes.

Documentation on Creating an App Backstage

Building a Docker image | Backstage Software Catalog and Developer Platform

Criando a app:

npx @backstage/create-app@latest

cd backstage

yarn install --frozen-lockfile
yarn tsc

yarn build:backend

Até aqui, tudo default. Neste lab, utilizamos também alguns outros plugins do backstage, então adicionamos:

yarn add --cwd packages/backend @backstage/plugin-kubernetes-backend
yarn add --cwd packages/app @backstage/plugin-kubernetes
yarn add --cwd packages/app @backstage/integration-aws-node
yarn add --cwd packages/app @backstage/plugin-home

Caso siga com o padrão, não é necessário adicionar os plugins acima, porém o código/config que está no repositório do lab precisa deles. Assim, também é necessário modificar no typescript. Seguimos as documentações:

Installation | Backstage Software Catalog and Developer Platform

Backstage homepage - Setup and Customization | Backstage Software Catalog and Developer Platform

@backstage/integration-aws-node | Backstage Software Catalog and Developer Platform

Criando imagem docker e subindo para o DockerHub. Já existe um Dockerfile para build do backend, foi criado junto com a estrutura inicial da app quando rodamos o npx:

docker image build . -f packages/backend/Dockerfile --tag backstage-app

docker images

docker tag db926b361c29 paulofponciano/backstage-app:latest
docker push paulofponciano/backstage-app:latest

Agora basta subir o código para o GitHub. Para facilitar nossa vida, criamos também um workflow para que esse build seja feito de forma automática sempre que subirmos alguma alteração para o repositório:

backstage-app/.github/workflows/master.yaml

name: Main Master Build

on:
  push:
    branches: [main]
    paths-ignore:
      - 'k8s/**'
      - 'catalog-entities/**'

jobs:
  build:
    runs-on: ubuntu-latest

    env:
      CI: true
      NODE_OPTIONS: --max-old-space-size=4096

    steps:
      - uses: actions/checkout@v3

      # Beginning of yarn setup
      - name: use node.js 18.x
        uses: actions/setup-node@v3
        with:
          node-version: 18.x
          registry-url: https://registry.npmjs.org/ # Needed for auth

      - name: cache all node_modules
        id: cache-modules
        uses: actions/cache@v3
        with:
          path: '**/node_modules'
          key: ${{ runner.os }}-node_modules-${{ hashFiles('yarn.lock', '**/package.json') }}

      - name: find location of global yarn cache
        id: yarn-cache
        if: steps.cache-modules.outputs.cache-hit != 'true'
        run: echo "dir=$(yarn config get cacheFolder)" >> $GITHUB_OUTPUT

      - name: cache global yarn cache
        uses: actions/cache@v3
        if: steps.cache-modules.outputs.cache-hit != 'true'
        with:
          path: ${{ steps.yarn-cache.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-

      - name: yarn install
        run: yarn install --immutable
      # End of yarn setup

      - name: type checking and declarations
        run: yarn tsc:full

      - name: build
        run: yarn --cwd packages/backend build

      - name: Login to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USER }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: build image and push to docker hub
        uses: docker/build-push-action@v4
        with:
          context: .
          file: packages/backend/Dockerfile
          push: true
          tags: paulofponciano/backstage:${{ github.sha }}, paulofponciano/backstage:latest

Estamos usando os secrets armazenados em repository secrets do GitHub para conectar ao DockerHub:

GitHub OAuth App

Para autenticação, utilizamos também o GitHub na parte de OAuth Apps.

Basta criar uma nova application (Settings > Developer settings > OAuth Apps). Com isso, teremos um Client ID e Client secrets, que utilizaremos como um secret do kubernetes para o backstage. É necessário informar a Homepage URL e Authorization callback URL:

Manifestos k8s

Criamos um diretório 'k8s' no repositório do backstage para concentrar os manifestos que aplicamos no cluster.

Criar namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: backstage
  labels:
    istio-injection: enabled

Backstage secrets:

# kubernetes/backstage-secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backstage-secrets
  namespace: backstage
type: Opaque
data:
  GITHUB_TOKEN: '' # sample base 64

Este GITHUB_TOKEN é necessário para que o backstage consiga acessar os repositórios onde estão os catálogos, templates, etc. Basta gerar um PAT (Personal access token) e colocar em base 64. No GitHub: Settings > Developer Settings > Personal access tokens (Classic).

Postgres secrets:

apiVersion: v1
kind: Secret
metadata:
  name: postgres-secrets
  namespace: backstage
type: Opaque
data:
  POSTGRES_USER: YmFja3N0YWdl # sample base 64
  POSTGRES_PASSWORD: aHVudGVyMg== # sample base 64

Postgres — Deployment, PVC, Service:

---
# kubernetes/postgres-storage.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgres-storage
  namespace: backstage
  labels:
    type: local
spec:
  storageClassName: gp3
  capacity:
    storage: 2G
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: '/mnt/data'
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-storage-claim
  namespace: backstage
spec:
  storageClassName: gp3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2G
---
# kubernetes/postgres.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
  namespace: backstage
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:13.2-alpine
          imagePullPolicy: 'IfNotPresent'
          ports:
            - containerPort: 5432
          envFrom:
            - secretRef:
                name: postgres-secrets
          volumeMounts:
            - mountPath: /var/lib/postgresql/data
              name: postgresdb
      volumes:
        - name: postgresdb
          persistentVolumeClaim:
            claimName: postgres-storage-claim
---
# kubernetes/postgres-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: postgres
  namespace: backstage
spec:
  selector:
    app: postgres
  ports:
    - port: 5432

GitHub Auth Secrets:

apiVersion: v1
kind: Secret
metadata:
  name: github-auth-secrets
  namespace: backstage
type: Opaque
data:
  AUTH_GITHUB_CLIENT_ID: '' # base 64
  AUTH_GITHUB_CLIENT_SECRET: '' # base 64

Neste informamos o Client ID e Client secret gerados anteriormente, quando criamos o GitHub OAuth App.

Backstage ingestion secret:

kubectl -n kube-system create serviceaccount backstage-ingestion
kubectl create clusterrolebinding backstage-ingestion --clusterrole=cluster-admin --serviceaccount=kube-system:backstage-ingestion

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: backstage-ingestion
  namespace: kube-system
  annotations:
    kubernetes.io/service-account.name: backstage-ingestion
type: kubernetes.io/service-account-token
EOF

kubectl -n kube-system get secret backstage-ingestion -o go-template='{{.data.token | base64decode}}'

A saída desse comando é o Service account token, que utilizamos como SA_TOKEN no plugin de kubernetes do backstage, possibilitando a ingestão dos dados do cluster para o backstage.

EKS secrets:

# kubernetes/eks-secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: eks-secrets
  namespace: backstage
type: Opaque
data:
  SA_TOKEN: '' # base 64
  CA_DATA: '' # base 64

Informamos o SA_TOKEN gerado anteriormente e o certificate authority gerado para o EKS. No secrets como CA_DATA. É possível localizar pela console do EKS:

Backstage — Deployment, SA, Service:

# kubernetes/backstage.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backstage
  namespace: backstage
spec:
  replicas: 1
  selector:
    matchLabels:
      app: backstage
  template:
    metadata:
      labels:
        app: backstage
    spec:
      serviceAccountName: backstage-service-account
      containers:
        - name: backstage
          image: paulofponciano/backstage:latest
          imagePullPolicy: 'Always'
          ports:
            - name: http
              containerPort: 7007
          envFrom:
            - secretRef:
                name: postgres-secrets
            - secretRef:
                name: backstage-secrets
            - secretRef:
                name: github-auth-secrets
            - secretRef:
                name: eks-secrets
          env:
          - name: POSTGRES_PORT
            value: "5432"
          - name: POSTGRES_HOST
            value: "postgres.backstage.svc.cluster.local"
# Uncomment if health checks are enabled in your app:
# https://backstage.io/docs/plugins/observability#health-checks
#          readinessProbe:
#            httpGet:
#              port: 7007
#              path: /healthcheck
#          livenessProbe:
#            httpGet:
#              port: 7007
#              path: /healthcheck
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: backstage-service-account
  namespace: backstage
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: backstage-cluster-ro
subjects:
- namespace: backstage
  kind: ServiceAccount
  name: backstage-service-account
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:aggregate-to-view
---
# kubernetes/backstage-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: backstage
  namespace: backstage
spec:
  selector:
    app: backstage
  ports:
    - name: http
      port: 80
      targetPort: http

Backstage ingress — Istio Gateway, Virtual Service:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: backstage-gateway
  namespace: backstage
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - backstage.pauloponciano.digital
      port:
        name: http
        number: 80
        protocol: HTTP
      tls:
        httpsRedirect: true
    - hosts:
        - backstage.pauloponciano.digital
      port:
        name: https-workloads
        number: 443
        protocol: HTTP
      tls:
        mode: PASSTHROUGH
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backstage
  namespace: backstage
spec:
  gateways:
    - backstage-gateway
  hosts:
    - backstage.pauloponciano.digital
  http:
    - route:
        - destination:
            host: backstage.backstage.svc.cluster.local
            port:
              number: 80
          weight: 100

Backstage app-config.yaml

No repositório do backstage, temos o arquivo app-config.yaml com as configurações e integrações. Até o momento, esse arquivo está default. Para esse lab, deixamos conforme abaixo e fizemos commit e push para o repo, acionando assim um novo build com GitHub Actions (workflow master.yaml) que já criamos.

app:
  title: Community Backstage App
  baseUrl: https://backstage.pauloponciano.digital

organization:
  name: Community

backend:
  baseUrl: https://backstage.pauloponciano.digital
  listen:
    port: 7007
  csp:
    connect-src: ["'self'", 'http:', 'https:']
  cors:
    origin: https://backstage.pauloponciano.digital
    methods: [GET, HEAD, PATCH, POST, PUT, DELETE]
    credentials: true
  database:
    client: pg
    connection:
      host: ${POSTGRES_HOST}
      port: ${POSTGRES_PORT}
      user: ${POSTGRES_USER}
      password: ${POSTGRES_PASSWORD}

integrations:
  github:
    - host: github.com
      token: ${GITHUB_TOKEN}
  aws:
    mainAccount:
    accounts:
      - accountId: ${AWS_ACCOUNT_ID}
        accessKeyId: ${AWS_ACCESS_KEY_ID}
        secretAccessKey: ${AWS_SECRET_ACCESS_KEY}
        region: ${AWS_REGION}

proxy:
  '/test':
    target: 'https://example.com'
    changeOrigin: true
techdocs:
  builder: 'local' # Alternatives - 'external'
  generator:
    runIn: 'docker' # Alternatives - 'local'
  publisher:
    type: 'local' # Alternatives - 'googleGcs' or 'awsS3'. Read documentation for using alternatives.

auth:
  environment: production
  providers:
    github:
      production:
        clientId: ${AUTH_GITHUB_CLIENT_ID}
        clientSecret: ${AUTH_GITHUB_CLIENT_SECRET}

scaffolder:
  defaultAuthor:
    name: ":robot: [backstage-bot]"
    email: paulofponciano@gmail.com

catalog:
  import:
    entityFilename: catalog-info.yaml
    pullRequestBranchName: backstage-integration
  rules:
    - allow: [Component, System, Group, Resource, Location, Template, API]
  locations:
    - type: url
      target: https://github.com/paulofponciano/backstage-app/blob/main/catalog-entities/locations.yaml

kubernetes:
  serviceLocatorMethod:
    type: 'multiTenant'
  clusterLocatorMethods:
    - type: 'config'
      clusters:
        - url: https://api-server-endpoint.gr7.us-east-2.eks.amazonaws.com
          name: pegasus # cluster name
          authProvider: 'serviceAccount'
          skipTLSVerify: false
          skipMetricsLookup: true
          serviceAccountToken: ${SA_TOKEN}
          caData: ${CA_DATA}
          customResources:
            - group: 'api.pauloponciano.digital' # Crossplane
              apiVersion: 'v1alpha1'
              plural: 'xcustomdatabases'
            - group: 'api.pauloponciano.digital' # Crossplane
              apiVersion: 'v1alpha1'
              plural: 'xcustomorders'

Backstage

Após finalizar a etapa anterior com sucesso no build, aplicamos todos os manifestos k8s no cluster. Pode ser feito em sequência:

kubectl apply -f backstage_ns.yaml
kubectl apply -f backstage_secrets.yaml
kubectl apply -f postgres_secrets.yaml
kubectl apply -f postgres.yaml
kubectl apply -f github_auth_secrets.yaml
kubectl apply -f eks_secrets.yaml
kubectl apply -f backstage.yaml
kubectl apply -f backstage_istio_ingress.yaml

Como criamos um CNAME em um DNS Público apontando para o NLB de entrada do istio, já podemos acessar o backstage:

Já temos alguns componentes que foram registrados na subida da app:

Esse import vem por esse bloco do app-config.yaml. Algumas dessas entidades no catálogo já não são default, mas servem de exemplo. Podem encontrá-las aqui.

catalog:
  import:
    entityFilename: catalog-info.yaml
    pullRequestBranchName: backstage-integration
  rules:
    - allow: [Component, System, Group, Resource, Location, Template, API]
  locations:
    - type: url
      target: https://github.com/paulofponciano/backstage-app/blob/main/catalog-entities/locations.yaml

GitHub Organization

Criamos uma Organization no GitHub para centralizar os repositórios de templates de apps, gitops (ArgoCD) e workflows reutilizáveis (GitHub Actions). Os repositórios criados pelo backstage com base nos templates para novas apps também ficam na organização:

Definimos também os secrets a nível de organização para utilizar nos workflows. Neste momento, o GH_PAT é o mesmo Personal access token que criamos para passar no secrets do kubernetes:

ArgoCD

O ArgoCD é o recurso central para as entregas no cluster EKS, nos permitindo utilizar a estratégia de GitOps. Assim, conectamos o Argo ao repositório 'gitops' da organização com a estrutura abaixo:

deployed_apps/applications
deployed_infra/system:default

Utilizamos esse manifesto para criar as applications, project e conectar ao repositório:

apiVersion: v1
kind: Secret
metadata:
  name: public-repo-gitops
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/paulofponciano-idp/gitops.git
---
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: idp
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  description: Internal Developer Portal
  sourceRepos:
    - 'https://github.com/paulofponciano-idp/gitops.git'
  destinations:
    - namespace: '*'
      server: 'https://kubernetes.default.svc'
      name: 'in-cluster'
  clusterResourceWhitelist:
    - group: '*'
      kind: '*'
  namespaceResourceWhitelist:
    - group: '*'
      kind: '*'
  orphanedResources:
    warn: true
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: idp-infra-aws
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: idp
  source:
    repoURL: https://github.com/paulofponciano-idp/gitops.git
    targetRevision: HEAD
    path: deployed_infra/system:default
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
      allowEmpty: true
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: idp-apps
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: idp
  source:
    repoURL: https://github.com/paulofponciano-idp/gitops.git
    targetRevision: HEAD
    path: deployed_apps/applications
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
      allowEmpty: true

Template GO (Backstage fetch:template)

No repositório go-template-backstage da organização, temos uma estrutura padrão como exemplo para uma aplicação em golang. Esse repositório serve como template para o backstage quando algum consumidor acionar a criação de uma nova app.

Uma parte importante desse template é o workflow que também será utilizado no momento em que o backstage realizar o fetch e criar um novo repositório (push). Esse workflow é responsável por acionar outros workflows (workflow_call) que estão no repositório .github da organização.

Do lado do backstage utilizamos o template app-go.yaml abaixo, que guardamos no próprio repositório do backstage nesse caso:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: golang-template
  title: Golang Template
  description: Create a new Golang App

  tags:
    - golang
    - website
    - component
spec:
  owner: group:sre
  type: component

  parameters:
    - title: Provide some simple information
      required:
        - component_id
        - system
        - lifecycle
        - owner
        - type
      properties:
        component_id:
          title: Name
          type: string
          pattern: "^([a-z0-9\\-]+)$"
          description: Unique name of the component
          ui:field: EntityNamePicker
          ui:autofocus: true
        description:
          title: Description
          type: string
          description: Help others understand what this website is for.
        system:
          title: System
          type: string
          description: System of the component
          ui:field: EntityPicker
          ui:options:
            allowedKinds:
              - System
            defaultKind: System
        lifecycle:
          title: Lifecycle
          description: 'Application lifecycle'
          type: string
          default: experimental
          enum:
            - deprecated
            - experimental
            - production
        type:
          title: Type
          description: 'Application type'
          type: string
          default: service
          enum:
            - service
            - website
            - library
        owner:
          title: Owner
          type: string
          description: Owner of the component
          ui:field: OwnerPicker
          ui:options:
            allowedKinds:
              - Group

    - title: Choose a location
      required:
        - repoUrl
      properties:
        repoUrl:
          title: Repository Location
          type: string
          ui:field: RepoUrlPicker
          ui:options:
            allowedHosts:
              - github.com
            allowedOwners:
              - paulofponciano-idp

    - title: Infrastructure
      properties:
        kube:
          title: Create Kubernetes App
          description: Checking this will also create Kubernetes App
          type: boolean
          default: false
        env:
          title: Environment
          description: 'Environment to create resources'
          type: string
          default: dev
          enum:
            - dev
            - stg
            - prd
        dryRun:
          title: Only perform a dry run, don't publish anything
          type: boolean
          default: false

  steps:
    - id: template
      name: Fetch Application Template on GitHub Repo
      action: fetch:template
      cookiecutterCompat: true
      input:
        url: https://github.com/paulofponciano-idp/go-template-backstage
        copyWithoutTemplating:
          - .github/workflows/*
        values:
          component_id: ${{ parameters.component_id }}
          system: ${{ parameters.system }}
          description: ${{ parameters.description }}
          destination: ${{ parameters.repoUrl | parseRepoUrl }}
          owner: ${{ parameters.owner }}
          lifecycle: ${{ parameters.lifecycle }}
          type: ${{ parameters.type }}
          env: ${{ parameters.env}}

    - id: publish
      name: Publish Application
      action: publish:github
      if: ${{ parameters.dryRun !== true }}
      input:
        allowedHosts:
          - github.com
        description: This is ${{ parameters.component_id }}
        repoUrl: ${{ parameters.repoUrl }}
        defaultBranch: main
        repoVisibility: public
        collaborators:
          - team: sre
            access: maintain
          - team: ${{ parameters.owner }}
            access: push

    - id: fetch-kube
      name: Fetch Kubernetes Template
      action: fetch:template
      if: ${{ parameters.kube == true }}
      input:
        targetPath: ./kube
        url: https://github.com/paulofponciano/backstage-app/tree/main/catalog-entities/skeleton/kubernetes/apps/kustomize
        values:
          component_id: ${{ parameters.component_id }}
          description: ${{ parameters.description }}
          destination: ${{ parameters.repoUrl | parseRepoUrl }}
          owner: ${{ parameters.owner }}

    - id: kube-pr
      name: "Open PR in GitOps Repository"
      action: publish:github:pull-request
      if: ${{ parameters.kube == true }}
      input:
        repoUrl: github.com?repo=gitops&owner=paulofponciano-idp
        branchName: create-${{ parameters.component_id }}
        title: ':robot: [backstage-bot] Create new App ${{ parameters.component_id }}'
        description: |
          # New project: ${{ parameters.component_id }}
          ${{ parameters.description if parameters.description }}
        sourcePath: kube
        targetPath: deployed_apps

    - id: register
      name: Register Application in Catalog
      action: catalog:register
      if: ${{ parameters.dryRun !== true }}
      input:
        repoContentsUrl: ${{ steps['publish'].output.repoContentsUrl }}
        catalogInfoPath: "/catalog-info.yaml"

  output:
    links:
      - title: Go to Repository
        url: ${{ steps['publish'].output.repoContentsUrl }}
      - title: Go to GitOps Pull Request
        url: ${{ steps.kube-pr.output.remoteUrl }}
      - title: Open in catalog
        icon: catalog
        entityRef: ${{ steps['register'].output.entityRef }}

Skeleton k8s (Backstage fetch:template)

No passo anterior, cuidamos do template de aplicação e das ações do backstage no momento de criar essa nova aplicação. Como essa app é entregue (argocd) e opera no kubernetes, precisamos também do 'esqueleto' para os manifestos. Guardamos o skeleton aqui com essa estrutura:

Registrar template GO no Backstage

Registrar o template é um processo simples, apenas informar a url e importar:

Criando nova app (go) através do Backstage

Validamos agora tudo que foi criado até o momento, buscando o fluxo que desenhamos:

Input das informações:

Aprovar pull-request no repositório de GitOps:

Podemos ver o replace das informações que passamos dentro dos manifestos que o backstage pegou no diretório de 'skeleton'; esses manifestos agora estão no diretório 'deployed_apps' de GitOps.

Checando o novo repositório da app e workflow de first-release:

O workflow de first-release é acionado no momento do push que o backstage faz para criação do novo repositório. Este, por sua vez, faz a chamada (workflow_call) dos workflows reutilizáveis de env, build e deploy:

Checando o sync no ArgoCD, vemos que a nova app já está sendo entregue no cluster:

Agora em nosso Backstage Catalog, temos o novo componente registrado. Podemos visualizar os detalhes:

Detalhes dos recursos no kubernetes relacionados à aplicação:

Detalhes de CI/CD do GitHub Actions:

Acessando a app de exemplo:

Backstage + Crossplane para provisionar recursos

Levando em conta que já temos o crossplane rodando no cluster EKS como parte do setup da infraestrutura, podemos utilizá-lo no cenário de provisionamento de recursos junto ao backstage, neste lab usando AWS como provider. A estratégia é a mesma, utilizar o backstage para fazer o input das informações que serão passadas em um manifesto (claim) e entregar com ArgoCD.

Registrar o template de rds no backstage:

Skeleton do claim para composition de rds:

# CLAIM
---
apiVersion: api.pauloponciano.digital/v1alpha1
kind: CustomDatabase
metadata:
  name: ${{values.name}}-${{values.env}}-${{values.engine}}-db
  namespace: environment-crossplane
  labels:
    backstage.io/kubernetes-id: rds
spec:
  compositionSelector:
    matchLabels:
      db-engine: ${{values.engine}}
  resourceConfig:
    providerConfigName: aws
    region: ${{values.region}}
    size: ${{values.size}}
    engine: ${{values.engine}}
    tags:
      automation-by: crossplane
      ownerName: ${{values.owner}}

Composition e definition já devem estar aplicadas no cluster para o crossplane. Podem encontrá-las aqui.

Input das informações:

Aprovar pull-request no repositório de GitOps:

Checando o sync no ArgoCD, na application 'idp-infra-aws':

No catálogo do backstage, podemos checar que a composite do crossplane foi criada no cluster:

Olhando na console AWS, podemos confirmar a criação do recurso:

Com isso, podemos ver as grandes possibilidades e facilidades que o backstage, combinado com outras soluções, pode trazer para os times de uma organização.

Agradecimento a todos que publicam conteúdos abertos para fortalecer a comunidade, e que ajudaram muito nesse lab.

Happy building!

IDP port e Crossplane composition no Amazon EKS [Lab Session]

Paulo Ponciano — Tue, 30 Jan 2024 11:14:11 +0000

Seguindo em mais um lab, este de certa forma é uma continuação do Serverless com Crossplane composition no EKS + GitOps [Lab Session]. Vamos adicionar mais alguns elementos, um deles é o Internal Developer Portal (IDP) port. O IDP nos permite abstrair muitos elementos subjacentes, proporcionando aos consumidores maior foco em suas entregas finais.

É claro, ainda é necessário manter esses 'elementos subjacentes' assim como a própria abstração dos mesmos. Esse normalmente é o trabalho do time de Engenharia de Plataforma.

Arquitetura do Lab

Vamos utilizar a mesma composition do crossplane que entrega uma arquitetura serverless na AWS. Desta vez, o input das informações não será diretamente em um yaml de claim e sim no IDP port.

Com crossplane, o yaml utilizado para o claim já é bem enxuto; utilizando um IDP isso fica ainda mais simples para o consumidor.

Repositórios:

https://github.com/paulofponciano/EKS-Crossplane-ArgoCD.git

Port blueprints e actions

No DevPortal Builder do port, vamos criar os blueprints Cluster, Namespace e Order (stack serverless AWS). Blueprints são utilizados como modelos de dados dos nossos elementos e permitem a composição dos catálogos.

app.getport.io

Os arquivos json utilizados estão em port/blueprints do repositório.

Cluster blueprint:

{
  "identifier": "cluster",
  "description": "This blueprint represents a Kubernetes Cluster",
  "title": "Cluster",
  "icon": "Cluster",
  "schema": {
    "properties": {},
    "required": []
  },
  "mirrorProperties": {},
  "calculationProperties": {},
  "relations": {}
}

Namespace blueprint:

{
    "identifier": "namespace",
    "description": "This blueprint represents a k8s Namespace",
    "title": "Namespace",
    "icon": "Environment",
    "schema": {
      "properties": {
        "creationTimestamp": {
          "type": "string",
          "title": "Created",
          "format": "date-time",
          "description": "When the Namespace was created"
        },
        "labels": {
          "type": "object",
          "title": "Labels",
          "description": "Labels of the Namespace"
        }
      }
// Removed for brevity

Order blueprint:

{
  "identifier": "order",
  "description": "This blueprint represents an Order App",
  "title": "Order",
  "icon": "Microservice",
  "schema": {
    "properties": {
      "provider": {
        "icon": "AWS",
        "title": "Provider",
        "description": "The provider where the app is deployed",
        "type": "string",
        "default": "n/a",
        "enum": [
          "default",
          "n/a"
        ],
        "enumColors": {
          "default": "lightGray",
          "n/a": "lightGray"
        }
      }
// Removed for brevity

Resultado:

Agora vamos criar as actions do blueprint Order. As actions serão responsáveis por acionar o GitHub Actions em eventos de CREATE e DELETE. Podemos editar o blueprint e inserir o json port/actions do repositório em 'Actions':

Este é o trecho em que informamos o workflow que será acionado em cada action:

// Removed for brevity
"invocationMethod": {
      "type": "GITHUB",
      "omitPayload": true,
      "omitUserInputs": false,
      "reportWorkflowStatus": true,
      "org": "paulofponciano",
      "repo": "EKS-Crossplane-ArgoCD",
      "workflow": "create-order-app.yaml"
    },
    "trigger": "CREATE",
    "description": "Create an Order App",
    "requiredApproval": false
  }
// Removed for brevity

Na primeira integração, é necessário conectar o port ao GitHub para que ele possa acionar os workflows — GitHub app installation:

Agora em Self-Service já temos as actions de Create e Delete para a composition do crossplane:

GitHub Actions

Os workflows do GitHub Actions serão responsáveis por receber os inputs enviados no payload do port quando as actions são executadas. Esses inputs são passados no manifesto de claim da composition do crossplane e é feito o commit desse manifesto em um repositório monitorado pelo ArgoCD (deployed_infra):

.github/workflows/create-order-app.yaml

name: Create an order app
on:
  workflow_dispatch:
    inputs:
      name:
        required: true
        description: "The name of the app"
      provider:
        required: true
        description: "The provider where the app is deployed"
        default: "aws"
      region:
        required: true
        description: "The provider region"
        default: "us-east-1"
      ownerName:
        required: true
        description: "The owner name"
        default: "ownerName"
      projectName:
        required: true
        description: "The project name"
        default: "projectName"
jobs:
  deploy-app:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          persist-credentials: false
          fetch-depth: 0

      - name: Create an order app
        run: |
          chmod +x scripts/create-app-order.sh
          ./scripts/create-app-order.sh ${{ inputs.name }} ${{ inputs.provider }} ${{ inputs.region }} ${{ inputs.ownerName }} ${{ inputs.projectName }}

      - name: Commit changes
        run: |
          git config --local user.email "github-actions[bot]@users.noreply.github.com"
          git config --local user.name "github-actions[bot]"
          git add .
          git commit -a -m "Create app order ${{ inputs.name }}"

      - name: push
        uses: ad-m/github-push-action@master

scripts/create-app-order.sh

NAME=$1
PROVIDER=$2
REGION=$3
OWNER=$4
PROJECT=$5

FILE_PATH=deployed_infra/${NAME}.yaml

cp crossplane_compositions/order/order-claim-port.yaml $FILE_PATH
yq --inplace ".metadata.name = \"${NAME}\"" $FILE_PATH
yq --inplace ".spec.resourceConfig.providerConfigName = \"${PROVIDER}\"" $FILE_PATH
yq --inplace ".spec.resourceConfig.region = \"${REGION}\"" $FILE_PATH
yq --inplace ".spec.resourceConfig.tags.ownerName = \"${OWNER}\"" $FILE_PATH
yq --inplace ".spec.resourceConfig.tags.projectName = \"${PROJECT}\"" $FILE_PATH

.github/workflows/delete-order-app.yaml

name: Delete an order app
on:
  workflow_dispatch:
    inputs:
      name:
        required: true
        description: "The name of the app"
jobs:
  delete-app:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          persist-credentials: false
          fetch-depth: 0

      - name: Delete an order app
        run: |
          rm deployed_infra/${{ inputs.name }}.yaml

      - name: Commit changes
        run: |
          git config --local user.email "github-actions[bot]@users.noreply.github.com"
          git config --local user.name "github-actions[bot]"
          git add .
          git commit -a -m "Delete app order ${{ inputs.name }}"

      - name: push
        uses: ad-m/github-push-action@master

ArgoCD

Criamos uma application no ArgoCD, definindo como source o repo/path onde teremos o commit do manifesto feito pelo workflow do GitHub Actions:

apiVersion: v1
kind: Secret
metadata:
  name: public-repo-crossplane
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/paulofponciano/EKS-Crossplane-ArgoCD.git
---
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: idp
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  description: Internal Developer Portal
  sourceRepos:
    - 'https://github.com/paulofponciano/EKS-Crossplane-ArgoCD.git'
  destinations:
    - namespace: '*'
      server: 'https://kubernetes.default.svc'
      name: 'in-cluster'
  clusterResourceWhitelist:
    - group: '*'
      kind: '*'
  namespaceResourceWhitelist:
    - group: '*'
      kind: '*'
  orphanedResources:
    warn: true
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: idp-infra-aws
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: idp
  source:
    repoURL: https://github.com/paulofponciano/EKS-Crossplane-ArgoCD.git
    targetRevision: HEAD
    path: deployed_infra
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
      allowEmpty: true

kubectl apply -f argocd/application.yaml

Port k8s-exporter

O k8s-exporter permite que o port possa ingerir de volta os dados dos recursos criados pelo crossplane no cluster kubernetes, assim podendo alimentar o catálogo do IDP.

Port Documentation - Kubernetes

Precisamos das credenciais de API do port para instalação via helm no cluster. Essas credenciais já existem no port, vamos apenas utilizá-las como variáveis na instalação:

Antes de executar a instalação via helm, precisamos informar no arquivo config.yaml os atributos para que os recursos criados sejam 'reconhecidos' como entidades, assim serão exportados para o port:

# Removed for brevity
- kind: api.pauloponciano.pro/v1alpha1/customorder
  selector:
    query: .metadata.namespace | startswith("environment")
  port:
    entity:
      mappings:
        - identifier: .metadata.name + "-" + .metadata.namespace + "-" + "paulop"
          title: .metadata.name
          icon: '"Microservices"'
          blueprint: '"order"'
          properties:
            provider: .spec.resourceConfig.providerConfigName
            region: .spec.resourceConfig.region
            ownerName: .spec.resourceConfig.tags.ownerName
            projectName: .spec.resourceConfig.tags.projectName
            labels: .metadata.labels
            annotations: .metadata.annotations
          relations:
            Namespace: .metadata.namespace + "-" + "paulop"

Instalação:

helm repo add port-labs https://port-labs.github.io/helm-charts

helm upgrade --install port-k8s-exporter port-labs/port-k8s-exporter \
    --create-namespace --namespace port-k8s-exporter \
    --set secret.secrets.portClientId=$CLIENT_ID --set secret.secrets.portClientSecret=$CLIENT_SECRET \
    --set-file configMap.config=config.yaml

Agora já podemos verificar o que está sendo ingerido e apresentado no catálogo do port:

Não temos nada em Orders porque ainda não criamos uma, calma jovem! Faremos isso da mesma forma que o usuário fará.

Usando o Self-Service

CREATE

Na área de self-service do port, vamos executar a action de CREATE, fazendo os inputs necessários para o claim da composition do crossplane:

Sucesso da execução da action:

Sucesso na execução do workflow de create no GitHub Actions:

O manifesto de claim foi criado com os inputs feitos através do IDP:

O ArgoCD fez a entrega do claim no cluster kubernetes que já possui a composition e definition do crossplane, assim os recursos da stack são criados na AWS:

Voltando ao catálogo do port, em Orders:

AWS stack serverless:

DELETE

Vamos agora executar a action de DELETE, também pelo IDP:

Workflow de delete:

ArgoCD prune resources:

Happy building!

References:

DevOps Toolkit

Serverless com Crossplane composition no EKS + GitOps [Lab Session]

Paulo Ponciano — Tue, 30 Jan 2024 10:41:26 +0000

Build control planes without needing to write code. Crossplane has a highly extensible backend that enables you to orchestrate applications and infrastructure no matter where they run, and a highly configurable frontend that lets you define the declarative API it offers.
https://www.crossplane.io/

Crossplane Introduction

Source: https://docs.crossplane.io/latest/getting-started/introduction/

Neste lab vamos provisionar a arquitetura serverless abaixo na AWS utilizando uma composition do Crossplane. Tudo é provisionado como código e, com o Crossplane, os componentes/serviços AWS se tornam recursos dentro do Kubernetes e são gerenciados como tal.

Além da composition, que serve como um template para criação de vários recursos gerenciados de uma só vez (stack na imagem abaixo), criamos também os managed resources, que são os recursos gerenciados de uma forma mais 'individual'. Adicionamos as funcionalidades do ArgoCD para GitOps neste cenário de managed resources.

Repositórios:

https://github.com/paulofponciano/EKS-Crossplane-ArgoCD.git

O código node.js das funções lambda que utilizamos, bem como o pattern, é trabalho disponível no https://serverlessland.com/.

Deploy Amazon EKS — Cluster de gerenciamento

O cluster EKS e toda infra necessária para ele (vpc, nlb, etc.) nós subimos com terraform. Nesse deploy também subimos o crossplane via helm:

terraform init
terraform plan --var-file variables.tfvars
terraform apply --var-file variables.tfvars

Conectando no cluster provisionado:

aws eks --region us-east-2 update-kubeconfig --name pegasus

Listando os pods do crossplane e providers:

kubectl get pods -n crossplane-system

Deploy Crossplane composition

Primeiro criamos um secret para utilizar no ProviderConfig do crossplane:

kubectl create secret \
generic aws-secret \
-n crossplane-system \
--from-file=creds=./cred.txt

No arquivo cred.txt existente na raiz do repositório, temos as informações de access key e secret key da AWS. O crossplane precisa dessas credenciais para provisionar os recursos.

Criando o ProviderConfig:

cat <<EOF | kubectl apply -f -
apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: aws-secret
      key: creds
EOF

Reference: https://docs.crossplane.io/latest/getting-started/provider-aws/

Agora vamos aplicar no cluster a composition e definition da stack serverless:

kubectl apply -f composition.yaml
kubectl apply -f definition.yaml

Neste ponto, temos nosso template pronto no cluster para ser acionado. Fazemos isso através do claim. O claim pode ser a única interação necessária para o usuário/desenvolvedor, sendo um yaml extremamente enxuto. No final das contas, todas as definições e guardrails estão no template (composition.yaml e definition.yaml).

composition.yaml

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: order.pauloponciano.pro
spec:
  compositeTypeRef:
    apiVersion: api.pauloponciano.pro/v1alpha1
    kind: XCustomOrder
  patchSets:
    - name: common-fields
      patches:
        - type: FromCompositeFieldPath
          fromFieldPath: spec.resourceConfig.providerConfigName
          toFieldPath: spec.providerConfigRef.name
        - type: FromCompositeFieldPath
          fromFieldPath: spec.resourceConfig.region
          toFieldPath: spec.forProvider.region
  resources:
## API GATEWAY
    - name: order-api-gateway
      base:
        apiVersion: apigateway.aws.upbound.io/v1beta1
        kind: RestAPI
# Removed for brevity

definition.yaml

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xcustomorders.api.pauloponciano.pro
spec:
  group: api.pauloponciano.pro
  names:
    kind: XCustomOrder
    plural: xcustomorders
  claimNames:
    kind: CustomOrder
    plural: customorders
  versions:
  - name: v1alpha1
    served: true
    referenceable: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              resourceConfig:
                  description: ResourceConfig defines general properties of this AWS
                    resource.
                  properties:
                    providerConfigName:
                      type: string
                    region:
                      type: string
                      oneOf:
                        - pattern: 'us-east-2'
                        - pattern: 'us-east-1'
# Removed for brevity

Aplicando o claim.yaml:

apiVersion: api.pauloponciano.pro/v1alpha1
kind: CustomOrder
metadata:
  name: order-composition
  namespace: default
spec:
  resourceConfig:
    providerConfigName: default
    region: us-east-1
    tags:
      ownerName: SRE
      projectName: PE

kubectl apply -f claim.yaml

Agora a composite CustomOrder será provisionada. Podemos ver:

kubectl get composite

kubectl describe composite order-composition-qmfjw

kubectl get managed

Caso algum desses recursos seja deletado, via console AWS por exemplo, o crossplane vai identificar e provisionar novamente… reconciliation process!

Testando a stack serverless

Vamos fazer um describe para identificar a URL de invocação da API Gateway:

kubectl describe deployment.apigateway.aws.upbound.io/order-composition-qmfjw-k9p95

Fazemos vários POST's na API Gateway no /order, neste caso usando Thunder Client no VS Code:

{
  "restaurantName": "calabresoPizza",
  "order": "samplePizza",
  "customerName": "Paulo",
  "amount": "10"
}

Podemos ver que a lambda de putOrder foi invocada pela API Gateway:

Logs:

Na rule do EventBridge, estamos esperando o event pattern abaixo para invocar a outra lambda, definida como target:

Podemos ver em 'Monitoring' da rule que ela foi acionada após nossos POST's na API Gateway e também invocou a outra lambda:

Lambda consumer:

Logs:

Crossplane managed resources — GitOps com ArgoCD

Adicionamos uma application no Argo, baseada no mesmo repositório que usamos até agora, porém no path crossplane_managed/vpc.

São os recursos para construção de uma VPC, mas dessa vez não como uma 'composition' do crossplane.

Deixamos o Argo fazer o deploy:

Vamos olhar no kubernetes:

kubectl get vpc

kubectl get managed

Além do controller do crossplane, contamos com o Argo para sempre manter o estado desejado dos recursos no cluster.

Happy building!