CI/CD moderno com o GKE: aplique o fluxo de trabalho do programador

Last reviewed 2023-09-11 UTC

Este tutorial mostra como integrar uma nova aplicação, desenvolver uma funcionalidade para a aplicação e implementar a aplicação em produção usando técnicas modernas de integração contínua/entrega contínua (CI/CD) com o Google Kubernetes Engine (GKE).

Este documento faz parte de uma série:

Neste tutorial, vai usar ferramentas como o Skaffold, kustomize, Artifact Registry, Config Sync, Cloud Build e Cloud Deploy para desenvolver, criar e implementar a sua aplicação.

Este documento destina-se a arquitetos empresariais e programadores de aplicações, bem como a equipas de segurança de TI, DevOps e engenharia de fiabilidade do site (SRE). Alguma experiência com ferramentas e processos de implementação automatizados é útil para compreender os conceitos neste documento.

Arquitetura

Neste tutorial, vai integrar uma nova aplicação. Em seguida, desenvolve uma nova funcionalidade e implementa a aplicação em ambientes de desenvolvimento, preparação e produção. A arquitetura de referência contém a infraestrutura e as ferramentas necessárias para integrar e lançar uma nova aplicação com o fluxo de trabalho apresentado no diagrama seguinte:

O ciclo de desenvolvimento abrange repositórios de código, o Cloud Build e pipelines de implementação na nuvem.

Começando no repositório de código para CI, o fluxo de trabalho inclui os seguintes passos:

  1. Partilha o código-fonte da sua aplicação através dos repositórios da aplicação.

  2. Quando confirma e envia o código para o repositório da aplicação, aciona automaticamente um pipeline de CI no Cloud Build. O processo de CI cria e envia uma imagem de contentor para o Artifact Registry.

  3. O processo de CI também cria uma versão de CD para a aplicação no Cloud Deploy.

  4. O lançamento de CD gera manifestos do Kubernetes totalmente renderizados para o desenvolvimento através do skaffold e implementa-os no cluster do GKE de desenvolvimento.

  5. Em seguida, o lançamento de CD é promovido do ambiente de desenvolvimento para um destino de preparação, que gera manifestos de preparação totalmente renderizados e implementa-os no cluster GKE de preparação.

  6. Em seguida, o lançamento de CD é promovido da preparação para a produção, o que gera manifestos de produção totalmente renderizados e implementa-os em clusters GKE de produção.

Para mais informações sobre as ferramentas e a infraestrutura usadas neste fluxo de trabalho, consulte CI/CD moderno com o GKE: crie um sistema de CI/CD.

Integre uma nova aplicação

A arquitetura de referência contém uma fábrica de aplicações. Esta fábrica é uma coleção de um repositório git denominado application-factory-repo e os seguintes acionadores do Cloud Build:

  • create-app
  • tf-plan
  • tf-apply
  • create-team

Usa a fábrica de aplicações para integrar uma nova aplicação a partir de repositórios iniciais. A integração de aplicações consiste nos seguintes passos:

  1. Crie a definição da aplicação: crie a definição da aplicação num ficheiro do Terraform e armazene-a em application-factory-repo, que funciona como um catálogo de aplicações.

  2. Crie a infraestrutura da aplicação: execute o Terraform no ficheiro de definição da aplicação para criar a infraestrutura da aplicação. A infraestrutura de aplicações é composta pelo seguinte:

    1. Uma zona de destino para a nova aplicação inclui a definição do espaço de nomes, da conta de serviço e das políticas base no repositório acm-gke-infrastructure-repo. A zona de destino só é criada num cluster do GKE de desenvolvimento durante a integração de uma nova aplicação. Isto é feito para desbloquear os programadores, para que possam usar o ambiente de desenvolvimento e começar a iterar sobre ele. A zona de destino nos clusters de preparação e produção é criada com a abordagem GitOps. Esta abordagem é demonstrada mais adiante neste documento quando estiver tudo pronto para promover o lançamento nesses clusters.

    2. O repositório de infraestrutura do repositório inicial de infraestrutura que aloja o código para criar o pipeline de CI no Cloud Build, o pipeline de CD no Cloud Deploy e o repositório do Artifact Registry para armazenar artefactos.

    3. Um acionador do Cloud Build de infraestrutura que usa o código no repositório de infraestrutura e cria os recursos com base na respetiva definição.

    4. Um repositório de aplicações do repositório inicial de aplicações que aloja o código-fonte da aplicação.

  3. Criar recursos de CI/CD da aplicação: usa a infraestrutura da aplicação para criar recursos de CI/CD para a aplicação.

