Como implantar uma carga de trabalho do Confidential Space com MIGs usando escalonamento automático, recuperação automática e atualizações de imagem

1. Visão geral

O Confidential Space (CS) oferece um ambiente seguro, atestado e criptografado para processar dados sensíveis. A dependência de instâncias de VM autônomas cria uma sobrecarga operacional, já que a orquestração manual não tem a escalonabilidade necessária para serviços essenciais. Sem a orquestração automatizada, realizar atualizações rotativas sincronizadas ou implantar novas imagens de SO em uma frota se torna tecnicamente difícil e propenso a tempo de inatividade.

Neste codelab, você vai aprender a implantar uma carga de trabalho do Confidential Space em um grupo gerenciado de instâncias (MIG). Você também vai aprender a ativar a recuperação automática usando verificações de integridade, o escalonamento automático com base na utilização da CPU e atualizações graduais para imagens do SO e cargas de trabalho.

Os processos mostrados neste codelab ajudam você a configurar seu próprio Confidential Space seguro e pronto para produção para implantações de longa duração e essenciais para a missão.

O que você vai aprender

• Como criar um modelo de instância especializada para o Confidential Space.
• Como usar o Google Compute Engine e configurar MIGs e grupos de instâncias
• Como criar uma regra de firewall e uma verificação de integridade para recuperação automática.
• Como configurar um MIG zonal com o modelo e a verificação de integridade.
• Como configurar o escalonamento automático para o MIG.
• Como configurar atualizações de imagem do SO com um clique usando scripts em MIGs para imagens de carga de trabalho e novos lançamentos de imagens do SO para o Confidential Space

O que é necessário

• Ter um projeto do Google Cloud com o faturamento ativado.
• Familiaridade com editores de texto, implantações do Docker e scripts em Bash
• A ferramenta de linha de comando gcloud instalada e autenticada.
• Entendimento básico do Compute Engine, Confidential Space, IAM, VMs confidenciais, tecnologia de contêineres, repositórios remotos, contas de serviço, Cloud Run e Cloud Scheduler
• Uma imagem de contêiner de carga de trabalho do Confidential Space já criada e enviada para o Artifact Registry.

2. Como o Confidential Space com MIGs funciona

Usar um grupo gerenciado de instâncias (MIG) para implantar uma carga de trabalho do Confidential Space torna um aplicativo seguro mais robusto, escalonável e fácil de operar.

As necessidades operacionais e de segurança de um serviço de produção são divididas logicamente entre os dois componentes. O Confidential Space oferece a segurança necessária executando a carga de trabalho em um ambiente altamente isolado, criptografado e atestado chamado ambiente de execução confiável (TEE). Em contraste, os MIGs oferecem os recursos operacionais essenciais necessários para executar o aplicativo seguro em grande escala, semelhante ao Kubernetes. Os MIGs eliminam os riscos inerentes à execução de uma carga de trabalho essencial em uma única VM, que pode ser lenta ou suscetível a falhas. Essa combinação garante a proteção de dados e a confiabilidade do sistema. Essa solução garante alta disponibilidade e recuperação automática porque a carga de trabalho é executada em várias VMs em um pool. Se uma VM falhar, o serviço vai continuar funcionando normalmente devido ao balanceamento de carga e à presença das instâncias restantes.

Além disso, os MIGs usam verificações de integridade configuráveis para monitorar constantemente o status operacional das VMs. Se uma instância for considerada não íntegra, o MIG a substituirá automaticamente por uma VM nova e íntegra, garantindo assim a operação contínua.

Os MIGs também oferecem escalonabilidade eficaz para os usuários com o recurso de escalonamento automático. Esse recurso oferece uma maneira automática de gerenciar a capacidade sem intervenção manual, atendendo à necessidade de adicionar ou remover capacidade de forma flexível com base na utilização.

Por fim, os MIGs permitem atualizações sem inatividade usando atualizações graduais. Um dos principais benefícios é a capacidade de upgrade com um clique para a imagem do SO do Confidential Space ou a imagem do contêiner do aplicativo (ou ambos), sem causar tempo de inatividade do serviço. O MIG gerencia essa mudança substituindo gradualmente as instâncias mais antigas por novas que executam a imagem atualizada, garantindo disponibilidade constante durante toda a implantação. Talvez seja necessário que seu aplicativo seja compatível com versões anteriores para oferecer suporte a esse tipo de upgrade gradual.

3. Como configurar recursos do Cloud

Antes de começar

1. Configurar um projeto do Google Cloud. Para mais informações sobre como criar um projeto do Google Cloud, consulte o codelab"Configurar e navegar no primeiro projeto do Google". Consulte Como criar e gerenciar projetos para saber como recuperar o ID do projeto e a diferença entre ele, o nome e o número do projeto.
2. Ative o faturamento dos projetos.
3. Em um dos projetos do Google no Cloud Shell, defina as variáveis de ambiente necessárias, conforme mostrado abaixo.

export  CURRENT_PROJECT_ID=<Google Cloud project id of current project>

4. Ative a API Computação confidencial e as seguintes APIs no seu projeto.

gcloud config set project $CURRENT_PROJECT_ID
gcloud services enable \
cloudapis.googleapis.com \
container.googleapis.com \
artifactregistry.googleapis.com \
confidentialcomputing.googleapis.com \
compute.googleapis.com \
logging.googleapis.com \
run.googleapis.com \
cloudscheduler.googleapis.com

5. No Cloud Shell do seu projeto na nuvem do Google Cloud, clone o repositório do GitHub do codelab do Confidential Space e use o comando abaixo para receber os scripts necessários para concluir este codelab.

git clone https://github.com/GoogleCloudPlatform/confidential-space.git

6. Mude o diretório para o diretório de scripts do codelab do grupo de instâncias.

cd confidential-space/codelabs/mig_cs_codelab/scripts

7. Atualize a linha do ID do projeto em config_env.sh para refletir o projeto escolhido.
8. Defina as variáveis preexistentes. Substitua os nomes dos recursos usando estas variáveis

• É possível definir as seguintes variáveis com nomes de recursos de nuvem atuais. Se a variável estiver definida, os recursos de nuvem correspondentes do projeto serão usados. Se não estiver definido, o nome do recurso de nuvem virá do script config_env.sh.

9. Execute o script config_env.sh para definir os nomes de variáveis restantes deste projeto como valores baseados no ID do projeto para nomes de recursos.

source config_env.sh

10. Adicione permissões para o projeto. Para adicionar permissões, siga os detalhes na página da Web de concessão de um papel do IAM.

Você precisa das seguintes permissões para este projeto

• Gravador do Artifact Registry
• Administrador do Cloud Scheduler
• Agente de serviço do Compute
• Usuário da carga de trabalho de computação confidencial
• Gravador de registros
• Desenvolvedor do Cloud Run
• Chamador do Cloud Run

gcloud config set project $CURRENT_PROJECT_ID

# Add Artifact Registry Writer role
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/artifactregistry.writer'

# Add Confidential Space Workload Userd
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/confidentialcomputing.workloadUser'

# Add Logging Log Writer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/logging.logWriter'

# Add Cloud Run Developer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.developer'

# Add Cloud Run Invoker
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.invoker'


# Add Cloud Scheduler Admin
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/cloudscheduler.admin'

11. Confira test_workload.py

• Verifique a saída da carga de trabalho revisando o código-fonte. Ele deve apenas imprimir a versão atual da carga de trabalho.
• Quando enviamos nossa carga de trabalho para o CS e verificamos a saída, vemos "versão A" impressa.

4. Como configurar a carga de trabalho

Primeiro, crie uma imagem Docker para a carga de trabalho usada neste codelab. A carga de trabalho é um script simples que imprime a versão da carga de trabalho que você está executando. Ele vai imprimir que a carga de trabalho está sendo iniciada, depois a versão dela, aguardar 5 segundos e imprimir que a carga de trabalho foi concluída.

Etapas para criar uma carga de trabalho

1. Execute create_workload.sh para criar a carga de trabalho. Este script:

