Como implantar contêineres Docker em servidores remotos

Trabalhando com contêineres Docker em servidores remotos Tornou-se essencial para qualquer pessoa que queira implantar aplicações modernas sem se perder em dependências, versões de bibliotecas e o clássico "funciona na minha máquina". No entanto, quando passamos de executar um simples docker run Ao passar da configuração de uma implantação local robusta em um servidor Linux, com Docker Compose, compartilhamentos do GitHub, Plesk, Portainer ou até mesmo aplicativos gráficos acessíveis via navegador, as coisas ficam um pouco mais complicadas.

Se o seu objetivo é implantar contêineres Docker em um servidor remoto (Ubuntu, Debian, Windows com WSL 2, um servidor em nuvem, Plesk, etc.) e fazer isso de forma sustentável, automatizada e segura, este guia oferece uma jornada bastante completa: desde o uso básico do Docker Compose remotamente, até ambientes de desenvolvimento com VS Code, implantações a partir do Plesk, administração com Portainer e execução remota de aplicativos gráficos usando noVNC e Caddy.

Conceitos básicos: contêineres Docker e implantação remota.

Docker é uma plataforma de contêineres. Ele empacota um aplicativo com tudo o que ele precisa (bibliotecas, dependências, binários, configuração mínima do sistema) para que seja executado da mesma forma em qualquer máquina com o mecanismo Docker instalado. A principal diferença em relação a uma máquina virtual é que o contêiner não inclui um sistema operacional completo; em vez disso, ele compartilha o kernel do host, resultando em imagens mais leves e melhor desempenho.

Para implantar contêineres Docker em servidores remotos Normalmente, você tem um host (por exemplo, um servidor Ubuntu na nuvem) com Docker e, opcionalmente, Docker Compose, e então envia o código ou as imagens para ele executar. Você pode fazer isso manualmente via SSH, automatizar com o GitHub Actions ou integrar com painéis como o Plesk ou ferramentas como o Portainer.

Os principais cenários do mundo real que você encontrará Quando se fala em "Docker remoto", há três aspectos a considerar: desenvolvimento local com execução de contêineres em outra máquina (ou no WSL 2), implantação automatizada de serviços de backend/frontend e gerenciamento de contêineres de produção (monitoramento, registro de logs, reinicializações, políticas de rede etc.). A tecnologia é a mesma; o que muda é a forma como ela é orquestrada.

Além dos serviços tradicionais de back-endO Docker permite algo menos conhecido, mas muito poderoso: executar aplicativos gráficos (clientes de e-mail, IDEs, ferramentas de análise, etc.) dentro de contêineres remotos e acessá-los a partir de um navegador usando VNC sobre WebSocket. É uma maneira conveniente de aproveitar servidores potentes quando seu PC não é suficientemente potente.

De `docker run` para Docker Compose em um servidor remoto

Um padrão bastante comum de implantação manual. Consiste em ter um repositório de código no GitHub, um servidor Ubuntu remoto com Docker instalado e um fluxo de trabalho de CI/CD (por exemplo, GitHub Actions) que faz o seguinte quando você envia alterações para um branch: development o main:

Conecte-se ao servidor remoto via SSH.
Pare e remova os recipientes em funcionamento.
Baixe as novas imagens do Docker Hub (ou do seu registro privado).
corrida docker run para cada serviço.
Configure o Nginx (ou o proxy reverso que você utiliza) para redirecionar o tráfego para as portas de cada contêiner.

Ao migrar para o Docker Compose O fluxo é bastante simplificado, pois, em vez de gerenciar contêineres um por um, você define toda a sua pilha (frontend, backend, banco de dados, cache etc.) em um único contêiner. docker-compose.yml, com suas redes, volumes e variáveis ambientais.

A prática mais simples (e bastante comum) com o GitHub Actions O fluxo de trabalho deve executar um cd para o diretório do projeto no servidor remoto (onde seu docker-compose.yml) e executar comandos como:

