Ubuntu 23.04: downgrade en PHP7

bobic13 · Le 02/08/2023, à 17:18

Bonjour à tous,

Je viens de changer d'ordi, et quand j'ai voulu réinstaller mon ancien Kubuntu 20.04, l'ordi ne démarrait pas.
J'ai donc récupéré la dernière version, la 23.04. Tout fonctionne.

Sauf que, je fais du dev PHP, et j'ai du code en php7. Or sous la 23.04 j'ai découvert qu'il y avait uniquement la version 8, mais pire, les dépots que j'utilise d'habitude (ppa ondrej) ne supporte pas cette version...

Du coup, je suis comme un **** avec ma version php8 et je cherche un moyen de repasser en 7.

Vous n'auriez pas une idée sur comment faire ?
Merci à vous !

Vobul · Le 02/08/2023, à 17:26

Apprends à utiliser Docker

Le coup d'utiliser la version de l'OS pour faire du dev c'est fini !

Tiens, pour t'aider : https://www.journalduhacker.net/search? … =relevance

bobic13 · Le 08/08/2023, à 01:39

Hello,

J'ai suivi tes conseils, et j'ai monté un docker avec apache + fpm + php7.
Cela fonctionne, mais c'est quand même assez peu pratique à configurer... Car pour chaque élément dont on a besoin (et on en oublie toujours), il faut modifier le fichier, puis rebuilder et tester. Du coup, ça peut vite devenir chronophage car il faut tester la commande dans un bash, puis une fois que l'on sait qu'elle fonctionne, l'ajouter dans fichier de config et rebuilder.
Surtout, que meme si on peut s'y connecter, les modifications faites par le bash ne sont pas conservées... (ou alors j'ai raté un truc !)

Après, une fois que l'on a l'image parfaite, c'est sur que l'on gagne du temps si on veut le réppliquer sur d'autres postes/serveurs, ça c'est une évidence.

Vobul · Le 08/08/2023, à 02:14

Non, tu peux par exemple monter le dossier qui contient le fichier de conf sur ton ordi et l'éditer direct. Mais je ne sais pas vraiment de quoi tu parles : "le fichier". Ton code est monté sur ton ordi, t'as pas besoin de rebuild quoique ce soit sauf bien sûr dans la phase initiale mais une fois que c'est fait c'est bon.

Là tu débutes donc y'a peut-être deux trois trucs que t'as pas bien compris, mais crois-moi c'est bien plus pratique de dev avec Docker. Si ton code est dans /app/, tu bind mount /home/bobic/dev/my-app:/app et hop, tu modifies les fichiers direct et c'est comme d'hab'. Penses à utiliser docker-compose également pour pas avoir de vieux scripts bash avec des docker run dedans. Si tu veux utiliser composer, tu peux utiliser l'image composer :

docker run --rm -it --volume $PWD:/app composer upgrade

ou utiliser le composer que t'as installé dans le container.

bobic13 · Le 08/08/2023, à 15:26

Oui, je débute avec Docker, donc forcément, y'a certaines choses que je ne connais pas et qui pourraient simplifier la conf, comme composer par exempe, que je connais mais de (tres) loin.
Pour les fichiers de conf, j'ai vu que l'on pouvait en effet les monter, pour ça, pas de soucis. Sauf que si je suis en ubuntu et l'autre en fedora par exemple, les chemins ne sont pas forcément les mêmes. Ce qui oblige donc à se connecter sur le container, vérifier les chemins, tester, et le mettre dans le fichier de conf, c'est ça que je trouve un peu chiant.

Même chose pour ce qui est par exemple, d'installer des paquets liés à php (xdebug, ou tout autre chose). A chaque fois qu'on en rajoute un dans le fichier de conf du conteneur (avec le RUN), faut rebuilder.
Mais si j'ai bien compris, composer permet de faciliter ça non ?

Dernière modification par bobic13 (Le 08/08/2023, à 15:37)

Vobul · Le 08/08/2023, à 17:53

> les chemins ne sont pas forcément les mêmes

Dans le container le chemin est toujours le même. Je ne comprends pas ton problème. Que ton host soit ubuntu ou fedora ne change rien, c'est bien là l'intérêt du container. xdebug est un paquet système, composer permet d'installer les librairies php, ce n'est pas pareil. J'ai bien conscience qu'utiliser Docker peut sembler lourd, surtout quand on débute, mais ça vaut clairement le coup.

bobic13 · Le 10/08/2023, à 16:29

Dans le container peut être, mais par rapport à l'hote pas forcément. Par exemple, sur certaines distrib, apache se lance avec la httpd et dans d'autre apache2. Du coup, pour savoir la commande du container, faut le lancer et y accéder par le bash pour vérifier non ?
Je suis de la vieille école à une époque ou docker n'éxistait pas.

Mais attention, je ne nie pas l'intérêt de la chose. Car une fois que l'image est nickel, c'est clair que pour déployer sur plusieurs postes de dev, c'est le top. pas besoin de tout réinstaller. La difficulté au départ quand on a pas cette habitude, c'est de faire une image correcte.

Vobul · Le 10/08/2023, à 16:42

Non, ce que tu viens de dire n'a aucun sens, ou alors je ne comprends pas ce que tu dis.

Dans ton container tu commences par un FROM avec ta distrib de choix. La commande pour lancer le service est donc toujours la même puisque tu contrôles ça. Alors certes, si tu fais "FROM fedora" ou "FROM debian" il y aura peut-être des différences, mais ça ne variera jamais en fonction de l'hôte. L'hôte c'est l'OS qui fait tourner le container, pour être clair.