Criar definição da aplicação:

Execute o acionador create-app para gerar um ficheiro de definição da aplicação em application-factory-repo. O ficheiro de definição contém a definição declarativa dos recursos necessários para criar uma aplicação.

  1. Na Google Cloud consola, aceda à página do Cloud Build:

    Aceda à página do Cloud Build

  2. Clique em create-app acionador.

  3. Clique em MOSTRAR PRÉ-VISUALIZAÇÃO DO URL para apresentar o URL necessário para invocar o webhook.

  4. No Cloud Shell, invoque o acionador fazendo um pedido curl no URL obtido no passo anterior e transmitindo os parâmetros como um payload.

    curl "WEBHOOK_URL" -d '{"message": {"app": "sample","runtime": "python","trigger_type": "webhook","github_team": ""}}'

    No exemplo de código anterior:

    • Substitua WEBHOOK_URL pelo URL obtido a partir do acionador.

    • "app": "sample" especifica o nome da aplicação.

    • "runtime": "python" indica à fábrica de aplicações que use o modelo Python para criar repositórios de aplicações.

    • "trigger_type": "webhook" especifica o tipo de pipelines de CI/CD para a aplicação.

    • "github_team": "" é uma equipa no GitHub que vai ser associada aos repositórios criados para a aplicação. Uma vez que ainda não criou uma equipa do GitHub, transmita-a como uma string vazia.

  5. Verifique o acionador create-app no pipeline:

    Aceda à página Histórico do Cloud Build.

    Existe um novo pipeline para o acionador create-app. Quando este processo estiver concluído, a definição da aplicação é criada em application-factory-repo.

  6. Reveja o ficheiro de definição da aplicação:

    1. Num navegador de Internet, aceda ao GitHub e inicie sessão na sua conta.

    2. Clique no ícone de imagem e, de seguida, em Your organizations. Escolha a sua organização.

    3. Clique no repositório application-factory-repo, aceda à pasta apps/python e abra o novo ficheiro denominado sample.tf criado pelo acionador create-app. Inspeccione o ficheiro. Este ficheiro contém código Terraform para criar uma nova aplicação.

Crie uma infraestrutura de aplicações:

Agora que criou a definição da aplicação, execute o acionador tf-apply para criar a infraestrutura da aplicação.

  1. Na Google Cloud consola:

    Aceda à página do Cloud Build .

    Clique no acionador tf-apply.

  2. Clique em "MOSTRAR ANTEVISÃO DO URL" para apresentar o URL necessário para invocar o webhook.

  3. Invocar o acionador:

    curl "WEBHOOK_URL" -d '{}'

    No exemplo de código anterior:

    • Substitua WEBHOOK_URL pelo URL obtido a partir do acionador.

  4. Verifique o acionador tf-apply no pipeline:

    Aceda à página Histórico do Cloud Build.

    Existe um novo pipeline para o acionador tf-apply. Aguarde a conclusão.

Este acionador cria a infraestrutura da aplicação.

Reveja a infraestrutura da aplicação:

Reveja os vários componentes da infraestrutura da aplicação.

Zona de aterragem

  1. Aceda ao Cloud Shell e defina o projeto. 

    gcloud config set core/project PROJECT_ID

    Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

  2. Obtenha credenciais para o cluster do GKE de desenvolvimento.

    gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a

  3. Verifique o espaço de nomes da aplicação. O espaço de nomes tem o nome da aplicação, sample.

    kubectl get namespaces sample

    O resultado é semelhante ao seguinte: 

    NAME     STATUS   AGE
