Rejeite infraestrutura inválida antes do planejamento

Introdução

Sua equipe já tem armazenamento de relatórios gerenciado pelo Terraform. Antes de adicionar implantações automatizadas, você precisa de um job que rejeite configurações mal formatadas ou estruturalmente inválidas antes de chegar ao planejamento.

Você configurará duas verificações estáticas obrigatórias, observará cada uma interromper um job em execução e corrigirá a configuração. Você já deve compreender a configuração do Terraform, plano/estado, conceitos básicos de Git e códigos de saída do shell. O ambiente preparado não exige uma conta pessoal da AWS.

Relação com certificações

Adicione verificações antes do plano

Nesta etapa, você conectará verificações estáticas a um job sequencial fornecido. O bucket e o relatório existentes são infraestrutura de apoio: este laboratório deve manter seus dados e o estado do Terraform inalterados.

Use a interface Terminal. Entre no repositório Git fornecido e carregue o ambiente de ferramentas. source aplica as variáveis preparadas ao shell atual; ele não implanta infraestrutura.

cd /home/labex/project/report-delivery
source environment.sh

Inspecione a configuração dos recursos e as etapas atuais do job. cat imprime cada arquivo para que você possa ver o que o job gerencia e o que ele executa.

cat main.tf pipeline.json

O bucket tem uma tag Purpose. Atualmente, o job tem apenas uma etapa plan. Um plano bem-sucedido, por si só, não demonstra que as verificações de formatação e estrutura foram executadas antes.

terraform fmt -check verifica a formatação canônica do Terraform sem reescrever arquivos. terraform validate verifica se a configuração inicializada é internamente consistente, incluindo os atributos de recursos suportados. Nenhum deles comprova que a configuração atende aos requisitos de negócio; as asserções de módulos serão abordadas no próximo laboratório.

O executor fornecido mapeia nomes de etapas para comandos fixos do Terraform e para no primeiro erro. Mantenha run-job.py inalterado: sua tarefa é configurar pipeline.json, e não reescrever o executor fornecido. As verificações confirmam que o ponto de entrada em uso corresponde ao original fornecido antes de avaliar seu comportamento. Adicione as duas verificações antes do planejamento. O here-document escreve o JSON entre seus delimitadores em pipeline.json; colocar EOF entre aspas preserva seu conteúdo literal.

cat > pipeline.json <<'EOF'
{"stages":["fmt","validate","plan"]}
EOF

Execute o job com o interpretador padrão do Python. Este é um executor local didático; suas etapas executam comandos padrão do Terraform.

python3 run-job.py

Espere [fmt] native exit 0, [validate] native exit 0 e [plan] native exit 0. O plano informa que não há alterações porque a infraestrutura fornecida já corresponde à sua configuração. Um erro interrompe as etapas posteriores. Um plano com alterações usa o código de saída nativo 2, que o executor trata como uma prévia bem-sucedida, nunca como autorização para aplicar.

Inspecione sua alteração com o Git. -- separa o caminho das opções do comando.

git diff -- pipeline.json

O diff deve mostrar as duas novas verificações obrigatórias antes de plan. Não existe uma etapa de aplicação neste job.

Interrompa diante de um erro de formatação

Nesta etapa, você introduzirá uma expressão HCL válida com espaçamento fora do padrão canônico e comprovará que a verificação de formatação interrompe o job antes do planejamento.

Acrescente um pequeno bloco de saída. >> acrescenta conteúdo ao arquivo existente. O espaçamento compacto é intencional; a saída não gerencia um novo recurso.

cat >> main.tf <<'EOF'

output "format_probe" {value="spacing"}
EOF

Execute o job novamente. Espera-se que este comando falhe; a falha é o resultado útil.

python3 run-job.py

A primeira etapa informa o código de saída nativo 3 e lista main.tf. O job imprime Job stopped; later stages did not run. Não deve haver nenhuma linha [validate] ou [plan]. A formatação pode ser corrigida sem contatar a AWS.

