Loja virtual em contêiner Docker: como saber se a sua já roda assim, o que muda na VPS e quando não vale a pena

Quem instalou a loja direto na VPS — arquivos no disco, Apache, PHP e MySQL montados à mão — quase certamente não está em contêiner. Veja como confirmar isso em um minuto, o que containerizar exige de verdade e em quais casos esse trabalho pode esperar.

Se a loja foi instalada direto na VPS, com arquivos no disco e Apache, PHP e MySQL montados à mão, ela não é uma loja virtual em contêiner Docker. Contêiner é transformar essa instalação artesanal numa peça que qualquer máquina consegue repetir — e é por isso que ele é o pré-requisito do burst.

• Loja subida por FTP ou git pull numa VPS com painel de hospedagem está instalada no sistema operacional, não em contêiner. Painel gerencia serviço instalado no sistema: é o modelo oposto.
• Três checagens de um minuto tiram a dúvida: a pergunta certa ao dev, docker ps no servidor e a busca por Dockerfile na pasta do projeto.
• Containerizar não muda endereço, provedor, backup nem painel administrativo. Muda o jeito de publicar alteração: em vez de sobrescrever arquivo, você troca a imagem.
• Pode esperar se a loja está lenta todo dia, se o gargalo é o banco, se há plugin gravando na própria pasta ou se a hospedagem é compartilhada sem acesso root.
• Contêiner é pré-requisito do burst: só uma peça reproduzível pode ser duplicada dentro da janela de um pico.

Loja virtual em contêiner Docker comparada com a instalação direta na VPS

Hoje sua loja provavelmente roda assim: Apache ou nginx, PHP e MySQL instalados no sistema da VPS, os arquivos numa pasta e a configuração espalhada entre arquivos do sistema, do PHP e telas do painel. Funciona. O problema é que essa montagem foi feita uma vez e ninguém sabe repetir igual.

Contêiner é a aplicação empacotada com tudo de que ela precisa para rodar — versão do PHP, extensões, bibliotecas, módulos do servidor web e configuração — num pacote fechado que sobe igual em qualquer máquina com Docker instalado.

Dois termos aparecem sempre: a imagem é a receita gravada, o pacote pronto; o contêiner é essa receita rodando. Com imagem, acrescentar capacidade deixa de ser “instalar tudo de novo na outra máquina” e vira “rodar a mesma imagem em outra máquina”.

Não é máquina virtual. O contêiner compartilha o núcleo do sistema da máquina hospedeira — o kernel — em vez de carregar um sistema operacional próprio. Por isso sobe em segundos e ocupa pouco, o que permite abrir e fechar capacidade numa janela em que uma VM completa não entra.

Quando o dev diz “sua loja precisa estar em Docker”, a frase quer dizer uma coisa só: a aplicação precisa virar um pacote que outra máquina sobe igual, sem ninguém refazer a instalação na mão. Multiplicar réplica não é o mesmo que multiplicar máquina — a distinção está em auto scaling em VPS.

Três checagens de um minuto que dizem se a loja está containerizada

1. Pergunte ao dev com a pergunta certa. Não “a gente usa Docker?”, e sim: “a loja sobe a partir de uma imagem ou está instalada direto no sistema da VPS?”. A primeira aceita um sim vago; a segunda obriga a escolher um lado.
2. Rode docker ps no servidor. Linhas de contêineres rodando significam sim. command not found significa que nem Docker existe ali. Lista vazia significa Docker instalado e a loja fora dele. Erro de permissão não é resposta: repita com sudo.
3. Procure docker-compose.yml, compose.yml ou Dockerfile na pasta do projeto. A presença é indício forte; a ausência, somada às outras duas checagens, fecha o diagnóstico.

Caso ambíguo comum: Docker existe na máquina por causa de outra coisa — um banco, uma ferramenta de monitoramento, um painel auxiliar — e a loja continua fora dele. docker ps lista contêineres, mas nenhum deles é a loja. Vale conferir o que cada linha está rodando.

O que containerizar exige: imagem, uploads, banco e variáveis de ambiente

Containerizar não é instalar Docker e seguir a vida. É reescrever a forma como a aplicação nasce, em quatro frentes:

• A imagem da aplicação. Alguém precisa escrever o Dockerfile: versão do PHP, extensões que a loja usa, módulos do servidor web, o código. É aqui que aparece toda configuração feita à mão e nunca documentada.
• Uploads e arquivos gravados pela loja precisam de endereço fixo fora do contêiner — volume compartilhado ou armazenamento de objeto. Contêiner é descartável: o que está dentro dele some na troca. É o item que mais derruba migração malfeita, e o inventário está em o que some quando a loja roda em dois servidores.
• O banco de dados normalmente fica fora do contêiner da aplicação, como serviço central ao qual todas as cópias perguntam. Ele não é replicado junto; é consultado por todas.
• Variáveis de ambiente. Senha do banco, chaves e endereços saem de arquivo editado à mão e passam a ser injetados na hora de subir. É isso que permite a mesma imagem rodar na VPS e na nuvem sem editar nada.

E o deploy muda de natureza. Em vez de sobrescrever arquivo no servidor, você gera uma imagem nova, publica e troca. Se der errado, volta para a imagem anterior — o que hoje, com FTP, costuma ser restauração de backup feita sob pressão.

O que muda no dia a dia da loja — e o que continua igual

O ponto do plugin merece destaque porque pega todo mundo. Instalar plugin pela tela administrativa grava arquivo dentro do contêiner em execução. Na próxima troca de imagem, aquele arquivo não está mais lá: a instalação precisa entrar na imagem, não no contêiner que está rodando.