sample   Active   15m

  4. Verifique a conta de serviço no espaço de nomes.

    kubectl get serviceaccounts -n sample

    Existe uma conta de serviço além da predefinição. O resultado é semelhante ao seguinte: 

    NAME         SECRETS   AGE
default      0         15m
sample-ksa   0         15m

Repositório de infraestrutura

Num navegador de Internet, aceda ao GitHub e inicie sessão na sua conta. Clique no ícone de imagem. Em seguida, clique em Your organizations. Escolha a sua organização e clique no repositório sample-infra.

Este repositório tem quatro ramificações: cicd-trigger, dev, staging e prod. Também contém quatro pastas: cicd-trigger, dev, staging e prod. O ramo predefinido é cicd-trigger e pode enviar o código para este ramo. Os outros ramos têm regras de proteção, pelo que não pode enviar código diretamente para esses ramos. Para enviar o código para esses ramos, tem de criar um pedido de obtenção. A pasta cicd-trigger tem código para criar recursos de CI/CD para a aplicação, enquanto as pastas dev, staging e prod têm código para criar infraestrutura para diferentes ambientes da aplicação.

Acionador de infraestrutura

  • Na Google Cloud consola:

    Aceda à página do Cloud Build

    Existe um novo acionador denominado deploy-infra-sample.

  • Este acionador está ligado ao repositório sample-infra de modo que, quando ocorre um envio de código para este repositório, o acionador é invocado, identifica o ramo onde ocorreu o envio, acede à pasta correspondente nesse ramo e executa o Terraform aí. Por exemplo, se o código for enviado para o ramo cicd-trigger, o acionador executa o Terraform na pasta cicd-trigger do ramo cicd-trigger. Da mesma forma, quando ocorre um push para o ramo dev, o acionador executa o Terraform na pasta dev do ramo dev e assim sucessivamente.

Repositório de aplicações

  • Aceda ao GitHub e aceda aos repositórios na sua organização. Existe um novo repositório com o nome sample. Este repositório aloja o código fonte e os passos para criar contentores em configurações Dockerfile e kustomize que descrevem as configurações necessárias da aplicação e skaffold.yaml que define os passos de implementação a serem usados pelo Cloud Deploy para a IC.

Crie recursos de CI/CD de aplicações

Agora que criou a estrutura da aplicação, execute o acionador deploy-infra-sample para criar os respetivos recursos de CI/CD. Pode invocar o acionador manualmente através do respetivo URL do webhook ou fazendo uma confirmação no repositório git sample-infra.

  1. Para invocar o acionador do Cloud Build, adicione uma nova linha a um ficheiro no repositório. Em seguida, envie as alterações:

    1. Se nunca usou o Git no Cloud Shell, configure o Git com o seu nome e endereço de email. O Git usa estas informações para identificar o utilizador como o autor das confirmações que cria na Cloud Shell:

      git config --global user.email "GITHUB_EMAIL_ADDRESS"
git config --global user.name "GITHUB_USERNAME"

      Substitua o seguinte:

      • GITHUB_EMAIL_ADDRESS: o endereço de email associado à sua conta do GitHub
      • GITHUB_USERNAME: o nome de utilizador associado à sua conta do GitHub

    2. Clone o repositório Git sample-infra:

      git clone https://github.com/GITHUB_ORG/sample-infra

cd sample-infra

      Substitua o seguinte:

      • GITHUB_ORG com a sua organização do GitHub.

      O ramo predefinido cicd-trigger é extraído.

    3. Adicione uma nova linha ao ficheiro env/cicd-trigger/main.tf, confirme a alteração e envie-a.

        echo "" >> env/cicd-trigger/main.tf

    4. Confirme e envie as alterações:

      git add .
