Google Cloud Provider 8.0: um default novo pode mudar sua infraestrutura

O Google Cloud Provider 8.0 para Terraform chegou à disponibilidade geral com alterações incompatíveis.[14] A HashiCorp recomenda passar primeiro pela versão mais recente da série 7.x e resolver os avisos de depreciação antes da migração.[14] A mudança mais fácil de ignorar não está numa linha que deixa de validar, mas num campo omitido que passa a significar outra coisa.

O que muda para quem desenvolve

Em google_compute_backend_service e google_compute_global_forwarding_rule, o default de load_balancing_scheme muda de EXTERNAL para EXTERNAL_MANAGED.[14] Configurações sem valor explícito passam a apontar para o Application Load Balancer externo novo, em vez do Classic.[14]

Minha leitura: infraestrutura declarativa continua dependendo de semântica versionada. Um arquivo igual não significa uma intenção igual quando o provider muda. Recomendo tornar explícitas as escolhas que precisam permanecer estáveis e conferir sua tradução no plano.

A versão remove google_iap_brand e google_iap_client.[14] Os recursos google_notebooks_* são substituídos por google_workbench_instance.[14] Alguns atributos mudam de listas para conjuntos, e source_contents passa a ser obrigatório em google_workflows_workflow.[14] Isso exige revisar tanto recursos quanto expressões que dependam dos tipos anteriores.

Não tente resolver todas as diferenças como ruído de atualização. Separe alteração de representação, migração necessária e mudança real de infraestrutura. Cada categoria pede uma decisão diferente.

Como aplicar

Crie uma cópia controlada da configuração e fixe as versões usadas no ensaio. Gere primeiro um plano de referência na linha 7.x atualizada, resolvendo depreciações. Depois, compare com o plano da 8.0 sem aplicar nada automaticamente.

Procure os dois recursos de balanceamento afetados e identifique os que omitem load_balancing_scheme. Quando a intenção for preservar o comportamento clássico, declare EXTERNAL explicitamente, conforme a orientação reportada.[14] Revise também qualquer proposta de substituição ou destruição antes de seguir.

Liste recursos removidos e atributos cujo tipo mudou. Se uma expressão indexa uma coleção pela posição, confira se essa escolha ainda faz sentido. Documente a transformação pretendida e seu efeito no objeto remoto.

O critério de aceitação do experimento deve ser um plano compreendido: cada criação, alteração, substituição e remoção tem uma justificativa ligada ao objetivo da migração. Plano sem erro não basta. Só depois programe aplicação e verificação funcional no escopo autorizado.

Cuidados e limites

O provider oferece atributos write-only para valores sensíveis em recursos com suporte, evitando armazenar esses valores no estado.[14] Isso não significa que todos os dados sensíveis do projeto desapareçam do estado ou de outros artefatos. Mantenha controles de acesso e examine o que cada recurso realmente suporta.

Para OpenTofu, write-only exige versão 1.11 ou posterior, enquanto a reportagem não confirma suporte a Resource Identity nem equivalência ao fluxo Terraform query.[14] Não assuma compatibilidade integral entre CLIs.

A matéria não lista todas as remoções.[14] Portanto, use esta notícia para iniciar a revisão, não como checklist exaustivo. A mudança segura é aquela cujo plano você consegue explicar antes de executá-lo.

Fonte

[14] Fonte: InfoQ