Mam takie pytanie czy jest sposób, żeby uruchomić dwie wersje php na jednym serwerze, na różnych portach (kubuntu 20.04) na razie mam dwa serwery virtualne na dwóch portach, ale jak próbuje załadować dwie wersje php to mam komunikat
Starting apache2 (via systemctl): apache2.serviceJob for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xe" for details.
failed!
No mam taki komunikat po wydaniu tego polecenia.
systemctl status apache2.service
Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this m>
to trzeba uruchomić drugi adres.
Mozesz ale sie tylko przelaczac. Port nie ma tu znaczenia bo uruchamias usługe, wiec mozesz sobie uruchomic php7 na porcie dowolnym czy php8 na innym ale tylko jedna usluga musi byc uruchomiona. :)
coś czytałam kiedyś że jedna wersja jako cgi druga jako moduł apache
Jeśli mówimy o samym php, to możesz to banalnie zrobić wbudowanym serverem w PHP
php7 -S localhost:8080
php8 -S localhost:8081
@TomRiddle: Takie rozwiązanie też mi odpowiada, bo mi chodzi o testowanie php8.1 w innej aplikacji.
pol90 napisał(a):
@TomRiddle: Takie rozwiązanie też mi odpowiada, bo mi chodzi o testowanie php8.1 w innej aplikacji.
No to skoro tak, to to był klasyczny problem X/Y.
Mogles od razu napisać o co Ci chodzi.
A masz możliwość postawienia tam Dockera? Wtedy takie problemy znikają i możesz na jednym serwerze mieć dowolna ilość konfiguracji w dość prosty sposób. Jak pójdziesz o krok dalej i ogarniesz sobie pipeliny np. za pomocą github Actions to możesz sobie po każdym commicie do repozytorium deployowac aplikacje z różnymi wersjami php.
Ogolnie preferuję Dockera bo jak masz tradycyjny config to trudno ogarnąć bardziej zaawansowane scenariusza konfiguracji jak np postawienie kilku wersji mysql, różnych konfigow php/apacha per aplikacja itp. Z dockerami takie rzeczy są dość proste.
hadwao napisał(a):
A masz możliwość postawienia tam Dockera? Wtedy takie problemy znikają i możesz na jednym serwerze mieć dowolna ilość konfiguracji w dość prosty sposób. Jak pójdziesz o krok dalej i ogarniesz sobie pipeliny np. za pomocą github Actions to możesz sobie po każdym commicie do repozytorium deployowac aplikacje z różnymi wersjami php.
Ogolnie preferuję Dockera bo jak masz tradycyjny config to trudno ogarnąć bardziej zaawansowane scenariusza konfiguracji jak np postawienie kilku wersji mysql, różnych konfigow php/apacha per aplikacja itp. Z dockerami takie rzeczy są dość proste.
Niby tak, ale sporo też tracisz.
Pierwsze co mi przychodzi do głowy to performance. Na lokalnej instalacji php odpalanie suita testów to 10 sekund, na dockerze to zawsze jest 25 sekund+ (a mam high-endową maszynę). Dodaktowo, jeśli chcesz zmienić ustawienia pod development, na lokalnej maszynie to jest sekunda, na dockerze musisz przebudować obraz i stworzyć od nowa kontenery.
Także coś za coś.
Ja osobiście stawiam bazy na dockerze (faktycznie baza lokalna i dockerowa - to dockerowa to jest obvious choice), ale instalacje PHP trzymam lokalnie w wielu wersjach (7.1, 7.2, 7.3, 7.4, 8.0 i 8.1rc), sprawdza się dużo lepiej niż na dockerze.
@TomRiddle nie jestem co prawda zbyt dobry w technikaliach Dockera i ogólnie tematach z przekroju devops, ale wydaje mi się, że coś masz źle skonfigurowane.
Swego czasu byłem na szkoleniu z Dockerów i tam człowiek "co się zna" mówił, że na Linux proces odpalony w Dockerze ma praktycznie zerowy narzut i z grubsza działa tak jak system odpalony bez użycia dockera. Oczywiście docker na maszynie developerskiej niesie ze sobą pewne koszty np. udostępnianie volumenów z hosta itp, ale nadal przy zdroworozsądkowym podejściu to są różnice mierzone w procentach a nie setkach procent.
Taki rozrzut jak tutaj opisałeś to obstawiam jeden lub kilka z powyższych czynników:
Ogólnie powiem tak - pracuję na Ubuntu z bardzo zasobożernym systemem Magento, który ma ogromną ilość vendorów, których NIE wrzucam do kontenera tylko udostępniam jako wolumin (czyli niezbyt to optymalne) i nie obserwuję żadnych znaczących problemów z wydajnością. Ten sam zestaw odpalam na produkcji (tylko oczywiście wtedy już cały code base w kontenerze) i nie odbiega on wydajnością od tradycyjnego systemu.
Tak jak pisałem nie jestem devopsem, więc może gdzieś mijam się z prawdą, ale uważam, że coś jest nie tak z Twoim setupem.
Co do zysków z dockerów to dla mnie uniezależnienie się od różnic w konfiguracji serwera i środowiska dev jest ogromną wartością. Sporo pracuję z aplikacjami komunikującymi się między sobą po API, wiec praktycznie każdy projekt ma inny setup. Możliwość przechowywanie setupu w pliku i prostego odtworzenia go w czasie deployu na serwerze to jest ogromne ułatwienie. Jak jeszcze doda się do tego takie narzędzia jak Traefik czyli taki jakby serwer proxy dla kontenerów + gihtub actions to bardzo łatwo zautomatyzować wszystko po drodze czyli testy, statyczna analiza kodu, deployment, przebudowywanie środowisk testowych itd itp.
Na Apache można zrobić 2 vhosty z różnymi wersjami php i na różnych portach i w zasadzie jest to banalne
TomRiddle napisał(a):
Pierwsze co mi przychodzi do głowy to performance. Na lokalnej instalacji php odpalanie suita testów to 10 sekund, na dockerze to zawsze jest 25 sekund+ (a mam high-endową maszynę). Dodaktowo, jeśli chcesz zmienić ustawienia pod development, na lokalnej maszynie to jest sekunda, na dockerze musisz przebudować obraz i stworzyć od nowa kontenery.
A ile z tego czasu to startup a ile same testy? Testy zapisują coś na dysku kontenera? Na Linuxie narzut powinien być niezauważalny, po prostu proces jest lepiej odizolowany, ale nadal jest uruchamiany natywnie na hoście. Jeżeli odpalsz to na macu albo windowsie, to pod spodem działa VMka, więc to inna historia.
Także coś za coś.
Ja osobiście stawiam bazy na dockerze (faktycznie baza lokalna i dockerowa - to dockerowa to jest obvious choice), ale instalacje PHP trzymam lokalnie w wielu wersjach (7.1, 7.2, 7.3, 7.4, 8.0 i 8.1rc), sprawdza się dużo lepiej niż na dockerze.
Na produkcji? Dane żyją na zmapowanym wolumenie? Sam docker, czy jednak działa na jakimś orkiestratorze jak k8s? Myślałem, że ze względów wydajnościowych zazwyczaj robi się odwrotnie. Serwisy w kontenerach, a baza na dedykowanej instancji VMki.
hadwao napisał(a):
Swego czasu byłem na szkoleniu z Dockerów i tam człowiek "co się zna" mówił, że na Linux proces odpalony w Dockerze ma praktycznie zerowy narzut i z grubsza działa tak jak system odpalony bez użycia dockera. Oczywiście docker na maszynie developerskiej niesie ze sobą pewne koszty np. udostępnianie volumenów z hosta itp, ale nadal przy zdroworozsądkowym podejściu to są różnice mierzone w procentach a nie setkach procent.
No, trochę prawda - trochę nie prawda. Tutaj chodzi o to że jeśli odpalasz kontener dockera z takim samym kernelem jak host, to śmiga, a jak nie, to są przeprowadzane transformacje pamięci i procesów. Np kontener linuxowy na linxie śmiga; ale kontener windowsowy na windowsie śmiga. Jak są odwrotnie, np kontener windowsowy na linuxie, albo kontener linuxowy na windowsie - to wtedy działa wolno.
Więć to nie jest tak że Linux - dobry, Windows - zły; tylko zgodne kernele działają szybko, niezgodne działają wolno.
Taki rozrzut jak tutaj opisałeś to obstawiam jeden lub kilka z powyższych czynników:
- odpaliłeś Dockery na Windows lub MacOs
- udostępniałeś jakieś duże ilości plików z HOSTA (w Linux narzut jest niewielki, ale już udostępnianie z Windowsa to spory problem). Tutaj polecam prosty trick jak kopiowanie do Dockera wszelkich zasobów, których nie edytujesz do kontenera (np. całe vendory można tam śmiało wrzucić zamiast udostępniać jako udział)
- miałeś złą konfigurację - np. oficjalne obrazy od PHP mają wyłączony opcache i trzeba go skonfigurować w Dockerfile
Ogólnie powiem tak - pracuję na Ubuntu z bardzo zasobożernym systemem Magento, który ma ogromną ilość vendorów, których NIE wrzucam do kontenera tylko udostępniam jako wolumin (czyli niezbyt to optymalne) i nie obserwuję żadnych znaczących problemów z wydajnością. Ten sam zestaw odpalam na produkcji (tylko oczywiście wtedy już cały code base w kontenerze) i nie odbiega on wydajnością od tradycyjnego systemu.
No, to mogłoby być jakimś rozwiązaniem; jeśli nigdy nie zmieniasz zależności; bo jeśli pracujesz na różnych branchach, na którym masz różne zależności w różnych wersjach, to teraz oprócz instalacji zależności (np npm install, mvn install, composer install); musisz też przenosić je na kontener.
Także znowu, coś za coś.
Co do zysków z dockerów to dla mnie uniezależnienie się od różnic w konfiguracji serwera i środowiska dev jest ogromną wartością. Sporo pracuję z aplikacjami komunikującymi się między sobą po API, wiec praktycznie każdy projekt ma inny setup. Możliwość przechowywanie setupu w pliku i prostego odtworzenia go w czasie deployu na serwerze to jest ogromne ułatwienie. Jak jeszcze doda się do tego takie narzędzia jak Traefik czyli taki jakby serwer proxy dla kontenerów + gihtub actions to bardzo łatwo zautomatyzować wszystko po drodze czyli testy, statyczna analiza kodu, deployment, przebudowywanie środowisk testowych itd itp.
Tak, docker zapewnia odseparowanie aplikacji od środowiska; ale czy to jest taka dobra rzecz? Pracowałem 2 lata temu w firmie, w której mieliśmy dockerka; ale jeden z pracowników odpalił go na swojej lokalnej maszynie; i aplikacja przestała działać. Okazało się jednak, że problem nie był z jego środowiskiem, tylko był autentyzcny bug w aplikacji, którego nie widzieliśmy na dockera, ponieważ każdy miał takiego samego. Odwzorowaliśmy potem konfiguracje lokalnej maszyny w teście i naprawiliśmy buga.
Także tak; jeśli aplikacja się jebie na róznych lokalnych maszynach; to być może wszystko jest git, i docker jest git; albo być może jest źle napisana i różnica w środowisku to objaw, a nie przyczyna; i należałoby ją wyleczyć
Także znowu - coś za coś.
a FPM tego nie łyknie?