git commit -m "A dummy commit to invoke the infrastrucutre trigger"
git push
cd ..

      Assim que as alterações forem enviadas, o acionador do Cloud Deploy deploy-infra-sample é iniciado.

  2. Monitorize o estado do acionador:

    Aceda à página do histórico do Cloud Build para ver o pipeline e aguarde pela conclusão.

Reveja os recursos de CICD da aplicação

Reveja os vários recursos de CI/CD criados para a aplicação.

  1. Na Google Cloud consola:

    Aceda à página do Cloud Build e veja o acionador deploy-app-sample.

    Este é o acionador do pipeline de CI. Está associado ao repositório de código da aplicação sample. O acionador é invocado quando é feito um push para o repositório da aplicação e executa os passos de compilação conforme definidos na configuração do acionador. Para ver os passos que o acionador executa quando invocado, clique no nome do acionador e, de seguida, clique no botão ABRIR EDITOR.

  2. Aceda à página do Artifact Registry e veja o novo repositório com o nome sample.

    Este repositório de artefactos armazena os artefactos da aplicação.

  3. Aceda à página do pipeline do Cloud Deploy e veja o pipeline com o nome sample. Esta é a pipeline de implementação contínua que implementa a aplicação nos clusters do GKE.

Implemente a aplicação no ambiente de desenvolvimento

O acionador deploy-app-sample está ligado ao repositório de aplicações denominado sample. Pode invocar o acionador manualmente, através do URL do webhook, ou através de um envio para o repositório da aplicação.

  1. Adicione uma nova linha num ficheiro no repositório sample e envie as alterações para invocar o acionador do Cloud Build:

    1. Clone o repositório Git sample:

      No Cloud Shell:

      git clone https://github.com/GITHUB_ORG/sample

cd sample

      Substitua GITHUB_ORG pela sua organização do GitHub.

    2. Adicione uma nova linha ao ficheiro skaffold.yaml.

        echo "" >> skaffold.yaml

    3. Confirme e envie as alterações:

      git add .
git commit -m "A dummy commit to invoke CI/CD trigger"
git push

    4. Assim que as alterações forem enviadas, o acionador do Cloud Deploy deploy-app-sample é iniciado.

  2. Monitorize o estado do acionador:

    Aceda à página do histórico do Cloud Build para ver o pipeline e aguarde pela conclusão.

    O acionador executa os passos definidos na respetiva configuração. O primeiro passo é criar uma imagem do Docker a partir do código da aplicação no repositório sample. O último passo é iniciar o pipeline do Cloud Deploy que implementa a aplicação no cluster do GKE de desenvolvimento.

  3. Verifique a implementação no cluster de desenvolvimento:

    Aceda à página do pipeline do Cloud Deploy.

    Clique no pipeline sample. A implementação no cluster do GKE de desenvolvimento foi iniciada. Aguarde a conclusão.

Verifique se a aplicação foi implementada com êxito :

  1. Obtenha credenciais para o cluster de desenvolvimento.

    gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a

  2. Crie um túnel para o cluster do GKE.

    gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080

  3. Na barra de ferramentas do Cloud Shell, clique em

    Pré-visualização na Web e, de seguida, clique em Pré-visualizar na porta 8080: Comandos da barra de ferramentas do Cloud Shell.

    O resultado é o seguinte:

    Hello World!

  4. No Cloud Shell, prima CTRL+C para terminar o encaminhamento de portas.

Adicione uma nova funcionalidade à aplicação

Quando desenvolve uma nova funcionalidade, tem de implementar rapidamente as alterações no ambiente de desenvolvimento para as testar e iterar. Neste tutorial, vai fazer alterações no repositório de código da aplicação e implementá-las no ambiente de programação.

  1. No Cloud Shell, altere o diretório para o repositório sample já clonado:

  2. Atualize a aplicação para emitir uma mensagem diferente:

      sed -i "s/Hello World/My new feature/g" main.py

  3. Confirme e envie as alterações:

    git add .