• Cria o Artifact Registry pertencente ao projeto em que a carga de trabalho será publicada.
• Cria o código e o empacota em uma imagem Docker. Consulte a configuração do Dockerfile associada para mais informações.
• Publica a imagem Docker no Artifact Registry pertencente ao projeto.
• Concede à conta de serviço <nome da sua conta de serviço> permissões de leitura para o registro de artefatos <nome do repositório do registro de artefatos>

5. Como configurar um modelo de instância e um MIG

Etapas para criar um modelo de instância

Primeiro, crie um modelo de instância. Esse modelo é o blueprint necessário que o grupo gerenciado de instâncias (MIG) vai usar para provisionar e executar suas cargas de trabalho no Confidential Space.

O modelo de instância é essencial porque define todos os parâmetros especializados:

• Tipo de máquina:neste exemplo, usamos um tipo de máquina VM confidencial (por exemplo, n2d-standard-2) que oferece suporte à tecnologia de computação confidencial AMD SEV (--confidential-compute-type=SEV).
• Imagem do SO da VM:usamos o confidential-space-images projeto e a confidential-space-debug família de imagens para extrair a imagem mais recente do sistema operacional do Confidential Space.
• Observação:usamos a imagem debug neste guia para facilitar a solução de problemas. Ao contrário da imagem de produção, a versão de depuração mantém a VM em execução após a conclusão da carga de trabalho e permite o acesso SSH para testes. Para implantações de produção que usam dados sensíveis do mundo real, mude para a família de imagens de produção.
• Referência da carga de trabalho:a linha obrigatóriatee-image-reference nos metadados contém a imagem de contêiner específica (sua carga de trabalho de aplicativo) que a VM do Confidential Space vai iniciar.

Essa configuração garante que cada VM criada pelo MIG seja um Confidential Space configurado corretamente e pronto para executar sua carga de trabalho.

Etapas para criar um grupo gerenciado de instâncias

A próxima etapa é criar o grupo gerenciado de instâncias (MIG) usando o modelo que você acabou de definir. O MIG é essencial porque automatiza a implantação, o gerenciamento e o escalonamento de várias VMs idênticas.

O script create_launch_mig.sh cumpre três objetivos principais:

1. Criar o MIG

• Comando: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
• Finalidade:esse comando cria o grupo que vai gerenciar suas VMs.
• --size 3: especifica que o MIG deve criar e manter inicialmente três instâncias da sua carga de trabalho.
• --template ${TEMPLATE_NAME}: é fundamental que ele faça referência ao modelo de instância criado anteriormente, garantindo que todas as três instâncias sejam configuradas como VMs do Confidential Space executando seu contêiner de carga de trabalho tee-image-reference específico.
• --zone ${CURRENT_PROJECT_ZONE}: especifica o local de implantação das instâncias.

2. Buscar número do projeto

• Comando: PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
• Finalidade:o script busca o ID numérico do seu projeto. Esse número é geralmente necessário para criar papéis e permissões de contas de serviço, especialmente para agentes de serviço gerenciados pelo Google.

3. Conceder permissões do IAM

• Comando: gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
• Finalidade:esta etapa concede o papel de Agente de serviço do Compute Engine à conta de serviço da sua carga de trabalho (${SERVICE_ACCOUNT}). Essa permissão é importante porque permite que a conta de serviço atue em nome do serviço do Compute Engine do projeto, o que geralmente é necessário para os recursos automatizados do MIG, como gerenciamento de instâncias, configuração de rede e interação com outros serviços do Google Cloud.

Execute create_launch_mig.sh para criar o grupo gerenciado de instâncias.

6. Etapas para ativar a recuperação automática e o escalonamento automático

Como configurar a recuperação automática

Para garantir a alta disponibilidade, verificamos se a carga de trabalho está responsiva. Se o aplicativo congelar, o MIG vai substituir a VM. As regras de firewall para intervalos de IP de origem estão definidas neste documento.

