Hébergement web sur Windows 11 avec WSLC : le principe
WSLC permet d’exécuter des conteneurs Linux depuis Windows 11. Le serveur et ses dépendances restent dans le conteneur : pas besoin d’installer Nginx, PHP ou Python sur le système principal. C’est pratique pour le développement web et le test de site web, sans transformer le PC en serveur permanent.
Ouvrez le terminal et vérifiez la disponibilité de WSLC avec la commande wslc version. Si elle n’est pas reconnue, contrôlez WSL avec wsl –version, puis lancez wsl –update avant de réessayer. Cette vérification évite de chercher un problème de configuration Windows 11 dans un composant simplement absent ou obsolète.
| Besoin | Approche avec WSLC |
|---|---|
| Serveur web local | Conteneur Nginx exposé sur un port Windows |
| Application Python | Image contenant Python et ses bibliothèques |
| Projet modifié souvent | Dossier Windows monté dans le conteneur |
| Site WordPress | Conteneurs séparés pour WordPress et MariaDB |
Le point important est simple : le conteneur isole les composants, mais ne dispense pas de gérer les ports, les mots de passe et les données. WSLC sert à garder un environnement prêt, pas à rendre un service public sécurisé par magie.
Créer un serveur web local Nginx sans installation classique
Pour lancer un serveur intégré Nginx, utilisez wslc run -d –name web -p 8080:80 nginx. WSLC récupère l’image si nécessaire, crée le conteneur et relie le port 80 de Nginx au port 8080 de Windows. Le site est alors accessible dans un navigateur à l’adresse http://localhost:8080.
Le cycle d’exploitation reste direct : wslc container start web démarre le service, wslc container stop web l’arrête et wslc container list –all affiche son état. On peut ainsi laisser un serveur de documentation éteint entre deux sessions, au lieu de faire tourner un service en permanence.
Pour vérifier une configuration sans ouvrir d’éditeur dans le conteneur, lancez wslc exec web cat /etc/nginx/nginx.conf. Une commande interactive comme wslc exec -it web /bin/bash permet, elle, d’explorer l’environnement Linux. Les fichiers modifiés dans le conteneur persistent lors d’un arrêt et d’un redémarrage, mais une suppression du conteneur n’équivaut pas à une sauvegarde.
Pour un essai rapide, Nginx suffit largement. Pour des données à conserver durablement, il faudra prévoir un volume ou un dossier monté, plutôt que compter uniquement sur le système de fichiers interne.
Héberger une application Python sans installer Python sur Windows
Une application Flask peut vivre entièrement dans son image Linux. Dans le dossier du projet, créez un fichier requirements.txt contenant flask, puis un fichier app.py avec une route d’accueil. Pour que le serveur soit joignable depuis le port publié, l’application doit écouter sur 0.0.0.0, et non seulement sur 127.0.0.1.
Créez ensuite un fichier Containerfile indiquant l’image de base python:3.13-slim, le répertoire de travail /app, l’installation de requirements.txt et le lancement de app.py. La construction se fait avec wslc build -t python-web ., depuis le dossier qui contient ces fichiers.
Démarrez l’application avec wslc run -d –name python-web -p 8000:8000 python-web, puis consultez http://localhost:8000. Python, pip et Flask restent confinés au conteneur : Windows conserve un système propre, ce qui est précisément l’intérêt de pouvoir héberger un site sans installation sur l’hôte.
Monter les sources Windows pour accélérer le développement web
Quand le code évolue souvent, reconstruire l’image à chaque modification devient vite pénible. Un montage associe par exemple C:projetsmia-app au chemin /app du conteneur ; le fichier app.py reste éditable avec un outil Windows, tandis que Python l’exécute sous Linux.
La commande de lancement peut alors inclure -v C:projetsmia-app:/app. L’image contient les dépendances, mais les fichiers du projet restent sur l’hôte : une modification est visible sans reconstruire l’image. Pour ce type de travail, séparer runtime et code source fait gagner du temps à chaque essai.
WordPress avec WSLC : relier le site à sa base MariaDB
WordPress demande plusieurs composants. Une méthode propre consiste à placer le CMS et MariaDB dans deux conteneurs reliés par un réseau dédié. Créez celui-ci avec wslc network create wordpress-net, puis lancez les deux conteneurs depuis PowerShell en leur attribuant ce réseau.
Le conteneur de base reçoit les variables MARIADB_DATABASE, MARIADB_USER et MARIADB_PASSWORD. Celui de WordPress reçoit les paramètres WORDPRESS_DB_HOST, WORDPRESS_DB_USER, WORDPRESS_DB_PASSWORD et WORDPRESS_DB_NAME. L’hôte de base peut être le nom du conteneur MariaDB, par exemple wordpress-db:3306, puisque les deux services partagent le réseau.
Publiez le port web avec -p 8080:80, puis ouvrez http://localhost:8080 pour terminer l’installation dans le navigateur. Remplacez les mots de passe d’exemple par des secrets uniques ; un mot de passe laissé dans un historique de commande ou un fichier partagé finit par être un problème, pas une commodité.
Ce montage convient à une maquette, à la vérification d’un thème ou à une préproduction locale. Il ne faut pas le confondre avec un hébergement public correctement sauvegardé et surveillé : les médias et la base doivent être conservés dans des volumes adaptés.
Rendre le site web local accessible sur le réseau
Par défaut, un port publié peut n’être accessible que depuis le PC. Vérifiez d’abord l’écoute avec netstat -ano | findstr “:8000”. Si le résultat indique 127.0.0.1:8000, les autres appareils du réseau ne peuvent pas joindre directement ce point d’écoute.
Pour un essai sur le réseau local, il est possible de configurer une redirection Windows avec netsh interface portproxy, en indiquant l’adresse LAN du PC, le port d’écoute et la destination locale. Ajoutez ensuite une règle de pare-feu entrante limitée au port nécessaire. Un téléphone pourra alors utiliser une adresse du type http://192.168.1.2:8000, avec l’adresse réelle du PC à la place de l’exemple.
-
Vérifiez l’adresse IPv4 du PC avec ipconfig /all.
-
N’ouvrez que le port utilisé par l’application, pas une plage entière.
-
Gardez le test limité au réseau de confiance et supprimez la règle après usage si elle n’est plus nécessaire.
Une redirection de port ne transforme pas un poste de travail en hébergement Internet sécurisé. Pour un site accessible depuis l’extérieur, il faut traiter aussi les mises à jour, le chiffrement, les sauvegardes et les règles du routeur ; pour un test ponctuel, le réseau local reste le périmètre raisonnable.
