L'application de Botte de ressort en tant que Service

ce qui suit est la façon la plus facile d'installer une application Java comme service système sous Linux.

supposons que vous utilisez systemd (ce que toute distro moderne fait de nos jours):

tout D'abord, créer un fichier de service dans /etc/systemd/system nommé par exemple javaservice.service avec ce contenu:

[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

deuxièmement, notifier systemd du nouveau fichier de service:

systemctl daemon-reload

et l'activer, donc il tourne sur boot:

systemctl enable javaservice.service

Finalement, vous pouvez utiliser les commandes suivantes pour démarrer/arrêter votre nouveau service:

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

pourvu que vous utilisiez systemd , c'est la façon la plus propre et non intrusive de configurer une application Java comme système-service.

ce que j'aime particulièrement dans cette solution est le fait que vous n'avez pas besoin d'installer et de configurer un autre logiciel. Le systemd embarqué fait tout le travail pour vous, et votre service se comporte comme n'importe quel autre service du système. Je l'utilise dans la production depuis un moment maintenant, sur différents distros, et ça fonctionne juste comme vous vous y attendiez.

un autre plus est que, en utilisant /usr/bin/java , vous pouvez facilement ajouter jvm paramètres tels que -Xmx256m .

également lire la partie systemd dans la documentation officielle de la botte de ressort: http://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html

vous pouvez également utiliser supervisord qui est un démon très pratique, qui peut être utilisé pour contrôler facilement les services. Ces services sont définis par des fichiers de configuration simples définissant ce qu'il faut exécuter avec quel utilisateur dans quel répertoire et ainsi de suite, Il ya un zillion d'options. supervisord a une syntaxe très simple, il fait donc une très bonne alternative à l'écriture de scripts D'initialisation SysV.

ici un simple supervisord fichier de configuration pour le programme que vous essayez d'exécuter/contrôler. (le mettre en /etc/superviseur/conf.d / yourrapp.conf )

/etc/superviseur/conf.d / yourrapp.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

pour contrôler l'application , vous devez exécuter supervisorctl , qui vous présentera un prompt où vous pouvez démarrer, arrêter, status yourrapp.

CLI

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

si le démon supervisord est déjà en cours d'exécution et que vous avez ajouté la configuration pour votre serivce sans redémarrer le démon, vous pouvez simplement exécuter une commande reread et update dans le shell supervisorctl .

cela vous donne vraiment toutes les flexibilités que vous auriez en utilisant des scripts D'initialisation SysV, mais facile à utiliser et à contrôler. Jetez un oeil à la documentation .

je viens d'avoir le temps de le faire moi-même, donc ce qui suit est où je suis jusqu'à présent en termes de CentOS init.d script du contrôleur de service. Ça marche plutôt bien jusqu'à présent, mais je ne suis pas un hacker de leet Bash, donc je suis sûr qu'il y a de la place pour l'amélioration, donc les idées pour l'améliorer sont les bienvenues.

tout d'abord, j'ai un script de configuration court /data/svcmgmt/conf/my-spring-boot-api.sh pour chaque service, qui met en place des variables d'environnement.

#!/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

J'utilise CentOS, donc pour assurez-vous que mes services sont démarrés après un redémarrage du serveur, j'ai un script de contrôle de service dans /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 

exit 0

comme vous pouvez le voir, cela appelle le script de configuration initial pour configurer les variables d'environnement, puis appelle un script partagé que j'utilise pour redémarrer tous mes services de démarrage de printemps. Ce script partagé est où la viande de tout cela peut être trouvé:

#!/bin/bash

echo "Service [$APP_NAME] - []"

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  in
start)
    start
;;
stop)
    stop
;;
restart)
    stop
    start
;;
esac
exit 0

lors de l'arrêt, il tentera d'utiliser le servomoteur à ressort pour effectuer un arrêt contrôlé. Cependant, si L'actionneur n'est pas configuré ou ne parvient pas à s'arrêter dans un délai raisonnable (je lui donne 5 secondes, ce qui est un peu court en réalité), le processus sera tué.