Inspecione as alterações exatas de formatação propostas. -diff as mostra, enquanto -check mantém o arquivo inalterado.

terraform fmt -check -diff

Este comando também retorna intencionalmente um código de saída diferente de zero. Mantenha o defeito de formatação para a verificação desta etapa; a próxima etapa o corrige.

Diferencie formatação de validade

Nesta etapa, você corrigirá a formatação e, em seguida, introduzirá um erro diferente que apenas a validação estrutural detecta.

Primeiro, deixe o Terraform reescrever o espaçamento no próprio arquivo. Executar fmt sem -check faz a alteração de formatação.

terraform fmt

A saída lista main.tf. Confirme que a configuração corrigida passa pelo job.

python3 run-job.py

Todas as etapas devem ser executadas. A saída adicional pode fazer plan retornar o código de saída nativo 2; ele propõe uma alteração de saída sem aplicá-la.

Agora acrescente uma referência a um atributo que o recurso de bucket S3 não exporta. Este bloco usa a formatação canônica e, por isso, pode passar pela primeira verificação.

cat >> main.tf <<'EOF'

output "missing" {
  value = aws_s3_bucket.reports.missing_attribute
}
EOF

Verifique primeiro apenas a formatação.

terraform fmt -check

O comando retorna zero sem imprimir nada. Em seguida, execute o job completo.

python3 run-job.py

Espere que a verificação de formatação passe, seguida pelo código de saída nativo 1 de validate e por um diagnóstico Unsupported attribute. Não deve haver nenhuma linha da etapa de planejamento. A expressão está formatada corretamente, mas faz referência a um atributo não suportado. Mantenha esse erro para a verificação da etapa.

Corrija a configuração e preserve o ambiente

Nesta etapa, você restaurará a configuração de recursos sabidamente válida, executará novamente o job com as verificações obrigatórias e verificará se o armazenamento dos relatórios permanece inalterado.

git restore -- main.tf restaura apenas esse arquivo a partir do commit inicial do repositório. Ele remove as duas saídas experimentais e mantém suas alterações separadas em pipeline.json.

git restore -- main.tf

Execute o job completo novamente.

python3 run-job.py

As três etapas devem retornar o código de saída nativo 0. O plano deve informar que não há alterações. Passar pelas verificações estáticas permite o planejamento; isso não aprova nem aplica uma implantação.

Leia o relatório diretamente do armazenamento. - envia seu conteúdo para a saída padrão, em vez de salvar outra cópia local.

aws s3   cp s3://delivery-gates-reports/report.csv -

Espere:

quarter,total
Q1,320

Inspecione o relatório vizinho que este exercício deve preservar.

aws s3   cp s3://delivery-gates-neighbor/keep.txt -

Ele ainda deve dizer preserve neighboring report. Revise o diff final do Git para confirmar que sua alteração persistente é a configuração do pipeline.

git diff -- main.tf pipeline.json

Não destrua nenhum dos dois buckets preparados: eles representam infraestrutura existente da equipe. O job não tem uma etapa de implantação nem de salvamento de plano, portanto não deixa novos recursos de nuvem ou artefatos de plano para limpar. Os experimentos temporários com saídas foram removidos pela restauração de main.tf. Mantenha suas verificações de qualidade obrigatórias para a verificação final.

Resumo

Você construiu um job sequencial do Terraform com formatação e validação estrutural antes do planejamento. Observou uma falha de formatação e uma falha separada de atributo não suportado interromperem as etapas posteriores e, em seguida, corrigiu a configuração e preservou os dados dos relatórios e o estado.

A validade estática é uma camada de qualidade. No próximo laboratório, asserções executáveis de módulos verificam se uma configuração válida produz o comportamento pretendido. Consulte a referência de fmt e a referência de validate oficiais para conhecer as verificações usadas aqui.