🐳 Docker & Automacao

Um container e uma caixa fechada que carrega o app e tudo que ele precisa para rodar: codigo, bibliotecas e configuracoes. E como uma mala pronta que abre igual em qualquer lugar.

Acaba com o "na minha maquina funciona". Se roda no container, roda no servidor, no laptop do colega e na nuvem, exatamente igual.

Container nao e maquina virtual: e mais leve e sobe em segundos. Cada container e isolado dos outros, mas compartilha o sistema do servidor.

O passo de baixar e instalar o Docker: Docker Desktop no Windows e Mac, ou o script oficial / gerenciador de pacotes no Linux do seu servidor.

Sem o Docker instalado, nenhum container roda. Instalar uma vez deixa o motor pronto para o resto da trilha.

Confira com docker --version e docker run hello-world. No Linux, adicione seu usuario ao grupo docker para nao precisar de sudo sempre.

O comando docker run baixa uma imagem (se preciso) e sobe um container a partir dela. Com ele voce coloca um servidor web no ar em um comando.

E o comando que voce mais vai usar. Em segundos voce tem um banco, um site ou uma ferramenta rodando, sem instalar nada na sua maquina.

-d roda em segundo plano, -p 8080:80 liga uma porta sua a porta do container, --name da um apelido. docker ps lista o que esta rodando.

A imagem e o molde congelado (a receita pronta); o container e uma copia viva rodando daquele molde. De uma imagem voce cria quantos containers quiser.

Confundir os dois gera bagunca. Entender a diferenca ajuda a saber o que apagar, o que reaproveitar e por que o container some mas a imagem fica.

docker images lista moldes; docker ps -a lista containers. Imagem = classe, container = objeto. Imagens vem do Docker Hub.

O Dockerfile e um arquivo de texto com a receita da sua imagem: de qual base partir, o que copiar, o que instalar e qual comando rodar ao iniciar.

E como voce empacota o SEU app, e nao so usa os prontos. Com um Dockerfile, qualquer pessoa monta a mesma imagem com um unico comando.

Instrucoes em maiusculas: FROM (base), COPY, RUN (instala), EXPOSE (porta), CMD (comando de inicio). Cada linha vira uma camada.

O docker build transforma o Dockerfile numa imagem real; o docker push envia essa imagem para um registro (como o Docker Hub) para usar em qualquer servidor.

E o ciclo completo: da receita ao app publicado. Com a imagem no registro, fazer deploy vira so um docker pull no servidor.

docker build -t usuario/app:1.0 . gera e nomeia (tag). Faca docker login antes do push. A tag latest e a versao padrao.

O Docker Compose e uma ferramenta para definir e rodar varios containers juntos. Voce descreve a aplicacao inteira (app + banco + cache) num arquivo so.

Apps reais raramente sao um container. Sem o Compose, subir app + banco vira uma sequencia chata de comandos longos e frageis.

Toda a stack vive num docker-compose.yml. docker compose up sobe tudo, down derruba. Um arquivo versionado = ambiente reproduzivel.

Um arquivo em formato YAML que lista os servicos da sua aplicacao. Cada servico aponta para uma imagem (ou um build) e suas configuracoes.

E o coracao do Compose. Entender a estrutura basica permite ler e escrever qualquer stack que voce encontrar pela frente.

YAML usa indentacao (espacos, nunca Tab). Comece por services: e, sob ele, cada servico com image ou build e ports.

Servicos sao os containers; redes deixam eles conversarem entre si pelo nome; volumes guardam dados que precisam sobreviver quando o container e recriado.

Sem volume, voce perde o banco de dados a cada restart. Sem rede certa, o app nao acha o banco. Esses tres conceitos sustentam qualquer stack.

Containers da mesma stack se acham pelo nome do servico (ex.: db). Volumes mapeiam uma pasta persistente. Dados no container somem; dados no volume ficam.

O momento de juntar tudo: definir um servico de app e um de banco no mesmo arquivo e subir a aplicacao completa com um unico docker compose up.

E o cenario mais comum de verdade. Quando voce sobe app + banco juntos, ja consegue rodar uma aplicacao completa no seu servidor.

docker compose up -d sobe em segundo plano. O app acha o banco pelo nome do servico. Use depends_on para definir a ordem de subida.

As ferramentas para ver o que cada container esta fazendo: logs mostra a saida, ps mostra o estado e exec entra dentro do container.

Quando algo nao sobe, o log diz o porque. Sem saber ler logs, voce fica adivinhando; com eles, voce resolve em minutos.

docker compose logs -f acompanha em tempo real. docker compose exec app sh abre um terminal dentro do container para investigar.

O fluxo de atualizar a aplicacao: baixar a nova imagem, recriar os containers e, se algo der errado, voltar (rollback) para a versao anterior.

Toda app evolui. Saber atualizar sem derrubar tudo e voltar atras rapido evita aquele susto de "quebrei a producao e nao sei desfazer".

docker compose pull baixa o novo, up -d recria so o que mudou. Fixar a tag da imagem (e nao usar so latest) torna o rollback simples.

