LAMP, WAMP, XAMPP, MAMP – porównanie i wybór lokalnego środowiska deweloperskiego

Wybór lokalnego środowiska deweloperskiego zależy od systemu operacyjnego i specyfiki kodu, a najpopularniejsze opcje to XAMPP dla uniwersalności, WAMP dla Windowsa, MAMP dla macOS oraz LAMP dla natywnych instalacji Linux. Odpalenie jednego z tych pakietów pozwala na szybkie postawienie serwera Apache, bazy danych i interpretera PHP na własnym dysku bez opłacania zewnętrznego hostingu.

Stawiasz stronę na WordPressie albo piszesz autorską aplikację webową. Potrzebujesz miejsca, żeby sprawdzić działanie kodu przed wypuszczeniem go w świat. Wrzucanie plików przez FTP na serwer docelowy po każdej zmianie jednej linijki to absolutna strata czasu. Maszyna musi przetwarzać skrypty bezpośrednio z twojego dysku twardego. Zmieniliśmy te zasady na robocie lata temu. Lokalny localhost to podstawa pracy każdego programisty.

Czym dokładnie jest serwer lokalny i po co instalujemy stack technologiczny?

Serwer lokalny to oprogramowanie symulujące prawdziwy hosting wewnątrz twojego komputera. Odcinasz się od internetu. Piszesz kod w pociągu albo w samolocie. Aplikacja działa i łączy się z bazą danych dokładnie tak samo, jakby leżała w potężnej serwerowni we Frankfurcie. Instalujemy ten stack z dwóch powodów.

• Zyskujemy środowisko testowe oparte o architekturę klient-serwer, w którym mamy pełne uprawnienia roota do edycji plików konfiguracyjnych takich jak php.ini czy my.cnf. Nikt nam nie blokuje funkcji systemowych.
• Oszczędzamy czas. Po prostu.

Pamiętam wdrożenie małego portalu dla klienta z wrocławskich Krzyków w zeszłym miesiącu. Siedziałem nad kodem o trzeciej nad ranem. Odpalam środowisko testowe, a tam czerwony błąd w logach. Port 80 zablokowany. Szlag człowieka trafia na miejscu. Okazało się, że jakaś obca usługa w tle na Windowsie nagle przejęła ten port po cichej aktualizacji systemu. Musiałem ręcznie wchodzić w plik httpd.conf i zmieniać nasłuchiwanie na port 8080. Takie sytuacje pokazują dobitnie, że nawet najlepszy wybór lokalnego środowiska deweloperskiego nie zwalnia nas z myślenia i znajomości podstaw sieci.

Jakie są główne różnice między LAMP, WAMP, XAMPP i MAMP?

Różnice sprowadzają się do systemu operacyjnego, na którym pracujesz, i dołączonych modułów. Każda z tych paczek zawiera rdzeń w postaci serwera WWW (najczęściej Apache), systemu zarządzania relacyjną bazą danych (MySQL lub MariaDB) oraz interpretera języka skryptowego (PHP). Różnią się panelem sterowania i procesem instalacji.

Widzisz tabelę. To suche dane. Prawda jest zresztą absolutnie taka, że wielu młodych programistów instaluje pierwszą paczkę z brzegu i potem męczy się z konfiguracją ścieżek dostępu. Wybór lokalnego środowiska deweloperskiego definiuje twój komfort pracy na najbliższe miesiące. Zła decyzja skutkuje błędami typu 500 Internal Server Error przy każdej próbie odpalenia bardziej złożonego skryptu.

Czy XAMPP to zawsze najlepszy wybór dla początkujących koderów?

XAMPP uchodzi za najpopularniejszą paczkę w sieci. Pobierasz instalator ważący ponad sto megabajtów. Klikasz dalej, dalej, zakończ. Masz gotowy panel kontrolny. Odpalasz apache’a i bazę jednym kliknięciem. Projekt rozwijany przez Apache Friends zdominował rynek tutoriali na YouTube. Niemal każdy poradnik o instalacji WordPressa zaczyna się od pobrania tego właśnie oprogramowania.

Ale XAMPP ma swoje za uszami. Zamiast czystego MySQL używa forka o nazwie MariaDB. W zdecydowanej większości przypadków te bazy są ze sobą w pełni kompatybilne. Kod SQL wykonuje się identycznie. Czasami jednak natrafisz na drobne różnice w obsłudze specyficznych typów danych JSON. Panel kontrolny XAMPP-a wygląda jak relikt z wczesnych lat dwutysięcznych. Brakuje mu szybkiego przełącznika wersji PHP. Jeśli masz stary projekt klienta napisany w PHP 7.4 i nowy w PHP 8.2, musisz ręcznie podmieniać zmienne środowiskowe albo instalować dwie osobne instancje programu. To irytuje.

Dodatkowo XAMPP ładuje do systemu usługi, których prawdopodobnie nigdy nie użyjesz. Serwer pocztowy Mercury i serwer Tomcat do Javy. Zjadają zasoby pamięci RAM. Lepiej je od razu wyłączyć w panelu głównym.

