Blog » Analizy i porady

Konfiguracja serwera aplikacji w trybie standalone

Konfiguracja serwera aplikacji

W dzisiejszym artykule omówimy konfigurację serwera aplikacji EuroAP w trybie standalone. Zajrzymy do katalogu EuroAP_HOME/stanadalone oraz przeanalizujemy strukturę pliku konfiguracyjnego standalone.xml.

Zakładamy, że czytelnik zna podstawowe koncepcje serwera aplikacji EuroAP czy też JBoss EAP, takie jak moduły, rozszerzenia, profile. Jeśli nie, to zachęcamy do lektury naszego poprzedniego artykułu Konfiguracja serwera aplikacji – garść teorii.

EuroAP_HOME/standalone/

Pliki konfiguracyjne trybu standalone są w katalogu EuroAP_HOME/standalone/ Przyjrzyjmy się zawartości tego folderu:

configuration/ data/ deployments/ lib/ log/ tmp/

Mamy tu aż 6 folderów (jeżeli nie uruchamialiśmy wcześniej serwera w trybie standalone to nie będzie data oraz log).

Nazwa każdego z nich doskonale odzwierciedla jego przeznaczenie:

  • configuration – zawiera konfigurację EuroAP. Jego zawartości przyjrzymy się uważniej
  • data – folder udostępniany podsystemom do przechowywania treści w systemie plików. Wykorzystują go na przykład bazy danych w pamięci (in-memory database) czy systemy kolejkowania
  • deployments – tutaj znajdziemy gotowe do wdrożenia pliki JAR/EAR/WAR. EuroAP i pokrewne serwery aplikacji umożliwiają wdrażanie aplikacji przez ten folder, co z pewnością w przyszłości opiszemy na naszym blogu. Dziś wspomnimy tylko, że w takim przypadku możemy też znaleźć w tym katalogu specjalne znaczniki (markery) obrazujące status wdrożenia
  • lib – bywa używany do wdrażania wspólnych JAR-ów. Zaleca się wdrażanie ich jako moduły. Dlatego najlepiej, gdy ten folder pozostaje pusty
  • log – tu domyślnie lądują wszystkie logi. Gdy szukamy gc.log lub server.log (logi ze startu EuroAP), to prawdopodobnie tu je znajdziemy
  • tmp – zawiera pliki tymczasowe. Jest używany na przykład przez CLI do uwierzytelniania lokalnych użytkowników za pomocą mechanizmu współdzielonych kluczy.

EuroAP_HOME/standalone/configuration/

Gdy wylistujemy zawartość folderu configuration, naszym oczom ukaże się treść podobna do tej:

application-roles.properties  mgmt-users.properties   standalone-load-balancer.xml
application-users.properties  standalone-full-ha.xml  standalone.xml
logging.properties            standalone-full.xml     standalone_xml_history/
mgmt-groups.properties        standalone-ha.xml

Znów, jeśli jeszcze nie uruchamialiśmy serwera aplikacji, to nie zobaczymy katalogu standalone_xml_history/, ponieważ, jak nazwa wskazuje, zawiera on historię konfiguracji, a my jeszcze żadnych danych historycznych nie mamy.

Gdy wylistujemy ten folder, to zobaczymy:

current/   standalone.boot.xml     standalone.last.xml
snapshot/  standalone.initial.xml

Są to oczywiście historyczne pliki konfiguracyjne, którym przyjrzymy się bliżej w artykule poświęconym zarządzaniu historią konfiguracji.

Pliki: application-roles.properties, application-users.properties, mgmt-groups.properties czy mgmt-users.properties zawierają informacje wygenerowane przez skrypt EuroAP_HOME/bin/add-user.sh. Użycie tego skryptu zostało omówione w artykule Pierwszy raz z serwerem aplikacji EuroAP.

W pliku logging.properties znajdziemy ustawienia loggera. Jest to plik wygenerowany przez podsystem logujący i zostanie przez niego nadpisany, gdy tylko zdefiniujemy system logujący w plikach XML.

standalone.xml

W końcu dochodzimy do najważniejszych plików: standalone.xml, standalone-full-ha.xml ,standalone-full.xml, standalone-ha.xml, standalone-load-balancer.xml. Wszystkie te pliki opisują konfigurację EuroAP, lub pokrewnego serwera aplikacji, w trybie standalone. Domyślnie, gdy uruchamiamy serwer skryptem EuroAP_HOME/bin/standalone.sh, ładowany jest plik standalone.xml, który zawiera konfigurację domyślnego profilu EuroAP.

Jeśli chcemy załadować inny predefiniowany profil, należy w przełączniku --server config podać odpowiadający mu plik. Na przykład, aby uruchomić serwer z profilem full, należy wpisać polecenie:

$ EuroAP_HOME/bin/standalone.sh --server-config=standalone-full.xml

Struktura standalone.xml

Plik standalone.xml ma następującą strukturę:

<server xmlns="urn:jboss:domain:11.0">
    <extensions...>
    <management...>
    <profile...>
    <interfaces...>
    <socket-binding-group...>
</server>

Najpierw mamy zdefiniowane rozszerzenia extensions, z których możemy korzystać w danej konfiguracji.

Zdefiniowanie rozszerzenia do logowania wygląda tak:

<extensions>
    ...
    <extension module="org.jboss.as.logging"/>
    ...
</extensions>

Następnie mamy element management, który zasługuje na osobny wpis. Teraz tylko nadmienimy, że definiuje on obszary zabezpieczeń (ang. security realms) dla użytkowników – sposoby ich uwierzytelnienia i autoryzacji, logowanie audytowe (domyślnie wyłączone), interfejsy zarządzania czy kontrolę dostępu.

<management>
    <security-realms..>
    <audit-log...>
    <management-interfaces...>
    <access-control...>
</management>

Kolejnym elementem jest profil, który składa się z elementów subsystem. Jak już wiemy z poprzedniego artykułu, podsystemy to konfiguracja rozszerzeń (zdefiniowanych w elemencie extensions). Każde rozszerzenie ma swój własny model zarządzania, więc parametry każdego podsystemu będą wyglądały inaczej. Dla podsystemu logowania może na przykład wyglądać tak:

<profile>
    ...
    <subsystem xmlns="urn:jboss:domain:logging:8.0">
            <console-handler name="CONSOLE">
                <level name="INFO"/>
                <formatter>
                    <named-formatter name="COLOR-PATTERN"/>
                </formatter>
            </console-handler>
            <root-logger>
                <level name="INFO"/>
                <handlers>
                    <handler name="CONSOLE"/>
                    <handler name="FILE"/>
                </handlers>
            </root-logger>
            <formatter name="COLOR-PATTERN">
                <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
            </formatter>
    </subsystem>
    ...
</profile>

Zostały już tylko dwa elementy: interfaces i socket-binding-group. Służą one do sterowania ustawieniami sieci i portów. Są na tyle ciekawym i obszernym tematem, że ich szczegółowemu objaśnieniu poświęcimy osobny materiał.

Wiemy już, jak wygląda plik standalone.xml. Pozostałe pliki zawierające konfiguracje prekonfigurowanych profili mają taką samą strukturę. Różnią się ustawieniami przede wszystkim rozszerzeń i podsystemów.

W tym artykule omówiliśmy strukturę katalogu EuroAP_HOME/standalone. Wyjaśniliśmy, jakie pliki zawiera i do czego one służą. Przeanalizowaliśmy także strukturę pliku konfiguracyjnego standalone.xml.

Niebawem kolejne wpisy poświęcone innym aspektom konfiguracji i zarządzania EuroAP. Zapraszamy.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *