Aplikacja Spring Boot jako usługa

Poniżej przedstawiamy najprostszy sposób instalacji aplikacji Java jako usługi systemowej w Linuksie.

Załóżmy, że używasz systemd (co robi obecnie każda nowoczesna Dystrybucja):

Najpierw Utwórz plik serwisowy w /etc/systemd/system o nazwie np. javaservice.service o treści:

[Unit]
Description=Java Service

[Service]
User=nobody
# The configuration file application.properties should be here:
WorkingDirectory=/data 
ExecStart=/usr/bin/java -Xmx256m -jar application.jar
SuccessExitStatus=143
TimeoutStopSec=10
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Po Drugie, powiadom systemd o nowym pliku serwisowym:

systemctl daemon-reload

I włączyć go, więc działa na boot:

systemctl enable javaservice.service

W końcu możesz użyć następujących poleceń, aby uruchomić / zatrzymać nowy serwis:

systemctl start javaservice
systemctl stop javaservice
systemctl restart javaservice
systemctl status javaservice

Pod warunkiem, że używasz systemd, jest to najbardziej nieinwazyjny i czysty sposób na skonfigurowanie aplikacji Java jako usługi systemowej.

To, co szczególnie podoba mi się w tym rozwiązaniu, to fakt, że nie trzeba instalować i konfigurować żadnego innego oprogramowania. Wysłane systemd wykonuje całą pracę za Ciebie, a Twoja usługa zachowuje się jak każda inna usługa systemowa. Używam go od jakiegoś czasu w produkcji, na różnych dystrybucjach, i działa tak jak ty spodziewaj się.

Kolejnym plusem jest to, że używając /usr/bin/java, możesz łatwo dodać jvm paramtery, takie jak -Xmx256m.

Przeczytaj również systemd część oficjalnej dokumentacji wiosennego rozruchu: http://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html

Możesz również użyćsupervisord , który jest bardzo poręcznym demonem, który może być używany do łatwego kontrolowania usług. Usługi te są definiowane przez proste pliki konfiguracyjne określające, co wykonać z jakim użytkownikiem, w którym katalogu i tak dalej, istnieje milion opcji. supervisord ma bardzo prostą składnię, więc jest bardzo dobrą alternatywą dla pisania skryptów sysv init.

Tutaj prosty plik konfiguracyjny dla programu, który próbujesz do uruchomienia / kontroli. (włóż to do /etc / supervisor / conf.d / yourapp.conf)

/etc / supervisor / conf.d / yourapp.conf

[program:yourapp]
command=/usr/bin/java -jar /path/to/application.jar
user=usertorun
autostart=true
autorestart=true
startsecs=10
startretries=3
stdout_logfile=/var/log/yourapp-stdout.log
stderr_logfile=/var/log/yourapp-stderr.log

Aby sterować aplikacją, musisz wykonać supervisorctl , który wyświetli Ci monit, w którym możesz uruchomić, zatrzymać, status.

CLI

# sudo supervisorctl
yourapp             RUNNING   pid 123123, uptime 1 day, 15:00:00
supervisor> stop yourapp
supervisor> start yourapp

Jeśli Demon supervisord jest już uruchomiony i dodałeś konfigurację dla swojego serwisu bez ponownego uruchamiania demona, możesz po prostu zrobić reread i update polecenie w powłoce supervisorctl.

To naprawdę daje Ci wszystkie flexibilites, które masz za pomocą skryptów Init SysV, ale łatwy w użyciu i kontroli. Zapoznaj się z dokumentacją .

Właśnie zacząłem to robić sam, więc poniżej jest miejsce, w którym jestem do tej pory pod względem CentOS init.skrypt kontrolera usługi D. Jak na razie działa całkiem nieźle, ale nie jestem hakerem leet Bash, więc jestem pewien, że jest miejsce na poprawę, więc przemyślenia nad poprawą są mile widziane.

Po pierwsze, dla każdej usługi mam krótki skrypt konfiguracyjny /data/svcmgmt/conf/my-spring-boot-api.sh, który ustawia zmienne środowiskowe.

#!/bin/bash
export JAVA_HOME=/opt/jdk1.8.0_05/jre
export APP_HOME=/data/apps/my-spring-boot-api
export APP_NAME=my-spring-boot-api
export APP_PORT=40001

Używam CentOS, więc aby upewnić się, że moje usługi są uruchamiane po serwerze restart, mam skrypt service control w /etc/init.d/my-spring-boot-api:

#!/bin/bash
# description: my-spring-boot-api start stop restart
# processname: my-spring-boot-api
# chkconfig: 234 20 80