git commit -m "Changed the message"
git push

    Assim que o código é enviado para o repositório do GitHub, o acionador do webhook deploy-app-sample é iniciado.

  4. Monitorize o estado do acionador na página do histórico do Cloud Build e aguarde pela conclusão.

  5. Aceda à página do pipeline do Cloud Deploy

    Clique no pipeline sample. A implementação no cluster do GKE de desenvolvimento foi iniciada. Aguarde a conclusão.

Verifique se a aplicação foi implementada com êxito :

  1. Obtenha credenciais para o cluster de desenvolvimento se tiver aberto um novo Cloud Shell:

    gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a

  2. Criar um túnel para o cluster do GKE:

    gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080

  3. Na barra de ferramentas do Cloud Shell, clique em

    Pré-visualização Web e, de seguida, clique em Pré-visualizar na porta 8080:

    Comandos da barra de ferramentas do Cloud Shell.

    O resultado é o seguinte:

    My new feature!

  4. No Cloud Shell, prima CTRL+C para terminar o encaminhamento de portas.

Promova a alteração para os clusters de preparação e produção

Antes de promover a aplicação para ambientes de preparação e produção, tem de criar a zona de destino da aplicação nos clusters do GKE para esses ambientes. Quando incorporou a aplicação, a zona de destino para o ambiente de desenvolvimento foi criada automaticamente no cluster do GKE de desenvolvimento adicionando código a acm-gke-infrastructure-repo no ramo de desenvolvimento.

Crie uma zona de destino em clusters GKE de preparação e produção

  1. Crie uma zona de destino no cluster GKE de preparação: tem de criar um pedido de obtenção do ramo de desenvolvimento para o ramo de preparação em acm-gke-infrastructure-repo e uni-lo.

    1. Aceda ao GitHub e navegue para o repositório acm-gke-infrastructure-repo. Clique no botão Pull requests e, de seguida, no botão New pull request. No menu Base, escolha staging e, no menu Comparar, escolha dev. Clique no botão Create pull request.

    2. Normalmente, alguém com acesso ao repositório revê as alterações e, em seguida, junta o PR para garantir que apenas as alterações pretendidas são promovidas para o ambiente de preparação. Para permitir que os indivíduos experimentem a arquitetura de referência, as regras de proteção de ramificações foram flexibilizadas para que o administrador do repositório possa ignorar a revisão e unir o PR. Se for administrador do repositório, combine o pedido de envio. Caso contrário, peça ao administrador para a unir.

    O Config Sync sincroniza as alterações que chegam ao ramo de preparação do repositório acm-gke-infrastructure-repo com o cluster GKE de preparação, o que resulta na criação da zona de destino para a aplicação no cluster GKE de preparação.

  2. Crie uma zona de destino em clusters GKE de produção: tem de criar um pedido de obtenção do ramo de preparação para o ramo de produção e uni-lo.

    1. Clique no botão Pull requests e, de seguida, no botão New pull request. No menu Base, escolha prod e, no menu Comparar, escolha staging. Clique no botão Create pull request.

    2. Se for administrador do repositório, combine o pedido de envio. Caso contrário, peça ao administrador para a unir.

    O Config Sync sincroniza as alterações que chegam ao ramo prod do repositório acm-gke-infrastructure-repo com os clusters GKE de produção, o que resulta na criação da zona de destino para a aplicação nos clusters GKE de produção.

Promova as alterações do ambiente de desenvolvimento para o ambiente de testes