docker compose pull para trazer as imagens mais recentes.
docker compose down Para parar e remover os recipientes antigos (opcionalmente com --remove-orphans).
docker compose up -d --build se você criar imagens a partir do próprio servidor.

Essa abordagem funciona bem e é bastante robusta.Desde que você tenha bom controle sobre credenciais, variáveis de ambiente e volumes, é possível melhorar a segurança impedindo que o GitHub Actions tenha acesso root completo ao servidor, restringindo chaves SSH, usando usuários dedicados ou até mesmo expondo o Docker como um serviço remoto seguro com certificados, em vez de executar tudo via SSH.

Não existe um "método mágico" muito melhor do que este. Para um ambiente simples: a chave é automatizar e escrever bem o docker-compose.ymlUtilize tags de imagem imutáveis (por exemplo, versões específicas) e tenha algum mecanismo de reversão (por exemplo, salvando a versão anterior da composição ou das imagens).

Ambiente de desenvolvimento remoto com Docker, WSL 2 e VS Code.

No Windows, é muito comum desenvolver com Docker usando o WSL 2.O Docker Desktop para Windows oferece um mecanismo baseado no WSL 2 que permite executar contêineres Linux e Windows na mesma máquina, enquanto você edita o código com o VS Code e testa no navegador local.

Fluxo de trabalho típico para configurar um ambiente de desenvolvimento com contêineres remotos usando o WSL 2. É o seguinte:

Instale o WSL 2 e uma distribuição Linux (Ubuntu, por exemplo).
Você instala o Docker Desktop no Windows e habilita a opção "Usar mecanismo baseado em WSL 2" em Configurações > Geral.
Em Configurações > Recursos > Integração com WSL, você seleciona as distribuições WSL nas quais deseja que o Docker funcione.
Você verifica a instalação com docker --version e correndo docker run hello-world dentro da distribuição WSL.

Desenvolver “dentro” dos contêineres E não use apenas o Docker como sua plataforma; o VS Code é fundamental. Com o WSL, os contêineres de desenvolvimento e as extensões do Docker, você pode fazer coisas como:

Abra a pasta do seu projeto hospedada no WSL diretamente no VS Code.
Reabra essa pasta “em um contêiner de desenvolvimento” (Dev Container), usando um Dockerfile e um devcontainer.json que descrevem seu ambiente ideal (versão do Python, Node, etc.).
Depure seu aplicativo a partir do VS Code enquanto ele estiver em execução no contêiner.

Um exemplo muito comum Funciona com um projeto Django ou Node.js: você clona o repositório dentro do WSL, abre a pasta com code .Você seleciona uma definição de contêiner de desenvolvimento (por exemplo, “Python 3”) e o VS Code cria a imagem e inicia o contêiner com todas as dependências. A partir daí, você pode executar, depurar e verificar se o código funciona no Linux, mesmo que seu sistema host seja Windows.

Essa abordagem também é útil quando sua máquina não é muito potente.Porque você pode transferir parte da carga para um servidor remoto com o Docker e conectar-se a ele com o VS Code via SSH e Dev Containers, funcionando quase como se fosse local, mas dependendo dos recursos do servidor.

Implantação de aplicações em um servidor na nuvem com Docker e Docker Compose.

Configure um servidor na nuvem com Docker pronto para implantação. Com a maioria dos provedores, é muito rápido: você escolhe uma imagem de sistema que já vem com o Docker pré-instalado, espera alguns minutos e sua máquina está pronta para receber contêineres.

Um padrão típico para implantar uma aplicação Node.js simples. Seria isto:

Crie o projeto Node.js (por exemplo, um "Olá, mundo!" com Express) em sua máquina local: pasta do projeto, subdiretório app, npm init, instalação de dependências (como express) e um index.js que configura um servidor na porta 3030 com uma mensagem básica.
Dockerize o aplicativo com um dockerfile que define a imagem base (por exemplo node:12), The WORKDIRCopie os arquivos do aplicativo e execute-o. npm install e exponha a porta interna.
Adicione um .dockerignore para evitar colocar coisas como node_modules.
Crie uma docker-compose.yml na raiz do projeto, indicando a versão (por exemplo, 3.8) e definindo o serviço principal, seu build, mapeamento de portas (3030:3030) e o comando (node index).

