[Tech][Misc] Hébergement web multi-application en 2024
Bonjour/Bonsoir la liste, J'installe une supervision pour mon infra perso sur un petit serveur dédié (Xeon 4C/8T, 8GB RAM) debian et me suis posé la question de l'état de l'art en 2024 quand on veut héberger différentes applications web, principalement PHP sur un seul serveur physique? J'ai des vieilles habitudes d'utiliser des VM, mais c'est gourmand et je testerai bien les conteneurs mais quel moteur? Un simple nginx pour rediriger les flux ou un truc plus poussé genre traefik? En bref, vous utilisez quoi, vous dans ces cas là? Kholah
Bonjour, Le Sat, Mar 02, 2024 at 04:34:07PM +0100, N R a écrit:
J'installe une supervision pour mon infra perso sur un petit serveur dédié (Xeon 4C/8T, 8GB RAM) debian et me suis posé la question de l'état de l'art en 2024 quand on veut héberger différentes applications web, principalement PHP sur un seul serveur physique? J'ai des vieilles habitudes d'utiliser des VM, mais c'est gourmand et je testerai bien les conteneurs mais quel moteur? Un simple nginx pour rediriger les flux ou un truc plus poussé genre traefik? En bref, vous utilisez quoi, vous dans ces cas là?
Ça dépend de tes envies... :) Tu peux - soit tout héberger directement sur un seul serveur sans aucune séparation; - soit mettre un proxmox en hyperviseur physique et utiliser des conteneurs LXC pour séparer tes applis, avec par exemple un haproxy en haut qui fait le ssl et le lien entre l'IP externe et les conteneurs sur différentes IP non externes (j'imagine que tu n'as pas un /xx à dispo) -- éventuellement pour faire plaisir aux jeunes, mettre de l'ipv6; - utiliser du Xen - utiliser de l'OpenStack - soit utiliser du docker ou autre techno à la mode Bref, n'importe quoi, sauf du VMWare, en somme :) Perso j'aime bien le Proxmox/LXC, tu as le côté clicky et facile, et de l'autre des environnements complets que tu peux gérer toi-même sans dépendre d'un tiers, et qui vont se partager la ram et le disque plus facilement (et plus légèrement avec moins de gourmandise) que des VMs. Désavantage par rapport à toutes les applis sur un seul serveur, ça démultiplie la maintenance. C'est un peu comme la cuisine, je pense qu'ici chacun aura sa propre recette favorite... Arnaud.
Bonjour, Un /var/www/site_web/ et des hôtes nginx qui pointent dedans : c'est facile à concevoir, simple à maintenir, la surface d'attaque est très limitée, et la consommation de ressources étant limitée au minimum tu obtiens une empreinte énergétique minimale (cf <https://github.com/hubblo-org/scaphandre> à tester). Ni besoin de virtualisation ni de ces middlewares pourris pour un besoin aussi simple. En prime tu gagnes en portabilité car tu peux à tout moment récupérer tes données+logs et changer d'OS quand tu veux, car beaucoup de middlewares à la mode ne fonctionnent en dehors de Linux, or tu pourrais apprécier protéger les données familiales par OpenBSD par exemple. Bien cordialement, Maxime DERCHE Le 2 mars 2024 15:34:07 GMT+00:00, N R <randria.nicolas@gmail.com> a écrit :
Bonjour/Bonsoir la liste,
J'installe une supervision pour mon infra perso sur un petit serveur dédié (Xeon 4C/8T, 8GB RAM) debian et me suis posé la question de l'état de l'art en 2024 quand on veut héberger différentes applications web, principalement PHP sur un seul serveur physique?
J'ai des vieilles habitudes d'utiliser des VM, mais c'est gourmand et je testerai bien les conteneurs mais quel moteur? Un simple nginx pour rediriger les flux ou un truc plus poussé genre traefik?
En bref, vous utilisez quoi, vous dans ces cas là?
Kholah
Bonjour, Et si tu veux quand même un peu t'amuser : - un pool FPM différent par application pour gérer indépendamment les limitations de ressources - haproxy en frontal pour faire le TLS-offloading et aussi pour jouer avec les backends fcgi connectés en direct aux pools FPM - nginx juste pour servir le contenu static des différents sites avec des vhost De: "Maxime DERCHE" <maxime@mouet-mouet.net> À: "frsag" <frsag@frsag.org> Envoyé: Samedi 2 Mars 2024 17:17:04 Objet: [*EXT*] **RSPAM** [FRsAG] Re: [Tech][Misc] Hébergement web multi-application en 2024application en 2024 Bonjour, Un /var/www/site_web/ et des hôtes nginx qui pointent dedans : c'est facile à concevoir, simple à maintenir, la surface d'attaque est très limitée, et la consommation de ressources étant limitée au minimum tu obtiens une empreinte énergétique minimale (cf < [ https://github.com/hubblo-org/scaphandre | https://github.com/hubblo-org/scaphandre ] > à tester). Ni besoin de virtualisation ni de ces middlewares pourris pour un besoin aussi simple. En prime tu gagnes en portabilité car tu peux à tout moment récupérer tes données+logs et changer d'OS quand tu veux, car beaucoup de middlewares à la mode ne fonctionnent en dehors de Linux, or tu pourrais apprécier protéger les données familiales par OpenBSD par exemple. Bien cordialement, Maxime DERCHE Le 2 mars 2024 15:34:07 GMT+00:00, N R <randria.nicolas@gmail.com> a écrit : Bonjour/Bonsoir la liste, J'installe une supervision pour mon infra perso sur un petit serveur dédié (Xeon 4C/8T, 8GB RAM) debian et me suis posé la question de l'état de l'art en 2024 quand on veut héberger différentes applications web, principalement PHP sur un seul serveur physique? J'ai des vieilles habitudes d'utiliser des VM, mais c'est gourmand et je testerai bien les conteneurs mais quel moteur? Un simple nginx pour rediriger les flux ou un truc plus poussé genre traefik? En bref, vous utilisez quoi, vous dans ces cas là? Kholah _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
J'installe une supervision pour mon infra perso sur un petit serveur dédié (Xeon 4C/8T, 8GB RAM) debian et me suis posé la question de l'état de l'art en 2024 quand on veut héberger différentes applications web, principalement PHP sur un seul serveur physique? J'ai des vieilles habitudes d'utiliser des VM, mais c'est gourmand et je testerai bien les conteneurs mais quel moteur?
Un simple virtualmin ( la partie virtual hosting de webmin ) fait très bien le taf pour gérer quelques dizaines de sites php sur un petit serveur dédié. La virtualisation peut être utile, mais souvent elle n' est pas nécessaire ou rentable.
Un simple nginx pour rediriger les flux ou un truc plus poussé genre traefik?
En bref, vous utilisez quoi, vous dans ces cas là?
Kholah _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
On Sat, Mar 02, 2024 at 04:34:07PM +0100, N R wrote:
Bonjour/Bonsoir la liste,
J'installe une supervision pour mon infra perso sur un petit serveur dédié (Xeon 4C/8T, 8GB RAM) debian et me suis posé la question de l'état de l'art en 2024 quand on veut héberger différentes applications web, principalement PHP sur un seul serveur physique?
J'ai des vieilles habitudes d'utiliser des VM, mais c'est gourmand et je testerai bien les conteneurs mais quel moteur? Un simple nginx pour rediriger les flux ou un truc plus poussé genre traefik?
En bref, vous utilisez quoi, vous dans ces cas là?
Sur mon serveur perso, j'ai un traefik en front, et derrière, j'ai du docker. J'ai un nextcloud-aio pour le nextcloud, un mailcow pour le mail, et des conteneurs avec un apache par site web. Comme apache sait gérer les fichiers plats et le php, c'est plus simple à maintenir que des piles nginx+php-fpm, et comme c'est derrière un traefik, y'a moins de chance de le casser à cause d'une faille. -- Mathieu Arnold
Je suis pas sur de saisir l'objet de la demande mais si l'objectif est de pousser que du site Web et de pouvoir en déléguer l'administration à certain, un bon ISP Config suffit et fait le café (Sauvegardes). https://www.ispconfig.org/ Bon courage. Maxime Le dim. 3 mars 2024 à 10:52, Mathieu Arnold <m.arnold@ovea.com> a écrit :
On Sat, Mar 02, 2024 at 04:34:07PM +0100, N R wrote:
Bonjour/Bonsoir la liste,
J'installe une supervision pour mon infra perso sur un petit serveur dédié (Xeon 4C/8T, 8GB RAM) debian et me suis posé la question de l'état de l'art en 2024 quand on veut héberger différentes applications web, principalement PHP sur un seul serveur physique?
J'ai des vieilles habitudes d'utiliser des VM, mais c'est gourmand et je testerai bien les conteneurs mais quel moteur? Un simple nginx pour rediriger les flux ou un truc plus poussé genre traefik?
En bref, vous utilisez quoi, vous dans ces cas là?
Sur mon serveur perso, j'ai un traefik en front, et derrière, j'ai du docker. J'ai un nextcloud-aio pour le nextcloud, un mailcow pour le mail, et des conteneurs avec un apache par site web. Comme apache sait gérer les fichiers plats et le php, c'est plus simple à maintenir que des piles nginx+php-fpm, et comme c'est derrière un traefik, y'a moins de chance de le casser à cause d'une faille.
-- Mathieu Arnold _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Hello,
Comme apache sait gérer les fichiers plats et le php, c'est plus simple à maintenir que des piles nginx+php-fpm, et comme c'est derrière un traefik, y'a moins de chance de le casser à cause d'une faille.
Je suis curieux, pour moi Traefik est un simple reverse-proxy et ne fait (par défaut, peut-être que y'a des plugins) pas WAF. Donc j'ai du mal à comprendre quelle sécurité apporte Traefik vs n'importe quel autre reverse-proxy. Je suis à coté de la plaque ou Traefik est effectivement plus "intelligent" que ça ? Ou tu sous-entendais que Apache en frontal c'est bof ? Librement, Louis
On Mon, Mar 04, 2024 at 01:22:37PM +0000, Louis G. via FRsAG wrote:
Hello,
Comme apache sait gérer les fichiers plats et le php, c'est plus simple à maintenir que des piles nginx+php-fpm, et comme c'est derrière un traefik, y'a moins de chance de le casser à cause d'une faille.
Je suis curieux, pour moi Traefik est un simple reverse-proxy et ne fait (par défaut, peut-être que y'a des plugins) pas WAF. Donc j'ai du mal à comprendre quelle sécurité apporte Traefik vs n'importe quel autre reverse-proxy.
Je suis à coté de la plaque ou Traefik est effectivement plus "intelligent" que ça ? Ou tu sous-entendais que Apache en frontal c'est bof ?
C'est pas un WAF, mais il va terminer le SSL et faire reverse proxy, donc en cas de trou de sécu dans le serveur web qui est derrière, ça complique l'attaque vu que traefik ne va pas laisser passer une requête sensée exploiter un bug du serveur qui est derrière telle quelle, vu qu'il fait proxy et réécrit des bouts, il y a de bonnes chances que la requête malicieuse ne le soit plus. -- Mathieu Arnold
Bonsoir la liste, Merci pour vos réponses. Pardon pour le manque de clarté de mon message, je ne cherche pas à faire du multi-client, mais merci Maxime Pauwels pour la recommandation d'ISPconfig. Le besoin c'est héberger un serveur icinga, un serveur wazuh et un site statique sur la même machine. Les données de supervision seront collectées via un vpn Wireguard. Initialement j'étais parti pour faire un truc simple avec un nginx (possiblement tester le fork libre) ou un apache proprement configuré pour faire du multi-domaine en frontal comme il a été suggéré ici. J'ai eu un doute à cause d'une mauvaise expérience en essayant d'installer Icinga sur le même serveur qu'un Nextcloud existant qui n'utilisaient pas les mêmes versions de PHP, d'où mes questions sur les containers. Je pense partir sur un truc un peu hybride, mettre un front-end nginx directement installé sur la machine et des conteneurs lxc, j'ai déjà un peu bidouillé, ce sera l'occasion de pratiquer plus. Sur la digression WAF, j'ai récemment découvert NAXSI qui s'intègre à nginx, ce sera l'occasion de tester. Je garde les solutions avec du traefik et du docker pour d'autres cas, là j'ai peur que ce soit un peu trop pour le temps que j'ai envie de consacrer à la maintenance de la supervision. Encore merci pour toutes les réponses, Bien à vous, Kholah Le lun. 4 mars 2024 à 18:16, Mathieu Arnold <m.arnold@ovea.com> a écrit :
On Mon, Mar 04, 2024 at 01:22:37PM +0000, Louis G. via FRsAG wrote:
Hello,
Comme apache sait gérer les fichiers plats et le php, c'est plus simple à maintenir que des piles nginx+php-fpm, et comme c'est derrière un traefik, y'a moins de chance de le casser à cause d'une faille.
Je suis curieux, pour moi Traefik est un simple reverse-proxy et ne fait (par défaut, peut-être que y'a des plugins) pas WAF. Donc j'ai du mal à comprendre quelle sécurité apporte Traefik vs n'importe quel autre reverse-proxy.
Je suis à coté de la plaque ou Traefik est effectivement plus "intelligent" que ça ? Ou tu sous-entendais que Apache en frontal c'est bof ?
C'est pas un WAF, mais il va terminer le SSL et faire reverse proxy, donc en cas de trou de sécu dans le serveur web qui est derrière, ça complique l'attaque vu que traefik ne va pas laisser passer une requête sensée exploiter un bug du serveur qui est derrière telle quelle, vu qu'il fait proxy et réécrit des bouts, il y a de bonnes chances que la requête malicieuse ne le soit plus.
-- Mathieu Arnold _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonsoir, Installer plusieurs versions de php n'est pas forcement compliqué, par exemple sur debian avec le repo deb.sury.org. Il suffit ensuite de lancer plusieurs php-fpm. Chaque appli peut avoir un utilisateur dédié, utilisable pour les directives apache mpm-itk et le process php-fpm. J'aime bien garder haproxy pour la terminaison ssl devant tout ça. Le mar. 5 mars 2024, 21:25, N R <randria.nicolas@gmail.com> a écrit :
Bonsoir la liste,
Merci pour vos réponses.
Pardon pour le manque de clarté de mon message, je ne cherche pas à faire du multi-client, mais merci Maxime Pauwels pour la recommandation d'ISPconfig.
Le besoin c'est héberger un serveur icinga, un serveur wazuh et un site statique sur la même machine. Les données de supervision seront collectées via un vpn Wireguard.
Initialement j'étais parti pour faire un truc simple avec un nginx (possiblement tester le fork libre) ou un apache proprement configuré pour faire du multi-domaine en frontal comme il a été suggéré ici. J'ai eu un doute à cause d'une mauvaise expérience en essayant d'installer Icinga sur le même serveur qu'un Nextcloud existant qui n'utilisaient pas les mêmes versions de PHP, d'où mes questions sur les containers.
Je pense partir sur un truc un peu hybride, mettre un front-end nginx directement installé sur la machine et des conteneurs lxc, j'ai déjà un peu bidouillé, ce sera l'occasion de pratiquer plus.
Sur la digression WAF, j'ai récemment découvert NAXSI qui s'intègre à nginx, ce sera l'occasion de tester.
Je garde les solutions avec du traefik et du docker pour d'autres cas, là j'ai peur que ce soit un peu trop pour le temps que j'ai envie de consacrer à la maintenance de la supervision.
Encore merci pour toutes les réponses, Bien à vous,
Kholah
Le lun. 4 mars 2024 à 18:16, Mathieu Arnold <m.arnold@ovea.com> a écrit :
On Mon, Mar 04, 2024 at 01:22:37PM +0000, Louis G. via FRsAG wrote:
Hello,
Comme apache sait gérer les fichiers plats et le php, c'est plus simple à maintenir que des piles nginx+php-fpm, et comme c'est derrière un traefik, y'a moins de chance de le casser à cause d'une faille.
Je suis curieux, pour moi Traefik est un simple reverse-proxy et ne fait (par défaut, peut-être que y'a des plugins) pas WAF. Donc j'ai du mal à comprendre quelle sécurité apporte Traefik vs n'importe quel autre reverse-proxy.
Je suis à coté de la plaque ou Traefik est effectivement plus "intelligent" que ça ? Ou tu sous-entendais que Apache en frontal c'est bof ?
C'est pas un WAF, mais il va terminer le SSL et faire reverse proxy, donc en cas de trou de sécu dans le serveur web qui est derrière, ça complique l'attaque vu que traefik ne va pas laisser passer une requête sensée exploiter un bug du serveur qui est derrière telle quelle, vu qu'il fait proxy et réécrit des bouts, il y a de bonnes chances que la requête malicieuse ne le soit plus.
-- Mathieu Arnold _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonjour/Bonsoir la liste,
J'installe une supervision pour mon infra perso sur un petit serveur dédié (Xeon 4C/8T, 8GB RAM) debian et me suis posé la question de l'état de l'art en 2024 quand on veut héberger différentes applications web, principalement PHP sur un seul serveur physique?
J'utilise incus (https://github.com/lxc/incus) pour ça, qui est le fork de lxd par ses créateurs / mainteneurs originels (suite à un mouvement de Canonical pour réintégrer lxd à ses infrastructures). Plein de containers, mais aussi des VM quand c'est nécessaire, avec une gestion commune plutôt bien faite.
J'ai des vieilles habitudes d'utiliser des VM, mais c'est gourmand et je testerai bien les conteneurs mais quel moteur? Un simple nginx pour rediriger les flux ou un truc plus poussé genre traefik?
Dans le même esprit pour nginx, il y a de l'eau dans le gaz entre la communauté et F5 (la société qui a racheté nginx) : https://thenewstack.io/freenginx-a-fork-of-nginx/ Bref, attention à la pérennité et au la gouvernance des projets :-) (même sujet mais sans rapport avec la question : talend open studio est retiré par Qlik au profit d'une version cloud propriétaire... si vous avec des fichiers d'install, gardez les précieusement !) Franck
yolo,
J'utilise incus (https://github.com/lxc/incus <https://github.com/lxc/incus>) pour ça, qui est le fork de lxd par ses créateurs / mainteneurs originels (suite à un mouvement de Canonical pour réintégrer lxd à ses infrastructures).
Est-il vrai qu'il est possible de migrer à chaud des conteneurs LXC d'un nœud à l'autre ? Vous confirmez que cela fonctionne ? C'est stable ? Franchement je me demande comment cela est possible. C'est comme avoir leur beur et l'argent du beur. (les avantages de la virtu hardware + virtu système)
Le mercredi 6 mars 2024, 04:33:26 CET Pierre-Philipp Braun a écrit :
yolo,
J'utilise incus (https://github.com/lxc/incus <https://github.com/lxc/incus>) pour ça, qui est le fork de lxd par ses créateurs / mainteneurs originels (suite à un mouvement de Canonical pour réintégrer lxd à ses infrastructures).
Est-il vrai qu'il est possible de migrer à chaud des conteneurs LXC d'un nœud à l'autre ? Vous confirmez que cela fonctionne ? C'est stable ?
non, ça ne marche pas vraiment. D'ailleurs, la doc est explicite sur ce sujet : "Live migration means migrating an instance while it is running. This method is supported for virtual machines. For containers, there is limited support. ... For containers, there is limited support for live migration using CRIU. However, because of extensive kernel dependencies, only very basic containers (non-systemd containers without a network device) can be migrated reliably. In most real-world scenarios, you should stop the container, move it over and then start it again. If you want to use live migration for containers, you must first make sure that CRIU is installed on both systems. To optimize the memory transfer for a container, set the migration.incremental.memory property to true to make use of the pre-copy features in CRIU. With this configuration, Incus instructs CRIU to perform a series of memory dumps for the container. After each dump, Incus sends the memory dump to the specified remote. In an ideal scenario, each memory dump will decrease the delta to the previous memory dump, thereby increasing the percentage of memory that is already synced. When the percentage of synced memory is equal to or greater than the threshold specified via migration.incremental.memory.goal, or the maximum number of allowed iterations specified via migration.incremental.memory.iterations is reached, Incus instructs CRIU to perform a final memory dump and transfers it."
Franchement je me demande comment cela est possible. C'est comme avoir leur beur et l'argent du beur. (les avantages de la virtu hardware + virtu système)
En effet :-) !
participants (11)
-
Arnaud Launay -
Franck Routier -
Ionel GARDAIS -
Louis G. -
Mathieu Arnold -
Maxime DERCHE -
Maxime Pauwels -
N R -
neo futur -
Pierre-Philipp Braun -
Thomas Samson