O systemd e o sistema que liga e gerencia tudo que roda no Linux: e o primeiro programa a subir no boot e o responsavel por iniciar os demais servicos.

E ele que mantem seu app no ar 24h. Sem o systemd, voce teria que reiniciar tudo na mao toda vez que o servidor reiniciasse.

A unidade basica e o "service" (.service). Voce conversa com o systemd pelo comando systemctl. Quase todo Linux moderno usa systemd.

Um arquivo .service que descreve seu app para o systemd: qual comando rodar, em que pasta, com qual usuario e o que fazer se ele cair.

E como voce transforma um script solto num servico de verdade, gerenciado pelo sistema, que sobe sozinho e e tratado como peca seria.

Tres secoes: [Unit] (descricao e dependencias), [Service] (ExecStart, usuario) e [Install]. Os arquivos ficam em /etc/systemd/system/.

Os comandos do dia a dia: start liga, stop desliga, restart reinicia e enable garante que o servico suba no boot.

Sao os botoes de controle do seu servico. Com eles voce sobe, derruba e reinicia sem reiniciar o servidor inteiro.

Diferenca-chave: start liga agora; enable liga em todo boot. Use systemctl status nome para conferir se esta ativo (active/running).

O journalctl e a central de logs do systemd. Ele guarda tudo que cada servico escreveu, com data e hora, para voce consultar quando precisar.

Quando um servico falha, o log conta a historia. Saber filtrar o journal e o que separa "nao sei o que houve" de "achei o erro em 30 segundos".

journalctl -u nome filtra por servico; -f acompanha ao vivo; -e pula para o fim. Combine com --since para um intervalo.

A forma de dizer ao systemd que um servico depende de outro: por exemplo, seu app so deve subir depois que o banco de dados ja estiver pronto.

Sem a ordem certa, o app sobe antes do banco e quebra no boot. Definir dependencias garante que tudo ligue na sequencia correta, sozinho.

No [Unit]: After= define ordem; Requires= obriga o outro a estar ativo; Wants= e uma dependencia suave (recomendada).

A configuracao que faz o systemd reiniciar automaticamente um servico que travou ou caiu, sem que voce precise estar acordado para isso.

Apps caem. Com restart automatico, o servidor se cura sozinho e seu app volta ao ar em segundos, mesmo as 3 da manha.

No [Service]: Restart=always (ou on-failure) e RestartSec=5 (espera antes de tentar). Apos editar, rode systemctl daemon-reload.

O cron e um agendador que roda no Linux o tempo todo, vigiando o relogio. Quando chega a hora marcada, ele dispara o comando que voce agendou.

E o jeito classico de automatizar tarefas repetitivas: backups, relatorios, limpezas. Voce configura uma vez e ele faz para sempre, sozinho.

Cada tarefa agendada e um "cron job". A lista de jobs vive numa tabela chamada "crontab". O cron roda em segundo plano e nao precisa de ninguem logado.

A linha de um cron job comeca com cinco campos que definem quando rodar: minuto, hora, dia do mes, mes e dia da semana, seguidos do comando.

Errar a sintaxe e o erro numero um. Entender os cinco campos faz a diferenca entre "rodar todo dia as 3h" e "rodar a cada minuto sem parar".

Ordem: min hora dia mes diasemana. O * significa "todo". 0 3 * * * = todo dia as 3h. Use o site crontab.guru para conferir.

O comando crontab -e abre, num editor, a sua tabela de agendamentos. Cada linha que voce escreve ali vira um job ativo ao salvar.

E a porta de entrada para criar, editar e remover seus jobs. Sem isso, voce nao consegue de fato agendar nada no servidor.

crontab -e edita, crontab -l lista. Cada usuario tem sua propria crontab. Use caminhos absolutos nos comandos para evitar surpresas.

Casos reais de cron job: um backup do banco todo dia de madrugada, uma limpeza de arquivos temporarios toda semana, um script de manutencao mensal.

Ver exemplos prontos acelera tudo. Com poucos modelos na mao, voce adapta para qualquer rotina que o seu servidor precise.

Backup: 0 2 * * * chama um script de dump. Limpeza: 0 4 * * 0 (domingo) apaga temporarios. Sempre aponte para um script, nao um comando gigante.

As formas de saber se um cron job rodou e o que ele fez: redirecionar a saida do comando para um arquivo de log e consultar o log do sistema.

Cron roda em silencio. Sem log, voce nunca sabe se o backup aconteceu de verdade, ate o dia que precisa dele e descobre que falhava ha meses.

Acrescente >> /var/log/meujob.log 2>&1 ao fim da linha para gravar saida e erros. No journal, filtre por journalctl -u cron (ou crond).

Os systemd timers sao a alternativa moderna ao cron: um arquivo .timer agenda quando um .service deve rodar, integrado ao systemd.

Timers tem logs no journal, sabem recuperar execucoes perdidas e se integram aos servicos. Em servidores modernos, muitas vezes sao a escolha melhor.

Um par: o .service faz a tarefa, o .timer diz quando. OnCalendar= define o horario; systemctl list-timers mostra os proximos disparos.