- Configurar políticas de reinicialização, como "unless-stopped", é vital para garantir que os serviços voltem a ficar ativos após a reinicialização do sistema.
- A implementação de unidades systemd resolve conflitos de ordem de inicialização quando existem dependências em montagens de disco ou redes externas.
- A atualização dos contêineres usando `docker compose up -d` é obrigatória para que as alterações no arquivo YAML entrem em vigor no mecanismo do Docker.
Se você se deparou com o problema de seus serviços Docker não iniciarem automaticamente após a reinicialização do servidor, não se desespere; é um problema mais comum do que você imagina. Às vezes, o arquivo de configuração parece perfeito, mas ao se reconectar à máquina, você descobre que... Os contêineres adormeceram. E não há sinais de atividade em seus aplicativos.
Para resolver isso, é importante entender que simplesmente escrever algumas linhas em um arquivo YAML não é suficiente; a interação entre o daemon do Docker, o sistema de gerenciamento de serviços do Linux e a forma como as configurações são armazenadas entram em jogo. Vamos analisar isso passo a passo. todas as causas possíveis e como deixá-las niqueladas para que nunca mais falhem.
O segredo das políticas de reinicialização no Compose.
Para que um conjunto de serviços seja iniciado automaticamente, duas coisas devem coincidir: o serviço Docker deve estar habilitado no sistema e cada serviço deve ter um ambiente de execução (`.`) política de reinicialização apropriadaNão existe uma configuração global para todo o arquivo, portanto, a linha precisa ser adicionada. restart: unless-stopped o always a cada um dos serviços definidos.
É aqui que muitas pessoas cometem um erro: editando o arquivo. compose.yaml Não altera a configuração de um contêiner existente. A política de reinicialização é salva no objeto do contêiner, não lida em tempo real do arquivo. Portanto, se você apenas alterar o texto e reiniciar, nada acontecerá. Você precisa executar docker-compose up -d para que o Docker detecte a alteração, destrua o contêiner antigo e crie um novo com a política correta.
Diferenças reais entre os valores de reinicialização
Nem todos os valores de reinicialização têm a mesma função, e escolher o valor errado pode causar problemas. Aqui está a explicação detalhada:
- NãoEste é o valor padrão. O contêiner nunca será reiniciado automaticamente.
- sempreSempre reinicie o contêiner. Mesmo que você o tenha parado manualmente há uma semana, assim que o daemon do Docker iniciar, o contêiner será reiniciado. Isso pode ser inconveniente se você quiser deixar algo desligado intencionalmente.
- a menos que seja interrompidoEsta é a opção mais equilibrada. Ela se comporta como `always`, mas com uma diferença fundamental: se você interrompeu o contêiner manualmente, Respeitaremos sua decisão. e permanecerá desligado após a reinicialização do sistema.
- em caso de falhaIsso só se aplica se o contêiner falhar (código de saída diferente de zero). Observe que um desligamento normal do servidor não é considerado um erro. Não sobreviverá a uma reinicialização. do anfitrião.
Quando o daemon do Docker não é suficiente
Às vezes, mesmo que você tenha o restart: unless-stoppedA pilha falha. Isso geralmente acontece porque o daemon do Docker inicia antes de outros componentes críticos. Se sua pilha depende de um disco criptografado, um compartilhamento NFS ou um Interface VPN que demora muito para conectarO Docker pode tentar iniciar o contêiner, não encontrar o caminho e criar uma pasta vazia, deixando seu banco de dados sem dados.
Nesses casos, a solução profissional é criar um unidade systemdIsso permite que você diga ao sistema: "Não inicialize esta pilha até que o disco X esteja montado." Para fazer isso, um arquivo é criado em /etc/systemd/system/ configurado como Type=oneshot y RemainAfterExit=yesÉ essencial usar a diretiva Requer MontagensPara= para garantir que haja espaço de armazenamento disponível e After=docker.service Respeitar a ordem lógica.
Considerações técnicas e erros silenciosos
Existem detalhes que podem sabotar sua configuração sem aviso prévio. Por exemplo, se você iniciar um contêiner usando docker compose runIsso é tratado como algo temporário e não herdará a política de reinicialização a partir do arquivo YAML. Se você perceber que um serviço está ignorando as regras, verifique como ele foi iniciado.
Outro ponto crítico é o Docker sem rootSe você executar o Docker sem privilégios de root, o daemon será um serviço de usuário que será encerrado quando você fizer logout. Para evitar que seus contêineres sejam encerrados ao fazer logout, você deve executar loginctl enable-linger usuariopermitindo que o processo continue em segundo plano.
Gestão avançada e ferramentas modernas
Vamos falar sobre a evolução das ferramentas. Atualmente, o padrão é Docker Compose V5 (invocado como) docker compose(sem o hífen), que substituiu o antigo binário do Python. Para quem gerencia infraestruturas maiores, existe Docker Swarmque permite converter vários hosts em um cluster gerenciado centralmente usando nós mestre e escravo.
No Swarm, a orquestração é mais poderosa, permitindo serviços replicados (para dimensionar instâncias de um servidor web, por exemplo) ou serviços globais (Assim, cada nó do cluster terá uma cópia do contêiner, ideal para antivírus ou monitoramento). Embora o Compose seja ótimo para um único servidor, o Swarm é a solução quando você precisa de alta disponibilidade e balanceamento de carga nativo.
Manutenção e fluxo de trabalho diário
Para manter tudo sob controle, dominar os comandos de diagnóstico é vital. Usando docker compose ps Isso nos dá uma visão geral rápida do estado, mas Monitore os logs do Docker com o Dozzle. É aqui que a mágica acontece quando se trata de encontrar erros de inicialização. Se você precisar fazer uma alteração rápida sem quebrar o contêiner, docker compose exec É o caminho mais direto para entrar no terminal de serviço e revisar arquivos de configuração interno.
É aconselhável evitar misturar gerenciadores de processos se você não souber o que está fazendo, embora uma unidade systemd de execução única coexista perfeitamente com as políticas de reinicialização do Docker. Na verdade, é o combinação vencedoraO systemd garante que a ordem de inicialização esteja correta e o daemon do Docker é responsável por reiniciar o contêiner caso ele falhe às três da manhã.
A estabilidade de um ambiente de contêineres depende de uma configuração consistente da política de reinicialização do arquivo YAML, da ativação correta do serviço Docker no sistema e, em casos complexos, do uso de unidades systemd para gerenciar dependências externas. unless-stopped com uma execução de docker compose up -d E para garantir a persistência do usuário no modo sem privilégios de root, é garantido que os aplicativos permaneçam operacionais sem intervenção manual após qualquer reinicialização do servidor.
Apaixonado por tecnologia desde pequeno. Adoro estar atualizado no setor e, acima de tudo, comunicá-lo. É por isso que há muitos anos me dedico à comunicação em sites de tecnologia e videogames. Você pode me encontrar escrevendo sobre Android, Windows, MacOS, iOS, Nintendo ou qualquer outro tópico relacionado que lhe vier à mente.