Assim que o projeto e a composição estiverem prontos, você já pode começar.A implantação no servidor remoto geralmente segue este fluxo:

Você se conecta ao servidor via SSH.
Você clona o repositório ou carrega os arquivos (Git, SCP, rsync…).
você instala docker-compose se ainda não estivesse lá (em muitas distribuições, você precisa instalá-lo separadamente do Docker, por exemplo, baixando o binário do GitHub e concedendo permissões de execução).
Você executa docker-compose up (o docker compose up (dependendo da versão) para que as imagens sejam baixadas, a imagem do seu aplicativo seja criada e os contêineres sejam iniciados.

Um ponto que muitas vezes é negligenciado é o firewall do fornecedor.Se o seu serviço estiver escutando na porta 3030, você precisará abri-la nas regras do seu firewall ou criar uma política específica e associá-la ao servidor. Caso contrário, você verá apenas uma mensagem de "conexão recusada" externamente, mesmo que o contêiner esteja funcionando corretamente.

Assim que estiver operacional, você poderá acessar o aplicativo. usando o endereço IP público do servidor e a porta exposta (por exemplo, https://IP_DEL_SERVIDOR:3030), ou ocultando essa porta atrás de um proxy reverso como Nginx/Traefik que escuta nas portas 80/443.

Gerenciando contêineres remotos com Plesk e Docker

Se você usa o Plesk como seu painel de controle.Você também pode contar com a extensão Docker para gerenciar contêineres diretamente da interface web, tanto no próprio servidor quanto em hosts Docker remotos.

O Plesk oferece suporte ao Docker em uma boa variedade de sistemas operacionais.CentOS 7, RHEL 7, Debian 10/11/12, várias versões do Ubuntu (18.04, 20.04, 22.04, 24.04), AlmaLinux 8/9, Rocky Linux 8.x e Virtuozzo 7 atualizado. No Plesk para Windows, o Docker não é executado localmente, mas em uma máquina remota que atua como host do Docker.

Existem algumas limitações importantes a serem consideradas.:

Não é possível usar a extensão do Docker se o Plesk estiver implantado dentro de um contêiner Docker.
Para usar serviços Docker remotos (ou seja, hosts externos), você precisa de uma licença adicional ou de pacotes específicos (Pacote de Hospedagem, Pacote Power, Pacote de Desenvolvedor).
Os contêineres Docker gerenciados pelo Plesk não são "migratórios" propriamente ditos, embora seja possível fazer backup dos dados que eles utilizam por meio de volumes ou snapshots.

Na interface do Plesk, você pode pesquisar imagens. tanto no repositório local (imagens já baixadas para o host) quanto no Docker Hub. Para iniciar um contêiner, o painel o guiará:

Existe uma Docker > Contêineres > Executar contêiner.
Encontre a imagem desejada e consulte a documentação correspondente no Docker Hub (se aplicável).
Opcionalmente, selecione um rótulo/versão de imagem específico.
Configure os parâmetros do contêiner (variáveis de ambiente, portas, volumes, memória, inicialização automática, etc.) e clique em Executar.

O Plesk também permite gerenciar configurações avançadas. Para cada contêiner: reatribua portas (automática ou manualmente), decida se a porta é acessível pela Internet ou apenas pelo localhost, limite a RAM que o contêiner pode consumir, defina volumes (caminho no host e no contêiner) ou adicione quantas variáveis de ambiente forem necessárias.

Com relação ao aspecto de orquestração remotaO Plesk pode trabalhar com "serviços Docker remotos". Isso envolve configurar o daemon Docker no host remoto (por exemplo, usando um...). /etc/docker/daemon.json (com suporte para sockets TLS e TCP), gerar certificados .pem e registre esse host no Plesk a partir de Docker > Ambientes > Adicionar servidorEm seguida, você pode marcar esse nó do Docker como ativo e alternar entre diferentes servidores a partir da mesma interface.

Implante stacks do Docker Compose a partir do Plesk.

Se você já utiliza o Docker Compose para sua infraestruturaVocê pode ter interesse em que o Plesk gerencie a implantação de "stacks" a partir de arquivos. docker-compose.yml.

Fluxograma para implantação do Compose no Plesk É relativamente simples:

Entrar em Docker > Pilhas > Adicionar Pilha.
Atribua um nome de projeto à pilha.
Escolha a origem do arquivo Compose: editor (cole o conteúdo), carregue um arquivo do seu computador ou selecione um arquivo existente no espaço web de um domínio.
Confirme a configuração e permita que o Plesk declare e crie os contêineres definidos.

Tudo o que é construído durante o processo de construção. O arquivo Compose associado é armazenado no diretório principal do site, o que facilita o acesso a registros, artefatos intermediários ou arquivos adicionais gerados pela compilação.

O Plesk também facilita o gerenciamento de imagens locais.: de Docker > Imagens Você pode filtrar, revisar diferentes tags de produtos, ver o espaço utilizado e excluir imagens desatualizadas para liberar espaço em disco. Isso é importante em ambientes remotos com espaço limitado.

Se você usa o Nginx como seu servidor web front-endO Plesk aplica regras de proxy (por exemplo, em nginx.conf (do domínio) para rotear o tráfego para seus contêineres Docker, mesmo em cenários com NAT. Isso evita que você precise lidar manualmente com configurações de proxy reverso em servidores remotos.

Gerencie contêineres remotos com o Portainer.

Portainer é uma interface web leve. Para o Docker, isso simplifica muito o trabalho diário daqueles que não querem ficar presos à linha de comando. Ele funciona como um contêiner em si e pode gerenciar o host local ou vários hosts remotos (inclusive com o Portainer Agent).

Para instalar o Portainer no seu servidor usando o Docker Geralmente, você segue estes passos básicos:

Criar um volume para os dados do Portainer: docker volume create portainer_data.
Inicie o contêiner Portainer mapeando as portas 8000 e 9000 e montando o socket do Docker (/var/run/docker.sock) e o volume de dados: docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer.

Isso fará com que o Portainer fique escutando na porta 9000 do servidor.Como sempre, você precisará abrir a porta no seu firewall ou expô-la através de um proxy reverso HTTPS. Na primeira vez que você acessar pelo navegador, o Portainer solicitará que você crie um usuário administrador e, em seguida, você poderá escolher se deseja gerenciar o Docker local ou hosts remotos adicionais.

O painel do Portainer é bastante intuitivo.Você verá contêineres ativos, seus registros, estatísticas de consumo de recursos, stacks do Compose, redes, volumes e muito mais. E, o mais importante, permite recriar contêineres com parâmetros diferentes, atualizar imagens, gerenciar stacks e centralizar vários servidores remotos a partir de uma única interface.

Execute aplicativos gráficos em contêineres remotos e acesse-os por meio de um navegador.

Quando seu computador fica sem recursos Mas se você precisar usar aplicativos gráficos pesados (como clientes de e-mail, IDEs ou ferramentas de engenharia reversa), uma solução muito interessante é executá-los em contêineres Docker em um servidor potente e acessá-los pela web.

Um estudo de caso muito bem documentado. A ideia é encapsular o Mozilla Thunderbird em um contêiner, expor sua interface gráfica através do TigerVNC/noVNC e proteger o acesso com o Caddy. Esse conceito pode ser reutilizado para praticamente qualquer aplicação GUI no Linux.

A arquitetura básica desse tipo de contêiner gráfico geralmente inclui:

Um servidor VNC/X11 leve (TigerVNC) que funciona como um servidor de exibição.
Um gerenciador de janelas minimalista (OpenBox) para lidar com janelas.
Um tipo de servidor pequeno e fácil de usar easy-novnc que expõe o VNC como um WebSocket e gera uma página HTML para conexão a partir do navegador.
supervisord ou similar para iniciar e monitorar todos os processos dentro do contêiner.
O próprio aplicativo (Thunderbird, GIMP, etc.) configurado para ser exibido no monitor remoto (DISPLAY=:0).

Na prática, configura-se um diretório de trabalho. (por exemplo, ~/thunderbird) onde eles são colocados:

Un supervisord.conf que define os programas a serem executados: TigerVNC, easy-novnc, OpenBox e o aplicativo principal, com prioridades para que o servidor gráfico seja iniciado antes do aplicativo.
Un menu.xml O OpenBox configura o menu da área de trabalho (aplicativo principal, terminal, monitor de processos com htop, etc.).
Un Dockerfile de múltiplos estágios que na primeira etapa compila easy-novnc com Go, e na segunda etapa cria a imagem final no Debian, instalando openbox, tigervnc, supervisor, utilitários de console, o aplicativo (Thunderbird no exemplo), copiando os binários e configurações, criando um usuário não root e definindo um volume de dados persistente em /data.

O comando padrão do contêiner geralmente é delegado ao supervisord., iniciando-o como um usuário normal usando gosuApós ajustar as permissões no volume de dados, quando o contêiner é iniciado, o VNC, o noVNC, o gerenciador de janelas e o aplicativo são iniciados automaticamente, e você só precisa acessar a porta HTTP exposta pelo easy-novnc.

Para torná-lo mais robusto e fácil de usar na internet.É uma boa ideia colocar um servidor web como o Caddy na frente, também em um contêiner, que atue como um proxy reverso para seu aplicativo gráfico, adicione autenticação básica (nome de usuário e senha criptografados) e, opcionalmente, exponha um WebDAV para acessar os arquivos. /data do seu computador local.

Orquestre a solução com redes, volumes e Caddy.

Para manter esse tipo de implantação organizado A abordagem usual é criar sua própria rede Docker e um ou mais volumes de dados:

Rede, por exemplo thunderbird-net, que será compartilhada por todos os contêineres relacionados.
Volume thunderbird-data que conterá o perfil do usuário e os dados persistentes do aplicativo gráfico.

O contêiner do aplicativo gráfico Você pode iniciá-lo com algo como:

Política --restart=always para que possa se sustentar sozinha.
Montagem de volume thunderbird-data:/data.
Conexão a la red thunderbird-net.
Nome identificável (thunderbird-app(por exemplo) que o Caddy usará para o proxy reverso.

Em outro diretório (por exemplo, ~/caddyA imagem de Caddy é construída. com os módulos necessários (como o plugin WebDAV) e um Caddyfile que define:

Um servidor na porta 8080.
Un reverse_proxy para thunderbird-app:8080 (ou a porta que o noVNC expõe).
Caminhos adicionais para navegar pelos arquivos (/files) e para WebDAV (/webdav), ambos servindo o conteúdo do volume de dados.
Um bloco de basicauth que protege todos os caminhos com um usuário e uma senha criptografada lidas de variáveis de ambiente.

Ao criar o contêiner CaddyO mesmo volume é montado thunderbird-data:/data, conecta-se à rede thunderbird-net e sua porta é publicada (por exemplo, -p 8080:8080) no host. Com isso, basta acessar o seu navegador para http://IP_DEL_SERVIDOR:8080Insira suas credenciais e clique em conectar para começar a usar o aplicativo gráfico remotamente.

A manutenção a longo prazo é simples.Quando precisar atualizar, você pode parar e excluir os contêineres, reconstruir as imagens com as novas versões e reiniciá-las. docker run manter o volume de dados, para que as configurações e os arquivos do usuário permaneçam intactos.

Com todas essas peças (Docker Compose, Plesk, Portainer, VS Code, WSL 2, Caddy, noVNC…) É possível configurar desde implantações de backend simples até desktops remotos encapsulados em contêineres e perfeitamente acessíveis via navegador, aproveitando servidores com muito mais poder de processamento do que sua máquina e mantendo um controle bastante preciso sobre redes, segurança, armazenamento e atualizações.