Ferramentas propostas
docker stats, docker inspect, htop, iostat, df e free para consumo. k6 para latência e taxa de erros, com perfil de carga repetível. curl, dig e openssl para rede e certificados.
Relatório de infraestrutura / Simulação de testes
Simulação de testes
Explore cenários hipotéticos de escala, compare saturação de CPU, RAM e disco e consulte o plano de benchmarks que ainda precisam ser executados em uma VPS real.
Módulo 05 de 07 · 1–40 containersCitizen Apps / Pesquisa de infraestrutura
Siebot Infrastructure Lab
Transforme hipóteses em métricas
Compare cargas de 1 a 40 containers e visualize o ponto de saturação projetado; depois valide o desempenho em ambiente real.
Laboratório de planejamento
Como o servidor reagiria a 1, 5, 10, 20 e 40 apps?
Compare o consumo agregado em um host. O fator de carga multiplica a demanda média de CPU por aplicação; a memória simulada representa consumo sob carga. Os números são premissas ajustáveis, não resultados de benchmark.
Teto calculado por recursos—O menor limite entre RAM, CPU e disco
Primeiro cenário acima do limite—Valores baseados exclusivamente no modelo
Utilização relativa projetada
Imagine várias aplicações funcionando ao mesmo tempo em uma única VPS. Cada conjunto de barras representa o quanto da capacidade reservada para as aplicações seria consumido por 1, 5, 10, 20 ou 40 containers.
RAMMemória
Espaço usado pelas aplicações abertas. Quanto mais apps, mais RAM reservada.
CPUProcessamento
Esforço estimado das aplicações executando tarefas simultaneamente.
!Acima de 100%
A demanda calculada ultrapassa o orçamento disponível. Não significa que a máquina aguente essa carga.
Como ler os percentuais: 50% significa metade do orçamento de recurso disponível após a reserva do sistema. 100% é o limite planejado; 120% significa demanda 20% acima desse limite. As barras param em 100% para caber no gráfico, mas o percentual real estimado continua visível.
■ RAM ■ CPU ▲ Excesso de capacidade planejada. Compare os valores detalhados na tabela.
| Cenário | RAM | CPU | Disco | Sinalização |
|---|
Não corresponde a k6/benchmark real. RPS, P95/P99, erros HTTP, usuários simultâneos e comportamento sob burst dependem de medição com aplicações reais. Esta página apenas ajuda a escolher o host a ser testado.
Execução das tasks
Plano de testes para transformar hipóteses em resultados
Sequência verificável, com artefatos de saída e critérios recomendados. Não é possível marcar uma validação de infraestrutura como concluída sem acesso à instância e medição.
| Teste | Como executar | Evidência necessária | Estado |
|---|---|---|---|
| 1. Inventário de host | nproc; free -h; df -h; docker info | vCPU, RAM, SSD, cgroups, Docker e rede | Pendente |
| 2. Baseline isolado | Iniciar 1 app de teste e medir idle + carga | CPU pico/média, RSS, I/O, latência P95 | Pendente |
| 3. Escala horizontal no host | Repetir 1, 5, 10, 20 containers com mesma carga | RPS, p95/p99, erros, OOM e CPU throttling | Pendente |
| 4. Isolamento | Sobrecarregar app B, medir app A e C | Quotas efetivas; nenhum acesso indevido à rede/segredos | Pendente |
| 5. Deploy e ciclo de vida | Subir, atualizar, reiniciar, reboot, rollback e remover | Healthchecks, persistência, recuperação e logs | Pendente |
| 6. Acesso externo | dig, curl -I, certificado HTTPS | DNS, código 200/301/404/502, certificado, redirect | Pendente |
| 7. Rota com underscore | Abrir /controle_visitas/ e navegar | CSS/JS, formulário, autenticação, cookies, WebSocket | Pendente |
| 8. Recuperação | Restaurar backup e revogar token de API | RTO/RPO medidos e permissão realmente revogada | Pendente |
Critérios de aceite sugeridos
Definir previamente metas de P95 e RPS por app. Como ponto inicial de alerta, trabalhar com CPU sustentada inferior a 70%, RAM inferior a 80%, erro HTTP abaixo de 1% sob carga-alvo e zero OOM. São metas propostas, não medidas nem SLA contratado.