Codelab "Eventos do Cloud Run for Anthos"

1. Introdução

6a5cf23c8e20491f.png

O Cloud Run permite executar contêineres sem estado em um ambiente totalmente gerenciado. Ele foi criado com base no Knative de código aberto, permitindo que você execute seus contêineres de forma totalmente gerenciada com o Cloud Run ou em um cluster do Google Kubernetes Engine com o Cloud Run for Anthos.

Os Eventos do Cloud Run for Anthos facilitam a conexão dos serviços do Cloud Run com eventos de diversas fontes. Ele permite criar arquiteturas orientadas a eventos em que os microsserviços são acoplados com flexibilidade e distribuídos. Ele também cuida da ingestão, da entrega, da segurança, da autorização e do tratamento de erros de eventos para você, o que melhora a agilidade do desenvolvedor e a resiliência de aplicativos.

Neste codelab, você aprenderá sobre eventos do Cloud Run for Anthos. Mais especificamente, você vai detectar eventos do Cloud Pub/Sub, de registros de auditoria, do Cloud Storage e do Cloud Scheduler e como produzir/consumir eventos personalizados.

O que você vai aprender

  • Visão de longo prazo dos eventos do Cloud Run for Anthos
  • Estado atual dos eventos do Cloud Run for Anthos
  • Crie um coletor do Cloud Run
  • Criar um gatilho de evento para o Cloud Pub/Sub
  • Criar um gatilho de evento para registros de auditoria
  • Criar um gatilho de evento para o Cloud Storage
  • Criar um gatilho de evento para o Cloud Scheduler
  • Produza e consuma eventos personalizados

2. Visão de longo prazo

À medida que adotamos a arquitetura sem servidor, os eventos se tornam uma parte essencial da forma como os microsserviços separados se comunicam. Os eventos do Cloud Run for Anthos tornam os eventos um cidadão de primeira classe da oferta do Cloud Run for Anthos, facilitando a criação de aplicativos sem servidor orientados a eventos.

O Eventos do Cloud Run for Anthos possibilita a entrega assíncrona, segura e escalonável de eventos de fontes de eventos empacotadas ou criadas por apps para consumidores dentro e fora do cluster.

ce389bcafba6d669.png

Origens do Google Cloud

Origens de eventos que são produtos do Google Cloud

Fontes do Google

Origens de eventos que são produtos do Google, como Gmail, Hangouts, Gerenciamento do Android e muito mais

Origens personalizadas

Origens de eventos que não são produtos do Google e são criadas pelos próprios usuários finais. Podem ser fontes Knative desenvolvidas pelo usuário ou qualquer outro app em execução no cluster que possa produzir um evento do Cloud.

Fontes de terceiros

Origens de eventos que não são do Google nem do usuário final. Isso inclui fontes de eventos conhecidas, como GitHub, SAP, Datadog, Pagerduty etc. que pertencem e são mantidos por provedores terceirizados, parceiros ou comunidades de OSS.

Os eventos são normalizados para o formato CloudEvents v1.0 para interoperabilidade entre serviços. O CloudEvents é uma especificação aberta independente de fornecedor que descreve dados de eventos em formatos comuns, permitindo a interoperabilidade entre serviços, plataformas e sistemas.

Os eventos do Cloud Run seguem o Knative Eventing e permitem a portabilidade de contêineres de e para outras implementações baseadas no Knative. Isso fornece um framework consistente e independente da nuvem para conectar de maneira declarativa os produtores de eventos aos consumidores do evento.

3. Estado atual

Essa prévia é a primeira versão que oferece um conjunto inicial da funcionalidade de longo prazo.

b1dd0d8a73185b95.png

Para permitir que os usuários criem aplicativos sem servidor orientados a eventos, nosso foco inicial é em duas partes:

  1. Fornecer um amplo ecossistema de fontes do Google Cloud que permitem que os serviços do Cloud Run no cluster do Anthos reajam a eventos dos serviços do Google Cloud.
  • No início, os eventos das origens do Google Cloud são entregues com os Registros de auditoria do Cloud (CAL), o que permite várias origens de eventos. A latência e a disponibilidade da entrega de eventos dessas origens estão vinculadas às dos Registros de auditoria do Cloud. Sempre que um evento de uma fonte do Google Cloud é publicado, uma entrada correspondente no registro de auditoria do Cloud é criada.
  • Além dos Registros de auditoria do Cloud, há suporte de primeira classe para consumir eventos do Cloud Storage, Cloud Pub/Sub e Cloud Scheduler. Vamos continuar ampliando esse ecossistema de fontes com mais fontes de primeira classe à medida que aprendermos mais com as jornadas dos usuários e com o feedback.
  1. Ative aplicativos e serviços do usuário final para emitir eventos personalizados publicando em um URL de agente local de cluster com escopo de namespace.