Agora que criou a zona de destino para a aplicação nos clusters do GKE de teste e produção, promova a aplicação do ambiente de desenvolvimento para o ambiente de teste.

  1. Encontre o nome da versão mais recente e guarde-o como uma variável de ambiente:

      export RELEASE=$(gcloud deploy targets describe dev --region=us-central1 --format="json" | jq -r '."Active Pipeline"[0]."projects/PROJECT_ID/locations/us-central1/deliveryPipelines/sample"."Latest release"' | awk -F '/' '{print $NF}')

    Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

    Verifique se a variável de ambiente foi definida:

      echo $RELEASE

  2. No Cloud Shell, execute o seguinte comando para acionar a promoção da versão do ambiente de desenvolvimento para o ambiente de preparação:

     gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=staging --quiet

  3. Verifique a implementação de preparação:

    Aceda à página do pipeline do Cloud Deploy

    Clique no pipeline sample. A implementação no cluster do GKE de preparação foi iniciada. Aguarde a conclusão.

  4. Verifique se a implementação de preparação ocorreu com êxito:

    1. Obtenha credenciais para o cluster de preparação:

      gcloud container clusters get-credentials gke-staging-us-central1 --location us-central1-a

    2. Criar um túnel para o cluster do GKE:

      gcloud container clusters get-credentials gke-staging-us-central1 --location us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080

    3. Na barra de ferramentas do Cloud Shell, clique em

      Pré-visualização Web e, de seguida, clique em Pré-visualizar na porta 8080:

      Comandos da barra de ferramentas do Cloud Shell.

      O resultado é o seguinte:

      My new feature!

    4. No Cloud Shell, prima CTRL+C para terminar o encaminhamento de portas.

Promova as alterações do ambiente de preparação para o ambiente de produção

