Chlebik walks alone – deployment HowToJava

Zgodnie z zapowiedziami dorobiłem się w końcu własnej przestrzeni w necie. Do tego przestrzeni całkiem sympatycznej bo z własnym Jetty i paroma innymi rzeczami. Rzecz jasna trzeba było spróbować ponownie pokazać światu moje Grailsowe wypociny.

Samego procesu deploymentu do tej pory nie ruszałem. Lokalnie uruchamianie aplikacji odbywa się poprzez NetBeans, zapędów do konfiguracji serwerów/kontenerów też póki co nie mam. Jak wspomniałem również wcześniej – niedługo Helion wyda na podobne tematy książkę, zatem poczekam jeszcze trochę by zapoznać się z tematem dogłębniej. Jednakże by wrzucić coś na serwer docelowy z całą pewnością wypada skonfigurować dostęp do bazy danych. Oczywiście by to osiągnąć wypada wpisać odpowiednie dane dostępowe do DataSource.groovy.

Kiedy się z tym uporałem przyszedł czas na zbudowanie paczki dystrybucyjnej. W Grails jest to proste jak konstrukcja gwoździa. Wystarczy przejść do katalogu z aplikacją i wydać polecenie:

grails war

Pomieli, przemieli i ostatecznie w tymże katalogu wypluje nam paczkę (plik z rozszerzeniem *.WAR). Teraz ten plik (ja jego nazwę zmieniłem na howtojava.war, wyrzucając numerację wersji) należy wrzucić na serwer produkcyjny. Domyślnie Jetty wszystkie aplikacje próbuje odnaleźć w katalogu /webapps. Konwencja ta jest słuszna, zatem w tymże katalogu stworzyłem następny (o nazwie a jakże howtojava) i do niego wrzuciłem plik WAR. Teraz przyszedł czas na konfig serwera.

Należy zajrzeć do pliku jetty.xml, który rezyduje w podkatalogu /etc podstawowego folderu serwera. Możemy z góry określić wspólną konfigurację dla serwera (jak np. uruchamia się na nim jedną aplikację) – i to są ustawienia domyślne. Ja jednakże postanowiłem, iż dla każdej aplikacji (na razie jedna, ale może będzie i więcej) będę posiadał oddzielny plik konfiguracyjny. Wyedytowałem plik i dodałem takie oto zapisy:

<Call name="addLifeCycle">
<Arg>
<New class="org.mortbay.jetty.deployer.ContextDeployer">
<Set name="contexts"><Ref id="Contexts"/></Set>
<Set name="configurationDir"><SystemProperty name="jetty.home" default="."/>/contexts</Set>
<Set name="scanInterval">5</Set>
</New>
</Arg>
</Call>

W folderze z Jetty należy utworzyć wskazany katalog (/contexts). I następnie wrzucamy do niego pliczek o wdzięcznej nazwie Howtojava.xml. Wygląda on tak:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<configure class="org.mortbay.jetty.webapp.WebAppContext">
<Set name="contextPath">/howtojava</Set>
<Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/howtojava/howtojava.war</Set>
</configure>

Jednakże przy takiej konfiguracji, wejście na podstawową domenę powoduje brzydkie zgłoszenie błędu 404 i wylistowanie wszystkich dostępnych kontekstów. Dlatego tez dodałem jeszcze jeden plik w katalogu /contexts – default.xml. Oto on:


<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<configure class="org.mortbay.jetty.webapp.WebAppContext">
<Set name="contextPath">/</Set>
<Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/howtojava/howtojava.war</Set>
</configure>

Dzięki temu domyślnie wskazanie na domenę leci pod konkretny adres. Uruchomienie serwera to odpalenie pliku start.jar z odpowiednimi uprawnieniami. Mój jakże miły admin (choć nie wiem czy to on, czy po prostu lekko wyedytował defaultowe skrypty) dostarczył mi 2 pliczki, które opakowywują uruchamianie i zamykanie serwera: Start.sh:

#!/bin/sh

export port=$(expr $(cat base_port) + 0)

echo "Starting the Jetty process at port $port"

nohup java -Xmx$(cat ram_size)m -Drun.mode=production -Djetty.port=$port -jar -server start.jar etc/jetty.xml >> logs/std.out 2>> logs/err.out &
echo $! > prod.pid
echo "The PID is $!"

Nie jest to nic skomplikowanego. Obok tego pliku w katalogu leżą 2 inne pliki – jeden (base_port) zawiera informację o porcie, na którym ma być uruchomiony serwer, a drugi (ram_size) to wejściowa ilość RAMu dla serwera. Przypisany ID procesu jest zapisywany do pliku, a wyjście zarówno System.out, jak i strumień błędów są przekierowywane do odpowiednich katalogów. Drugi skrypt to po prostu odczytanie zapisanego ID procesu z pliku i zabicie tego procesu. Uwadze polecam również plik /bin/jetty-service.conf, gdzie można znaleźć kilka ciekawych zmiennych, którymi można się pobawić.

I tyle. Teraz wystarczy odwiedzić : pewien adres by zobaczyć jak śmiga HowToJava. Subdomena póki co mi nie chwyciła, ale jak załapie to z całą pewnością przepnę ją na nowy adres.

Gdyby ktoś był zainteresowany hostingiem dla aplikacji Grails i bardzo profesjonalną obsługą, wówczas wystarczy napisać mejla na adres admin@serenity.org.pl i ładnie poprosić o ofertę. Jako, że serwery cały czas są w fazie ‘beta’ (w sumie GMail też jest :), zatem szereg rzeczy jeszcze nie działa tak jak powinno, a części póki co nie ma. Ale ceny bardzo konkurencyjne, zaś z jakości usługi jestem póki co bardzo zadowolony.

Advertisements

3 thoughts on “Chlebik walks alone – deployment HowToJava

  1. chlebik Post author

    To dosc dziwne. Zapytalem jednego z ludzi stamtad na GG i czekam na odpowiedz. Jak cos moge mu dac Twojego mejla?

  2. chlebik Post author

    No juz sie dogadalem. Odpisze, konfig serwera poczty zawinil – jak mowilem, usluga jeszcze w fazie beta. Powodzonka zycze.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s