Hosting Docker Compose. Twój compose, nasz serwer.

1. Docker como tipo de aplicação, não como produto adicional

Muitos fornecedores de hosting tratam o Docker como uma funcionalidade reservada a planos VPS ou cloud mais caros, porque exige mais isolamento e controlo do que o hosting partilhado habitual. No Saplo, o Docker é apenas um tipo de aplicação do catálogo, tão acessível como o WordPress ou um site estático, sem um limiar de preço superior adicional pelo simples facto de executar contentores.

Na prática, 152 das 166 aplicações do catálogo do Saplo têm Docker por baixo, pelo que o motor de contentores funciona em cada Box com Docker, independentemente de se instalar uma configuração pronta do catálogo ou uma imagem própria do tipo custom.

Para a tua própria imagem Docker, existe o tipo de aplicação custom, onde podes indicar o teu próprio Dockerfile ou docker-compose, sem te limitares aos modelos prontos do catálogo, o que te dá total liberdade para projetos personalizados.

2. Registo privado de imagens incluído no preço

O catálogo de aplicações também inclui o Docker Registry: um registo privado de imagens (imagem oficial registry:2) com uma UI simples para consultar repositórios, tags e camadas no navegador, protegido por basic auth com credenciais geradas aleatoriamente durante a instalação.

Para uma equipa que constrói as suas próprias imagens em CI/CD, isto significa manter imagens privadas sem uma conta no Docker Hub e sem os limites de pull rate aplicados às contas gratuitas de registos públicos quando transferes imagens com frequência durante os deploys.

A UI do registo funciona como reverse proxy da API do próprio registo, num único domínio e sem CORS. Assim, docker login, push e pull funcionam diretamente no domínio da aplicação, sem ports adicionais para configurar.

3. De quanta RAM precisam as aplicações Docker

As aplicações Docker mais comuns no catálogo do Saplo requerem entre 1 e 2 GB de RAM (Baserow, Chatwoot, Flowise, n8n, Windmill e Typebot, entre 1 e 2 GB cada), porque o contentor da imagem oficial costuma incluir mais dependências do que uma instalação PHP leve ou uma aplicação estática simples.

O Box M (2 GB de RAM) permite-te alojar confortavelmente uma aplicação Docker típica, enquanto o Box L (6 GB de RAM) permite-te alojar várias aplicações Docker em paralelo. Quando constróis um conjunto maior de ferramentas (CRM, chat e automatização em conjunto), o Box L é o mínimo real para que não compitam pela memória. Para um conjunto ainda maior de aplicações Docker, vale a pena considerar o Box XL, em que os 12 GB de RAM deixam uma margem real para desenvolveres o catálogo de ferramentas sem precisares de verificar frequentemente qual aplicação consome mais memória em cada Box.

Para as tuas próprias imagens Docker não padronizadas (tipo custom), os requisitos de RAM dependem do que cada imagem faz. Testa o consumo de memória localmente antes de escolheres um Box, tal como em qualquer outra implantação de contentores.

4. Docker no Saplo vs. Docker num VPS limpo

Num VPS sem nada instalado, tens de instalar o Docker manualmente, configurar as portas dos contentores no firewall e definir manualmente um proxy reverso com SSL para cada serviço em execução, o que representa uma barreira concreta para quem não está familiarizado com a administração Linux.

No Saplo, o contentor LXC do Box já tem o suporte para o Docker configurado (keyctl, nesting), pelo que docker run ou docker compose up funcionam assim que te ligas por SSH. O painel configura o reverse proxy e o SSL para aplicações públicas quando associas um domínio.

A diferença de custo entre um VPS limpo e um Box com Docker é normalmente pequena para recursos semelhantes, mas o tempo necessário para lançar o primeiro serviço é significativamente menor no Saplo, porque não tens de configurar o motor de contentores de raiz.

5. Para quem é indicado

Para implementares a tua própria imagem Docker sem configurares um VPS de raiz, o tipo de aplicação custom num Box M ou L dá-te um ambiente pronto com suporte a Docker e SSL automático para o domínio associado.