Dlaczego programiści Windowsa wciąż wybierają WAMP?

WAMP Server to projekt dedykowany wyłącznie dla okienek od Microsoftu. Jest lżejszy od XAMPP-a. Główna przewaga tego rozwiązania leży w zielonej ikonce ukrytej w pasku zadań obok zegara. Klikasz lewym przyciskiem myszy i masz dostęp do wszystkiego. Restartujesz usługi. Zmieniasz wersję PHP w locie z menu rozwijanego. Otwierasz logi błędów bez szukania plików tekstowych po głębokich folderach na dysku C.

WAMP instaluje się bezpośrednio w głównym katalogu partycji. Narzuca twardy rygor struktury plików. Katalog www to miejsce, gdzie wrzucasz swoje projekty. Konfiguracja wirtualnych hostów (vhosts) odbywa się przez prosty interfejs w przeglądarce. Zamiast wpisywać w pasek adresu localhost/moj_projekt/public, tworzysz ładną lokalną domenę typu mojprojekt.local. WAMP automatycznie dopisuje odpowiednie reguły do pliku hosts w systemie operacyjnym Windows.

Szczerze mówiąc brakuje nam twardych danych z tego kwartału na temat tego, ilu deweloperów porzuciło WAMP-a na rzecz kontenerów, więc wydaje się to tylko jedną z możliwych hipotez na najbliższe lata, że tradycyjne instalatory zaczną tracić na znaczeniu. Mimo to WAMP trzyma się mocno w agencjach interaktywnych. Używamy go na co dzień do szybkiego łatania starych stron.

Kiedy natywny LAMP na Linuxie bije na głowę gotowe instalatory?

Pracujesz na Ubuntu. Otwierasz terminal. Wpisujesz sudo apt install apache2 mysql-server php. System dociąga pakiety z repozytorium. Konfigurujesz uprawnienia katalogu /var/www/html. Masz środowisko LAMP. Nie ma tu żadnego graficznego panelu sterowania. Wszystko robisz z poziomu konsoli wpisując komendy tekstowe.

Dlaczego to podejście jest lepsze? Ponieważ twój serwer produkcyjny u klienta to w dziewięćdziesięciu procentach przypadków dokładnie taki sam Linux. Używając natywnego LAMP-a, uczysz się prawdziwej administracji serwerem. Rozumiesz mechanizmy działania systemu uprawnień plików CHMOD. Wiesz, jak zrestartować usługę za pomocą systemctl. Rozwiązujesz problemy z zaporą ufw. Gotowe paczki pod Windowsa ukrywają tę wiedzę przed użytkownikiem pod warstwą przycisków.

Zbudowanie poprawnego LAMP-a na czystym systemie Debian zajmuje wprawnemu administratorowi kilkanaście minut. Deploy na produkcję z takiego środowiska jest bezbolesny. Omijasz problemy z wielkością liter w nazwach plików. Windows traktuje Plik.php i plik.php tak samo. Linux rozróżnia wielkość znaków. Wiele projektów działało idealnie na WAMP-ie, a po wrzuceniu na produkcję wyrzucało błędy braku plików. Natywny LAMP brutalnie weryfikuje te pomyłki już na etapie pisania kodu.

MAMP to narzędzie dla macOS czy coś więcej?

MAMP powstał z myślą o użytkownikach komputerów od Apple. System macOS ma wbudowanego Apache i PHP, ale ich konfiguracja bywa uciążliwa po każdej większej aktualizacji systemu operacyjnego. MAMP rozwiązuje ten problem, dostarczając odizolowane środowisko w jednym folderze w katalogu Aplikacje.

Wersja darmowa jest bardzo ograniczona. Prawdziwą wartość wnosi płatny MAMP Pro. Płacisz kilkadziesiąt dolarów i dostajesz potężny kombajn do zarządzania projektami.

• Tworzysz nielimitowaną liczbę wirtualnych hostów jednym kliknięciem, przypisując każdemu z nich inną wersję PHP, od archaicznego 5.6 po najnowsze gałęzie.
• Narzędzie posiada wbudowanego klienta poczty do testowania wysyłki e-maili ze skryptów bez konfigurowania serwerów SMTP w kodzie.
• Funkcja snapshotów pozwala na zrobienie kopii zapasowej całej bazy danych i plików projektu przed niebezpieczną aktualizacją wtyczek w systemie CMS.
• Udostępniasz swój lokalny serwer do sieci zewnętrznej przez tunelowanie NGROK. Klient widzi twoją pracę na żywo pod wygenerowanym linkiem, a pliki fizycznie nie opuszczają twojego laptopa.

To zmienia sposób pracy. Zmieniliśmy te zasady na robocie w zespole projektowym, kupując licencje na wersję Pro dla każdego grafika i koderka. Oszczędność nerwów przy konfiguracji zwraca się po pierwszym tygodniu.