# 1. Create Health Check (TCP Port 22)
gcloud compute health-checks create tcp ${HEALTH_CHECK_NAME} \
  --port 22 \
  --check-interval 30s \
  --healthy-threshold 1 \
  --timeout 10s \
  --unhealthy-threshold 3 \
  --global

# 2. Allow Health Check Traffic (Firewall)
gcloud compute firewall-rules create allow-health-check \
    --allow tcp:22 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default \
    --project="${CURRENT_PROJECT_ID}" \ 

# 3. Apply to MIG
gcloud compute instance-groups managed update ${CURRENT_MIG_NAME} \
    --health-check ${HEALTH_CHECK_NAME} \
    --initial-delay 60 \
    --zone ${CURRENT_PROJECT_ZONE}

Como configurar o escalonamento automático

Vamos configurar o grupo para escalonar automaticamente entre 1 e 5 instâncias para lidar com picos de tráfego.

gcloud compute instance-groups managed set-autoscaling ${CURRENT_MIG_NAME} \
    --max-num-replicas 5 \
    --target-cpu-utilization 0.80 \
    --cool-down-period 90 \
    --zone ${CURRENT_PROJECT_ZONE}

7. Verificar a carga de trabalho e configurar atualizações de imagem

Verificar carga de trabalho

Depois que o grupo gerenciado de instâncias (MIG) iniciar as VMs, precisamos verificar se a carga de trabalho do Confidential Space está sendo executada corretamente.

Você pode fazer isso pelo Console do Google Cloud ou pela linha de comando.

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} \
    --zone ${CURRENT_PROJECT_ZONE}

Você também pode verificar a saída da porta serial dessa instância específica para conferir o registro da sua carga de trabalho.

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Como configurar as atualizações de imagem

Em um ambiente de produção, o grupo gerenciado de instâncias (MIG) precisa ser atualizado regularmente para lidar com dois cenários distintos:

1. Atualizações de carga de trabalho:lançamento de uma nova versão do código do aplicativo (por exemplo, atualização de test_workload.py da v1 para a v2).
2. Atualizações de infraestrutura:o Google lança um patch de segurança ou uma atualização para o SO do Confidential Space. É recomendável buscar a imagem mais recente do CS pelo menos uma vez por mês.

Como configuramos nosso modelo de instância com um link de imagem dinâmica (.../images/family/...) e uma tag de contêiner dinâmica (:latest), podemos processar os dois cenários com uma única operação "Substituição gradual". Isso garante que sua frota de VMs esteja sempre executando a pilha mais recente sem inatividade e sem exigir que você crie um modelo de instância para cada pequena mudança.

O script de substituição gradual

No diretório update_images, navegue até update_images_script.sh. Esse script aciona uma substituição gradual, que destrói e recria gradualmente todas as VMs do grupo.

#!/bin/bash

# Initialize the template
gcloud compute instance-groups managed set-instance-template "${CURRENT_MIG_NAME}" \
--template=projects/"${PROJECT_ID}"/global/instanceTemplates/"${TEMPLATE_NAME}" \
--zone="${CURRENT_PROJECT_ZONE}" \
--project="${PROJECT_ID}"

# Trigger the rolling replace
gcloud compute instance-groups managed rolling-action replace "${CURRENT_MIG_NAME}" \
    --version=template="${TEMPLATE_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --version-target-reached "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${PROJECT_ID}"

Para esse script, podemos usar "replace" em vez de "restart".

• Um reinicio apenas reinicializa a máquina. Ele preserva o disco do SO atual, o que significa que não vai receber novos patches do SO.
• Um Replace exclui a VM e cria uma nova do modelo. Isso força o sistema a pesquisar a imagem do SO mais recente do Confidential Space na família e extrair a imagem do contêiner "Mais recente" do registro.

--max-surge=1: permite que o MIG crie temporariamente uma VM extra acima do tamanho de destino. Ele inicia uma nova VM (atualizada) e espera que ela fique íntegra antes de excluir uma VM antiga (desatualizada).

–max-unavailable=0: garante inatividade zero. Ele informa ao MIG que não é permitido colocar nenhuma máquina off-line, a menos que ela já tenha substituído uma com sucesso.

