Comece com cinco blocos:
Evite registrar senhas, tokens, IPs privados de terceiros ou dados de producao. Se uma configuracao depender de valor sensivel, descreva a variavel e forneca um exemplo ficticio. Tambem registre falhas relevantes: um erro diagnosticado com clareza mostra mais aprendizado do que uma sequencia de comandos sem contexto.
Use este modelo no laboratorio Nginx com Docker Compose ou na checagem HTTP com Python. O objetivo nao e montar um portfolio artificial; e manter evidencia honesta do que voce praticou e consegue discutir.
]]>Um laboratorio pequeno tambem pode expor portas, credenciais ou servicos que voce esqueceu de desligar. Antes de publicar uma porta, encaminhar trafego no roteador ou compartilhar um endereco, faca um inventario curto: qual servico esta em execucao, em qual endereco ele escuta e quem realmente precisa acessa-lo.
Esse levantamento nao e uma auditoria formal nem promete deixar um host seguro. Ele cria uma base observavel para decidir o que manter, restringir ou remover.
No Linux, comece pela visao de sockets de rede:
sudo ss -lntup
Observe protocolo, porta, endereco de bind e processo. Um servico ligado a 127.0.0.1 atende somente o proprio host; um servico em 0.0.0.0 ou :: pode aceitar conexoes de outras redes, dependendo do firewall e das rotas. Registre as portas esperadas pelo laboratorio e investigue as que nao reconhece.
Evite usar esse resultado como motivo para abrir tudo no firewall. Uma porta em escuta e apenas uma parte do caminho; acesso externo tambem depende de regras locais, rede, balanceadores e DNS.
Para cada servico que precisa permanecer, responda perguntas simples:
No acesso remoto, confirme a configuracao efetiva do SSH antes de mudar uma regra. sshd -T ajuda a inspecionar valores resolvidos pelo daemon; mantenha uma sessao administrativa funcional enquanto testa qualquer alteracao. Em producao, siga o processo de mudancas do ambiente em vez de aplicar um comando copiado de um laboratorio.
Guarde no README do laboratorio as portas esperadas, a data da revisao e como reproduzir o teste. Esse registro torna mais facil perceber quando um novo container, proxy ou servico alterou a superficie exposta.
Veja tambem a InfraTip sobre portas em escuta no Linux e use somente documentacao oficial para regras de firewall ou SSH do seu sistema.
Verificar uma URL pelo navegador e util durante um teste rapido. Quando a mesma checagem precisa acontecer varias vezes, um script deixa claro qual URL foi testada, qual status voltou e qual falha precisa ser investigada.
Este exemplo usa somente a biblioteca padrao do Python. Ele e apropriado para um laboratorio ou para uma verificacao simples; monitoramento de producao exige alertas, historico e tratamento de dependencias mais completo.
Salve o arquivo como check_http.py:
import sys
from urllib.error import HTTPError, URLError
from urllib.request import Request, urlopen
def check(url):
request = Request(url, headers={"User-Agent": "InfraTips-lab-check/1.0"})
try:
with urlopen(request, timeout=10) as response:
print(f"OK {response.status} {response.url}")
return 0
except HTTPError as error:
print(f"HTTP {error.code} {url}")
return 1
except URLError as error:
print(f"ERRO de rede: {error.reason}")
return 2
if __name__ == "__main__":
if len(sys.argv) != 2:
raise SystemExit("uso: python3 check_http.py https://exemplo.local/")
raise SystemExit(check(sys.argv[1]))
python3 check_http.py https://www.infratips.com.br/
Uma resposta OK 200 indica que a requisicao HTTP terminou com sucesso. Um HTTP 404 mostra que o servidor respondeu, mas o recurso nao existe; um erro de rede aponta para DNS, conexao, TLS ou indisponibilidade antes de haver uma resposta HTTP.
Teste tambem uma aplicacao local que voce controla:
python3 -m http.server 8000
python3 check_http.py http://127.0.0.1:8000/
Use uma segunda janela para manter o servidor local em execucao. Pare o processo ao terminar com Ctrl+C.
O codigo sai com status diferente de zero quando a verificacao falha. Isso permite usa-lo em um script de laboratorio ou em uma automacao simples. Antes de adicionar autenticacao, tokens ou URLs internas, prefira variaveis de ambiente e nunca grave segredos no arquivo ou no historico do terminal.
Se usar uma ferramenta de IA para propor timeout, repeticao ou novos testes, trate a resposta como uma hipotese: revise o diff, confirme as APIs na documentacao oficial e execute primeiro contra um endpoint controlado. Nao envie tokens, URLs internas ou respostas com dados sensiveis ao prompt. A evidencia continua sendo o comportamento reproduzido pelo script, nao a explicacao gerada pela ferramenta.
Para diagnosticar uma falha, combine o resultado com a experiencia de conectividade por camadas. O script prova somente a requisicao feita a partir da maquina onde ele foi executado.
Um padrao recorrente em ambientes Linux e Cloud ocorre quando a aplicacao responde em localhost, mas usuarios externos recebem timeout ou conexao recusada. A primeira reacao costuma ser alterar a aplicacao. Na pratica, o erro pode estar em qualquer camada entre o processo e o cliente.
Este relato resume um roteiro de diagnostico que pode ser aplicado a ambientes de laboratorio e producao, sempre respeitando as mudancas aprovadas para o ambiente.
O servico respondia localmente:
curl -i http://127.0.0.1:8080
Mas uma requisicao a partir de outra maquina nao recebia resposta. O sintoma era insuficiente para concluir se a aplicacao, o host ou a rede estava errado.
O primeiro passo foi confirmar em qual endereco o processo estava ouvindo:
ss -lntup | grep ':8080'
Um servico vinculado somente a 127.0.0.1 aceita conexoes locais, mas nao recebe trafego em um endereco de rede do host. Quando ele esta em 0.0.0.0 ou no IP correto, a investigacao segue para o firewall local, regras de seguranca Cloud, rotas, balanceador e DNS.
Tambem e importante diferenciar timeout de conexao recusada. Timeout sugere bloqueio ou caminho inexistente. Conexao recusada normalmente indica que o destino foi alcancado, mas nao havia processo aceitando naquela porta.
O roteiro que reduziu tentativas aleatorias foi:
localhost;Cada teste deve alterar uma unica variavel. Assim, a equipe consegue provar o que foi corrigido e evita abrir portas ou permissoes desnecessarias.
Com a sequencia, o problema deixa de ser “a aplicacao nao abre” e passa a ser uma hipotese mensuravel. O tempo de diagnostico diminui porque cada comando elimina uma camada inteira de possibilidades.
Veja tambem a InfraTip sobre portas em escuta no Linux.
]]>Quando um servidor fica sem espaco, apagar arquivos aleatoriamente e uma forma rapida de piorar o incidente. Primeiro, descubra qual parte do filesystem cresceu.
Para listar o consumo dos diretorios diretamente dentro de /var:
sudo du -xh --max-depth=1 /var | sort -h
O du calcula o uso em disco. --max-depth=1 limita a visao ao primeiro nivel, e sort -h ordena tamanhos como MB e GB corretamente.
Repita o comando no diretorio que apareceu no topo da lista. Por exemplo, se /var/log estiver grande:
sudo du -xh --max-depth=1 /var/log | sort -h
Uso alto em /var pode vir de logs, cache de pacotes, imagens de containers ou arquivos temporarios. Identifique o responsavel antes de remover qualquer arquivo. Tambem confirme em qual filesystem voce esta trabalhando com df -h.
Consulte man du e man df no sistema para conhecer as opcoes disponiveis na distribuicao usada.
Em tecnologia, sempre existe uma nova ferramenta, certificacao ou trilha prometendo resolver a proxima etapa da carreira. O resultado comum e abrir muitos cursos, assistir muitas aulas e terminar poucos artefatos que provem aprendizado.
Uma alternativa melhor e trabalhar em ciclos pequenos. Cada ciclo responde a uma pergunta concreta: “consigo publicar uma pagina em um container?”, “consigo explicar uma regra de rede?” ou “consigo automatizar esta tarefa repetitiva?”.
Evite objetivos como “aprender Cloud”. Prefira resultados que possam ser verificados:
plan;Um objetivo observavel facilita escolher materiais e revela quando voce realmente terminou a pratica.
Reserve uma sessao curta para entender o conceito. Em seguida, reproduza-o em um laboratorio. Por fim, registre o que funcionou, o que falhou e quais comandos foram importantes.
Esse registro pode virar README, anotacao tecnica, repositório Git ou uma InfraTip. O valor nao esta em publicar tudo: esta em construir uma referencia que voce consiga reutilizar depois.
O laboratorio Nginx com Docker Compose e um exemplo de ciclo pequeno. Depois de concluir, varie uma unica coisa: mude a porta, altere o volume ou acompanhe logs. Variacoes controladas ensinam mais do que trocar de assunto a cada hora.
Quando algo falhar, guarde o sintoma, a hipotese e a correcao. Isso forma um repertorio de diagnostico e deixa claro quais lacunas ainda existem.
Uma lista de erros comuns tambem ajuda a estudar para certificacoes. Em vez de memorizar apenas definicoes, relacione cada tema com um comando, uma configuracao ou um incidente que voce conseguiu reproduzir.
Uma rotina de duas ou tres sessaoes por semana e suficiente quando cada uma tem um objetivo definido. O ponto principal e manter uma sequencia repetivel: escolher, praticar, registrar, revisar e seguir para a proxima variacao.
Carreira tecnica evolui melhor com evidencias praticas acumuladas do que com uma lista longa de cursos iniciados.
]]>A KubeCon + CloudNativeCon North America 2026 esta programada para os dias 9 a 12 de novembro, em Salt Lake City, Utah. O evento e organizado pela Cloud Native Computing Foundation (CNCF) e pela Linux Foundation.
Para quem trabalha ou estuda Cloud e DevOps, a agenda e uma oportunidade de acompanhar projetos do ecossistema Cloud Native, praticas de plataforma, observabilidade, seguranca e operacao de clusters.
Nao e necessario tentar acompanhar todos os temas. Escolha uma pergunta pratica antes de consultar a agenda: como operar um cluster pequeno, como observar uma aplicacao ou como reduzir o ciclo de entrega. Registre palestras e projetos relacionados a essa pergunta e transforme os aprendizados em um laboratorio ou uma InfraTip.
Consulte detalhes de agenda, viagem e inscricao na pagina oficial da KubeCon + CloudNativeCon North America 2026. Datas e disponibilidade devem ser confirmadas diretamente com a organizacao.
]]>Este laboratorio cria um servidor Nginx local usando Docker Compose. O foco nao e decorar comandos: e observar a relacao entre arquivo de configuracao, porta publicada, container e resposta HTTP.
docker compose.8080.mkdir -p lab-nginx/site
cd lab-nginx
Crie site/index.html com um conteudo simples:
<!doctype html>
<html lang="pt-BR">
<body>
<h1>InfraTips lab Nginx</h1>
</body>
</html>
Agora crie compose.yaml:
services:
web:
image: nginx:alpine
ports:
- "8080:80"
volumes:
- ./site:/usr/share/nginx/html:ro
Inicie o container em segundo plano:
docker compose up -d
docker compose ps
Abra http://localhost:8080 no navegador ou valide pelo terminal:
curl -i http://localhost:8080
A resposta deve ter status 200 e conter InfraTips lab Nginx. Para acompanhar o que o processo escreveu no log:
docker compose logs --follow
A porta 8080 pertence ao host e encaminha trafego para a porta 80 do container. O volume monta seu diretorio local como conteudo servido pelo Nginx. A opcao :ro deixa o container ler os arquivos, sem poder modifica-los.
Altere o HTML, atualize o navegador e confirme que a mudanca aparece sem recriar a imagem. Isso mostra a diferenca entre uma imagem imutavel e um volume montado durante a execucao.
Quando terminar, remova o ambiente:
docker compose down
Antes de usar essa estrutura em um servidor, nao exponha portas sem entender firewall, rede e autenticacao. Este laboratorio e intencionalmente local e minimo.
O comando terraform apply pode alterar recursos reais. Uma rotina curta antes do apply diminui erros de sintaxe, variaveis ausentes e mudancas inesperadas.
Na raiz do modulo Terraform, execute:
terraform fmt -check -recursive
terraform init
terraform validate
terraform plan
fmt -check mostra arquivos que precisam ser formatados. init baixa providers e modulos declarados. validate verifica a configuracao local, e plan apresenta as alteracoes pretendidas.
Para aplicar a formatacao antes de revisar o diff:
terraform fmt -recursive
git diff --check
Um plan valido nao substitui revisao humana. Confira recursos que serao destruidos ou recriados, o provider e a conta Cloud usada pelo terminal. Em automacoes, mantenha o mesmo conjunto de variaveis e credenciais usado no ambiente alvo.
Consulte a documentacao oficial dos comandos validate e plan.
Ao investigar um serviço indisponível, primeiro confirme se algum processo está aguardando conexões na porta esperada.
ss -lntup
As opções mostram sockets em escuta (-l), conexões TCP (-t) e UDP (-u), endereços numéricos (-n) e o processo associado (-p). Para procurar uma porta específica:
ss -lntup | grep ':443'
Informações de processos pertencentes a outros usuários podem exigir privilégios administrativos. Encontrar uma porta em escuta confirma o estado local do socket, mas não garante que firewall, regras de Cloud ou roteamento permitam acesso externo.
Consulte a documentação local com man ss.