Jak poprawnie skonfigurować serwer lokalny pod wymagania bazy danych?

Instalacja to początek. Domyślne ustawienia PHP w pakietach XAMPP czy WAMP są bardzo restrykcyjne. Mają chronić serwer przed zapętleniem kodu i wyciekami pamięci. W środowisku lokalnym te limity często przeszkadzają. Próbujesz zaimportować dużą bazę danych MySQL o wadze 150 megabajtów przez narzędzie phpMyAdmin. Wyskakuje błąd o przekroczeniu dopuszczalnego rozmiaru pliku. Skrypt przerywa działanie.

Wchodzisz w plik konfiguracyjny php.ini. Szukasz wartości upload_max_filesize. Domyślnie wynosi ona zaledwie 2M. Zmieniasz ją na 256M. To samo robisz z dyrektywą post_max_size. Zapisujesz plik. Musisz zrestartować serwer Apache, żeby wczytał nową konfigurację do pamięci podręcznej. Od tego momentu import ciężkich zrzutów bazy danych przebiega bez zająknięcia.

Kolejny parametr to max_execution_time. Określa, jak długo skrypt PHP może działać, zanim serwer go ubije. Domyślne 30 sekund to za mało na uruchomienie ciężkich skryptów migracyjnych, które przenoszą tysiące wpisów z jednego systemu do drugiego. Podbijamy tę wartość do 300 sekund na środowisku lokalnym. Ryzyko jest żadne, bo i tak nikt z zewnątrz nie ma dostępu do naszej maszyny.

Co psuje się najczęściej na localhost i jak naprawić awarię portów?

Najczęstszy problem związany z wyborem lokalnego środowiska deweloperskiego to konflikty sieciowe. Apache domyślnie nasłuchuje żądań na porcie 80 dla ruchu HTTP i na porcie 443 dla szyfrowanego ruchu HTTPS. Jeśli inny program w systemie operacyjnym już zajął ten kanał komunikacyjny, serwer WWW po prostu się nie uruchomi. Panel sterowania wyrzuci błąd. Usługa zostanie zatrzymana.

Główni winowajcy na systemach Windows to komunikator Skype oraz wbudowana usługa World Wide Web Publishing Service (IIS). Ten drugi proces często uruchamia się automatycznie ze startem systemu operacyjnego. Rozwiązanie jest proste. Wchodzisz w usługi systemowe (services.msc). Odszukujesz proces IIS. Klikasz prawym przyciskiem myszy i zmieniasz tryb uruchamiania na ręczny. Zatrzymujesz usługę. Odpalasz panel XAMPP lub WAMP ponownie. Apache wstaje z martwych.

Drugi irytujący błąd to problem z połączeniem do bazy danych z poziomu kodu PHP. Skrypt wyrzuca komunikat „Access denied for user 'root’@’localhost'”. Domyślnie większość lokalnych instalatorów tworzy głównego użytkownika bazy danych o nazwie „root” z całkowicie pustym hasłem. Jeśli w swoim pliku wpiszesz jakiekolwiek hasło podczas łączenia się z bazą przez PDO lub mysqli, autoryzacja odrzuci żądanie. Należy zostawić pole hasła jako pusty ciąg znaków.

Prawda jest zresztą absolutnie taka, że wielu początkujących gubi się w strukturze katalogów. Wrzucają pliki projektu do głównego folderu instalacyjnego zamiast do podkatalogu htdocs w XAMPP lub www w WAMP. Serwer nie wie, gdzie szukać pliku index.php i wyświetla pustą strukturę drzewa katalogów. Trzeba czytać dokumentację ze zrozumieniem.

Zakończenie bez owijania w bawełnę

Porzuć szukanie idealnego narzędzia, którego nie ma. Zainstaluj to środowisko, które pasuje do twojego aktualnego systemu operacyjnego, i zacznij wreszcie pisać kod. Jeśli masz Windowsa, bierz WAMP-a. Jeśli klikasz na Macu, wybierz MAMP-a. XAMPP jest w porządku do szybkiej weryfikacji skryptów z internetu. Z kolei LAMP na Ubuntu to opcja dla ludzi, którzy poważnie myślą o karierze w administracji serwerami i DevOps. Wybór lokalnego środowiska deweloperskiego ma wspierać twoją pracę, a nie stanowić cel sam w sobie. Zmierz się z konfiguracją wirtualnych hostów już dzisiaj i przestań testować projekty w podkatalogach localhosta. To amatorskie podejście psuje ścieżki do obrazków i skryptów CSS na produkcji.

Schemat FAQ dla wyszukiwarek

Bibliografia autorytatywna

1. Apache Software Foundation – https://apache.org
2. PHP Group – https://php.net
3. MariaDB Foundation – https://mariadb.org
4. Oracle Corporation (MySQL) – https://mysql.com
5. Ubuntu – https://ubuntu.com