. /data/svcmgmt/conf/my-spring-boot-api.sh

/data/svcmgmt/bin/spring-boot-service.sh $1

exit 0

Jak widać, wywołuje początkowy skrypt konfiguracyjny, aby skonfigurować zmienne środowiskowe, a następnie wywołuje współdzielony skrypt, którego używam do ponownego uruchomienia wszystkich moich usług Spring Boot. Ten współdzielony skrypt jest miejscem, w którym można znaleźć mięso tego wszystkiego:

#!/bin/bash

echo "Service [$APP_NAME] - [$1]"

echo "    JAVA_HOME=$JAVA_HOME"
echo "    APP_HOME=$APP_HOME"
echo "    APP_NAME=$APP_NAME"
echo "    APP_PORT=$APP_PORT"

function start {
    if pkill -0 -f $APP_NAME.jar > /dev/null 2>&1
    then
        echo "Service [$APP_NAME] is already running. Ignoring startup request."
        exit 1
    fi
    echo "Starting application..."
    nohup $JAVA_HOME/bin/java -jar $APP_HOME/$APP_NAME.jar \
        --spring.config.location=file:$APP_HOME/config/   \
        < /dev/null > $APP_HOME/logs/app.log 2>&1 &
}

function stop {
    if ! pkill -0 -f $APP_NAME.jar > /dev/null 2>&1
    then
        echo "Service [$APP_NAME] is not running. Ignoring shutdown request."
        exit 1
    fi

    # First, we will try to trigger a controlled shutdown using 
    # spring-boot-actuator
    curl -X POST http://localhost:$APP_PORT/shutdown < /dev/null > /dev/null 2>&1

    # Wait until the server process has shut down
    attempts=0
    while pkill -0 -f $APP_NAME.jar > /dev/null 2>&1
    do
        attempts=$[$attempts + 1]
        if [ $attempts -gt 5 ]
        then
            # We have waited too long. Kill it.
            pkill -f $APP_NAME.jar > /dev/null 2>&1
        fi
        sleep 1s
    done
}

case $1 in
start)
    start
;;
stop)
    stop
;;
restart)
    stop
    start
;;
esac
exit 0

Skrypt zakłada również, że proces java uruchamiający aplikację będzie jedynym z "my-spring-boot-api.jar " w tekście szczegółów procesu. Jest to bezpieczne założenie w moim środowisku i oznacza, że nie muszę śledzić PID.

Jeśli chcesz użyć Spring Boot 1.2.5 z wtyczką Spring Boot Maven 1.3.0.M2, oto rozwiązanie:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.2.5.RELEASE</version>
</parent>

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>1.3.0.M2</version>
            <configuration>
                <executable>true</executable>
            </configuration>
        </plugin>
    </plugins>
</build>

<pluginRepositories>
    <pluginRepository>
        <id>spring-libs-milestones</id>
        <url>http://repo.spring.io/libs-milestone</url>
    </pluginRepository> 
</pluginRepositories>

Następnie skompiluj jako ususal: mvn clean package, Utwórz dowiązanie symboliczne ln -s /.../myapp.jar /etc/init.d/myapp, wykonywalny chmod +x /etc/init.d/myapp i uruchom go service myapp start (z Ubuntu Server)

Wiem, że to starsze pytanie, ale chciałem przedstawić jeszcze inny sposób, który jest appassembler-Maven-plugin . Oto odpowiednia część z mojego POM, która zawiera wiele dodatkowych wartości opcji, które uznaliśmy za przydatne:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>appassembler-maven-plugin</artifactId>
    <configuration>
        <generateRepository>true</generateRepository>
        <repositoryLayout>flat</repositoryLayout>
        <useWildcardClassPath>true</useWildcardClassPath>
        <includeConfigurationDirectoryInClasspath>true</includeConfigurationDirectoryInClasspath>
        <configurationDirectory>config</configurationDirectory>
        <target>${project.build.directory}</target>
        <daemons>
            <daemon>
                <id>${installer-target}</id>
                <mainClass>${mainClass}</mainClass>
                <commandLineArguments>
                    <commandLineArgument>--spring.profiles.active=dev</commandLineArgument>
                    <commandLineArgument>--logging.config=${rpmInstallLocation}/config/${installer-target}-logback.xml</commandLineArgument>
                </commandLineArguments>
                <platforms>
                    <platform>jsw</platform>
                </platforms>
                <generatorConfigurations>
                    <generatorConfiguration>
                        <generator>jsw</generator>
                        <includes>
                            <include>linux-x86-64</include>
                        </includes>
                        <configuration>
                            <property>
                                <name>wrapper.logfile</name>
                                <value>logs/${installer-target}-wrapper.log</value>
                            </property>
                            <property>
                                <name>wrapper.logfile.maxsize</name>
                                <value>5m</value>
                            </property>
                            <property>
                                <name>run.as.user.envvar</name>
                                <value>${serviceUser}</value>
                            </property>
                            <property>
                                <name>wrapper.on_exit.default</name>
                                <value>RESTART</value>
                            </property>
                        </configuration>
                    </generatorConfiguration>
                </generatorConfigurations>
                <jvmSettings>
                    <initialMemorySize>256M</initialMemorySize>
                    <maxMemorySize>1024M</maxMemorySize>
                    <extraArguments>
                        <extraArgument>-server</extraArgument>
                    </extraArguments>
                </jvmSettings>
            </daemon>
        </daemons>
    </configuration>
    <executions>
        <execution>
            <id>generate-jsw-scripts</id>
            <phase>package</phase>
            <goals>
                <goal>generate-daemons</goal>
            </goals>
        </execution>
    </executions>
