Laravel Valet i wiele wersji PHP jednocześnie

|

W poprzednim artykule przedstawiłem instalację, konfigurację i ogólne możliwości środowiska Laravel Valet dla PHP. Nic z tym dodatkowo nie trzeba robić dopóki robimy nowe projekty na najnowszej wersji PHP. Problemy zaczynają się w momencie jak chcemy odpalić jakieś stare aplikacje. Nie dość, że musimy ogarnąć „sterownik” do naszej aplikacji (o ile wychodzi poza klasyczny zestaw Valeta czyli Laravel, Lumen, Symfony, Zend, Cake3, WordPress itd.) to jeszcze potrzebujemy starych wersji PHP. Biorąc pod uwagę, że Valet działa na PHP 7.1 to jak to jednocześnie uruchomić?

Jak działa Valet?

Żeby zrozumieć nasz problem i dojść do tego jak go rozwiązać potrzebujemy zgłębić jak działa Valet. Otóż jego podstawowa konfiguracja zakłada, że wszystkie żądania przechodzące przez nginx są kierowane do valetowego skryptu PHP. I to właśnie on dzięki rozszerzeniom sprawdza do jakiego typu aplikacji go przypisać i co z nim zrobić. I tu dochodzimy do sedna problemu: co z tego, że zrobimy sterownik do aplikacji w np. Kohana2 skoro sama aplikacja to takie straszne „legacy”, że uruchomi się co najwyżej w PHP 5.3. Nie ma wyjścia, musimy obejść zupełnie wyświetlanie przez Valetowe skrypty (tak prawdę mówiąc nie są nam one do niczego potrzebne).

Instalujemy wiele wersji PHP

Szukając rozwiązania na wiele jednoczesnych wersji PHP dla MacOS trafiałem jedynie na same absurdalne rozwiązania typu: zainstaluj kilka wersji PHP, a następnie rób link/unlink w brew. Co w tym złego? Przede wszystkim nie rozwiązuje to problemu. Wprawdzie możemy mieć wiele wersji PHP ale w takim układzie nie działają one jednocześnie. A to jest kluczowe chcąc odpalić jakieś „stare szajsy”, a jednocześnie działać na współczesnych rozwiązaniach (obsługa valeta, composera itp.). Naprawmy to!

Zacznijmy od zainstalowania starych wersji PHP. Wybierz to co potrzebujesz bo oczywiście nie ma sensu instalowania wszystkiego co się rusza (a w zasadzie tutaj to się już od dawna nie rusza 🙂 ).

Schemat postępowania jest taki sam:

brew unlink obecne_php
brew install nowe_php
brew services start nowe_php

czyli

brew unlink php71 && brew install php56 && brew services start php56
brew unlink php56 && brew install php53 && brew services start php53

Jak już zainstalujemy potrzebne nam wersje to wracamy do podstawowej wersji:

brew unlink php53 && brew link php71

Pod brew services list można zobaczyć co mamy odpalone:

brew services list

brew services list

Żeby wszystkie wersje PHP mogły jednocześnie działać musimy odpalić je na innych portach. Przechodzimy do /usr/local/etc/php gdzie znajdziemy pliki konfiguracyjne php-fpm.conf dla danych wersji. Szukamy linijki z opcją listen i zamieniamy ją na listen = 127.0.0.1:9053. Numery portów są dowolne ale żeby się nie pogubić uprośćmy je do nazewnictwa :9053 dla PHP53, :9056 dla PHP 5.6 itd. PHP 7.1 zostawiamy ustawione na socket.

Teraz zostało nam zrestartować po kolei wszystkie edytowane wersje PHP brew services restart php53 i gotowe. Mamy kilka jednocześnie działających wersji PHP.

Konfiguracja Nginxa

Żeby odpalić naszą „legacy” aplikację musimy zmodyfikować generowane przez Valeta pliki konfiguracyjne. Żeby to zrobić linkujemy sobie katalog z aplikacją (zobacz opis w poprzednim artykule) valet link mojaapka i jak potrzebujemy SSL to valet secure mojaapka. Pliki konfiguracyjne lądują w ~/.valet/Nginx.

W zależności od tego jaką mamy apkę i czy będzie to wersja z lub bez SSL modyfikujemy wpisy wg. potrzeb pamiętając aby:

  • puścić ruch bezpośrednio na naszą apkę (skasować przekierowanie na plik Valeta)
  • zmienić port na potrzebną nam wersję PHP.

Przykładowo dla aplikacji w Kohanie i PHP 5.3 SSL może to wyglądać tak:

server {
    listen 80;
    server_name legacy.dev;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name legacy.dev;
    root /Users/nrm/workspace/legacy/;
    charset utf-8;
    index index.php index.html;

    ssl_certificate /Users/nrm/.valet/Certificates/legacy.dev.crt;
    ssl_certificate_key /Users/nrm/.valet/Certificates/legacy.dev.key;

    location / {
        try_files $uri $uri/ /index.php?kohana_uri=$request_uri;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log /Users/nrm/.valet/Log/nginx-error.log;

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass 127.0.0.1:9053;
        fastcgi_index /Users/nrm/workspace/legacy/index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~ /\.ht {
        deny all;
    }
}

Jak wszystko nam działa to warto zrobić sobie backup tych plików konfiguracyjnych Nginxa dla danego hosta gdyż niestety te pliki są generowane przez Valeta i jeżeli kiedykolwiek coś poknocimy (albo będziemy chcieli skorzystać z valet secure/link itp.) to zostaną one niestety nadpisane. Taki „brudny hack” ale działa!

Wiele wersji PHP dla MacOS

Ten sposób konfiguracji nie jest związany tylko i wyłącznie z Laravel Valet dlatego bez problemu można go wykorzystać w sytuacji kiedy ktoś korzysta bezpośrednio z pakietów brew.

Dodaj na LinkedIn
Mirosław Okoński
Przede wszystkim admin, potem webdeveloper choć kiedyś było odwrotnie. Obecnie Full Stack Engineer, CTO i System Architect. Po godzinach fan dobrych seriali, których nigdy nie ma czasu obejrzeć. Kawożłop. Miłośnik piwa i Metaxy. W czasie pomiędzy kontuzjami biega.