Puncte:0

Apache2: 2 versiuni php în același VHOST

drapel in

Migrez aplicația mea de la PHP 5.6 la php 8.0 având un controler frontal care redirecționează către aplicația mea moștenită sau noua mea aplicație, în funcție de uri.

Am încercat cu alias și funcționează, dar trebuie să păstrez exact aceeași gazdă pentru ambele și nici un alias.

De exemplu: https://foo.bar.com/my_php80_routes https://foo.bar.com/my_php56_routes

Iată încercarea mea nesatisfăcătoare cu alias

<VirtualHost *:80>
    ServerName foo.bar.com

    DocumentRoot /var/www/html/foobar/public
    # Unwanted prefix
    Alias /legacy /var/www/html/foobar/legacy/web

    <Directory /var/www/html/foobar/public>
        AllowOverride none
        Require all granted

        SetEnv APP_ENV "dev"

        # Handled by php8.0 : ok
        <FilesMatch \.php$>
            SetHandler "proxy:unix:/var/run/php/php8.0-fpm.sock|fcgi://localhost/"
        </FilesMatch>

        FallbackResource /index.php
        DirectoryIndex index.php
    </Directory>

    <Directory /var/www/html/foobar/legacy/web>
        AllowOverride none
        Require all granted

        # Handled by libapache2-mod-php5.6 : ok
        FallbackResource /app_dev.php
        DirectoryIndex app_dev.php
    </Directory>

    ErrorLog /var/log/apache2/foobar.log
    CustomLog /var/log/apache2/foobar.log combined
</VirtualHost>

Am căutat o altă metodă, poate bazată pe un antet HTTP personalizat precum „FOOBARAPP_LEGACY: 1”, dar nu am găsit o modalitate de a mapa HEADER HTTP la o locație a sistemului de fișiere cu Apache.

Există vreo altă soluție?

[Editați | ×]

O sa incerc sa ma explic mai bine.

Ceea ce încerc să obțin este să am 2 aplicații care rulează fiecare pe o versiune PHP diferită, una fiind „Main App” (noua aplicație pe PHP8.0) și redirecționarea către „A doua aplicație” dacă ruta nu este găsită de „Main”. Aplicație”. Toate acestea fiind complet transparente pentru utilizatorul final. (același domeniu, fără prefix)

Dacă https://foo.bar.com/posts nu este încă migrat: Aplicația principală nu găsește ruta și redirecționează către a doua aplicație care va difuza conținutul.

Când acest punct final este migrat la „Aplicația principală”: Aplicația principală găsește ruta și difuzează conținutul.

Așa că cer o soluție care nu implică un /prefix sau un nou subdomeniu.

Puncte:1
drapel it
RVT

Deci, încercați să canalizați o anumită gazdă virtuală, printr-o conductă, care merge la un modul proxy pentru a accesa gazda pe loopback??? Dar numai pentru fișiere PHP? Sună inutil de complicat.

De ce să nu rulați o a doua gazdă virtuală, pe un port secundar și să folosiți mod_proxy pentru a gestiona întreaga gazdă virtuală. (adică, în general, „modul” de a face un upgrade, și încă îl aveți orientat spre Internet).

Sau, știți, puteți face literalmente o gazdă virtuală pentru fiecare, pe măsură ce migrați. Și apoi drop-in simple redirecționări între virtualhosts, când URL-ul „alternativ” apare pe gazda „greșită”.

Când aveți de-a face cu acest tip de migrare, alegeți cel mai simplu formă de „aceasta versus asta” și rostogolește așa.

Sau, dacă eu complet ați ratat „întreaba” din întrebarea dvs.... aveți succes să rulați mai multe versiuni de PHP în aceeași instanță? Vă rog să clarificați, pentru că sincer... este nu ceva ce l-aș recomanda vreodată pentru că, știi... PHP. ;-)

drapel in
Atm Am încercat doar mai multe versiuni php pe mediul meu local dev Debian (fără virtualizare) și se pare că funcționează bine chiar și în aceeași gazdă virtuală. (modapache pentru 5.6 și fpm pentru 7.4 și 8.0). Deoarece sunt dezvoltator și nu operațiuni, nu văd încă cum va funcționa sugestia ta cu același domeniu și cookie phpsessid, dar voi încerca, mulțumesc.
RVT avatar
drapel it
RVT
Sincer, cel mai bun lucru pentru dezvoltatori este să folosească mai multe containere Docker, cu diferite versiuni și configurații PHP, între ele. Rularea mai multor versiuni ale aceluiași middleware pe aceeași gazdă Apache înseamnă doar „cere” pentru confuzie, în opinia mea (și NU este ceva ce doriți să injectați accidental într-o conductă de producție, desigur). S-ar putea să realizați același tip de lucru, folosind VirtualBox și Vagrant pentru a ridica și a demola mașinile virtuale de pe propria mașină. Dar, în general, sentimentul meu este că la început ar trebui să încerci să le păstrezi discrete, doar pentru a evita potențialele probleme.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.