</plugin>

W tym pytaniu odpowiedź od @PbxMan powinna zacząć:

Uruchamianie aplikacji Java jako usługi na Linuksie

Edit:

Jest inny, mniej przyjemny sposób na rozpoczęcie procesu przy ponownym uruchomieniu, używając crona:

@reboot user-to-run-under /usr/bin/java -jar /path/to/application.jar

To działa, ale nie daje przyjemnego interfejsu start/stop dla Twojej aplikacji. Nadal możesz po prostu kill to i tak...

Mój skrypt SysVInit dla Centos 6 / RHEL (jeszcze nie idealny). Ten skrypt wymaga ApplicationPidListener .

Źródło /etc/init.d/app

#!/bin/sh
#
# app Spring Boot Application 
#
# chkconfig:   345 20 80
# description: App Service
#           

### BEGIN INIT INFO
# Provides: App
# Required-Start: $local_fs $network
# Required-Stop: $local_fs $network
# Default-Start: 3 4 5 
# Default-Stop: 0 1 2 6
# Short-Description: Application
# Description:      
### END INIT INFO

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

exec="/usr/bin/java"
prog="app"
app_home=/home/$prog/
user=$prog

[ -e /etc/sysconfig/$prog ] && . /etc/sysconfig/$prog

lockfile=/var/lock/subsys/$prog    
pid=$app_home/$prog.pid

start() {

    [ -x $exec ] || exit 5
    [ -f $config ] || exit 6
    # Check that networking is up.
    [ "$NETWORKING" = "no" ] && exit 1
    echo -n $"Starting $prog: "
    cd $app_home
    daemon --check $prog --pidfile $pid --user $user $exec $app_args &
    retval=$?
    echo
    [ $retval -eq 0 ] && touch $lockfile
    return $retval
}

stop() {
    echo -n $"Stopping $prog: "
    killproc -p $pid $prog
    retval=$?
    [ $retval -eq 0 ] && rm -f $lockfile
    return $retval
}

restart() {
    stop
    start
}

reload() {
    restart
}

force_reload() {
    restart
}

rh_status() {
    status -p $pid $prog
}

rh_status_q() {
    rh_status >/dev/null 2>&1
}

case "$1" in
    start)
        rh_status_q && exit 0
        $1
        ;;
    stop)
        rh_status_q || exit 0
        $1
        ;;
    restart)
        $1
        ;;
    reload)
        rh_status_q || exit 7
        $1
        ;;
    force-reload)
        force_reload
        ;;
    status)
        rh_status
        ;;
    condrestart|try-restart)
        rh_status_q || exit 0
        restart
        ;;
    *)
        echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload}"
        exit 2
esac
exit $?

Przykładowy plik konfiguracyjny /etc/sysconfig/app:

exec=/opt/jdk1.8.0_05/jre/bin/java

user=myuser
app_home=/home/mysuer/

app_args="-jar app.jar"

pid=$app_home/app.pid

Oto skrypt, który wdraża wykonywalny jar jako usługę systemd.

Tworzy użytkownika dla Serwisu iplik service, i umieść plik jar w / var, i sprawia, że pewne podstawowe zablokowanie uprawnień.

#!/bin/bash

# Argument: The jar file to deploy
APPSRCPATH=$1

# Argument: application name, no spaces please, used as folder name under /var
APPNAME=$2

# Argument: the user to use when running the application, may exist, created if not exists
APPUSER=$3

# Help text
USAGE="
Usage: sudo $0 <jar-file> <app-name> <runtime-user>
If an app with the name <app-name> already exist, it is stopped and deleted.
If the <runtime-user> does not already exist, it is created.
"

# Check that we are root
if [ ! "root" = "$(whoami)" ]; then
    echo "Must be root. Please use e.g. sudo"
    echo "$USAGE"
    exit
fi

# Check arguments
if [ "$#" -ne 3 -o ${#APPSRCPATH} = 0 -o ${#APPNAME} = 0 -o ${#APPUSER} = 0 ]; then
    echo "Incorrect number of parameters."
    echo "$USAGE"
    exit
fi

if [ ! -f $APPSRCPATH ]; then
    echo "Can't find jar file $APPSRCPATH"
    echo "$USAGE"
    exit
fi

# Infered values
APPFILENAME=$(basename $APPSRCPATH)
APPFOLDER=/var/javaapps/$APPNAME
APPDESTPATH=$APPFOLDER/$APPFILENAME

# Stop the service if it already exist and is running
systemctl stop $APPNAME >/dev/null 2>&1

# Create the app folder, deleting any previous content
rm -fr $APPFOLDER
mkdir -p $APPFOLDER

# Create the user if it does not exist
if id "$APPUSER" >/dev/null 2>&1; then
    echo "Using existing user $APPUSER"
else
    adduser --disabled-password --gecos "" $APPUSER
    echo "Created user $APPUSER"
fi

# Place app in app folder, setting owner and rights
cp $APPSRCPATH $APPDESTPATH
chown $APPUSER $APPDESTPATH
chmod 500 $APPDESTPATH
echo "Added or updated the $APPDESTPATH file"

# Create the .service file used by systemd
echo "
[Unit]
Description=$APPNAME
After=syslog.target
[Service]
User=$APPUSER
ExecStart=/usr/bin/java -jar $APPDESTPATH
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
" > /etc/systemd/system/$APPNAME.service
echo "Created the /etc/systemd/system/$APPNAME.service file"

# Reload the daemon
systemctl daemon-reload

# Start the deployed app
systemctl start $APPNAME
systemctl status $APPNAME

Przykład:

Staram się tworzyć aplikacje springboot, które są prezentowane jako " init.d " Style Shell script with a compressed java application tacked on the end

Poprzez symlinkowanie tych skryptów z /etc / init.d / spring-app do / opt / spring-app.jar i chmod 'aby jar był wykonywalny, można utworzyć" / etc / init.d / spring-app start "" / etc / init.d / spring-app stop " i inne możliwości, takie jak praca statusowa

Prawdopodobnie, jako init.skrypty w stylu D z springboot wyglądają, że mają aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript.]}

Ale chciałem go uruchomić z systemd

Aby to zadziałało próbowałem wielu przepisów w innych odpowiedziach powyżej, ale żadna z nich nie zadziałała dla mnie na Centos 7.2 z Springboot 1.3 głównie uruchomili by usługę, ale nie byli w stanie śledzić pid

W końcu znalazłem następujące działa dla mnie, gdy /etc / init.D link był również na miejscu. Plik podobny do poniższego powinien być zainstalowany jako /usr/lib/systemd/system/spring-app.service

[Unit]
Description=My loverly application
After=syslog.target 

[Service]
Type=forking
PIDFile=/var/run/spring-app/spring-app.pid
ExecStart=/etc/init.d/spring-app start
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

Nie znam "standardowego" sposobu, aby to zrobić z aplikacją Java, ale jest to zdecydowanie dobry pomysł(chcesz skorzystać z możliwości keep-alive i monitorowania systemu operacyjnego, jeśli tam są). To jest na mapie drogowej, aby zapewnić coś z wsparcia Spring Boot tool (maven i gradle), ale na razie prawdopodobnie będziesz musiał zwijać własne. Najlepszym rozwiązaniem, jakie obecnie znam, jest Foreman , który ma podejście deklaratywne i jedną linię poleceń do pakowania skryptów init dla różnych standardowych formatów systemu operacyjnego (monit, sys V, upstart itp.). Istnieją również dowody na to, że ludzie skonfigurowali coś z gradle (np. Tutaj).

Używasz Mavena? Następnie powinieneś wypróbować wtyczkę AppAssembler:

Wtyczka Application Assembler jest wtyczką Maven do generowania skryptów do uruchamiania aplikacji java. ... Wszystkie artefakty (zależności + artefakt z projektu) są dodawane do ścieżki klas w generowanych skryptach bin.

Obsługiwane platformy:

Unix-warianty

Windows NT (Windows 9x nie jest obsługiwany)

Java Service Wrapper (JSW)

Zobacz: http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/index.html

Można to zrobić za pomocą usługi Systemd w Ubuntu

<code>
[Unit]
Description=A Spring Boot application
After=syslog.target

