Como alojar um site no ZimaOS com o Docker

Pode alojar um site no ZimaOS sem modificar a própria pilha web do sistema operativo: execute o Apache, o Nginx ou outro servidor web dentro de um contentor Docker isolado e publique uma porta separada do anfitrião, como a 8080. Assim, a configuração do site mantém-se independente da interface de gestão do ZimaOS.

O exemplo da comunidade demonstra esse padrão básico, mas há um detalhe que precisa de ser corrigido: o respetivo Dockerfile expõe a porta 10000, mas não instala o Webmin. Expor uma porta não cria um serviço por detrás dela.

Use um contentor em vez de reconfigurar o próprio ZimaOS

O ZimaOS já utiliza serviços web para a sua própria interface. Substituir ou reconfigurar esses serviços do anfitrião cria riscos desnecessários durante as atualizações e pode causar conflitos de portas. Um contentor separado dá ao site o seu próprio sistema de ficheiros, pacotes e portas.

O ZimaOS suporta aplicações personalizadas baseadas em Docker, e a sua atual referência de aplicações Docker Compose separa as definições normais de execução do Compose dos metadados da App Store do ZimaOS.

Um padrão Apache mais simples

Para um site estático ou local básico, não precisa de criar primeiro uma imagem Ubuntu completa. Um serviço Compose mínimo pode montar o diretório do site numa imagem Apache:

services:
  web:
    image: httpd:2.4
    restart: unless-stopped
    ports:
      - "8080:80"
    volumes:
      - /path/to/www:/usr/local/apache2/htdocs:ro

Em seguida, aceda a http://SERVER-IP:8080 na rede local. Utilize um diretório persistente do anfitrião para os ficheiros do site. Se precisar de PHP, de uma base de dados, de um proxy inverso ou de uma interface de administração, adicione esses componentes como serviços explícitos em vez de presumir que uma porta exposta os disponibiliza.

Porque é que a porta 10000 não significava que o Webmin estava instalado

O Dockerfile do fórum instalava o Apache e vários utilitários e, em seguida, declarava EXPOSE 80 443 10000. A declaração da porta no Docker é apenas metadados. A imagem continua a precisar de um processo à escuta na porta 10000. Como esse Dockerfile não instalava nem iniciava o Webmin, publicar apenas -p 10000:10000 não pode produzir um painel do Webmin.

A documentação do Docker sobre publicação de portas explica que as portas publicadas encaminham o tráfego para um serviço do contentor; não criam a própria aplicação.

O desenvolvimento local e o alojamento público têm níveis de risco diferentes

Um site acessível apenas na rede local é simples. O alojamento na Internet pública acrescenta TLS, DNS, autenticação, aplicação de correções, registos, configuração de proxy inverso e exposição do router e da firewall. Não reencaminhe para a Internet uma interface de gestão direta, como o Webmin, só porque o contentor pode publicar a porta.

Se o objetivo for uma pilha autoalojada sempre disponível, um servidor pequeno para autoalojamento pode executar a carga de trabalho, mas a segurança pública continua a depender da arquitetura do software e dos controlos de rede, não do modelo de hardware.

Em resumo

Execute o site como o seu próprio serviço Docker e publique uma porta que não entre em conflito. Utilize imagens concebidas para esse fim ou uma pilha Compose claramente definida, mantenha os dados do site persistentes fora do contentor e adicione o Webmin, bases de dados ou TLS apenas quando instalar e configurar efetivamente esses serviços.