O script de reinicialização contínua

No diretório update_images, há também outro script update_workload_image_script.sh. Esse script aciona uma reinicialização gradual, um método mais rápido usado estritamente para atualizar a carga de trabalho. Como o Confidential Space extrai a imagem do contêiner do registro a cada inicialização, uma reinicialização é suficiente para atualizar o aplicativo para a versão :latest sem alterar o host subjacente.

#!/bin/bash
# Reboots the existing VMs to refresh the container
gcloud compute instance-groups managed rolling-action restart "${CURRENT_MIG_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --stable "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${CURRENT_PROJECT_ID}"

Verificar a carga de trabalho atualizada

Podemos testar a "Atualização com um clique" simulando o lançamento de um aplicativo real. Vamos modificar o código da carga de trabalho, enviá-lo ao Artifact Registry, atualizar o MIG e verificar se a nova versão está sendo executada sem tempo de inatividade.

Etapa 1: implantar uma nova versão da carga de trabalho

Primeiro, precisamos criar uma versão "nova" do seu aplicativo.

1. Abra o arquivo local test_workload.py.
2. Mude a instrução de exibição da versão de print("Workload Version A") para print("Workload Version B")
3. Recrie e envie a imagem do contêiner para o Artifact Registry executando create_workload.sh. Estamos enviando para a mesma tag (:latest).

Etapa 2: executar a atualização gradual

Execute o script de atualização que criamos na seção anterior. Isso vai forçar o MIG a substituir todas as VMs, extraindo o novo hash do contêiner associado a :latest.

# Run your update script
./update_images/update_images_script.sh

Aguarde a conclusão do script

Etapa 3: verificar a atualização pela porta serial

Depois que a atualização é concluída, verificamos se as novas VMs estão executando o código atualizado.

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Receber o nome de uma nova instância:

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} --zone ${CURRENT_PROJECT_ZONE}

Verifique os registros:

# Replace <NEW_INSTANCE_NAME> with one of the names of the running VMs
gcloud compute instances get-serial-port-output <NEW_INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

Quando as instâncias estiverem em execução, selecione qualquer nome de instância do comando gcloud anterior para conferir a porta serial.

Saída esperada:você vai ver a mensagem de registro atualizada, confirmando que a implantação foi concluída:

... Versão B da carga de trabalho ...

Etapa 4: verificar a configuração da infraestrutura (opcional)

Você também pode verificar se o modelo de instância está configurado corretamente para extrair atualizações dinâmicas do SO e da carga de trabalho inspecionando os metadados.

Execute o comando a seguir para ver a referência do contêiner dinâmico:

gcloud compute instance-templates describe ${TEMPLATE_NAME} \
    | grep -A 1 tee-image-reference

Resultado:a imagem do contêiner vai terminar com :latest.

• Implicação:como o modelo aponta para a tag e não para um hash específico, toda substituição de ação contínua extrai o código mais recente enviado na etapa 1.

(Opcional) Atualizações automáticas

Embora as atualizações manuais sejam úteis para lançamentos de versões principais, muitas vezes você quer que sua frota receba automaticamente os patches de segurança mais recentes ou builds de implantação regulares sem intervenção humana.

Podemos automatizar o processo "Substituição gradual" agrupando nosso script de atualização em um job do Cloud Run. Neste codelab, vamos acionar a cada 15 minutos. Em um ambiente de produção, ele precisa ser executado com muito menos frequência. Dependendo das necessidades do usuário, ele pode configurar o recurso semanalmente ou mensalmente.

Etapa 1: colocar o script do Updater em um contêiner

Primeiro, precisamos empacotar nosso update_images_script.sh (que contém a lógica gcloud ... rolling-action replace) em um contêiner do Docker para que ele possa ser executado na nuvem.

Preparamos um script auxiliar que cria esse contêiner e o envia por push para o Artifact Registry.

Execute este comando:

# Build and Push the "Updater" Container
# This packages your update logic into a docker image
./update_images/deploy_docker_script_image.sh