O mecanismo de entrega subjacente usa tópicos e assinaturas do Cloud Pub/Sub que estão visíveis no projetos. Portanto, o recurso oferece as mesmas garantias de entrega que o Cloud Pub/Sub.

O acionador de evento oferece uma maneira de se inscrever em eventos para que os eventos correspondentes ao filtro do acionador sejam entregues ao destino (ou coletor) para o qual o acionador aponta.

Todos os eventos são entregues no formato Cloud Events v1.0 para interoperabilidade entre serviços.

Continuaremos oferecendo mais valor de forma iterativa até o GA e além.

4. Configuração e requisitos

Configuração de ambiente autoguiada

  1. Faça login no console do Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

  • O Nome do projeto é o nome de exibição do projeto. Contanto que você siga as convenções de nomenclatura, é possível usar o que quiser e atualizar a qualquer momento.
  • O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser alterado (não pode ser alterado depois de definido). O console do Cloud gera automaticamente uma string exclusiva. normalmente você não se importa com o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, que normalmente é identificado como PROJECT_ID. Se não gostar, gere outro ID aleatório ou faça um teste e veja se ele está disponível. Então está "congelado" depois que o projeto for criado.
  1. Em seguida, será necessário ativar o faturamento no Console do Cloud para usar os recursos do Google Cloud.

A execução deste codelab não será muito cara, se for o caso. Siga todas as instruções na seção "Limpeza", que orienta você sobre como encerrar recursos para não incorrer em cobranças além deste tutorial. Novos usuários do Google Cloud estão qualificados para o programa de US$300 de teste sem custo financeiro.

Inicie o Cloud Shell

Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.

No Console do GCP, clique no ícone do Cloud Shell na barra de ferramentas localizada no canto superior direito:

bce75f34b2c53987.png

O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:

f6ef2b5f13479f3a.png

Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Todo o trabalho neste laboratório pode ser feito apenas com um navegador.

5. Ative APIs, defina zona e plataforma

Configurar o ID do projeto e instalar os componentes Alfa

No Cloud Shell, o nome GOOGLE_CLOUD_PROJECT já deve estar definido como o ID do seu projeto. Caso contrário, verifique se ele está definido e se a gcloud está configurada com esse ID do projeto:

export GOOGLE_CLOUD_PROJECT=your-project-id
gcloud config set project ${GOOGLE_CLOUD_PROJECT}

Verifique se o componente gcloud para Alfa está instalado:

gcloud components install alpha

Ativar APIs

Ative todos os serviços necessários:

gcloud services enable cloudapis.googleapis.com 
gcloud services enable container.googleapis.com 
gcloud services enable containerregistry.googleapis.com
gcloud services enable cloudbuild.googleapis.com

Definir zona e plataforma

Antes de criar um cluster do GKE com os eventos do Cloud Run, defina o nome do cluster, a zona e a plataforma. Por exemplo, aqui definimos o nome e a zona como events-cluster e europe-west1-b, e a plataforma é gke,.

No Cloud Shell, faça o seguinte:

export CLUSTER_NAME=events-cluster
export CLUSTER_ZONE=europe-west1-b

gcloud config set run/cluster ${CLUSTER_NAME}
gcloud config set run/cluster_location ${CLUSTER_ZONE}
gcloud config set run/platform gke

Verifique se a configuração foi definida:

gcloud config list

...
[run]
cluster = events-cluster
cluster_location = europe-west1-b
platform = gke

6. Criar um cluster do GKE com eventos do Cloud Run

Crie um cluster do GKE executando o Kubernetes 1.15.9-gke.26, com os seguintes complementos ativados: CloudRun, HttpLoadBalancing, HorizontalPodAutoscaling:

