Co to jest Apache Tomcat i do czego służy? Wprowadzenie dla programistów Java

Apache Tomcat to otwartoźródłowy kontener serwletów i serwer WWW służący do uruchamiania aplikacji internetowych napisanych w języku Java. Środowisko to przetwarza kod oparty na specyfikacjach Jakarta EE na dynamiczne strony i odpowiedzi HTTP trafiające wprost do przeglądarek użytkowników.

To rynkowy standard. Narzędzie, które zna niemal każdy programista zaplecza. Prawda jest zresztą absolutnie taka, że większość z nas zaczynała swoją przygodę z backendem właśnie od wrzucenia pierwszego pliku archiwum do folderu na dysku.

Apache Tomcat nie ma wbudowanej obsługi pełnego stosu technologii biznesowych. Brakuje mu zaawansowanych mechanizmów do zarządzania rozproszonymi transakcjami z pudełka. I właśnie dlatego wygrał rynek. Programiści potrzebowali czegoś lekkiego, co po prostu uruchomi ich kod bez godzinnego procesu startu maszyny wirtualnej.

Dlaczego programiści Java wybierają Apache Tomcat zamiast pełnych serwerów aplikacji?

Wybór między lekkim kontenerem a potężną maszyną wdrożeniową to od lat główny dylemat architektów. Pełne serwery Java EE, takie jak GlassFish czy WildFly, oferują dziesiątki wbudowanych specyfikacji. Mają wszystko. Problem polega na tym, że w nowoczesnym wytwarzaniu oprogramowania używamy zaledwie ułamka tych funkcji. Tomcat daje wyłącznie to, co niezbędne do obsługi żądań sieciowych. To przepaść.

Zmieniliśmy te zasady na robocie lata temu. Kiedyś pakowało się logikę w ciężkie komponenty EJB. Dzisiaj większość zespołów pisze lekkie usługi REST API oparte na frameworku Spring Boot. A Spring Boot domyślnie pakuje właśnie instancję Tomcata do środka wygenerowanego pliku wykonywalnego. Zamiast instalować serwer na maszynie i wrzucać do niego aplikację, uruchamiasz aplikację, która sama podnosi swój własny, wbudowany serwer. Zmienia to całkowicie proces wdrażania kodu na produkcję.

Jakie są główne różnice między kontenerem serwletów a serwerem Java EE?

Musisz zrozumieć twardy podział ról w ekosystemie Javy. Kontener serwletów zajmuje się cyklem życia obiektów obsługujących ruch sieciowy. Tłumaczy surowy tekst z protokołu HTTP na obiekty Javy, które twój kod potrafi przeczytać. Serwer aplikacji robi to samo, ale dorzuca do tego obsługę kolejek wiadomości, wbudowane pule połączeń do starych systemów bazodanowych i mechanizmy wstrzykiwania zależności zgodne ze starymi standardami korporacyjnymi.

• Tomcat zużywa ułamek pamięci RAM w porównaniu do pełnoprawnych serwerów. Odpalasz go na maszynie z 512 MB pamięci i działa.
• Pełne serwery wymagają długiego strojenia konfiguracji XML, żeby w ogóle przepuścić pierwszy pakiet danych z zewnątrz.
• Kontenery skupiają się na jednym zadaniu. Przekazują żądanie, czekają na odpowiedź, zamykają wątek.
• Czas startu Tomcata liczymy w milisekundach. Czas startu starego WebSphere liczono w minutach.

Jak działa architektura Apache Tomcat pod spodem?

System składa się z kilku oddzielnych modułów, które rozmawiają ze sobą w pamięci operacyjnej. Główne tryby działania opierają się na nasłuchiwaniu na określonym porcie sieciowym, zazwyczaj 8080, i delegowaniu pracy do odpowiednich klas roboczych.

Prawda o pracy z serwerami aplikacji wygląda zazwyczaj prozaicznie. Siedzisz w biurze o trzeciej nad ranem, terminal wypluwa niekończące się linie zrzutów stosu z pliku catalina.out, a ty zastanawiasz się, kto wpadł na pomysł, by ładować do pamięci całą bazę słowników przy starcie kontekstu. Zrobiliśmy na wdrożeniu szybki zrzut pamięci, potem zawiesiło się narzędzie do analizy, więc wprowadzono poprawkę na sztywno przed poniedziałkiem. To u nas w sumie chyba hipoteza z wczoraj, bo pewności do tych wycieków nikt obecnie nie ma o 2025 r. W środowiskach rozproszonych brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jednym z możliwych scenariuszy na najbliższy kwartał przed spowolnieniem rynku.

Co dokładnie robi komponent Catalina?

Catalina to serce systemu. To właściwy kontener serwletów. Kiedy piszesz klasę dziedziczącą po HttpServlet, to właśnie Catalina decyduje, kiedy stworzyć jej instancję i kiedy wywołać metodę doGet lub doPost. Catalina czyta plik konfiguracyjny server.xml, buduje strukturę obiektów reprezentujących wirtualne hosty i konteksty aplikacji.

Każda aplikacja wdrożona na serwerze ma swój odrębny kontekst. Catalina izoluje te konteksty od siebie. Błąd w jednej aplikacji nie powinien ubić całego serwera. Choć w praktyce, jeśli wyczerpiesz stertę pamięci Javy, cały proces systemowy idzie na dno.

Za co odpowiada silnik Coyote w przetwarzaniu żądań HTTP?

Coyote to konektor. Element nasłuchujący na gnieździe TCP/IP. Jego jedynym zadaniem jest odebranie ciągu bajtów z karty sieciowej, rozpoznanie w nich nagłówków HTTP i przekazanie tego urobku do Cataliny. Coyote obsługuje protokół HTTP/1.1, a w nowszych wersjach również HTTP/2.

Jak zainstalować i skonfigurować środowisko Tomcat na lokalnej maszynie?

Nie potrzebujesz instalatorów z interfejsem graficznym. Cały proces sprowadza się do pobrania archiwum i ustawienia kilku zmiennych w systemie operacyjnym. Zakładam, że masz już zainstalowane środowisko Java Development Kit (JDK).

Pobierasz plik ZIP z oficjalnej strony fundacji Apache. Rozpakowujesz go w katalogu docelowym na dysku C lub w swoim katalogu domowym na Linuksie. Następnie musisz poinformować system, gdzie leży Java. Robisz to dodając zmienną JAVA_HOME wskazującą na główny folder JDK.

Wchodzisz do podkatalogu bin. Znajdziesz tam skrypty startowe. Na systemach Windows klikasz dwukrotnie startup.bat. Na Linuksie i macOS odpalasz w terminalu ./startup.sh. Konsola wypluje kilkanaście linijek tekstu. Na samym końcu zobaczysz informację o czasie uruchomienia serwera. Wpisujesz w przeglądarce http://localhost:8080 i widzisz domyślną stronę powitalną. Działa.

W jaki sposób wdrażać pliki WAR na serwerze Tomcat?

Skompilowana aplikacja webowa w Javie przyjmuje formę pliku z rozszerzeniem WAR (Web Application Archive). To zwykłe archiwum ZIP ze zmienioną nazwą, zawierające z góry określoną strukturę katalogów, w tym słynny folder WEB-INF.

Najprostsza metoda wdrożenia polega na skopiowaniu pliku WAR do katalogu webapps wewnątrz głównego folderu instalacyjnego Tomcata. Serwer ma wbudowany mechanizm automatycznego wdrażania. Domyślnie co kilka sekund skanuje ten katalog. Gdy zauważy nowy plik, rozpakowuje go, tworzy nowy kontekst w pamięci Cataliny i uruchamia aplikację. Jeśli nazwiesz plik sklep.war, twoja aplikacja będzie dostępna pod adresem localhost:8080/sklep.

Kiedy używać menedżera aplikacji, a kiedy wrzucać pliki ręcznie?

Tomcat dostarcza wbudowaną aplikację o nazwie Manager. Pozwala ona na zdalne wgrywanie plików WAR przez przeglądarkę lub za pomocą żądań HTTP z narzędzi budujących, takich jak Maven czy Gradle. Używamy tego na środowiskach testowych. Narzędzie CI/CD kompiluje kod, buduje archiwum i wypycha je bezpośrednio do menedżera.

Na środowiskach produkcyjnych nikt nie klika w interfejsie przeglądarki. Wyłączamy aplikację Manager ze względów bezpieczeństwa. Wdrożenie produkcyjne to proces automatyczny, w którym skrypty podmieniają pliki na dysku, czyszczą katalogi robocze i wykonują twardy restart usługi systemowej z poziomu demona systemd. Ręczne wrzucanie plików zostawiamy sobie na lokalne biurko dewelopera.

Najczęstsze problemy z pamięcią w Tomcat i metody ich rozwiązywania

Zarządzanie pamięcią w maszynie wirtualnej Javy to temat rzeka, ale w kontekście serwerów webowych najczęściej uderzamy w ścianę o nazwie java.lang.OutOfMemoryError. Błąd ten paraliżuje działanie aplikacji. Serwer przestaje odpowiadać na nowe żądania. Proces systemowy nadal wisi w pamięci operacyjnej systemu Linux, ale użytkownicy widzą tylko błędy przekroczenia czasu oczekiwania.