[Service]
User=baeldung
ExecStart=/path/to/your-app.jar SuccessExitStatus=143

[Install] 
WantedBy=multi-user.target
</code>

Możesz skorzystać z tego linku, aby uzyskać bardziej szczegółowy opis i różne sposoby na to. http://www.baeldung.com/spring-boot-app-as-a-service

JAKO USŁUGA WINDOWS

Jeśli chcesz to uruchomić na komputerze z systemem windows Pobierz winsw.exe z

 http://repo.jenkins-ci.org/releases/com/sun/winsw/winsw/2.1.2/

Następnie zmień jego nazwę na jar filename (np: your-app.jar)

winsw.exe -> your-app.exe

Teraz Utwórz plik xml Twoja-aplikacja.xml i skopiować do tego

<?xml version="1.0" encoding="UTF-8"?>
<service>
     <id>your-app</id>
     <name>your-app</name>
     <description>your-app as a Windows Service</description>
     <executable>java</executable>
     <arguments>-jar "your-app.jar"</arguments>
     <logmode>rotate</logmode>
</service>

Upewnij się, że exe i xml wraz z jar znajdują się w tym samym folderze.

Po tym otwarciu wiersz polecenia w panelu administratora previlege i zainstaluj go w usłudze windows.

your-app.exe install
eg -> D:\Springboot\your-app.exe install

If it fails with

Error: Registry key 'Software\JavaSoft\Java Runtime Environment'\CurrentVersion' has value '1.8', but '1.7' is required.

Następnie spróbuj:

Delete java.exe, javaw.exe and javaws.exe from C:\Windows\System32

To wszystko:).

Aby odinstalować usługę w systemie windows

your-app.exe uninstall

Aby zobaczyć/uruchomić / zatrzymać usługę: win + r i wpisz Narzędzia administracyjne , a następnie wybierz z nich usługę . Następnie Kliknij prawym przyciskiem myszy wybierz opcję - Uruchom / Zatrzymaj

Podążając za doskonałą odpowiedzią Chada, Jeśli pojawi się błąd "Error: Could not find or load main class" - i spędzasz kilka godzin próbując go rozwiązać, niezależnie od tego, czy wykonujesz skrypt powłoki, który uruchamia aplikację java, czy uruchamiasz ją z samego systemd - i wiesz, że Twoja ścieżka klasowa jest w 100% poprawna, np. ręczne uruchamianie skryptu powłoki działa tak samo, jak uruchamianie tego, co masz w systemd execstart. Upewnij się uruchamiasz rzeczy jako właściwy użytkownik! W moim przypadek, próbowałem różnych użytkowników , po dłuższym czasie rozwiązywania problemów-w końcu miałem przeczucie, umieścić root jako użytkownika-voila, aplikacja rozpoczęła się poprawnie. Po ustaleniu, że był to zły problem użytkownika, i chown -R user:user folder i podfoldery i aplikacja działała poprawnie jako określony użytkownik i grupa, więc nie trzeba już uruchamiać go jako root (złe zabezpieczenia).

W plikach jednostek systemd można ustawić katalog zmiennych środowiskowych lub za pomocą EnvironmentFile. Proponowałbym robienie rzeczy w ten sposób, ponieważ wydaje się, że jest to najmniejsza ilość tarcia.

Przykładowy plik jednostkowy

$ cat /etc/systemd/system/hello-world.service
[Unit]
Description=Hello World Service
After=systend-user-sessions.service

[Service]
EnvironmentFile=/etc/sysconfig/hello-world
Type=simple
ExecStart=/usr/bin/java ... hello-world.jar

Następnie Ustaw plik pod /etc/sysconfig/hello-world, który zawiera wielkie nazwy zmiennych ROZRUCHOWYCH Spring. Na przykład zmienna o nazwie server.port następowałaby po postaci SERVER_PORT jako zmienna środowiskowa:

$ cat /etc/sysconfig/hello-world
SERVER_PORT=8081

Mechanizm wykorzystywany tutaj to sprężynowy but aplikacje pobierają listę właściwości, a następnie tłumaczą je, czyniąc wszystko wielkimi literami i zamieniając kropki na podkreślenia. Gdy aplikacja Spring Boot przejdzie przez ten proces, szuka zmiennych środowiskowych, które pasują, i używa odpowiednio znalezionych.

Jest to podkreślone bardziej szczegółowo w tym pytaniu o tytuł: Jak ustawić właściwość Spring Boot z podkreśleniem w nazwie za pomocą zmiennych środowiskowych?

Referencje

• część IV. funkcje sprężynowego buta-24. Konfiguracja Zewnętrzna