gcloud beta container clusters create ${CLUSTER_NAME} \
  --addons=HttpLoadBalancing,HorizontalPodAutoscaling,CloudRun \
  --machine-type=n1-standard-4 \
  --enable-autoscaling --min-nodes=3 --max-nodes=10 \
  --no-issue-client-certificate --num-nodes=3 --image-type=cos \
  --enable-stackdriver-kubernetes \
  --scopes=cloud-platform,logging-write,monitoring-write,pubsub \
  --zone ${CLUSTER_ZONE} \
  --release-channel=rapid

7. Configurar eventos do Cloud Run (plano de controle)

Os eventos do Cloud Run têm um plano de controle e um plano de dados que precisam ser configurados separadamente. Para configurar o plano de controle:

No Cloud Shell, faça o seguinte:

gcloud beta events init 

Isso vai inicializar os eventos e criar várias contas de serviço necessárias. Selecione "Sim" quando a criação da conta de serviço for solicitada.

Nesse ponto, o plano de controle deve ser inicializado corretamente. Aparecerão quatro pods com um

Status Running, 2 (controller-xxx-xxx e webhook-xxx-xxx) no namespace cloud-run-events e 2 (eventing-controller-xxx-xxx e eventing-webhook-xxx-xxx) no namespace knative-eventing. Para verificar, execute os seguintes comandos:

kubectl get pods -n cloud-run-events

NAME                         READY   STATUS    RESTARTS   AGE
controller-9cc679b67-2952n   1/1     Running   0          22s
webhook-8576c4cfcb-dhz82     1/1     Running   0          16m
kubectl get pods -n knative-eventing

NAME                                   READY   STATUS    RESTARTS   AGE
eventing-controller-77f46f6cf8-kj9ck   1/1     Running   0          17m
eventing-webhook-5bc787965f-hcmwg      1/1     Running   0          17m

8. Configurar eventos do Cloud Run (plano de dados)

Em seguida, é preciso configurar o plano de dados nos namespaces do usuário. Isso cria um agente com as permissões apropriadas para ler/gravar no Pub/Sub.

No Cloud Shell, defina uma variável de ambiente NAMESPACE para o namespace que você quer usar nos objetos. Defina-o como default se quiser usar o namespace padrão, conforme mostrado abaixo:

export NAMESPACE=default

Se o namespace especificado não existir (ou seja, se o namespace não for o padrão), será necessário criá-lo:

kubectl create namespace ${NAMESPACE}

Para inicializar o namespace com o secret padrão:

gcloud beta events namespaces init ${NAMESPACE} --copy-default-secret 

Crie um agente padrão no namespace:

gcloud beta events brokers create default --namespace ${NAMESPACE}

Verifique se o agente foi criado. Pode levar alguns segundos até que o agente fique pronto:

kubectl get broker -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-brokercell-ingress.cloud-run-events.svc.cluster.local/default/default

9. Descoberta de eventos

Você pode descobrir quais são as origens registradas, os tipos de eventos que elas podem emitir e como configurar gatilhos para consumi-los.

Para ver a lista com diferentes tipos de eventos:

gcloud beta events types list

Para mais informações sobre cada tipo de evento:

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

10. Criar um coletor do Cloud Run

Como coletor de eventos, implante um serviço do Cloud Run que registre o conteúdo do CloudEvent recebido.

Você pode usar o event_display do Knative, que já está compilado, e a imagem de contêiner dele criada como parte da versão do Knative. Veja os detalhes da imagem do contêiner em event-display.yaml:

...
containers:
  - image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

Implantar no Cloud Run

Implante o aplicativo conteinerizado no Cloud Run:

export SERVICE_NAME=event-display
gcloud run deploy ${SERVICE_NAME} \
  --namespace=${NAMESPACE} \
  --image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

Em caso de sucesso, a linha de comando exibe o URL de serviço. Agora você pode acessar o contêiner implantado abrindo o URL de serviço em qualquer janela do navegador.

11. Criar um gatilho de evento para o Cloud Pub/Sub

Uma maneira de receber eventos é pelo Cloud Pub/Sub. Os aplicativos personalizados podem publicar mensagens no Cloud Pub/Sub, que podem ser entregues aos coletores do Google Cloud Run com os eventos do Cloud Run.

Criar um tópico

