Proteja o histórico dos relatórios durante atualizações

Introdução

Um relatório mais recente não deve eliminar a capacidade da equipe de ler seus dados anteriores. Você configurará o versionamento, publicará dois relatórios e separará leituras históricas de leituras atuais antes de limpar deliberadamente este armazenamento descartável.

Use os conhecimentos de variáveis, referências a objetos e diretórios raiz independentes do laboratório anterior. Este novo ambiente fornece apenas ferramentas, acesso pelo provedor e um relatório de referência não relacionado.

Relação com certificações

Publique a primeira versão

Nesta etapa, você gerenciará a configuração de versionamento do bucket com o Terraform antes de publicar seu primeiro relatório.

As versões de objetos do S3 são cópias preservadas dos dados, cada uma com um ID de versão. Elas são diferentes das revisões de HCL no Git e do arquivo de bloqueio de provedores do Terraform. O Terraform pode configurar o versionamento; o S3 então preserva versões de objetos quando os dados são atualizados. Um plano sem alterações, por si só, não comprova que os dados históricos podem ser lidos.

Entre no diretório raiz preparado e escreva a definição do armazenamento:

cd /home/labex/project/report-history
cat > main.tf <<'EOF'
variable "report" { type = string }

resource "aws_s3_bucket" "reports" {
  bucket = "terraform-history-reports"
}

resource "aws_s3_bucket_versioning" "reports" {
  bucket = aws_s3_bucket.reports.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_object" "report" {
  bucket       = aws_s3_bucket.reports.id
  key          = "reports/current.csv"
  content      = var.report
  content_type = "text/csv"
  depends_on   = [aws_s3_bucket_versioning.reports]
}
EOF

Agora há três recursos: um bucket, suas configurações de versionamento e um objeto. O objeto já depende do bucket por meio da referência ao seu ID. O depends_on explícito adiciona a ordem que não pode ser inferida dessa referência: o versionamento deve ser habilitado antes do primeiro upload.

Escreva a entrada do primeiro relatório e inicialize:

cat > release1.tfvars <<'EOF'
report = "orders,12\n"
EOF
terraform init
terraform validate
terraform plan -var-file=release1.tfvars

Espere três adições. Aplique e digite yes:

terraform apply -var-file=release1.tfvars

Consulte a configuração efetiva e a primeira versão:

aws s3api \
  get-bucket-versioning \
  --bucket terraform-history-reports
aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query 'Versions[].{Key:Key,VersionId:VersionId,Current:IsLatest}'

O status é Enabled. O relatório tem um ID de versão não nulo e Current: true. O AWS View mostra o objeto atualmente disponível para leitura; use a consulta de versões para inspecionar o histórico.

Atualize o relatório e leia seu histórico

Nesta etapa, você publicará bytes diferentes, lerá explicitamente a versão antiga e comprovará que ler o histórico mantém o relatório atual inalterado.

Crie um segundo arquivo de entradas. Manter os dois arquivos facilita comparar as versões pretendidas dos dados; os arquivos em si não são o histórico armazenado.

cat > release2.tfvars <<'EOF'
report = "orders,25\n"
EOF
terraform plan -var-file=release2.tfvars -out=update.tfplan
terraform show update.tfplan

Espere uma atualização de objeto sem substituição do bucket. -out salva um artefato de plano que inclui os valores de entrada selecionados. Aplique esse artefato revisado; este comando não pede confirmação porque você já selecionou o plano salvo:

terraform apply update.tfplan

Liste novamente as versões efetivas:

aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query 'Versions[].{Key:Key,VersionId:VersionId,Current:IsLatest}'

As entradas antiga e atual têm IDs de versão diferentes. Selecione o ID do relatório mais antigo e exiba-o. A consulta filtra a chave do relatório e IsLatest == false; [0] escolhe a primeira entrada antiga correspondente no histórico de duas versões deste laboratório.

OLD_VERSION=$(aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query 'Versions[?Key==`reports/current.csv` && IsLatest==`false`].VersionId | [0]' \
  --output text)
echo "$OLD_VERSION"
CURRENT_VERSION=$(aws s3api \
  head-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  --query VersionId \
  --output text)
echo "$CURRENT_VERSION"

Baixe a versão antiga pelo ID e, em seguida, baixe a versão atual sem um ID de versão:

aws s3api \
  get-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  --version-id "$OLD_VERSION" \
  old-report.csv
cat old-report.csv
aws s3api \
  get-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  current-report.csv
cat current-report.csv

Espere orders,12 no arquivo antigo e orders,25 no arquivo atual. Um GET específico de versão lê uma versão existente; ele não a copia por cima do objeto atual. Consulte o ID atual mais uma vez e compare-o com o CURRENT_VERSION exibido:

aws s3api \
  head-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  --query VersionId \
  --output text

O ID permanece inalterado. Conclua a verificação desta etapa antes de excluir qualquer versão. A verificação lê os bytes efetivos antigos e atuais e preserva ambos. Consulte o versionamento do S3 para entender a distinção entre uma chave de objeto, suas versões e os marcadores de exclusão.

Remova deliberadamente o histórico sob sua responsabilidade

Nesta etapa, você fará o inventário e excluirá todas as versões do seu bucket descartável de relatórios antes de remover seus recursos de configuração do Terraform.

Destruir infraestrutura e decidir descartar o histórico dos relatórios são ações diferentes. Um bucket com versionamento não vazio normalmente não pode ser excluído. Remover um objeto atual sem um ID de versão pode criar um marcador de exclusão, que oculta o objeto atual enquanto as versões anteriores permanecem. Aqui, você excluirá explicitamente as versões inventariadas por ID, após comprovar a retenção na etapa anterior.

Crie uma solicitação de exclusão a partir da listagem nativa de versões. Este laboratório tem apenas um pequeno conjunto de versões de relatórios e nenhum marcador de exclusão existente; cada versão listada pertence ao seu bucket. --query transforma cada entrada nos campos Key/VersionId aceitos por delete-objects.

aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query '{Objects: Versions[].{Key:Key,VersionId:VersionId}}' \
  > owned-versions.json
cat owned-versions.json

Confira se o arquivo contém apenas versões de terraform-history-reports. Em seguida, exclua exatamente essas versões. file:// solicita à AWS CLI que leia uma solicitação JSON do arquivo local.

aws s3api \
  delete-objects \
  --bucket terraform-history-reports \
  --delete file://owned-versions.json
aws s3api \
  list-object-versions \
  --bucket terraform-history-reports

A listagem bem-sucedida não contém entradas Versions nem DeleteMarkers. Agora destrua os recursos deste diretório raiz e digite yes:

terraform destroy -var-file=release2.tfvars

O Terraform primeiro atualiza o estado consultando os recursos e pode perceber que o objeto já foi removido. Em seguida, remove a configuração de versionamento restante e o bucket vazio. Por fim, inspecione o mapeamento e a referência preservada:

terraform state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

A lista do estado está vazia, e apenas o bucket de referência da equipe permanece. Não use este procedimento de descarte de dados em um armazenamento cujo histórico precise ser preservado.

Resumo

Você distinguiu alterações de configuração de versões de dados, habilitou o versionamento antes do upload, leu bytes distintos dos relatórios antigo e atual sem sobrescrever a versão atual e fez explicitamente o inventário e o descarte apenas das versões sob sua responsabilidade.