Comment héberger un site web sur ZimaOS avec Docker

Vous pouvez héberger un site web sur ZimaOS sans modifier sa propre pile web : exécutez Apache, Nginx ou un autre serveur web dans un conteneur Docker isolé et publiez un port distinct de l’hôte, comme 8080. La configuration de votre site reste ainsi indépendante de l’interface de gestion de ZimaOS.

L’exemple de la communauté illustre ce principe de base, mais un détail doit être corrigé : son Dockerfile expose le port 10000, mais n’installe pas Webmin. Exposer un port ne crée pas de service derrière celui-ci.

Utiliser un conteneur plutôt que reconfigurer ZimaOS lui-même

ZimaOS utilise déjà des services web pour sa propre interface. Remplacer ou reconfigurer ces services de l’hôte crée des risques inutiles liés aux mises à niveau et aux conflits de ports. Un conteneur séparé fournit au site web son propre système de fichiers, ses propres paquets et ses propres ports.

ZimaOS prend en charge les applications personnalisées basées sur Docker, et sa documentation de référence sur les applications Docker Compose actuelle distingue les paramètres d’exécution Compose classiques des métadonnées de l’App Store de ZimaOS.

Un modèle Apache plus simple

Pour un site web statique ou local basique, il n’est pas nécessaire de commencer par créer une image Ubuntu complète. Un service Compose minimal peut monter le répertoire du site dans une image Apache :

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

Accédez ensuite à http://SERVER-IP:8080 depuis le réseau local. Utilisez un répertoire persistant de l’hôte pour vos fichiers de site. Si vous avez besoin de PHP, d’une base de données, d’un proxy inverse ou d’une interface d’administration, ajoutez-les en tant que services explicites au lieu de supposer qu’un port exposé les fournit automatiquement.

Pourquoi le port 10000 ne signifiait pas que Webmin était installé

Le Dockerfile du forum installait Apache et plusieurs utilitaires, puis déclarait EXPOSE 80 443 10000. La déclaration de port de Docker ne constitue que des métadonnées. L’image doit tout de même exécuter un processus à l’écoute du port 10000. Comme ce Dockerfile n’installait ni ne démarrait Webmin, la publication de -p 10000:10000 ne peut pas, à elle seule, fournir un tableau de bord Webmin.

La documentation de Docker sur la publication des ports explique que les ports publiés redirigent le trafic vers un service du conteneur ; ils ne créent pas l’application elle-même.

Le développement local et l’hébergement public présentent des niveaux de risque différents

Un site limité au réseau local est simple à mettre en place. L’hébergement sur Internet ajoute la gestion de TLS, du DNS, de l’authentification, des correctifs, des journaux, de la configuration du proxy inverse et de l’exposition du routeur et du pare-feu. Ne redirigez pas une interface d’administration brute telle que Webmin vers Internet simplement parce que le conteneur peut publier ce port.

Si votre objectif est d’exécuter en permanence une pile auto-hébergée, un petit serveur d’auto-hébergement peut exécuter cette charge de travail, mais la sécurité publique dépend toujours de l’architecture logicielle et des contrôles réseau, plutôt que du modèle matériel.

En résumé

Exécutez le site web comme son propre service Docker et publiez un port qui n’entre pas en conflit. Utilisez des images dédiées ou une pile Compose clairement définie, conservez les données du site en dehors du conteneur et n’ajoutez Webmin, des bases de données ou TLS que lorsque vous installez et configurez réellement ces services.