E há o que containerizar não muda: o gargalo. Se o banco está no teto hoje, continua no teto depois. Contêiner reorganiza a forma da aplicação; não acelera consulta nem deixa página pesada mais leve.

Quando containerizar não vale a pena agora

• Plugin que grava direto na pasta da aplicação. Construtor de página que salva CSS no diretório do tema, plugin de cache que escreve na própria pasta. Containerizar sem resolver isso troca um problema por outro.
• Site lento todos os dias, inclusive fora do pico. O problema não é falta de capacidade: é a aplicação. O caminho é achar o gargalo na VPS, não empacotar a lentidão numa imagem.
• Gargalo no banco de dados. Duplicar aplicação em cima de um banco apertado piora o aperto, containerizado ou não — a mecânica está em gargalo de banco de dados MySQL na VPS.
• Hospedagem compartilhada sem acesso root. Não há como instalar Docker. A decisão anterior é sair da hospedagem compartilhada.
• Pico raríssimo e curto, de poucas horas por ano. Trocar o plano da VPS por alguns dias pode sair mais barato do que reconstruir toda a forma de publicar a loja.

Preciso migrar para Kubernetes para ter contêiner?

Não. Kubernetes é um orquestrador grande — o software que decide em qual máquina cada contêiner roda — feito para operação com time dedicado. Para uma loja em VPS, costuma custar mais em complexidade do que devolve. Docker Swarm faz o essencial com muito menos peça para administrar: rodar a mesma imagem em várias máquinas, distribuir o acesso e acrescentar ou remover máquina.

E vale separar os dois passos: containerizar e orquestrar são coisas diferentes. Dá para empacotar a loja e continuar rodando numa VPS só, sem cluster nenhum, e acrescentar máquinas quando isso fizer falta. O passo a passo do cluster está em como configurar cloud bursting no Docker Swarm.

Contêiner é o pré-requisito do burst porque só se duplica o que é reproduzível

Burst é acrescentar máquina na nuvem só durante o pico e removê-la quando a demanda cai. Isso impõe uma condição dura: a máquina nova precisa começar a atender em minutos, sem ninguém do lado dela.

Instalação artesanal não cabe nessa janela. Ninguém instala PHP, ajusta extensão, copia arquivo e confere configuração enquanto a loja está no pico da Black Friday — e, mesmo que desse tempo, o resultado seria uma tentativa de reproduzir a original, não a original.

Imagem cabe. A máquina nova baixa a imagem, sobe o contêiner e entra no atendimento. É a mesma peça. Por isso “sua loja precisa estar em Docker” não é preferência de quem instala: é a condição que separa capacidade sob demanda de promessa vazia. O conceito inteiro está em o que é cloud bursting.

O SwarmBurst é instalado no cluster do próprio cliente e trabalha em cima dessa imagem. Sem ela, não existe o que duplicar quando o pico chega. O próximo passo é curto: rode as três checagens e, se a resposta for “não está em contêiner”, use os casos acima para decidir se há um diagnóstico anterior na frente.

Quero saber se a minha loja está pronta para virar imagem

Se você já rodou as checagens e quer discutir o caso da sua loja — o que containerizar exige aí dentro e se vale a pena agora —, é uma conversa no WhatsApp.

Perguntas frequentes

Como sei em um minuto se minha loja já está em contêiner?

Existem três checagens simples: primeiro, pergunte ao dev a forma correta (“a loja sobe a partir de uma imagem ou está instalada direto no sistema?”), não uma pergunta vaga. Segundo, rode docker ps no servidor — linhas de contêineres rodando significam sim, command not found significa que Docker nem existe ali. Terceiro, procure docker-compose.yml, compose.yml ou Dockerfile na pasta do projeto. A presença é indício forte de containerização.

O que é um contêiner comparado com a VPS que eu já tenho?

Um contêiner é a aplicação empacotada com tudo de que ela precisa para rodar — versão do PHP, extensões, bibliotecas, módulos do servidor web e configuração — num pacote fechado que sobe igual em qualquer máquina com Docker instalado. Ao contrário de máquinas virtuais, o contêiner compartilha o núcleo (kernel) do sistema da máquina hospedeira em vez de carregar um sistema operacional próprio. Por isso sobe em segundos e ocupa pouco, permitindo acrescentar e remover capacidade rapidamente.

O que muda e o que não muda no dia a dia após containerizar a loja?

Continuam iguais: o endereço da loja, domínio, caixas de e-mail, provedor da VPS, backup de banco e uploads, e o painel administrativo da plataforma. Mudam: o jeito de subir alteração (de FTP no servidor para gerar imagem nova e publicar), quem mexe precisa saber o básico de Docker, e passa a existir ambiente de teste igual ao de produção com volta atrás rápida. Importante: instalar plugin pela tela administrativa grava arquivo dentro do contêiner em execução, não na imagem; na próxima troca de imagem, aquele arquivo não está mais lá.

Preciso migrar para Kubernetes ou Docker Swarm resolve?

Kubernetes é um orquestrador grande feito para operação com time dedicado, e costuma custar mais em complexidade do que devolve para uma loja em VPS. Docker Swarm faz o essencial com muito menos peça para administrar: rodar a mesma imagem em várias máquinas, distribuir o acesso e acrescentar ou remover máquina. Vale separar os dois passos: containerizar e orquestrar são coisas diferentes. Dá para empacotar a loja e continuar rodando numa VPS só, sem cluster nenhum, e acrescentar máquinas quando isso fizer falta.