Konfiguracja serwera aplikacji – garść teorii

Jak pokazaliśmy w artykule „Pierwszy raz z serwerem aplikacji EuroAP”, rozpoczęcie przygody z EuroAP jest bardzo proste. Ponieważ w kolejnych artykułach chcemy pokazać, jak konfigurować serwery aplikacji z rodziny EuroAP – dziś skupimy się na tym, co w ogóle będziemy konfigurować. Omówimy tryby pracy, profile i elementy je tworzące. Zatem zapraszam na garść teorii.

Na wstępie zaznaczę, iż serwer aplikacji EuroAP powstaje z kodu źródłowego JBoss^® EAP i w związku z tym ma takie same funkcjonalności. Poradnik ten znajdzie więc zastosowanie także w przypadku użytkowników JBoss^®.

Konfiguracja EuroAP przechowywana jest w plikach xml w folderze EuroAP_HOME/standalone/configuration lub EuroAP_HOME/domain/configuration w zależności od trybu pracy.

Serwer aplikacji możemy konfigurować, edytując pliki konfiguracyjne (niezalecane), używając CLI lub graficznej konsoli administratora. Zmiany wprowadzone w CLI i graficznej konsoli są natychmiast odzwierciedlane w plikach konfiguracyjnych i od razu są widoczne w tych narzędziach z dokładnością do cache’u przeglądarki ;-) Graficzna konsola administratora jest webową aplikacją, dlatego, jeśli nie widzimy w niej zmian wprowadzonych przez CLI, warto wyczyścić cache przeglądarki.

Nie zaleca się bezpośredniego edytowania plików, ponieważ nic nie sprawdza od razu poprawności konfiguracji np. tego, czy nie popełniliśmy literówki albo, czy użyte elementy mogą pojawić się w danym miejscu. O błędzie dowiemy się, dopiero gdy serwer nie będzie w stanie przeładować konfiguracji lub nie będzie w stanie wystartować. Ponadto narażamy się na nadpisanie naszych zmian przez osoby edytujące konfigurację przez CLI albo graficzną konsolę.

Tryby pracy serwera aplikacji – standalone server i managed domain

Serwery aplikacji z rodziny EuroAP mają dwa tryby pracy: standalone server – serwer wolnostojący i managed domain – zarządzana domena. Jedyną różnicą między nimi jest to, że domeną jesteśmy w stanie sterować w sposób scentralizowany. Z jednego miejsca, zwanym kontrolerem domeny (ang. domain controller), możemy zmieniać konfigurację wielu serwerów jednocześnie. Możemy wdrażać serwery EuroAP na wiele maszyn z jednej, centralnej lokalizacji.

Obydwa tryby pracy mają takie same możliwości, jeśli chodzi o dostępne podsystemy, budowanie klastrów czy też równoważenie ruchu. Można, bo kto bogatemu zabroni, zrobić domenę, używając jedynie trybu standalone. Jednak będziemy musieli siłować się z konfliktami portów czy też synchronizacją powtarzających się plików między różnymi serwerami.

Klocki budujące EuroAP

Elastyczność często uzyskuje się dzięki wielu malutkim, dobrze wyizolowanym klockom, które z łatwością można łączyć w większe całości. Łatwo nimi bowiem manipulować. W EuroAP i pokrewnych serwerach aplikacyjnych (np. JBoss^®), malutkie klocuszki to moduły, a łatwe do manipulowania większe całości to profile. Omówimy to dokładniej, stosując podejście od dołu do góry.

Moduły

Cały kod wewnątrz EuroAP jest uruchamiany jako moduł. Dotyczy to zarówno kodu tworzącego trzon EuroAP, jak i kodu uruchamianych na nim aplikacji. Każdy moduł jest ładowany przez odosobniony classloader i widzi inne klasy tylko i wyłącznie wtedy, gdy jawnie tego zażąda. Dzięki temu w EuroAP mamy drobnoziarnistą kontrolę widoczności kodu.

Wszystkie moduły powinny znajdować się w EuroAP_HOME/modules. W folderze EuroAP_HOME/modules/system/layers/base mieszczą się wszystkie moduły dostępne w EuroAP w momencie instalacji. W katalogu EuroAP_HOME/modules/layers znajdziemy moduły dodawane do serwera aplikacji przez inne produkty. Jeśli lokalny administrator dodaje moduły, to zwyczajowo tworzy je wewnątrz folderu EuroAP_HOME/modules. Wewnątrz tych folderów nazwa modułu jest używana do stworzenia drzewa katalogów. Na przykład dla modułu o nazwie org.apache.commons.lang3 zostanie utworzone drzewo org/apache/commons/lang3/.

Rozszerzenia (extensions)

Każdy moduł, który dostarcza EuroAP jakąś funkcję bądź zdolność nazywamy rozszerzeniem. Rozszerzenia, poza kodem modułu, dostarczają także model zarządzania, czyli podsystem. Każde rozszerzenie ma co najmniej jeden podsystem. To, że dodamy rozszerzenie do pliku konfiguracyjnego, nie oznacza, że serwer aplikacji je załaduje i uaktywni. EuroAP unika narzutu na moduły, które nie są niezbędne. Zostaną załadowane, dopiero gdy zostanie wdrożona aplikacja, która ich potrzebuje. Dodanie rozszerzenia do pliku konfiguracyjnego sprawia za to, że do pamięci ładowany jest jego model zarządzania i możemy go konfigurować przez CLI albo graficzną konsolę administratora.

W standloane.xml znajdziemy między innymi takie rozszerzenia:

<extension moduleRaw="org.wildfly.extension.request-controller"/> 
<extension moduleRaw="org.wildfly.extension.undertow"/>

Podsystemy (subsystems)

Podsystem (subsystem) to model zarządzania rozszerzeniem. Gdy dodajemy rozszerzenie do konfiguracji EuroAP, automatycznie powstaje element subsystem w pliku konfiguracyjnym. Każde rozszerzenie ma co najmniej jeden podsystem. Inaczej mówiąc, rozszerzenie musi zostać skonfigurowane. Możemy też jedno rozszerzenie skonfigurować na kilka sposobów. Wówczas powiemy, że rozszerzenie ma kilka podsystemów. Nawet jeśli nie mamy nic szczególnego do skonfigurowania, rozszerzenie musi mieć podsystem. Po prostu element subsystem będzie pusty. Każdy podsystem posiada swoją osobistą schemę XML-ową (XML Schema Definition). Oznacza to, że elementy pojawiające się w ramach konfiguracji podsystemu są unikatowe dla danego podsystemu. Schemy są dostępne w EuroAP_HOME/docs/schema .

W standloane.xml znajdziemy takie podsystemy dla pokazanych wcześniej rozszerzeń:

 <subsystem xmlns="urn:jboss:domain:request-controller:1.0"/>
 <subsystem xmlns="urn:jboss:domain:undertow:7.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
             <buffer-cache name="default"/>
             <server name="default-server">
                 <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
                 <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
                 <host name="default-host" alias="localhost">
                     <location name="/" handler="welcome-content"/>
                     <http-invoker security-realm="ApplicationRealm"/>
                 </host>
             </server>
             <servlet-container name="default">
                 <jsp-config/>
                 <websockets/>
             </servlet-container>
             <handlers>
                 <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
             </handlers>
 </subsystem>

Profile

Wreszcie doszliśmy do „łatwych w manipulacji większych całości” – profili. Profil to po prostu kolekcja podsystemów. W plikach konfiguracyjnych element profile zawiera tylko i wyłącznie elementy subsystem.Celem profili jest dopasowanie serwera aplikacji do konkretnej aplikacji i jej środowiska. Profile można tworzyć od zera lub edytować już istniejące. EuroAP umożliwia także dziedziczenie profili. Dzięki temu minimalizujemy powielanie konfiguracji między różnymi profilami. Każde uruchomione EuroAP ma swoją konfigurację – wie, jakie podsystemy ma załadować od razu, jakie może załadować i uaktywnić, jeśli wdrożona aplikacja tego zażąda. Mówiąc fachowo, każda instancja serwera aplikacji posiada jeden profil.

W trybie standalone server zawsze mamy jedną instancję serwera aplikacji, a co za tym idzie, tylko jeden profil. Nie potrzebujemy dla niego nazwy, ponieważ określenie „profil” jest jednoznaczne. W trybie managed domain mamy wiele instancji EuroAP, a każda z nich może mieć inny profil. Aby móc przypisywać instancjom konkretne profile, musimy móc się do nich odnieść – nazwać je. Dlatego profile w domenie określa się mianem „nazwane”, a w trybie standalone „anonimowe”.

Predefiniowane profile

EuroAP posiada 5 predefiniowanych profili, które uwzględniają większość typowych zastosowań. Możemy z nich usuwać nieużywane podsystemy. Jednak z punktu widzenia wydajności serwera aplikacji nie jest to konieczne, ponieważ nieużywane podsystemy i tak nie są ładowane.

W trybie standalone konfiguracje odpowiednich profili są w osobnych plikach w folderze EuroAP_HOME/standalone/configuration/:

standalone-full.xml
standalone-load-balancer.xml  
standalone-full-ha.xml
standalone-ha.xml 
standalone.xml

Zaś w trybie managed domain definicje wszystkich profili są w pliku EuroAP_HOME/domain/configuration/domain.xml.

Dostępne profile to:

default – zawiera wszystkie najczęściej używane podsystemy
ha – default + podsystemy umożliwiające wysoką dostępność (high availability) – jgroups i modcluster
full – default + podsystemy umożliwiające messaging – messaging-activemq and iiop-openjdk
full-ha default + ha + full = wszystkie możliwe podsystemy
load-balancer – tylko i wyłącznie podsystemy konieczne do równoważenia obciążenia pomiędzy instancjami EuroAP przy użyciu wbudowanego load balancera (mod_cluster).

Podsumowanie

W tym artykule przedstawiliśmy informacje niezbędne do zrozumienia konfiguracji serwerów aplikacji z rodziny EuroAP. Mamy nadzieję, że zdobyta wiedza zaowocuje podczas czytania kolejnego materiału o konfiguracji serwera aplikacji EuroAP w trybie standalone. Do zobaczenia niebawem.