Cloud workers: infraestrutura, runtime e operações

Objetivo e pré-requisitos

Cloud workers contém Workers, Provisioning history, Connections e Profiles. O registro Dova, a VM no provedor e o agente de execução são estados relacionados, mas distintos. Antes de provisionar, confirme tenant, conta cloud autorizada, permissões, regiões e capacidade. Google Cloud, AWS e Azure são tipos de conexão; a operação disponível depende das capacidades efetivas do provedor e do seu papel.

Uma conexão aprovada deve existir e satisfazer as regras de identidade, rede e localização. Um perfil define os recursos solicitados. A estimativa opcional de preço não garante valor de fatura nem disponibilidade de capacidade. Use um laboratório autorizado para praticar; os exemplos não autorizam criar recursos em uma conta de produção.

Preparar a conexão cloud

1. Abra Connections → New connection.
2. Preencha Name, Provider, Account / project ID e Default region.
3. Complete a identidade e a rede específicas do provedor com a configuração aprovada. Use federação ou impersonação temporária conforme o fluxo; não informe senhas cloud ou chaves privadas nesse formulário.
4. Escolha Authorized regions e confirme que a região padrão está incluída.
5. Use Save connection, siga as instruções de verificação e, se necessário, Copy steps. Execute Verify ou Re-verify.
6. Em Capacity, confira a capacidade e a margem para novos workers. Valores indisponíveis ou desconhecidos exigem investigação.

Preparar o perfil

1. Abra Profiles → New profile.
2. Defina Name, Provider, vCPU, Memory (GB) e Disk (GB).
3. Em SKU compatibility, diferencie Exact resources, que requer um tamanho correspondente, de Allow next larger SKU, que permite a seleção maior suportada.
4. Revise Status e as informações opcionais de preço, salve em Save profile e reabra o registro para confirmar os recursos.

Provisionar e verificar

1. Em Workers, selecione Provision worker.
2. Confirme Tenant e Worker access. Leia a diferença entre Private to this tenant e Public shared.
3. Selecione Cloud connection, Worker profile e Maximum concurrent slots.
4. Defina Worker name, Region e Zone quando exigido pelo provedor. Resolva erros de localização pelo controle de atualização suportado.
5. Use Continue e Back para revisar as etapas; solicite Get optional quote apenas se a estimativa for útil.
6. Selecione Create worker uma vez e acompanhe Provisioning history. Confirme separadamente recurso cloud, inscrição do agente, heartbeat e elegibilidade.

Diferenciar Status e Runtime

Use Refresh para atualizar a observação do provedor. Abra More actions ou o menu contextual da linha para as ações autorizadas. O acesso direto da linha abre View details. Ative a coluna opcional Runtime em Columns. Um worker público compartilha capacidade entre tenants autorizados; não torna pública uma Session, seus dados ou suas credenciais.

Operar planejamento, VM e Reset

Pause scheduling interrompe novas atribuições e permite terminar as atuais; Resume scheduling volta a admiti-las. Essas ações não suspendem ou retomam a VM no provedor. Pause scheduling, quando oferecido, é o fluxo de esvaziamento. Start VM e Stop VM dependem do estado e da autorização; Start VM também pode retomar uma VM suspensa quando o provedor permitir. Um worker padrão, ocupado ou público pode bloquear Stop VM.

Reset VM reinicia de forma forçada uma VM GCP Running e exige confirmação. Antes do envio, Dova verifica novamente a ausência de trabalhos, execuções e reservas ativas em todos os tenants autorizados a usar o worker. Um worker padrão ou público pode ser reiniciado se essa verificação completa confirmar inatividade; referências e política de compartilhamento são preservadas. A ação aparece apenas para provedores e estados compatíveis.

Enquanto o Reset não tiver resultado confirmado, novas atribuições e outro Reset ficam bloqueados. Reset pending ou Check reset informa a operação separadamente do Status principal da VM. Use Refresh para consultar, sem reenviar. Running, por si só, não prova conclusão; é necessário resultado da operação nativa e uma observação válida. Após a confirmação, Runtime ainda depende do próximo heartbeat para demonstrar prontidão do processo.

Rede de workers GCP

Novos workers GCP são provisionados apenas com IP privado, sem seletor de IP público. Configure Cloud NAT na região da sub-rede para HTTPS de saída até Dova e os destinos de pacotes e dependências autorizados, como Debian, PyPI e GitHub. Private Google Access atende APIs Google, mas não substitui Cloud NAT para destinos externos. Revise DNS e regras de saída exigidas pelos conectores autorizados.

Para manutenção, use IAP SSH com OS Login quando os papéis IAM e o firewall estiverem configurados. O agente obtém trabalhos e envia heartbeat por conexões de saída; não precisa de uma porta de aplicação aberta para receber trabalhos. A política public_shared trata de capacidade compartilhada e é independente de IP público.

Exemplo e falhas comuns

No laboratório, prepare worker-demo-a, confira Status, Runtime, heartbeat e slots e associe uma Session sintética compatível. Execute uma transformação pequena e confirme o resultado no Monitor. Se uma criação ou Reset demorar, consulte a operação antes de repetir. Para um worker Online, mas inelegível, revise tenant, capacidades e slots. Para uma VM Running com Runtime Offline, revise o serviço e a conectividade sem expor logs sensíveis.

Consulte também: Instalação, Migração e retirada, Overview.