Para uma equipa que constrói as suas próprias imagens em CI/CD, o Docker Registry privado do catálogo de aplicações elimina a necessidade de uma conta num registo público e dos respetivos limites de pull rate.

Para quem está a testar várias aplicações Docker do catálogo ao mesmo tempo (por exemplo, CRM, chat e automatização), o Box L com 6 GB de RAM dá espaço para executar várias em paralelo sem que compitam pela memória.

6. Primeira implantação da tua própria imagem Docker no Saplo

Depois de escolheres o tipo de aplicação custom, inicia sessão por SSH (a partir do Box M) e prepara o docker-compose.yml ou o Dockerfile do teu projeto, tal como farias em qualquer outro ambiente com o Docker instalado.

Configuras o reverse proxy e o SSL para um serviço público no painel do Saplo depois de associares um domínio, indicando a porta em que o teu contentor está à escuta, sem teres de configurar manualmente o nginx ou o certificado.

Configura os volumes de dados de modo a que os dados da aplicação sobrevivam ao reinício do contentor e sejam abrangidos pelo backup do Box, caso o teu plano inclua o backup no preço.

Para aplicações com vários contentores (por exemplo, uma base de dados, uma aplicação e um worker num único docker-compose), verifica se a RAM total de todos os contentores cabe no limite do Box escolhido antes de pores toda a stack a funcionar.

O Docker Registry privado do catálogo de aplicações permite-te armazenar as imagens que constróis e depois as descarregar para o Box com docker pull no mesmo domínio, sem precisar de uma conta num registo público.

7. CI/CD e compilação automática de imagens Docker

Um fluxo CI/CD típico passa por compilar a imagem num sistema externo (GitHub Actions, GitLab CI), fazer o push para o Docker Registry privado no Saplo e, depois, executar docker pull e reiniciar o contentor no Box de produção.

A automatização da última etapa (pull e reinício após uma nova imagem) pode ser feita com um script simples executado por SSH ou através de um webhook que ativa um workflow no n8n instalado no mesmo Box.

Um registo privado de imagens elimina os limites de pull rate aplicados às contas gratuitas em registos públicos, algo que, em implantações frequentes (várias vezes por dia), pode tornar-se um problema real para contas sem um plano pago de um fornecedor externo.

Para equipas que trabalham em vários ambientes (staging, produção), podes manter tags distintas para diferentes imagens no mesmo registo privado, o que facilita o controlo da versão da aplicação que está a ser executada em cada ambiente.

8. Boas práticas ao utilizar imagens Docker próprias em produção

Fixar uma versão exata da imagem base (por exemplo, node:20.11-alpine e não node:latest) evita que uma atualização da imagem base pelo respetivo fornecedor altere inesperadamente o comportamento da tua aplicação após a próxima reconstrução do contentor, muitas vezes sem qualquer aviso explícito da alteração.

A construção de imagens em várias etapas (multi-stage build) permite manter a imagem final de produção pequena, sem ferramentas de construção nem dependências de desenvolvimento. Isto acelera a transferência da imagem para o registo e do registo para o servidor de produção, além de reduzir a superfície de ataque do próprio contentor.

As variáveis de ambiente e os segredos (palavras-passe, chaves API) nunca devem ser escritos diretamente na imagem Docker como valores inseridos no Dockerfile; devem ser passados no momento do arranque do contentor, porque uma imagem já construída com um segredo no interior pode acabar no registo e ser reconstruída a partir de lá por qualquer pessoa com acesso ao registo.

Um healthcheck configurado na imagem ou no docker-compose permite detetar automaticamente que o contentor está em execução, mas a aplicação no interior deixou de responder, por exemplo devido a um processo bloqueado. Sem healthcheck, esta situação pode passar despercebida, porque o contentor continua formalmente em execução.

Os logs do contentor devem ser enviados para a saída padrão (stdout/stderr), e não para ficheiros dentro do contentor. Os logs em ficheiro desaparecem quando o contentor é removido, enquanto os da saída padrão podem ser recolhidos e analisados mais facilmente com as ferramentas padrão do Docker.

Rever regularmente quais imagens e tags do registo privado ainda estão em uso ajuda a manter a organização e a libertar espaço em disco ocupado por versões antigas que já não são necessárias, acumuladas após sucessivas implantações por CI/CD.

9. Ecossistema Docker Hub e imagens da comunidade como ponto de partida

Uma enorme quantidade de imagens Docker oficiais e prontas, disponíveis publicamente (bases de dados, servidores de aplicações, ferramentas auxiliares), permite implementar a maioria dos serviços comuns em Saplo sem teres de escrever um Dockerfile de raiz, aproveitando imagens já testadas e ativamente mantidas.

O catálogo de aplicações da Saplo inclui modelos prontos baseados em muitas dessas imagens oficiais (por exemplo, prestashop/prestashop, n8nio/n8n, flowiseai/flowise), o que significa que o cliente nem precisa de saber que a aplicação está a funcionar em Docker, porque toda a configuração já está preparada.

Para as tuas necessidades personalizadas (tipo de aplicação custom), o acesso a todo o ecossistema do Docker Hub e a outros registos públicos de imagens permite usar imagens prontas como ponto de partida, adaptando-as às tuas necessidades com o teu próprio Dockerfile construído sobre a imagem base.

O Docker Registry privado disponível no catálogo de aplicações do Saplo complementa este ecossistema, oferecendo um local para armazenar as tuas próprias imagens construídas sem necessidade de as publicar publicamente no Docker Hub, o que pode ser um requisito de segurança importante em projetos comerciais e confidenciais.

Para equipas técnicas que acompanham a evolução do ecossistema de contentores (novas ferramentas de orquestração, novas práticas de construção de imagens), o acesso SSH completo ao contentor LXC do Box, com suporte a Docker no Saplo, não impõe restrições relativamente ao que é possível fazer num servidor clássico com Docker, gerido de forma independente.

10. Testar imagens Docker antes da passagem a produção

Vale a pena testar uma nova imagem Docker localmente ou num contentor temporário no mesmo Box antes de substituir o contentor de produção em funcionamento, pois um erro na nova imagem, como uma versão incompatível de uma dependência, pode deixar o serviço indisponível até reverteres a alteração.

Atribuir versões às tags das imagens no registo privado, em vez de usar apenas latest, permite regressar facilmente à versão anterior e funcional caso a nova versão se revele problemática depois da implementação num contentor de produção.

Em aplicações com vários contentores (docker-compose com uma base de dados, uma aplicação e um worker), é importante testar a alteração como um conjunto, e não apenas o contentor alterado. As incompatibilidades de versões entre contentores interligados são uma causa frequente de problemas que não aparecem ao testar um único elemento isoladamente.

Um healthcheck configurado na imagem ajuda a detetar automaticamente que um novo contentor não está a funcionar corretamente após a implementação. Combinado com um script simples de rollback para a tag anterior da imagem, permite reverter rapidamente uma alteração problemática sem uma interrupção prolongada do serviço. Este mecanismo simples de teste e reversão, embora não seja um sistema CI/CD completo, já reduz significativamente o risco de uma paragem mais longa causada por uma única implementação mal testada de uma nova imagem.

11. Resumo: Docker como padrão, não uma funcionalidade premium

Tratar o Docker como um elemento de infraestrutura padrão, disponível em cada Box, e não como uma funcionalidade reservada aos planos mais elevados e caros reflete a popularidade que este método de empacotamento de aplicações ganhou nos últimos anos. Independentemente de escolheres uma receita pronta no catálogo ou implantares a tua própria imagem não padrão através do tipo de aplicação custom, o motor de contentores já está configurado e pronto a funcionar desde o primeiro dia no teu Box. Para as equipas técnicas habituadas a trabalhar com Docker nas suas próprias máquinas de desenvolvimento, a passagem para o Saplo não exige mudar de hábitos, apenas transferir a mesma forma de trabalho, já conhecida, para um ambiente de produção com suporte para domínio e certificado SSL.