en outre, le script fait l'hypothèse que le processus java exécutant l'appllication sera le seul avec" my-spring-boot-api.jar" dans le texte des détails du processus. C'est une hypothèse sûre dans mon environnement et signifie que je n'ai pas besoin de garder PIDs.

si vous voulez utiliser la botte de printemps 1.2.5 avec le Plugin de Botte de printemps Maven 1.3.0.M2, voici la solution:

<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>

puis compiler comme ususal: mvn clean package , faire un lien symbolique ln -s /.../myapp.jar /etc/init.d/myapp , le rendre exécutable chmod +x /etc/init.d/myapp et le démarrer service myapp start (avec le serveur Ubuntu)

je sais que c'est une question plus ancienne, mais je voulais présenter encore une autre voie qui est le appassembler-maven-plugin . Voici la partie pertinente de mon POM qui inclut beaucoup de valeurs d'options supplémentaires que nous avons trouvé utiles:

<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>

dans cette question, la réponse de @PbxMan devrait vous aider à commencer:

exécuter une Application Java comme un Service sur Linux

Edit:

il y a une autre façon moins agréable de démarrer un processus en redémarrant, en utilisant cron:

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

cela fonctionne, mais ne vous donne pas d'interface début/arrêt agréable pour votre application. Vous pouvez toujours simplement kill il de toute façon...

mon script SysVInit pour Centos 6 / RHEL (pas encore idéal). Ce script nécessite ApplicationPidListener .

Source de /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 "" in
    start)
        rh_status_q && exit 0
        
        ;;
    stop)
        rh_status_q || exit 0
        
        ;;
    restart)
        
        ;;
    reload)
        rh_status_q || exit 7
        
        ;;
    force-reload)
        force_reload
        ;;
    status)
        rh_status
        ;;
    condrestart|try-restart)
        rh_status_q || exit 0
        restart
        ;;
    *)
        echo $"Usage: "151900920" {start|stop|status|restart|condrestart|try-restart|reload|force-reload}"
        exit 2
esac
exit $?

exemple de fichier de configuration /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

voici un script qui déploie un jar exécutable comme un service systemd.

Il crée un utilisateur pour le service et l' .service file, et placer le fichier jar sous / var, et effectue un verrouillage basique des privilèges.

#!/bin/bash

# Argument: The jar file to deploy
APPSRCPATH=

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

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

# Help text
USAGE="
Usage: sudo "151900920" <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

exemple:

je suis en train de faire springboot les applications qui sont présentés comme un "init.d" style script shell avec un comprimé d'applications java cloué sur la fin

par symlinking ces scripts à partir de /etc/init.d/printemps-app /opt/printemps-app.jar et chmod avec le pot pour qu'il soit exécutable, il est possible de faire "/etc/init.d/printemps-app start" "/etc/init.d / spring-app stop "et d'autres possibilités comme le travail d'état

probablement, comme l'init.d style les scripts de springboot semblent avoir les chaînes magiques nécessaires (comme # Default-Start: 2 3 4 5 ) chkconfig serait en mesure de l'ajouter comme un" service "

Mais je voulais le faire fonctionner avec systemd

Pour faire ce travail, j'ai essayé beaucoup de recettes dans les autres réponses ci-dessus, mais n'a pas fonctionné pour moi sur Centos 7.2 avec Springboot 1.3 pour la Plupart, ils allaient commencer le service, mais ne pas être en mesure de suivre le pid

à la fin, j'ai trouvé que ce qui suit a fonctionné pour moi, quand le /etc/init.D link était également en place. Un fichier similaire à celui ci-dessous doit être installé comme /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

