1. Introdução
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.
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.
Para permitir que os usuários criem aplicativos sem servidor orientados a eventos, nosso foco inicial é em duas partes:
- 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.
- 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
- 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.
- 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.
- 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:
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:
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:
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:
No lado direito, verifique se Admin, Leitura e Gravação estão selecionados. Clique em "Salvar":
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:
Depois de executar a consulta, você verá registros dos tópicos do Pub/Sub, e um deles deve ser google.pubsub.v1.Publisher.CreateTopic:
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:
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:
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