Laboratório progressivo de infraestrutura e operações em nuvem, com atividades práticas em AWS, Linux, Terraform, Docker, CloudWatch, Zabbix, Bash e PowerShell.
O projeto documenta a construção e a operação de um ambiente de aplicação ao longo de uma trilha evolutiva: preparação da estação de trabalho, acesso seguro à nuvem, administração Linux, infraestrutura AWS, automação, observabilidade, troubleshooting, segurança, custos e confiabilidade.
Cada laboratório apresenta contexto, procedimentos, validações, evidências e, quando aplicável, scripts reutilizáveis e etapas de cleanup.
English summary: Hands-on cloud infrastructure and operations portfolio focused on AWS, Linux administration, automation, observability, troubleshooting, security and operational reliability. Each lab includes documented procedures, validation results and execution evidence.
Demonstrar competências práticas relacionadas às atividades de Cloud Operations, Infrastructure Operations, DevOps e SRE, por meio de cenários progressivos e reproduzíveis.
O repositório prioriza:
- execução prática e evidências verificáveis;
- segurança de acesso e proteção de informações sensíveis;
- diagnóstico antes de alterações;
- automação com escopo controlado;
- infraestrutura reproduzível;
- monitoramento, logs e resposta a falhas;
- controle de custos e remoção de recursos temporários;
- documentação técnica clara e rastreável.
| Categoria | Tecnologias e práticas |
|---|---|
| Cloud | AWS |
| Sistemas | Linux, Windows 11 e WSL |
| Infraestrutura como código | Terraform |
| Containers | Docker e Docker Compose |
| Observabilidade | Amazon CloudWatch e Zabbix |
| Automação | Bash e PowerShell |
| Acesso e identidade | AWS IAM Identity Center e AWS Systems Manager |
| Versionamento | Git e GitHub |
| Documentação | Markdown e Mermaid |
| Status | Laboratório | Conteúdo principal |
|---|---|---|
| Concluído | Lab 00 — Preparação da estação de trabalho | Git, VS Code, PowerShell e organização local |
| Concluído | Lab 01 — Configuração segura da conta AWS | Proteção da conta e acesso administrativo |
| Concluído | Lab 02 — AWS CLI e autenticação por SSO | Perfis, sessões temporárias e validação de identidade |
| Concluído | Lab 03 — Ferramentas de infraestrutura | Terraform e Session Manager Plugin |
| Concluído | Lab 04 — Arquivos e diretórios Linux | Navegação, busca e operações com arquivos |
| Concluído | Lab 05 — Usuários, grupos e permissões | Identidades, permissões e acesso compartilhado |
| Concluído | Lab 06 — Serviços e logs no Linux | systemctl, journalctl, diagnóstico e recuperação de serviço |
| Concluído | Lab 07 — Baseline operacional da conta AWS | Inventário somente leitura, segurança, tags, observabilidade e custos |
| Concluído | Lab 08 — Rede da aplicação na AWS | VPC, sub-redes, rotas, Internet Gateway, Security Group e cleanup |
| Concluído | Lab 09 — EC2 administrada pelo Systems Manager | EC2, IAM Role, Session Manager, validação e cleanup |
| Concluído | Lab 10 — Serviço web Nginx em Linux | Nginx, systemd, acesso HTTP restrito, Systems Manager, validação e cleanup |
| Concluído | Lab 11 — Armazenamento e recuperação | EBS, Amazon S3, integridade, cópia e restauração |
| Concluído | Lab 12 — Disponibilidade da aplicação | Application Load Balancer, health checks, distribuição de tráfego e recuperação |
| Concluído | Lab 13 — Troubleshooting de aplicação indisponível | Nginx, falha controlada, diagnóstico estruturado, recuperação e cleanup |
| Concluído | Lab 14 — Utilização de disco | Volume EBS dedicado, pressão controlada, diagnóstico, mitigação e cleanup |
| Concluído | Lab 15 — Troubleshooting de conectividade | Falha controlada no Security Group, diagnóstico por camadas, recuperação e cleanup |
| Concluído | Lab 16 — Troubleshooting do AWS Systems Manager | Falha controlada na saída HTTPS, diagnóstico SSM, recuperação e cleanup |
| Concluído | Lab 17 — Atualização controlada de aplicação | Baseline v1, falha de configuração, diagnóstico, rollback, atualização v2, confirmação e cleanup |
| Concluído | Lab 18 — Backup e restauração de aplicação | S3 versionado, SHA-256, perda controlada, diagnóstico, restauração por VersionId e cleanup |
O planejamento completo está disponível em docs/roadmap.md.
O Lab 18 — Backup e restauração de aplicação na AWS criou um backup verificável de quatro arquivos de uma aplicação Nginx em um bucket S3 privado e versionado. O pacote foi recuperado pelo VersionId registrado e conferido por SHA-256 e manifesto antes da simulação de perda.
A exclusão controlada de index.html e version produziu HTTP 404 em / e /version, enquanto o Nginx permaneceu ativo e /health continuou saudável. O diagnóstico identificou os arquivos ausentes. A restauração recuperou os dois arquivos da versão registrada; os quatro hashes finais coincidiram com o baseline e os testes HTTP locais e externos retornaram 200 com o conteúdo esperado.
O intervalo entre a perda e a recuperação observada localmente foi de 5 min 56,294 s, incluindo diagnóstico e espera do operador. O cleanup removeu EC2, volume root, Security Group, bucket e recursos IAM exclusivos, preservando a rede compartilhada do Lab 08.
Consulte o Lab 18 para os scripts, os resultados, os limites das medições e as evidências.
O Lab 17 — Atualização controlada de aplicação na AWS implantou uma aplicação Nginx na versão v1 e registrou seu estado inicial, com backup e hashes SHA-256. Uma candidata com diretiva inválida fez o teste nginx -t falhar, enquanto o serviço permaneceu ativo e continuou respondendo em v1. O diagnóstico confirmou que somente o arquivo de configuração diferia do backup.
O rollback restaurou os quatro arquivos da v1 com hashes idênticos aos do baseline. Em seguida, a candidata v2 passou pelas verificações do Nginx e pelos testes HTTP locais e externos, foi confirmada e manteve o backup v1. O cleanup removeu a instância EC2, o Security Group, o Instance Profile e a IAM Role exclusivos, preservando a VPC e a sub-rede compartilhadas do Lab 08.
Consulte o Lab 17 para o procedimento, os scripts, os estados validados e as evidências.
O Lab 16 — Troubleshooting do AWS Systems Manager investigou uma instância EC2 que continuava running, mas deixou de responder ao Systems Manager depois da remoção controlada de sua saída HTTPS. A primeira tentativa foi inconclusiva: o SSM permaneceu Online durante a janela de observação, e a regra foi restaurada. Após ajustar o procedimento para reiniciar somente a instância exclusiva e encerrar conexões existentes, uma segunda execução confirmou ConnectionLost.
O diagnóstico somente leitura verificou a rede compartilhada, a configuração IAM e a ausência da regra de saída no Security Group exclusivo. A recuperação restaurou HTTPS pela API do EC2, sem depender de uma sessão SSM, e a validação independente voltou a Healthy. Por fim, o cleanup removeu a instância, o Security Group, o Instance Profile e a IAM Role exclusivos, preservando a VPC e a sub-rede do Lab 08.
Consulte o Lab 16 para os scripts, a cronologia das tentativas, o diagnóstico e as evidências.
O Lab 15 — Troubleshooting de conectividade na AWS confirmou que uma aplicação Nginx pode permanecer saudável localmente enquanto uma regra de entrada ausente no Security Group impede o acesso HTTP externo. Após validar o estado Healthy, a regra TCP 80 restrita ao IPv4 do operador foi removida de forma controlada. A validação independente confirmou Failed, com Systems Manager e Nginx saudáveis. O diagnóstico somente leitura identificou a regra ausente; a recuperação restaurou apenas essa autorização e a validação voltou a Healthy. Por fim, o cleanup removeu os recursos exclusivos do Lab 15 e preservou a VPC e a sub-rede compartilhadas do Lab 08.
Consulte o Lab 15 para os comandos, resultados, scripts e evidências.
O Lab 14 — Utilização de disco e crescimento de logs implementou um cenário completo de investigação e mitigação de utilização elevada de disco em uma instância Amazon EC2 administrada pelo AWS Systems Manager.
O laboratório incluiu:
- implantação de uma instância Amazon EC2 com Amazon Linux 2023;
- criação de um volume EBS
gp3criptografado e dedicado aos logs; - formatação do volume com
ext4; - montagem persistente por UUID em
/var/log/lab14; - administração pelo Systems Manager, sem Key Pair e sem regra de entrada para SSH;
- IMDSv2 obrigatório;
- geração controlada de arquivos de log;
- proteção por limite máximo de utilização;
- diagnóstico estruturado e somente leitura;
- análise de capacidade em bytes e consumo de inodes;
- identificação dos maiores diretórios e arquivos;
- inspeção de arquivos removidos ainda abertos;
- coleta de eventos recentes do sistema;
- mitigação por rotação, compressão e retenção;
- validação de integridade antes da remoção dos arquivos originais;
- validação independente após a mitigação;
- cleanup protegido e idempotente;
- preservação da rede compartilhada do Lab 08.
Durante o incidente controlado, a utilização do volume dedicado chegou a 85%, ultrapassando o limite operacional de 80% e permanecendo abaixo do limite máximo de segurança de 88%.
O diagnóstico identificou:
24arquivos de pressão;- aproximadamente
1,50 GiBde dados recuperáveis; - arquivos de aproximadamente
64 MiB; - utilização de inodes de apenas
1%; - nenhum arquivo removido ainda aberto por processos;
- concentração do consumo no diretório controlado
/var/log/lab14/generated.
A investigação confirmou que o incidente estava relacionado ao consumo da capacidade em bytes e não ao esgotamento de inodes.
A mitigação processou somente os arquivos controlados, realizou compressão temporária, validou a integridade do conteúdo e removeu os arquivos originais somente após a confirmação de sucesso.
Após a mitigação, a utilização foi reduzida de 85% para 57%. A validação independente confirmou o retorno ao estado Healthy.
O cleanup removeu:
- a instância EC2 do Lab 14;
- o volume EBS dedicado;
- o Security Group;
- o Instance Profile;
- a IAM Role e sua associação com a política do Systems Manager.
A validação pós-cleanup confirmou que nenhum recurso exclusivo do Lab 14 permaneceu ativo. A VPC e a sub-rede compartilhadas do Lab 08 foram preservadas.
Consulte o Lab 14 — Utilização de disco e crescimento de logs para acessar a documentação completa, os scripts e as evidências.
| Diretório | Finalidade |
|---|---|
labs/ |
Laboratórios, scripts e evidências de execução |
docs/ |
Roadmap e documentação geral |
terraform/ |
Infraestrutura como código |
scripts/ |
Scripts compartilhados entre laboratórios |
templates/ |
Modelos de laboratório, checklist, incidente e runbook |
incident-response/ |
Registros de troubleshooting e recuperação |
resources/ |
Comandos, referências e materiais de apoio |
- Consulte o
roadmappara conhecer a sequência da trilha. - Acesse o diretório do laboratório desejado.
- Leia o objetivo, os pré-requisitos e as proteções antes da execução.
- Execute o procedimento no ambiente indicado.
- Confirme as validações e compare os resultados com as evidências documentadas.
- Remova os recursos temporários quando houver procedimento de cleanup.
Recursos AWS que possam gerar cobrança devem permanecer ativos somente durante a execução dos respectivos laboratórios.
- autenticação temporária por AWS IAM Identity Center;
- preferência por acesso administrativo pelo AWS Systems Manager;
- princípio do menor privilégio conforme a evolução da trilha;
- identificação explícita de perfil, Região, ambiente e recursos;
- validações antes e depois das alterações;
- diagnóstico antes da mitigação;
- scripts limitados ao escopo declarado;
- autorização explícita para operações destrutivas;
- proteção de credenciais e identificadores sensíveis;
- tratamento de respostas vazias e falhas esperadas;
- infraestrutura reproduzível e mudanças rastreáveis;
- preservação de recursos compartilhados;
- scripts de cleanup idempotentes;
- controle de custos e cleanup documentado.
Os laboratórios concluídos até esta etapa demonstram:
- preparação e validação de uma estação de trabalho;
- autenticação temporária na AWS por SSO;
- administração de sistemas Linux;
- usuários, grupos e permissões;
- serviços e logs com
systemdejournalctl; - inventário operacional de uma conta AWS;
- redes VPC, sub-redes, rotas e Internet Gateway;
- instâncias EC2 administradas pelo Systems Manager;
- IAM Roles e Instance Profiles;
- Security Groups com escopo controlado;
- armazenamento com Amazon EBS e Amazon S3;
- validação de integridade e recuperação de dados;
- disponibilidade com Application Load Balancer;
- health checks e distribuição de tráfego;
- introdução controlada de falhas;
- diagnóstico estruturado antes da recuperação;
- investigação de utilização elevada de disco;
- análise de capacidade e inodes;
- rotação, compressão e retenção de logs;
- investigação de perda de conectividade do Systems Manager;
- recuperação pela API do EC2 quando o SSM está indisponível;
- atualização controlada de aplicação com baseline, backup e confirmação;
- diagnóstico de configuração inválida e rollback verificado por hashes;
- backup de aplicação em S3 privado e versionado;
- restauração por VersionId com verificação de pacote e manifesto SHA-256;
- diagnóstico de perda parcial com comparação de arquivos e respostas HTTP;
- registro dos intervalos observados de recuperação e da idade do backup;
- automação com PowerShell e Bash;
- validação independente;
- cleanup seguro e preservação de infraestrutura compartilhada.
A trilha está dividida em nove etapas:
- preparação e acesso;
- operações Linux;
- infraestrutura AWS;
- operação e troubleshooting;
- Terraform;
- monitoramento e logs;
- Docker;
- segurança, custos e confiabilidade;
- projeto integrado de uma aplicação web.
Os laboratórios de preparação, operações Linux e infraestrutura AWS foram concluídos.
O módulo de operação e troubleshooting foi concluído. Os Labs 13 a 18 demonstraram aplicação indisponível, utilização elevada de disco, falha de conectividade, Systems Manager indisponível, atualização controlada e recuperação de aplicação a partir de backup versionado.
A próxima etapa prevista é o Lab 19 — Fluxo essencial do Terraform, que inicia o módulo de infraestrutura como código, com foco em:
- inicialização do diretório de trabalho com
terraform init; - formatação e validação com
terraform fmteterraform validate; - análise das mudanças propostas com
terraform plan; - aplicação e conferência do resultado com
terraform apply; - remoção dos recursos do exercício com
terraform destroy; - proteção do estado e preservação da infraestrutura compartilhada.
Este projeto está distribuído sob a licença MIT.