Primeiro, crie um tópico do Cloud Pub/Sub. É possível substituir TOPIC_ID por um nome de tópico exclusivo de sua preferência:

export TOPIC_ID=cr-gke-topic
gcloud pubsub topics create ${TOPIC_ID}

Criar um gatilho

Antes de criar o gatilho, confira mais detalhes sobre os parâmetros necessários para criar um gatilho para eventos do Cloud Pub/Sub:

gcloud beta events types describe google.cloud.pubsub.topic.v1.messagePublished

Crie um gatilho para filtrar eventos publicados no tópico do Cloud Pub/Sub no serviço implantado do Cloud Run:

gcloud beta events triggers create trigger-pubsub \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type google.cloud.pubsub.topic.v1.messagePublished \
  --parameters topic=${TOPIC_ID}

Testar o gatilho

Para verificar se o gatilho foi criado, liste todos os gatilhos:

gcloud beta events triggers list

Talvez seja necessário aguardar até 10 minutos para que a criação do gatilho seja propagada e comece a filtrar eventos.

Se quiser simular uma mensagem de envio de app personalizada, use gcloud para disparar um evento:

gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"

O coletor do Cloud Run que criamos registra o corpo da mensagem recebida. É possível conferir isso na seção "Registros" da instância do Cloud Run:

9526909a06c6d4f4.png

Observe que "Olá" será codificada em base64 como foi enviada pelo Pub/Sub e você terá que decodificá-la para ver a mensagem original enviada.

Excluir o gatilho

Também é possível excluir o gatilho depois de concluir o teste.

gcloud beta events triggers delete trigger-pubsub --namespace ${NAMESPACE}

12. Criar um gatilho de evento para registros de auditoria

Você vai configurar um gatilho para detectar eventos dos registros de auditoria. Mais especificamente, você procurará eventos de criação de tópicos do Pub/Sub nos registros de auditoria.

Ativar registros de auditoria

Para receber eventos de um serviço, você precisa ativar os registros de auditoria. No Console do Cloud, selecione IAM & Admin > Audit Logs no menu superior esquerdo. Na lista de serviços, verifique o Google Cloud Pub/Sub:

97bd4b57c6a05fcc.png

No lado direito, verifique se Admin, Leitura e Gravação estão selecionados. Clique em "Salvar":

bec31b4f35fbcea.png

Registros de auditoria de teste

Para aprender a identificar os parâmetros necessários para configurar um gatilho real, execute uma operação real.

Por exemplo, crie um tópico do Pub/Sub:

gcloud pubsub topics create cre-gke-topic1

Agora, vamos conferir que tipo de registro de auditoria essa atualização gerou. No Console do Cloud, selecione Logging > Logs Viewer no menu superior esquerdo.

Em Query Builder,, escolha Cloud Pub/Sub Topic e clique em Add:

f5c634057e935bc6.png

Depois de executar a consulta, você verá registros dos tópicos do Pub/Sub, e um deles deve ser google.pubsub.v1.Publisher.CreateTopic:

b083cce219773d24.png

Observe serviceName, methodName e resourceName. Eles serão usados na criação do acionador.

Criar um gatilho

Agora está tudo pronto para criar um gatilho de evento para os registros de auditoria.

Confira mais detalhes sobre os parâmetros necessários para criar um gatilho para eventos das origens do Google Cloud executando o seguinte comando:

gcloud beta events types describe google.cloud.audit.log.v1.written

Crie o acionador com os filtros certos:

gcloud beta events triggers create trigger-auditlog \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.audit.log.v1.written \
  --parameters serviceName=pubsub.googleapis.com \
  --parameters methodName=google.pubsub.v1.Publisher.CreateTopic

Testar o gatilho

Liste todos os acionadores para confirmar que eles foram criados:

gcloud beta events triggers list

Aguarde até 10 minutos para que a criação do gatilho seja propagada e comece a filtrar eventos. Quando estiver pronto, ele vai filtrar os eventos criados e enviá-los para o serviço. Agora está tudo pronto para disparar um evento.

Crie outro tópico do Pub/Sub, como você fez antes:

gcloud pubsub topics create cre-gke-topic2

Se você verificar os registros do serviço do Cloud Run no Console do Cloud, verá o evento recebido:

aff3b2e7ad05c75d.png

Excluir o gatilho e os tópicos

Você também pode excluir o gatilho depois de concluir o teste:

gcloud beta events triggers delete trigger-auditlog

Exclua também os tópicos:

gcloud pubsub topics delete cre-gke-topic1 cre-gke-topic2

13. Criar um gatilho de evento para o Cloud Storage

Configure um gatilho para detectar eventos do Cloud Storage.

Crie um bucket

Primeiro, crie um bucket do Cloud Storage na mesma região do serviço do Cloud Run implantado. É possível substituir BUCKET_NAME por um nome exclusivo de sua preferência:

export BUCKET_NAME=[new bucket name]
export REGION=europe-west1

gsutil mb -p $(gcloud config get-value project) \
  -l $REGION \
  gs://$BUCKET_NAME/

Configurar as permissões do Cloud Storage

Antes de criar um gatilho, conceda à conta de serviço padrão para que o Cloud Storage possa publicar no Pub/Sub.

Primeiro, você precisa encontrar a conta de serviço que o Cloud Storage usa para publicar no Pub/Sub. Para isso, siga as etapas em Como conseguir a conta de serviço do Cloud Storage ou use o seguinte comando:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://storage.googleapis.com/storage/v1/projects/$(gcloud config get-value project)/serviceAccount"

A conta de serviço será listada em email_address.

Suponha que a conta de serviço que você encontrou acima seja service-XYZ@gs-project-accounts.iam.gserviceaccount.com e defina-a como uma variável de ambiente:

export GCS_SERVICE_ACCOUNT=service-XYZ@gs-project-accounts.iam.gserviceaccount.com

Em seguida, conceda os direitos para que essa conta de serviço publique no Pub/Sub:

gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \
  --member=serviceAccount:${GCS_SERVICE_ACCOUNT} \
  --role roles/pubsub.publisher

Criar um gatilho

Agora você já pode criar um gatilho para eventos do Cloud Storage.

Confira mais detalhes sobre os parâmetros necessários para criar o gatilho:

gcloud beta events types describe google.cloud.storage.object.v1.finalized

Crie o acionador com os filtros certos:

gcloud beta events triggers create trigger-storage \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=google.cloud.storage.object.v1.finalized \
  --parameters bucket=${BUCKET_NAME}

Testar o gatilho

Liste todos os acionadores para confirmar que eles foram criados:

gcloud beta events triggers list

Aguarde até 10 minutos para que a criação do gatilho seja propagada e comece a filtrar eventos. Quando estiver pronto, ele vai filtrar os eventos criados e enviá-los para o serviço.

Agora está tudo pronto para disparar um evento.

Faça upload de um arquivo aleatório para o bucket do Cloud Storage:

echo "Hello World" > random.txt
gsutil cp random.txt gs://${BUCKET_NAME}/random.txt

Se você verificar os registros do serviço do Cloud Run no Console do Cloud, verá o evento recebido:

aff3b2e7ad05c75d.png

Excluir o gatilho

Você também pode excluir o gatilho depois de concluir o teste:

gcloud beta events triggers delete trigger-storage

14. Criar um gatilho de evento para o Cloud Scheduler

Você vai configurar um gatilho para detectar eventos do Cloud Scheduler.

Criar um aplicativo do App Engine

No momento, os usuários do Cloud Scheduler precisam criar um aplicativo do App Engine. Escolha um local do App Engine e crie o aplicativo:

export APP_ENGINE_LOCATION=europe-west
gcloud app create --region=${APP_ENGINE_LOCATION}

Criar um gatilho

Confira mais detalhes sobre os parâmetros necessários para criar um gatilho para eventos das origens do Google Cloud executando o seguinte comando:

gcloud beta events types describe google.cloud.scheduler.job.v1.executed

Escolha um local do Cloud Scheduler para criar o programador:

export SCHEDULER_LOCATION=europe-west1

Crie um gatilho que criará um job a ser executado a cada minuto no Google Cloud Scheduler e chame o serviço de destino:

gcloud beta events triggers create trigger-scheduler \
  --namespace ${NAMESPACE} \
  --target-service=${SERVICE_NAME} \
  --type=google.cloud.scheduler.job.v1.executed \
  --parameters location=${SCHEDULER_LOCATION} \
  --parameters schedule="* * * * *" \
  --parameters data="trigger-scheduler-data"

