Bonjour,
Je dois travailler en PHP sur un serveur Debian qui est toujours sous Debian 8 (jessie). Mettons à part que nous avons de très bonne raison de le faire évoluer, vers Debian 12 ;) Je n’ai que peux d’espoir dans un moyen-terme :/
La version la plus récente que j’ai est php7.2 (et ses extentions).
Mais avec Composer (sur ma machine de travail Debian 12) j’ai "installé" PhpSpreadsheet
Sur le serveur (Debian 8…)
Il y a un serveur Apache 2.0 (renseigner par les infos PHP) avec de nombreux “virtual host” et il n’utilisent pas tous la même version de PHP, en fonction de fichiers de configuration.
L’enjeu pour moi est que ce même serveur, ou cette même machine, adresse ip, répondent pour le sous-domaine en question mais que je puisse alors bénéficier de PHP 8 et ses extensions. Donc je me demande s’il une solution basée sur une sorte de virtualisation, de chroot ou je sais pas quoi que je pourrais suggérer au sysadmin, ne serait pas possible… ?
Car l’autre solution est de créer une nouvelle machine serveur (via ProxMox) avec Debian 12 et PHP 8. Mais alors je n’aurais pas aussi facilement accès à une certaine base de données et un certain système de fichiers présent sur le serveur actuel :/
Qu’en dite-vous ?
Moi, l’admin sys me dépasse un peux et je sais pas tout ce qui est possible…
Merci d’avance.
# systemd-nspawn
Posté par passke (site web personnel) . Évalué à 3 (+3/-1).
Il me semble qu'en Jessie, systemd-nspawn,LXC et Docker étaient déjà présents. Ce sont des solutions de virtualisation très légères et qui permettraient de faire tourner un version plus récente de Debian (ou juste un serveur Apache/PHP8 pour Docker) sur le serveur en Jessie.
A partir de là, le serveur Apache avec le mod proxy peut avec un virtualhost adéquat jouer le rôle de reverse proxy vers le Docker, nspawn ou LXC.
[^] # Re: systemd-nspawn
Posté par xandercagexxx . Évalué à 1 (+1/-1).
Je conseillerais aussi d'utiliser du docker pour ton cas et pourquoi pas mettre tout ce que tu peux avec du docker. Cela peut être une bonne solution en vue de l'évolution futur de la machine.
[^] # Re: systemd-nspawn
Posté par Space_e_man (site web personnel) . Évalué à 2 (+0/-0).
Merci, un Docker me semble en effet être une bonne solution.
Je vais faire la suggestion auprès du sysadmin…
Est-ce facile à mettre en œuvre ?
Car je sais qu’il est déjà fortement « débordé », le sysadmin :/
[^] # Re: systemd-nspawn
Posté par passke (site web personnel) . Évalué à 0 (+1/-2).
L'installation est plutôt simple, par contre cela va demander un peu de travail de ton côté et du sien pour maîtriser certaines notions de Docker et bénéficier de nouvelles pratiques en matière de développement et d'hébergement. Tu peux, mais ce n'est pas non plus obligatoire, commencer à faire CI/CD par exemple…
[^] # Re: systemd-nspawn
Posté par totof2000 . Évalué à 2 (+0/-0).
Là tu mélanges tout. Le CI/CD et les pratiques de développement, dans ce cas on s'en fiche. C'est un sujet qui peut (et doit) être traité indémendamment de docker.
Pour moi le problème n'est pas là etdans l'absolu je ne suis pas sûr que docker doit la réponse au problème remonté: si le serveur doit rester en debian 8 docker n'aidera pas forcément à régler le problème.
[^] # Re: systemd-nspawn
Posté par passke (site web personnel) . Évalué à 1 (+0/-0).
On est d'accord, c'est bien pour ça que je précisais que ce n'était pas obligatoire. C'est juste que les conteneurs font partie des outils disponibles et souvent utilisés pour mettre en oeuvre ce type de pratiques.
[^] # Re: systemd-nspawn
Posté par Voltairine . Évalué à 1 (+0/-0).
Il y a donc un administrateur système.
La première chose à faire et de lui demander comment il a configuré cette machine pour avoir simultanément plusieurs versions de PHP :
Docker ce n'est pas non plus la solution a tous les problèmes, voir le commentaire de @totof2000 et cela a aussi des implications en termes de maintenance et de sécurité. Quoique sur une machine qui tourne encore sous Jessie je me demande si c'est une préoccupation…
[^] # Re: systemd-nspawn
Posté par totof2000 . Évalué à 5 (+3/-0). Dernière modification le 24 novembre 2024 à 12:06.
D'abord, ce ne sont pas des solutions de virtualisation : ce sont des solutions de conteneurisation. Tu vas peut-être dire que c'est la même chose mais en fait non. Il y a une grosse nuance qui fait que dans ce cas ça ne marchera pas forcément.
En effet, contrairement à la virtualisation, ou l'hote et les VMs ont leur propre version de noyau, la conteneurisation partage le noyau de l'hôte avec les conteneurs : de ce fait on ne peut pas faire ce que l'on veut avec les versions d'OS qui tournent dessus. Donc, faire tourner une version d'OS plus récente n'est absolument pas garanti : le système dans ton conteneur peut faire appel a des choses qui ne sont pas implémentées dans le noyau et tu te retrouveras avec des conteneurs instables (ça m'est déjà arrivé avec centos). Dans ce cas précis je pense qu'une VM KVM aura plus de chances de faire tourner correctement un OS plus récent.
[^] # Re: systemd-nspawn
Posté par passke (site web personnel) . Évalué à 0 (+0/-1).
Tu as raison, conteneurs et machines virtuelles sont très différents, mais dans les deux cas il s'agit bien de virtualisation. Les machines virtuelles (kvm,xen,virtualbox) virtualisent le matériel, les conteneurs (lxc, systemd-nspawn, jails, docker, podman) virtualisent un OS et/ou une application.
[^] # Re: systemd-nspawn
Posté par totof2000 . Évalué à 4 (+2/-0).
Je ne suis pas d'accord avec cette définition. Je peux paraître puriste et chiant, mais je l'assume. Ce n'est pas pour couper le cheveu en 4 par pur plaisir, c'est juste que parler de "virtualisation" pour les deux portent à confusion ( et font que les gens s'y perdent). Tu aurais parlé de virtualisation légère j'aurais peut-être moins tiqué, mais ça reste quand même confus. Je réfère utiliser le terme "technologie d'isolation" (ou autre terme plus générique) qui englobe virtualisation et conteneurisation. Parce que dans l'abolu, les conteneurs, ce n'est pas de la virtualisation mais de l'isolation (un super chroot en quelque sorte).
[^] # Re: systemd-nspawn
Posté par passke (site web personnel) . Évalué à 0 (+0/-1).
Loin de moi l'idée de dire que tu serai chiant et puriste. Nous n'avons pas le même avis sur la manière de nommer ces technologies mais je comprend et respecte ton point de vue. Personnellement je n'ai pas de religion sur le sujet, j'utilise les unes ou les autres selon mes besoin et mes contraintes, et peu importe comment on les nomme.
# Les dépôts de Sury
Posté par fanto30 . Évalué à 1 (+0/-0).
Est-ce que tu as essayé les dépôts de Sury ?
https://php.watch/articles/install-php82-ubuntu-debian
J'ai du PHP 8.2 dans une Debian 10.
Peut être possible pour une Debian 8…
[^] # Re: Les dépôts de Sury
Posté par IceCat (Mastodon) . Évalué à 1 (+0/-0).
Malheureusmeent non, Sury indique bien que pour Jessie il faut passer par Freexian : https://deb.sury.org/
Cependant, ce n'est pas gratuit : https://www.freexian.com/lts/php/
# NFS + accès bd par le réseau
Posté par cg . Évalué à 3 (+1/-0).
J'ai eu des trucs du genre avec du Debian 5 et 6 en 2023 (oui oui…). Ma solution a été de déporter un par un les services.
Peut-être qu'en exportant le bout de système de fichier en NFS, et en autorisant la base de données à être accédée depuis une machine tierce, tu peux installer ta Debian 12, y mettre le bon PHP. Comme ça tu peux migrer les services un par un au fur et à mesure en dehors de la Debian 8.
Quand il ne reste plus que la base de données et le système de fichiers, tu copies sur la Debian 12 et hop.
# debian 12
Posté par steph1978 . Évalué à 4 (+2/-0). Dernière modification le 24 novembre 2024 à 15:31.
Je sais que tu ne viens pas pour qu'on te dise qu'il faut mettre à jour le système.
Mais je le dis quand même :)
La 8 est sortie il y a 9 ans et fin de support il y a 4 ans. Tu peux presque être sûr d'avoir des failles critiques en plus de ne pas pouvoir installer des logiciels récents.
Il faudrait isoler les logiciels qui vous bloquent en version 8 et utiliser de la containeurisation ou de la virtualisation pour les faire cohabiter avec un debian récent.
[^] # Re: debian 12
Posté par Voltairine . Évalué à 1 (+0/-0).
Entièrement d'accord surtout que même avec l'offre commerciale Debian ELTS le support s'arrête en juin 2025 pour Debian 8. ;)
[^] # Re: debian 12
Posté par steph1978 . Évalué à 2 (+0/-0).
Je n'avais pas connaissance de cette offre commerciale. Ils ne parlent pas de prix.
[^] # Re: debian 12
Posté par Voltairine . Évalué à 2 (+1/-0).
Si un peu plus loin :
https://www.freexian.com/lts/extended/docs/cost-estimation/
et c'est très cher ;)
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.