Agora, promova o lançamento da fase de testes para a produção. Tem dois clusters de produção e o Cloud Deploy tem um destino para cada um deles, denominados prod1 e prod2, respetivamente.

  1. No Cloud Shell, execute o seguinte comando para acionar a promoção do lançamento da preparação para o cluster prod1:

     gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod1 --quiet

  2. A implementação em clusters de produção requer aprovação, pelo que a implementação aguarda a sua aprovação. Para a ver:

    Aceda à página do pipeline do Cloud Deploy

    Clique em sample pipeline. A implementação na prod1 requer aprovação, e a função clouddeploy.approver é necessária para aprovar a implementação. Uma vez que é o proprietário do projeto, tem acesso para aprovar o lançamento.

  3. Aprove o lançamento para prod1:

    Execute o seguinte comando para obter o nome da implementação pendente de aprovação e guardá-lo numa variável de ambiente:

     export ROLLOUT=$(gcloud deploy targets describe prod1 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')

    Aprove a versão:

     gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet

  4. Após a aprovação, o lançamento da versão prod1 é iniciado. Monitorize o progresso na página do pipeline do Cloud Deploy.

  5. Após a conclusão da implementação do prod1, inicie o lançamento do prod2.

     gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod2 --quiet

  6. A versão para produção 2 também requer aprovação. Aprove o lançamento para o cluster prod2:

    Execute o seguinte comando para obter o nome da implementação pendente de aprovação e guardá-lo numa variável de ambiente:

     export ROLLOUT=$(gcloud deploy targets describe prod2 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')

    Aprove a versão:

     gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet

  7. Após a aprovação, o lançamento do prod2 é iniciado. Monitorize o progresso na página do pipeline do Cloud Deploy.

  8. Verifique se a implementação no cluster de produção foi bem-sucedida depois de as pipelines do Cloud Deploy em prod1 e prod2 estarem concluídas.

    1. Existe uma entrada em vários clusters criada em clusters de produção e usa um equilibrador de carga para aceder à aplicação de produção. Estas configurações de entrada de vários clusters são criadas através dos ficheiros YAML k8s/prod/mci.yaml e k8s/prod/mcs.yaml no repositório sample. Quando envia um pedido para o endereço IP do balanceador de carga, a entrada em vários clusters encaminha o pedido para uma das duas instâncias da aplicação em execução em dois clusters do GKE diferentes.

    2. Liste a regra de encaminhamento associada ao balanceador de carga para encontrar o endereço IP.

      gcloud compute forwarding-rules list

    3. O resultado é semelhante ao seguinte: 

      NAME: mci-qqxs9x-fw-sample-sample-ingress
REGION:
IP_ADDRESS: 34.36.123.118
IP_PROTOCOL: TCP
TARGET: mci-qqxs9x-sample-sample-ingress

    4. Abra um navegador de Internet e introduza o seguinte no URL: 

      http://IP_ADDRESS:80

      Substitua IP_ADDRESS pelo endereço IP do equilibrador de carga.

      O resultado é o seguinte:

      My new feature!

      Isto confirma que a aplicação é implementada conforme esperado nos clusters de produção.

Teste a capacidade de recuperação da aplicação

Nesta secção, testa a resiliência da aplicação em produção reiniciando um dos nós dos dois clusters GKE de produção sem afetar a aplicação.

A aplicação em produção usa a entrada de vários clusters e é acessível através de um IP do balanceador de carga. Quando a aplicação é acedida através desse IP, o Ingress de vários clusters encaminha-a para uma das duas instâncias da aplicação em execução em dois clusters do GKE diferentes. Quando um dos clusters do GKE não está em bom estado e não é possível aceder à instância da aplicação em execução no mesmo, o Ingress de vários clusters continua a enviar o tráfego para a instância em bom estado da aplicação em execução no outro cluster do GKE. Isto torna a indisponibilidade do cluster invisível para o utilizador final e a aplicação continua a processar os pedidos.

Para testar a resiliência:

  1. Encontre o node pool dos clusters do GKE de produção em execução em us-west1. 

     gcloud container clusters describe gke-prod-us-west1 --location=us-west1-a --format=json | jq ".nodePools[0].instanceGroupUrls[]" | tr '"' ' ' |  awk -F '/' '{for(i=NF-2; i<=NF; i=i+2) printf ("%s ",$i); print  ""}'

  2. O resultado é semelhante ao seguinte:

    us-west1-b gke-gke-prod-us-west1-node-pool-01-6ad4e1ed-grp
us-west1-c gke-gke-prod-us-west1-node-pool-01-98407373-grp

    O resultado tem duas colunas. A primeira coluna é a zona e a segunda coluna é o nome do grupo de instâncias associado ao conjunto de nós do cluster GKE de produção na região us-west1.

  3. Reinicie o grupo de instâncias correspondente aos conjuntos de nós:

     gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_1  --zone=ZONE_1 --max-unavailable=100%

 gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_2  --zone=ZONE_2 --max-unavailable=100%

    Substitua INSTANCE_GROUP_1 pelo nome do primeiro grupo de instâncias.

    Substitua ZONE_1 pela zona do primeiro grupo de instâncias.

    Substitua INSTANCE_GROUP_2 pelo nome do segundo grupo de instâncias.

    Substitua ZONE_2 pela zona do segundo grupo de instâncias.

  4. Verifique o estado do grupo de instâncias.

    Aceda à página Grupos de instâncias

    Os dois grupos de instâncias estão a ser reiniciados, enquanto os outros grupos têm uma marca de verificação verde.

    Estado dos grupos de instâncias.

  5. Abra um navegador de Internet e introduza o seguinte no URL: 

    http://IP_ADDRESS:80

    Substitua IP_ADDRESS pelo endereço IP do equilibrador de carga.

    Mesmo quando um dos dois clusters do GKE está inativo, a aplicação está disponível e o resultado é o seguinte:

     My new feature!

    Isto mostra que a sua aplicação é resiliente e altamente disponível.

Faça a gestão da aplicação

Quando criou esta aplicação a partir da fábrica de aplicações, recebeu repositórios git, infraestrutura e pipelines de CI/CD separados para a aplicação. Usou estes recursos para implementar a aplicação e adicionar uma nova funcionalidade. Para gerir ainda mais a aplicação, só precisa de interagir com estes repositórios git e o pipeline sem ter de atualizar a fábrica de aplicações. Pode personalizar os pipelines e os repositórios git da aplicação com base nos seus requisitos. Como proprietário de uma aplicação, pode definir quem tem acesso aos pipelines e aos repositórios git da sua aplicação para a gerir.