O que isso faz:

• Ele usa o update_images_script.sh do diretório update_images/.
• Ele cria uma imagem Docker que contém o SDK Google Cloud e seu script.
• Ele envia a imagem para ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest.

Etapa 2: implantar e programar o job

Agora precisamos instruir o Google Cloud a executar esse contêiner periodicamente. Usamos o Cloud Run Jobs para executar o contêiner e o Cloud Scheduler para acioná-lo.

Execute o script de configuração de programação:

# Create the Cloud Run Job and the Scheduler Trigger
./create_configs/create_schedule_job.sh

Dentro do script:esse script executa duas ações importantes:

1. Cria um job do Cloud Run:define um job chamado mig-updater-job que executa o contêiner que acabamos de enviar.
2. Cria um gatilho do Scheduler:configura um job do Cloud Scheduler para acessar a API Cloud Run Job a cada 15 minutos.

# (Snippet from create_schedule_job.sh for reference)
# The schedule is set to run every 15 minutes for testing purposes
gcloud scheduler jobs create http ${SCHEDULER_NAME} \
    --schedule "*/15 * * * *" \
    --uri "https://${CURRENT_PROJECT_REGION}-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/${PROJECT_ID}/jobs/${JOB_NAME}:run" \
    --http-method POST \
    --oauth-service-account-email ${SERVICE_ACCOUNT}

Etapa 3: verificar a automação

Não é necessário esperar 15 minutos para testar. Você pode forçar o agendador a ser executado imediatamente para verificar o pipeline.

1. Forçar a execução do job:

gcloud scheduler jobs run ${SCHEDULER_NAME} --location ${CURRENT_PROJECT_REGION}

2. Verificar execução:acesse o console do Cloud Run > Jobs. Uma nova execução vai começar.
3. Verifique o MIG:execute gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME}. Você vai ver as instâncias entrando no estado "RECREATING" à medida que o job aciona a atualização gradual.

Por que 15 minutos? Definimos a programação como */15 * * * * para este codelab para que você possa ver os resultados rapidamente. Em um ambiente de produção real, você provavelmente mudaria isso para execução diária (por exemplo, 0 3 * * * para 3h) ou semanal.

8. Limpeza

O script cleanup.sh pode ser usado para limpar os recursos criados como parte deste codelab. Como parte dessa limpeza, os seguintes recursos serão excluídos:

• O grupo gerenciado de instâncias (${CURRENT_MIG_NAME}) e as VMs subjacentes.
• O modelo de instância (${TEMPLATE_NAME}).
• A verificação de integridade e as regras de firewall (${HEALTH_CHECK_NAME}).
• O repositório do Artifact Registry (${REPOSITORY}).
• A conta de serviço (se você criou uma dedicada para este laboratório).

Se você já terminou de explorar, considere excluir seu projeto seguindo estas instruções: Como encerrar (excluir) projetos.

Parabéns

Parabéns, você concluiu o codelab.

Você aprendeu a escalonar com segurança as cargas de trabalho do Confidential Space usando grupos gerenciados de instâncias (MIGs). Você configurou o recuperação automática para se recuperar de falhas, o escalonamento automático para lidar com picos de tráfego e realizou atualizações sem tempo de inatividade para a imagem do SO do Confidential Space e o contêiner de carga de trabalho.

Qual é a próxima etapa?

Confira outros codelabs do Confidential Space:

• Como proteger modelos de ML e propriedades intelectuais usando o Confidential Space
• Instruções: como fazer transações de ativos digitais com computação multipartidária e o Confidential Space
• Analisar dados confidenciais com o Confidential Space
• Usar o Confidential Space com recursos protegidos que não estão armazenados com um provedor de nuvem

Leia mais

• Escalonamento com base nas métricas do Monitoring
• Está se sentindo isolado? A computação confidencial para salvar o dia
• Computação confidencial no GCP
• Confidential Space: o futuro da colaboração que preserva a privacidade
• Visão geral da segurança do Confidential Space
• Reforçar a privacidade de dados: colaboração confidencial multipartidária em grande escala