Je ne sais pas s'il existe une façon" standard " de le faire avec une application Java, mais c'est certainement une bonne idée (vous voulez profiter des capacités de maintien en vie et de surveillance du système d'exploitation s'ils sont présents). Il est sur la feuille de route pour fournir quelque chose de la prise en charge de L'outil de démarrage à ressort (maven et gradle), mais pour l'instant, vous allez probablement avoir à rouler votre propre. La meilleure solution que je connaisse actuellement est Foreman , qui a une déclaration approach et les commandes d'une ligne pour empaqueter des scripts d'initialisation pour différents formats D'OS standard (monit, sys V, upstart etc.). Il y a aussi des preuves que des gens ont installé des trucs avec gradle (par exemple ici ).

utilisez-vous Maven? Ensuite, vous devriez essayer le Plugin AppAssembler:

le Plugin assembleur D'Application est un plugin Maven pour générer des scripts pour démarrer des applications java. ... Tous les artefacts (dépendances + artefacts du projet) sont ajoutés à classpath dans les scripts bin générés.

plates-formes supportées:

Unix-variantes

Windows NT (Windows 9x n'est pas supporté)

Java Service Wrapper (JSW)

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

Il peut être fait en utilisant Systemd service dans 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>

vous pouvez suivre ce lien pour une description plus détaillée et différentes façons de le faire. http://www.baeldung.com/spring-boot-app-as-a-service

COMME UN SERVICE WINDOWS

si vous voulez que cela tourne dans Windows machine téléchargez le winsw.exe à partir de

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

après cela le renommer en Jar filename (par exemple: your-app .jar)

winsw.exe -> your-app.exe

créez maintenant un fichier xml votre-application.xml et copier le contenu suivant à celui

<?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>

s'assurer que le exe et xml avec pot dans un même dossier.

après cela, ouvrez l'invite de commande dans L'administrateur previlege et installez-le dans le service windows.

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

si elle échoue avec

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

puis essayez ce qui suit:

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

c'est ça :) .

à désinstaller le service dans windows

your-app.exe uninstall

pour les services see/run / stop: win+r et tapez Outils administratifs puis sélectionnez le service à partir de là. Puis clic droit choisir option-Exécuter / arrêter

suite à L'excellente réponse de Chad, si vous obtenez une erreur de " erreur: ne pouvait pas trouver ou charger la classe principale " - et vous passez quelques heures à essayer de le dépanner, que ce soit en exécutant un script shell qui démarre votre application java ou en le démarrant à partir de systemd lui - même-et vous savez que votre classpath est correct à 100%, par exemple exécuter manuellement le script shell fonctionne aussi bien qu'exécuter ce que vous avez dans systemd execstart. Être sûr vous êtes exécuter des choses en tant qu'utilisateur correct! Dans mon cas, j'avais essayé différents utilisateurs, après un certain temps de dépannage - j'ai enfin eu un pressentiment, mettre root comme utilisateur - voila, l'application a démarré correctement. Après avoir déterminé que c'était un problème d'utilisateur erroné, Je chown -R user:user le dossier et les sous-dossiers et l'application ont fonctionné correctement que l'utilisateur et le groupe spécifiés ainsi plus besoin de l'exécuter en tant que root (mauvaise sécurité).

dans les fichiers unités de systemd, vous pouvez définir un répertoire de variables d'environnement ou via un EnvironmentFile . Je proposerais de faire les choses de cette façon puisque cela semble être la moindre friction.

fichier des unités D'échantillonnage

$ 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

puis configurer un fichier sous /etc/sysconfig/hello-world qui inclut les noms en majuscules de vos variables de démarrage de printemps. Par exemple, une variable appelée server.port suivrait la forme SERVER_PORT comme variable d'environnement:

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

le mécanisme exploité ici est que les applications de Botte de printemps prendront la liste des propriétés et les traduiront ensuite, en faisant tout en majuscules, et en remplaçant les points par des underscores. Une fois que L'application de démarrage de printemps passe par ce processus, il cherche les variables d'environnement qui correspondent, et utilise toutes trouvées en conséquence.

ceci est mis en évidence plus en détail dans ce SO Q&A intitulé: comment mettre une botte à ressort propriété avec un underscore dans son nom via des Variables D'environnement?

Références

• Partie IV. Caractéristiques de la botte de printemps-24. Configuration Externalisée