Puis pour lancer le container c'est toujours la même également puisque c'est docker/docker-compose.

Bref, docker limite grandement les variations, donc tout est toujours pareil, sans surprises.

bobic13 · Le 10/08/2023, à 23:13

Oui, quand tu peux choisir la distrib, mais quand tu récup une image toute faites, tu la choisis pas. C'est en cela où tu peux avoir des différences de chemins, de commandes et autres. Pour le reste, oui en effet, c'est bien tjs les mêmes commandes pour le built et le run.

Mais prenons un exemple d'utilisation.

Je désire installer un autre paquet. Je fais donc un

run apt install nondupaquet

Il se trouve que je ne connais pas bien le nom du paquet... je ne peux donc pas le taper à l'aveugle dans le fichier de conf.
Contrairement à ce que je fais habituellement où je fais un apt search ou apt cache puis choisis le paquet dans la liste, là, je suis obligé de me connecter au container, lancer la commande search, noter le bon nom de paquet, puis modifier mon fichier de conf pour mettre dans le run le bon apt.
Il se trouve que pour mon image (php:7-apache) les commandes apt ne fonctionnent pas pour plein de trucs. En cherchant, je vois qu'il faut utiliser docker-php-ext-install.

Autre exemple, si je veux voir un fichier de conf d'un truc lambda, je veux faire un vi monfichier: ça fonctionne pas, il n'y a pas VI. Faut donc l'installr, mais il 'est pas dispo dans les paquets.

Autre exemple: Je veux chercher un fichier xxx. Habituellement j'utilise locate. Ben là, il n'est pas installé. Et je ne le trouve pas dans les paquets dispo.

Autre exemple, je désire copier mon fichier 000-default.conf. Chez moi, sur apache en local il est dans /etc/apache2/sites-enabled/000-default.conf.
Je le mets dans mon fichier de conf, je build, ça plante ("COPY failed: file not found in build context or excluded by .dockerignore: stat etc/apache2/sites-enabled/000-default.conf: file does not exist).
Du coup, je relance mon container pour m'y connecter via le bash. Je me rend compte qu'il éxiste une commande pour ça. Je fais quelques recherche et comprends qu'il faut que le fichier soit dans le 'context'. Allez, hop, je réouvre mon fichier de conf et ajoute la ligne. Je build ça fonctionne. cool

Mais quand le build prend 20 secondes, pour finir sur une erreur, que de temps perdu...

Tu vois, tous ces allers-retours, je trouve ça fastidieux et bien plus long qu'une install classique. Surtout que tout ne fonctionne jamais du premier coup, et qu'on en oublies toujours. Il y a bien sur de la méconnaissance de ma part d'où certaines erreurs, mais pour arriver à une image nickel, j'ai l'impression que c'est long. Plus qu'à l'ordinaire. Après à l'usage, oui, c'est certainement plus rapide pour déployer une fois l'image parfaite réalisée

Après j'ai peut être aussi une image biaisée du fait de ma méconnaissance

bobic13 · Le 10/08/2023, à 23:19

Autre exemple: j'ai copié mon fichier de conf d'Apache. Il ne fonctionne pas car je n'ai pas mis le bon chemin vers fpm et quelques autres petites choses.
Du coup, je dois arrêter le container, rebuilder sans la copie du fichier, le relancer, m'y connecter, récupérer le contenu du fichier de conf, copier les quelques lignes en erreur dans mon fichier local, modifier le fichier de conf du container, rebuilder et relancer. Et si j'ai encore une erreur, je dois refaire. Pffff c'est lassant ^^.

krodelabestiole · Le 11/08/2023, à 00:41

tu peux bind-mounter les fichiers de conf plutôt que les copier. tu n'auras pas besoin de rebuild à chaque fois (juste recharger la conf d'apache - ou relancer le container, ce qui est probablement plus simple).

krodelabestiole · Le 11/08/2023, à 00:50

je sais pas si ça peut t'intéresser, j'ai écrit un petit script pour déployer un environnement lamp en quelques secondes : https://gitlab.com/crachecode/docker-lamp-app
(pas super opti : c'est du php en module d'apache, pas du fpm : plutôt pour bricoler rapidement sur des projets)

bobic13 · Le 18/08/2023, à 10:09

Slt, merci, je vais regarder ça

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 02/08/2023, à 17:18

Ubuntu 23.04: downgrade en PHP7

#2 Le 02/08/2023, à 17:26

Re : Ubuntu 23.04: downgrade en PHP7

#3 Le 08/08/2023, à 01:39

Re : Ubuntu 23.04: downgrade en PHP7

#4 Le 08/08/2023, à 02:14

Re : Ubuntu 23.04: downgrade en PHP7

#5 Le 08/08/2023, à 15:26

Re : Ubuntu 23.04: downgrade en PHP7

#6 Le 08/08/2023, à 17:53

Re : Ubuntu 23.04: downgrade en PHP7

#7 Le 10/08/2023, à 16:29

Re : Ubuntu 23.04: downgrade en PHP7

#8 Le 10/08/2023, à 16:42

Re : Ubuntu 23.04: downgrade en PHP7

#9 Le 10/08/2023, à 23:13

Re : Ubuntu 23.04: downgrade en PHP7

#10 Le 10/08/2023, à 23:19

Re : Ubuntu 23.04: downgrade en PHP7

#11 Le 11/08/2023, à 00:41

Re : Ubuntu 23.04: downgrade en PHP7

#12 Le 11/08/2023, à 00:50

Re : Ubuntu 23.04: downgrade en PHP7

#13 Le 18/08/2023, à 10:09

Re : Ubuntu 23.04: downgrade en PHP7

Pied de page des forums