Docker — contentores isolados para sites estáveis
Toda a plataforma 4buildsite — o editor, a API, o motor de renderização e o serviço que entrega os sites publicados — corre em contentores Docker: pacotes isolados que contêm tudo aquilo de que cada serviço precisa. O teu site é renderizado de forma estática e entregue como uma versão completa, comutada atomicamente a cada publicação. O resultado, em linguagem simples: as publicações são versionadas e, se algo correr mal, voltas à versão anterior.
O que é um contentor — e porque é que isso importa para o teu site
Um contentor é um pacote padronizado que contém a aplicação e absolutamente tudo o que ela precisa para funcionar: runtime, bibliotecas, configuração. O contentor corre isolado do resto do servidor, mas usa diretamente o kernel Linux da máquina anfitriã — sem um sistema operativo separado por aplicação. O Docker, lançado em 2013, transformou esta tecnologia num padrão acessível; o formato de imagem está hoje normalizado como OCI (Open Container Initiative) e corre de forma idêntica em qualquer servidor Linux ou cloud.
A analogia clássica é o contentor marítimo: independentemente da carga que leva, tem sempre a mesma forma padrão e pode ser transportado por qualquer navio, comboio ou camião. Da mesma forma, os serviços da 4buildsite que constroem e entregam o teu site — o editor, a API FastAPI, o motor de renderização — são empacotados em imagens padrão que correm da mesma maneira no servidor de testes e no de produção. Para ti, enquanto proprietário de um site ou de uma loja, isso significa previsibilidade: o que viste na pré-visualização é exatamente o que os visitantes recebem.
- Contentor = a aplicação mais as suas dependências, num único pacote isolado
- Formato padrão OCI — a mesma imagem corre em qualquer servidor ou cloud
- Sem sistema operativo separado por serviço — arranque em segundos, não em minutos
- Na 4buildsite, a contentorização é gerida pela plataforma — a ti basta-te publicar
Isolamento: o teu site não depende dos vizinhos
Num alojamento partilhado clássico, centenas de sites partilham o mesmo servidor, os mesmos processos e, muitas vezes, a mesma instalação de PHP. Se um vizinho apanha um pico de tráfego ou se um script mal escrito consome todo o processador, o teu site fica mais lento — é o fenómeno do «noisy neighbour». A 4buildsite ataca o problema por duas frentes. A primeira: os sites publicados são renderizados de forma estática — nos servidores que os entregam não corre código por site (PHP, plugins, scripts), portanto não existe o script mal escrito de um vizinho a consumir o processador. A segunda: cada serviço da plataforma corre no seu próprio contentor, com processos e ficheiros separados (através de namespaces) e com a possibilidade de impor limites de CPU e de memória (através de cgroups, os mecanismos do kernel Linux).
O isolamento conta tanto para a segurança. No alojamento partilhado, um site comprometido pode tornar-se uma porta de entrada para os sites vizinhos no mesmo servidor. Na 4buildsite, o site publicado é um conjunto de ficheiros estáticos — não corre código que possa ser comprometido através de plugins ou de temas — e os serviços da plataforma que processam dados (encomendas, pagamentos, editor) ficam em contentores separados: o sistema de ficheiros está isolado e um eventual incidente permanece fechado nesse contentor.
- Site publicado = ficheiros estáticos — zero código por site que possa ser comprometido
- Serviços da plataforma: sistema de ficheiros e processos separados por contentor
- Entrega estática: nenhum código por site que sobrecarregue o processador nos picos de tráfego
A mesma versão em todo o lado: zero «no meu computador funciona»
A fonte mais frequente de falhas na web clássica é a diferença entre o ambiente em que o site foi testado e o servidor onde corre em produção: outra versão da linguagem, outra extensão em falta, outra configuração. Uma imagem Docker elimina toda esta categoria de problemas: a imagem é construída uma única vez, com todas as dependências fixadas, e é exatamente o mesmo artefacto que corre em testes e em produção. Não existe o «configurado à mão no servidor».
Para ti, isso traduz-se diretamente em estabilidade. Quando alteras o site no editor visual em panel.4buildsite.net e carregas em publicar, a versão que chega aos visitantes passou pelos mesmos passos, pelos mesmos serviços contentorizados, de todas as vezes. Menos surpresas depois de publicar significa menos noites com a loja em baixo — e, para uma loja online, cada hora de indisponibilidade significa encomendas perdidas.
Publicações com comutação atómica e rollback
Na 4buildsite, publicar não significa «desligamos o site, copiamos ficheiros e esperamos pelo melhor». Cada publicação gera uma versão nova e completa do teu site — renderizada de forma estática, separada daquela que está em produção — e a comutação para ela é atómica: numa única operação, o serviço de entrega passa a servir a versão nova. Os visitantes veem sempre uma versão completa — também a meio de uma encomenda no carrinho de compras. O mesmo princípio aplica-se aos serviços da plataforma: a versão nova de um contentor arranca ao lado da antiga e só recebe tráfego depois das verificações de saúde.
Igualmente importante é o caminho de volta. Cada versão publicada do site é guardada intacta, portanto voltar à versão anterior é simplesmente comutar de novo — uma operação simples, não um restauro de cópia de segurança que demora horas. Se uma publicação introduzir um problema, a tua loja não fica presa à versão com defeito. A única nuance honesta: os dados (encomendas, produtos, conteúdos) vivem na base de dados, separados das versões publicadas — por isso são geridos em volumes persistentes, à parte dos ficheiros do site.
- Cada publicação = uma versão nova e completa, comutada atomicamente
- Rollback = comutar de volta para a versão anterior
- Publicas alterações a qualquer momento, mesmo em plena época de vendas; cada versão anterior fica guardada
Eficiência e custos: mais desempenho pelo mesmo dinheiro
Uma máquina virtual clássica corre um sistema operativo completo para cada aplicação — gigabytes de memória e minutos de arranque gastos só na «embalagem». Os contentores partilham o kernel do anfitrião, por isso no mesmo servidor cabem muitos mais sites, cada um com o seu isolamento. Essa densidade é a razão pela qual a 4buildsite pode incluir alojamento e SSL na subscrição, sem um custo de infraestrutura separado por site.
Para o teu site publicado, escalar com o tráfego é ainda mais simples: sendo ficheiros estáticos, servi-los é extremamente barato — um pico de visitantes significa mais ficheiros entregues, não processos adicionais a pisar os pés uns aos outros. E os serviços da plataforma, sendo contentores que arrancam em segundos, podem receber instâncias adicionais quando é preciso. Pagas uma subscrição previsível e não uma infraestrutura permanentemente dimensionada para o dia mais movimentado do ano. Sobre a forma como operamos efetivamente estes contentores — orquestração, proxy, CI/CD, monitorização — lê a página Cloud & DevOps.
Vantagens e limitações
Vantagens
- O site publicado é servido de forma estática e a plataforma corre em contentores isolados — o site não partilha processos com os vizinhos.
- As mesmas imagens da plataforma em testes e em produção — zero «no meu computador funciona».
- Publicações com comutação atómica: a versão nova do site é gerada em separado e comutada numa única operação.
- Rollback para a versão publicada anteriormente se uma alteração não correr bem.
- Os contentores arrancam em segundos — os serviços da plataforma podem receber instâncias adicionais quando é preciso.
- Densidade elevada por servidor — alojamento incluído na subscrição, sem custo separado.
Limitações
- O isolamento assenta no kernel partilhado do anfitrião — é mais fraco do que o isolamento por hardware de uma máquina virtual dedicada.
- O contentor é efémero: os dados persistentes (base de dados, ficheiros carregados) exigem volumes e cópias de segurança geridos à parte.
- As imagens e as respetivas camadas ocupam espaço em disco — sem limpeza periódica vão-se acumulando.
- Para as equipas que o administram sozinhas, o Docker tem uma curva de aprendizagem real — na 4buildsite é totalmente gerido pela plataforma.
Veredicto breve
A contentorização com Docker é o padrão de facto da indústria para correr aplicações web: isolamento, consistência entre testes e produção e rollback instantâneo. Na 4buildsite, a plataforma que constrói e entrega o teu site corre contentorizada, e as publicações do teu site são versionadas, comutadas atomicamente e reversíveis — a forma como a infraestrutura é operada (orquestração, proxy, CI/CD) está descrita na página Cloud & DevOps.
Tabela de especificações
| Capacidade | Limite / limiar | Utilização típica | |
|---|---|---|---|
| Isolamento de recursos | Limites de CPU/RAM por contentor (cgroups, namespaces) | Kernel partilhado — não é isolamento por hardware como numa VM | Sites e lojas em infraestrutura partilhada |
| Arranque / deploy | O contentor arranca em segundos | A primeira transferência da imagem demora mais tempo | Publicações e atualizações frequentes, cada uma como versão completa |
| Rollback | Voltas a qualquer imagem anterior em segundos | Os dados da base de dados não regressam com a imagem | Regresso instantâneo quando uma atualização não corre bem |
| Portabilidade | Imagem OCI — corre em qualquer host Linux ou cloud | As imagens são por arquitetura (x86/ARM) | Mudança entre servidores sem reescrever a aplicação |
| Densidade / custo | Dezenas de contentores isolados num único servidor | Todos partilham o kernel e o disco do anfitrião | Custo baixo por site — alojamento incluído na subscrição |
Docker vs máquinas virtuais vs alojamento partilhado (cPanel)
| Critério | Docker (contentores) | Máquinas virtuais | Alojamento partilhado (cPanel) |
|---|---|---|---|
| Isolamento | Por contentor (processos, ficheiros, recursos) | Completo (hardware virtualizado) | Fraco — centenas de sites no mesmo servidor |
| Rapidez de arranque / deploy | Segundos | Minutos (arranque completo do SO) | Alterações diretamente no servidor em produção (FTP) |
| Consumo de recursos | Mínimo — sem SO separado por aplicação | Elevado — um SO completo por máquina | Baixo, mas partilhado sem controlo entre vizinhos |
| Rollback | Instantâneo — reinicias a imagem anterior | A partir de um snapshot — mais lento | Manual, a partir de cópia de segurança |
| Segurança | Incidente limitado ao contentor | O isolamento mais forte | Um site comprometido pode afetar os vizinhos |
| Custo por site | Baixo — densidade elevada por servidor | Alto — pagas a máquina inteira | Muito baixo, mas com desempenho imprevisível |
Perguntas frequentes
O Docker afeta a velocidade do meu site?
Não. Os contentores correm nativamente sobre o kernel Linux, sem uma camada de virtualização de hardware, pelo que a sobrecarga é negligenciável. A velocidade do site depende do código, da cache e da rede.
Porquê não usar alojamento clássico com cPanel, como no WordPress?
No alojamento partilhado clássico, centenas de sites partilham o mesmo servidor sem limites rigorosos: um vizinho sobrecarregado deixa-te lento e um vizinho comprometido pode afetar-te. Na 4buildsite, o site publicado é servido de forma estática — não corre código por site que possa ser comprometido — e os serviços da plataforma correm isolados em contentores, com publicações por comutação atómica. Coisas que o cPanel não oferece.
O que acontece se uma publicação estragar o meu site?
A versão publicada anteriormente continua a existir, intacta, por isso o regresso é simples: o serviço de entrega comuta de volta para ela. A loja não fica presa a uma versão com defeito e os dados da base de dados permanecem intactos.
Preciso de saber Docker para usar a 4buildsite?
Não. A contentorização é totalmente gerida pela plataforma: tu constróis o site no editor visual em panel.4buildsite.net e publicas. O Docker trabalha «por baixo do capô» — recebes os benefícios (isolamento, rollback, comutação atómica) sem qualquer configuração.
O Docker é seguro para uma loja online?
Sim. O isolamento dos processos e dos ficheiros limita o alcance de um eventual incidente ao contentor em causa e não ao servidor inteiro. De qualquer forma, os dados de cartão não passam pelo contentor — os pagamentos são processados pela Stripe, na infraestrutura certificada da Stripe.
O Docker é a mesma coisa que uma máquina virtual?
Não. Uma máquina virtual virtualiza o hardware por completo e corre o seu próprio sistema operativo — arranca em minutos e consome muito. Um contentor partilha o kernel do anfitrião: arranca em segundos, consome uma fração dos recursos e mantém o isolamento da aplicação.