Testar o gatilho

Liste todos os acionadores para confirmar que eles foram criados:

gcloud beta events triggers list

Aguarde até 10 minutos para que a criação do gatilho seja propagada e comece a filtrar eventos. Quando estiver pronto, ele vai filtrar os eventos criados e enviá-los para o serviço.

Se você verificar os registros do serviço do Cloud Run no console do Cloud, verá o evento recebido.

Excluir o gatilho

Você também pode excluir o gatilho depois de concluir o teste:

gcloud beta events triggers delete trigger-scheduler

15. Eventos personalizados (endpoint do agente)

Nesta parte do codelab, você produzirá e consumirá eventos personalizados usando o agente.

Criar um pod de curl para produzir eventos

Os eventos geralmente são criados de maneira programática. No entanto, nesta etapa, você vai usar curl para enviar eventos individuais manualmente e conferir como eles são recebidos pelo consumidor correto.

Para criar um pod que atue como produtor de eventos, execute o seguinte comando:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: curl
  name: curl
  namespace: $NAMESPACE
spec:
  containers:
  - image: radial/busyboxplus:curl
    imagePullPolicy: IfNotPresent
    name: curl
    resources: {}
    stdin: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    tty: true
EOF

Verifique se o pod curl está funcionando corretamente. Você verá um pod chamado curl com Status=Running:

kubectl get pod curl -n ${NAMESPACE}

Criar um gatilho

Você vai criar um gatilho com um filtro no tipo CloudEvents específico (neste caso, alpha-type) que vai ser emitido. A filtragem de correspondência exata para qualquer número de atributos do CloudEvents e extensões é compatível. Se o filtro definir vários atributos, o evento precisará ter todos os atributos para que o acionador possa filtrá-lo. Por outro lado, se você não especificar um filtro, todos os eventos serão recebidos no seu serviço.

Crie o gatilho:

gcloud beta events triggers create trigger-custom \
  --namespace ${NAMESPACE} \
  --target-service ${SERVICE_NAME} \
  --type=alpha-type \
  --custom-type

Testar o gatilho

Liste todos os acionadores para confirmar que eles foram criados:

gcloud beta events triggers list

Crie um evento enviando uma solicitação HTTP para o agente. Lembre-se do URL do agente executando o seguinte:

kubectl get brokers -n ${NAMESPACE}

NAME      READY   REASON   URL
default   True             http://default-broker.<NAMESPACE>.svc.cluster.local

Use SSH para se conectar ao pod curl criado anteriormente:

kubectl --namespace ${NAMESPACE} attach curl -it

Você se conectou ao pod por SSH e já pode fazer uma solicitação HTTP. Será exibida uma solicitação semelhante a esta:

Defaulting container name to curl.
Use 'kubectl describe pod/curl -n default' to see all of the containers in this pod.
If you don't see a command prompt, try pressing enter.
[ root@curl:/ ]$

Criar um evento:

curl -v "<BROKER-URL>" \
-X POST \
-H "Ce-Id: my-id" \
-H "Ce-Specversion: 1.0" \
-H "Ce-Type: alpha-type" \
-H "Ce-Source: my-source" \
-H "Content-Type: application/json" \
-d '{"msg":"send-cloudevents-to-broker"}'

Se o evento foi recebido, você receberá uma resposta HTTP 202 Accepted. Saia da sessão SSH com Ctrl + D.

Verifique se o evento publicado foi enviado analisando os registros do serviço do Cloud Run:

kubectl logs --selector serving.knative.dev/service=$SERVICE_NAME \
 -c user-container -n $NAMESPACE --tail=100

Excluir o gatilho

Você também pode excluir o gatilho depois de concluir o teste:

gcloud beta events triggers delete trigger-custom

16. Parabéns!

Parabéns por concluir o codelab.

O que aprendemos

  • Visão de longo prazo dos eventos do Cloud Run for Anthos
  • Estado atual dos eventos do Cloud Run for Anthos
  • Crie um coletor do Cloud Run
  • Criar um gatilho de evento para o Cloud Pub/Sub
  • Criar um gatilho de evento para registros de auditoria
  • Criar um gatilho de evento para o Cloud Storage
  • Criar um gatilho de evento para o Cloud Scheduler
  • Produza e consuma eventos personalizados