Serwer Apache to darmowe oprogramowanie typu open source, które odbiera żądania HTTP od przeglądarek internetowych i wysyła do nich z powrotem pliki tworzące strony WWW. Służy on do fizycznego utrzymywania i wyświetlania witryn w sieci, tłumacząc kod zapisany na dysku maszyny na obraz widoczny dla użytkownika.
Piszę te słowa w sumie o trzeciej nad ranem, po tym jak wczoraj na wdrożeniu u klienta w małej firmie na krakowskim Podgórzu padła nam cała konfiguracja hostingu. Prawda jest zresztą absolutnie taka, że praca z serwerami rzadko wygląda jak w sterylnych podręcznikach. Instalujesz paczkę, odpalasz usługę, a potem patrzysz na biały ekran błędu. Apache ma swoje lata. Narodził się w 1995 roku. I nadal ciągnie bez mała połowę starych firmowych systemów w polskim internecie. To kawał ciężkiego, starego kodu, do którego musimy wracać na co dzień.
Jak dokładnie działa serwer WWW Apache i co robi w tle?
Zasada działania opiera się na podstawowej architekturze klient-serwer. Ty wpisujesz adres w pasku Chrome. Przeglądarka to klient. Wysyła ona żądanie na port 80 lub 443 do maszyny, na której działa oprogramowanie Apache. Ten program z kolei przeszukuje strukturę plików na dysku twardym. Znajduje plik index.php. Przetwarza go w pamięci. Wypluwa wynik z powrotem do przeglądarki w formie czystego dokumentu HTML.
To zwykły kurier. Odbiera paczkę z pytaniem i odnosi paczkę z odpowiedzią.
Czasami czytam te wszystkie mądre fora dla administratorów, gdzie ludzie obrzucają się błotem, udowadniając wyższość jednego oprogramowania nad drugim, i autentycznie tracę wiarę w naszą branżę. Zamiast po prostu postawić maszynę i sprawdzić, jak zachowuje się pod obciążeniem stu użytkowników wklepujących dane do formularza, wchodzą w akademickie dysputy o ułamkach milisekund czasu odpowiedzi. A potem i tak klient dzwoni z pretensjami, że mu strona nie działa, bo zapomniał opłacić domenę u rejestratora na kolejny rok. Taka jest rzeczywistość IT, pełna prozaicznych wpadek, a nie wielkich architektonicznych batalii.
Dlaczego plik .htaccess sprawia nam tyle problemów na start?
Ten mały, ukryty plik tekstowy to absolutne przekleństwo początkujących webdeveloperów. Plik .htaccess pozwala na nadpisywanie globalnej konfiguracji serwera z poziomu zwykłego, pojedynczego katalogu na dysku. My używamy go w dwóch bardzo konkretnych celach.
- Wymuszamy przekierowania z niezabezpieczonego HTTP na bezpieczny protokół HTTPS, żeby przeglądarka nie rzucała w twarz ostrzeżeniami o braku kłódki szyfrowania. Ustawienie tego wymaga wklejenia trzech linijek kodu, które zazwyczaj i tak kopiujemy z dokumentacji technicznej, bo nikt u nas w biurze nie pamięta składni reguł mod_rewrite z głowy. Zawsze trzeba włączyć silnik przepisywania dyrektywą RewriteEngine On.
- Zmieniamy strukturę adresów URL na przyjazne dla oka linki.
Zrobiłem to setki razy. A i tak czasem postawię zły znak w wyrażeniu regularnym i cała domena zwraca błąd 500 Internal Server Error. Wtedy szlag człowieka trafia, bo serwer milczy i nie podpowiada, gdzie leży literówka.
Do czego służy serwer Apache w codziennej pracy webdevelopera?
Używamy go po prostu jako środowiska testowego na własnych maszynach. Zanim wyrzucimy nowy sklep internetowy na serwer produkcyjny u dostawcy, musimy go zbudować u siebie na laptopie. Tutaj wchodzi do gry pakiet XAMPP. To darmowa paczka zrzucająca nam na dysk Windowsa gotowego Apache, bazę danych MySQL i silnik języka PHP. Klikasz start w małym oknie kontrolnym. Zapala się zielona lampka obok nazwy usługi. Masz własny lokalny hosting odizolowany od reszty świata.
Na produkcji sprawa wygląda zupełnie inaczej. Tam bezwzględnie królują systemy Linux. Stawiamy tzw. stos LAMP (Linux, Apache, MySQL, PHP). Wchodzisz przez konsolę SSH. Wpisujesz komendę instalacyjną apt-get install apache2. Czekasz chwilę na pobranie pakietów.
Potem musisz skonfigurować wirtualne hosty, znane w branży jako VirtualHost. To mechanizm pozwalający jednej fizycznej maszynie obsługiwać dziesięć różnych domen internetowych jednocześnie. Apache rozdziela ruch na podstawie nazwy domeny, o którą pyta przeglądarka, i kieruje użytkownika do odpowiedniego folderu na dysku twardym. Jeśli klient pyta o strona-a.pl, serwer ładuje katalog /var/www/strona-a. Jeśli pyta o strona-b.pl, ładuje pliki z katalogu /var/www/strona-b.
Czym różni się Apache od Nginx i co wybrać na serwer WWW?
To odwieczne pytanie na grupach dla młodych programistów. Apache to ciężki kombajn. Ma wbudowane wszystko i radzi sobie z każdym typem żądania. Nginx powstał znacznie później z jednym głównym zamysłem. Miał radzić sobie z ogromnym ruchem sieciowym poprzez asynchroniczne przetwarzanie zdarzeń. Zrobiliśmy u nas testy obciążeniowe na starym serwerze w biurze w zeszłym miesiącu. Pchaliśmy ruch z tysiąca wirtualnych klientów w tej samej sekundzie.
Wyniki były brutalne dla staruszka.
| Cecha techniczna | Oprogramowanie Apache | Oprogramowanie Nginx |
| Przetwarzanie żądań | Tworzy nowy wątek roboczy w pamięci dla każdego użytkownika. | Asynchroniczna pętla zdarzeń, zjada mało zasobów przy tysiącach zapytań. |
| Konfiguracja katalogów | Posiada plik .htaccess dla lokalnych zmian. | Brak odpowiednika, wszystko trzyma w głównym pliku konfiguracyjnym. |
| Wydajność statyczna | Zadowalająca, ale zżera RAM przy dużej liczbie plików graficznych. | Zdecydowanie wyższa przy serwowaniu plików obrazów, wideo i arkuszy CSS. |
| Próg wejścia | Prosta instalacja. | Wymaga zmiany nawyków z przepisywaniem linków URL. |
Zdecydowaliśmy się ostatecznie zostawić Apache dla starych systemów opartych o WordPress, a nowe, szybkie aplikacje pisane w React od razu pchamy na Nginxa w kontenerach Docker. To jest bez mała najgorsza opcja z wszystkich dostępnych, bo musimy utrzymywać wiedzę o dwóch zupełnie różnych technologiach w jednym zespole. Koszty utrzymania rosną, ale wydajność zmusza nas do takich decyzji.
Jakie moduły Apache instalujemy najczęściej i po co to robimy?
Sam goły serwer po instalacji potrafi niewiele. Jego siła tkwi w modułach, które doładowujemy do pamięci w razie potrzeby. Traktujemy je jak klocki. W zdecydowanej większości przypadków na świeżej maszynie uruchamiamy cztery podstawowe dodatki rozszerzające funkcjonalność.
- mod_rewrite: Odpowiada za przepisywanie adresów. Bez niego linki w sklepach internetowych wyglądałyby jak ciąg losowych znaków z zapytaniami z bazy danych. Włączasz go jedną komendą w terminalu Ubuntu (a2enmod rewrite) i nagle wszystko staje się czytelne dla robota wyszukiwarki Google. Zawsze upewnij się, że zrestartowałeś usługę komendą systemctl restart apache2 po tym kroku, inaczej zmiany po prostu nie wejdą w życie.
- mod_ssl: Bezwzględny wymóg na dzisiejszym rynku. Otwiera port 443 i pozwala na instalację certyfikatów bezpieczeństwa. Kiedyś trzeba było za nie płacić ogromne pieniądze firmom zewnętrznym wydającym podpisy cyfrowe. Dzisiaj podpinamy darmowe Let’s Encrypt w pięć minut z użyciem bota certbot.
- mod_security: Tarcza ochronna przeciwko skryptowym atakom. To zapora sieciowa klasy WAF aplikowana bezpośrednio na serwer WWW. Chroni bazę przed wstrzyknięciami typu SQL Injection.
- mod_deflate: Moduł odpowiadający za kompresję danych w locie. Zmniejsza fizyczną wagę wysyłanych obrazków i skryptów tekstowych do przeglądarki klienta.
Zawsze powtarzam chłopakom z naszego działu wsparcia, żeby wyłączali moduły, których nie używamy. Każdy aktywny dodatek to otwarte drzwi dla potencjalnego ataku z zewnątrz i kompletnie niepotrzebne zużycie pamięci operacyjnej RAM na serwerze matce.
Zarządzanie logami, czyli gdzie szukać błędów na czarnym ekranie
Większość tanich firm hostingowych daje nam graficzny panel typu cPanel lub DirectAdmin. Tam wyklikanie nowej domeny czy sprawdzenie błędu zajmuje kilkanaście sekund. My jednak robimy to ręcznie w konsoli. Kiedy strona klienta przestaje odpowiadać, nie dzwonimy po wsparcie. Wchodzimy do katalogu z logami systemowymi.
Kierujemy komendę tail -f /var/log/apache2/error.log. Ta komenda wyrzuca nam na żywo to, co serwer odnotowuje w tle.
Najgorsze są literówki w plikach konfiguracyjnych. Wpiszesz w ustawieniach ServerAlias zamiast prawidłowego ServerName i nagle cały ruch sieciowy trafia w próżnię. Szukasz błędu przez godzinę na środowisku deweloperskim. Zaglądasz w logi błędów. A tam PUSTKA. Brak jakichkolwiek wskazówek. Wtedy po prostu wiesz, że literówka siedzi głęboko w samej składni konfiguracyjnej, a serwer nie potrafi nawet wystartować, żeby zapisać błąd do pliku tekstowego.
Uprawnienia plików i błąd 403 Forbidden
Młodzi programiści nagminnie zapominają o uprawnieniach. Serwer Apache działa w systemach Linux zazwyczaj pod specjalnym, ograniczonym użytkownikiem o nazwie www-data. Jeśli wrzucisz pliki na serwer przez protokół FTP logując się jako główny administrator root, Apache nie będzie miał praw do ich fizycznego odczytu z dysku. Zobaczysz w przeglądarce wielki błąd 403 Forbidden oznaczający brak dostępu.
To stały punkt programu na każdym naszym poniedziałkowym wdrożeniu. Wystarczy wpisać z palca chown -R www-data:www-data /var/www/mojastrona, żeby nadać odpowiednie prawa własności. I problem natychmiast znika z radarów.
Rodzaje MPM: Prefork, Worker i Event
Tu wchodzimy w twardą mechanikę. Apache posiada coś, co nazywa się Multi-Processing Modules (MPM). To rdzeń decydujący o tym, w jaki sposób serwer zarządza połączeniami sieciowymi od ludzi wchodzących na stronę. Masz do wyboru trzy drogi konfiguracji.
- Prefork: Najstarszy, najbezpieczniejszy, ale najbardziej pamięciożerny tryb. Tworzy osobny, całkowicie niezależny proces w systemie operacyjnym dla każdego nowego gościa na stronie. Jeśli masz tysiąc wejść na sekundę, serwer odpala tysiąc procesów. Szybko zabija to wolny RAM maszyny. My używamy go już tylko tam, gdzie stare aplikacje PHP nie potrafią działać bezpiecznie w środowisku wielowątkowym.
- Worker: Lepsze podejście. Tworzy kilka głównych procesów, a każdy z nich generuje dziesiątki mniejszych wątków. Zjada znacznie mniej pamięci.
- Event: Nowoczesny standard wbudowany w nowsze wersje systemu. Utrzymuje połączenia przy życiu (KeepAlive) bez blokowania całego wątku roboczego dla jednego użytkownika. Przerzuca obciążenie asynchronicznie, zbliżając wydajność Apache do tego, co oferuje od lat konkurencyjny Nginx.
Gdy diagnozowaliśmy powolne działanie sklepu opartego o Magento w zeszłym kwartale, okazało się, że ktoś zostawił domyślny tryb Prefork na maszynie z zaledwie dwoma gigabajtami pamięci RAM. Zmiana jednej linijki w konfiguracji na tryb Event obniżyła zużycie zasobów o połowę. To pokazuje, że nawet stary soft potrafi działać szybko, o ile wiesz, które przełączniki w nim aktywować.
Dlaczego w 2024 roku nadal używamy tego oprogramowania?
Wielu młodych inżynierów z korporacji twierdzi głośno na konferencjach, że to relikt przeszłości. Zafascynowani nowymi technologiami chmurowymi i rozwiązaniami omijają klasyczne maszyny wirtualne szerokim łukiem. Statystyki rynkowe pokazują jednak coś zupełnie odmiennego. Ogromna część polskiego i światowego internetu to wciąż małe strony firmowe u lokalnych przedsiębiorców, blogi na WordPressie i proste sklepy z asortymentem na wtyczce WooCommerce.
Te małe biznesy nie potrzebują rozproszonej, skomplikowanej architektury na chmurze AWS za setki dolarów miesięcznie. Wymagają taniego, stabilnego serwera VPS za kilkadziesiąt złotych, który po prostu działa i pozwala na łatwą edycję reguł na FTP. Apache dostarcza dokładnie taką wartość rynkową.
Ma też inną, niepodważalną zaletę. Posiada gigantyczną społeczność zbudowaną przez ponad dwie dekady. Wpisujesz dowolny, nawet najbardziej egzotyczny kod błędu w okno wyszukiwarki i masz całkowitą pewność, że ktoś na forum rozwiązał ten sam problem dziesięć lat temu na innej szerokości geograficznej. To oszczędza nasz czas na diagnozę problemu w środku nocy u klienta z awarią na produkcji.
Najczęściej zadawane pytania (FAQ)
- Czy oprogramowanie Apache jest w pełni darmowe? Oprogramowanie to udostępniane jest na licencji open source przez fundację, co pozwala na jego bezpłatne używanie nawet w bardzo potężnych projektach komercyjnych bez ponoszenia opłat licencyjnych.
- Gdzie znajduje się główny plik konfiguracyjny serwera? W systemach z rodziny Debian i Ubuntu główny plik znajdziesz zazwyczaj w ścieżce /etc/apache2/apache2.conf. W systemach CentOS leży on pod adresem /etc/httpd/conf/httpd.conf.
- Jak uruchomić ponownie usługę po zmianie konfiguracji? Należy zalogować się do konsoli serwera przez protokół SSH i wydać polecenie systemctl restart apache2 lub service apache2 restart w zależności od używanej wersji systemu operacyjnego Linux.
- Czym jest plik .htaccess w katalogu strony? To ukryty plik tekstowy pozwalający nadpisać globalne reguły działania maszyny dla konkretnego folderu. Używamy go głównie do zmiany struktury linków oraz wymuszania szyfrowania SSL.
- Dlaczego serwer zwraca w przeglądarce błąd 403 Forbidden? Błąd ten oznacza brak uprawnień do odczytu danych z dysku twardego. Najczęściej występuje, gdy pliki strony zostały wgrane przez użytkownika root, a proces www-data nie ma do nich fizycznego dostępu.
- Czy Apache nadaje się pod system CMS WordPress? Zdecydowanie tak. Jest to natywne i najbardziej zalecane środowisko dla tego systemu CMS, oferujące pełną zgodność z wbudowanymi mechanizmami przepisywania adresów URL z pudełka.
Nie ma sensu czytać kolejnych poradników w sieci i analizować suchych tabel z wydajnością różnych rozwiązań rynkowych. Odpal własną maszynę wirtualną na komputerze domowym. Zainstaluj pakiet prosto z repozytorium. Zepsuj celowo konfigurację pliku .htaccess i spróbuj ją naprawić opierając się tylko i wyłącznie na surowych logach z konsoli. Dopiero wtedy zrozumiesz, jak fizycznie na najniższym poziomie działa ruch pakietów w internecie i czym naprawdę jest serwer Apache.
Źródła
1. Apache Software Foundation – https://apache.org
2. Ubuntu – https://ubuntu.com
3. Debian – https://www.debian.org
4. Stack Overflow – https://stackoverflow.com
5. GitHub – https://github.com