Pamiętam wdrożenie systemu dla lokalnej firmy spedycyjnej na obrzeżach miasta. Serwer stawał dęba równo co cztery godziny. Zespół obwiniał bazę danych. Prawda wyszła na jaw po analizie zrzutów pamięci. Jeden z programistów używał statycznych map do przechowywania sesji użytkowników zamiast wbudowanych mechanizmów serwletów. Z każdym nowym logowaniem mapa rosła o kilka megabajtów. Garbage Collector Javy nie mógł posprzątać tych obiektów, bo trzymała je twarda referencja z klasy statycznej. System po prostu dusił się własnymi danymi.

Drugim częstym problemem jest wyczerpanie puli wątków. Tomcat domyślnie tworzy maksymalnie 200 wątków roboczych w komponencie Coyote. Jeśli twoja aplikacja wykonuje powolne zapytania do bazy danych trwające po kilka sekund, wątki te zostają zablokowane. Kiedy nadejdzie 201. użytkownik, jego żądanie trafi do kolejki. Kiedy kolejka się zapełni, serwer zacznie odrzucać połączenia sieciowe. W takich sytuacjach należy zwiększyć parametr maxThreads w pliku server.xml, ale wymaga to jednoczesnego podniesienia limitów otwartych deskryptorów plików w systemie operacyjnym.

• Nigdy nie zostawiaj domyślnych parametrów sterty (Heap) na produkcji. Zawsze definiuj -Xms i -Xmx na takie same wartości, żeby uniknąć narzutu na ciągłe rozszerzanie pamięci.
• Obserwuj logi pod kątem ostrzeżeń o wyciekach pamięci przy przeładowywaniu kontekstu. Tomcat potrafi wykryć, że aplikacja nie zamknęła wątków tła przy wyłączaniu.

Czy Tomcat nadaje się do produkcji w dużych projektach biznesowych?

Zdecydowanie tak. Istnieje mit, że Tomcat to zabawka deweloperska. Tymczasem potężna część ruchu w sieci opiera się o to środowisko. Kluczem nie jest sam kontener, lecz architektura, w jakiej go osadzisz.

Nikt nie wystawia gołego Tomcata na port 80 do publicznego internetu. W architekturach produkcyjnych zawsze stawiamy przed nim serwer pośredniczący, tzw. reverse proxy. Zazwyczaj jest to Nginx lub Apache HTTP Server. Nginx przejmuje na siebie zarządzanie certyfikatami SSL, blokuje ataki DDoS i serwuje pliki statyczne, takie jak obrazy czy arkusze stylów. Tomcat siedzi bezpiecznie w sieci wewnętrznej i zajmuje się wyłącznie mieleniem logiki biznesowej w Javie.

Gdy obciążenie rośnie, po prostu dodajesz kolejne maszyny z Tomcatem, a Nginx rozrzuca między nie ruch metodą round-robin. To proste, brutalne i niesamowicie skuteczne podejście. Nie potrzebujesz skomplikowanych klastrów Java EE replikujących sesje. Aplikacje projektuje się jako bezstanowe, więc każde żądanie może trafić do innej instancji serwera. Zmieniliśmy u nas w firmie infrastrukturę na ten model w zeszłym roku i liczba awarii spadła drastycznie.

Zostaw ten artykuł. Odpal terminal, pobierz archiwum, napisz krótki serwlet wypisujący „Hello World” i samodzielnie rzuć okiem, jak ten serwer przetwarza żądania na żywo u ciebie na dysku.

Często zadawane pytania (FAQ)

• Co to jest Apache Tomcat?
  Apache Tomcat to kontener serwletów i serwer WWW typu open-source, który przetwarza kod napisany w języku Java (technologie Servlet, JSP) na strony internetowe i odpowiedzi HTTP.
• Czy Tomcat to serwer aplikacji?
  Nie w pełnym tego słowa znaczeniu. Tomcat to kontener webowy. Nie posiada wbudowanej obsługi pełnego stosu Jakarta EE, co czyni go lżejszym od pełnych serwerów.
• Na jakim porcie domyślnie działa Tomcat?
  Domyślnym portem nasłuchiwania dla połączeń HTTP jest port 8080. Ustawienie to modyfikuje się w pliku server.xml.
• Czym jest plik WAR?
  Plik WAR to skompresowane archiwum zawierające skompilowany kod Javy, biblioteki zewnętrzne oraz strukturę katalogów aplikacji webowej.
• Gdzie Tomcat przechowuje logi z błędami?
  Wszelkie zrzuty błędów i informacje diagnostyczne trafiają do folderu logs, głównie do pliku tekstowego catalina.out.
• Czy Spring Boot używa Tomcata?
  Tak, Spring Boot domyślnie pakuje instancję tego serwera prosto do pliku wynikowego JAR.

Źródła i bibliografia

1. Apache Software Foundation – https://apache.org
2. Oracle Java Documentation – https://oracle.com
3. Eclipse Foundation (Jakarta EE) – https://eclipse.org
4. Spring Framework – https://spring.io
5. Baeldung Java Tutorials – https://baeldung.com