Application Spring Boot en tant que service
Comment configurer joliment l'application Spring Boot conditionnée en jar exécutable en tant que service dans un système linux? Cette approche est-elle recommandée ou devrais-je convertir cette application en guerre et l'installer dans Tomcat?
Actuellement, je peux exécuter une application de démarrage Spring à partir de la session screen, ce qui est bien, mais nécessite un démarrage manuel après le redémarrage du serveur.
Ce que je recherche, c’est un conseil/une direction générale ou un exemple de script init.d, si mon approche avec un exécutable jar est correcte.
Ce qui suit est la manière la plus simple d’installer une application Java en tant que service système sous Linux.
Supposons que vous utilisiez systemd (comme le fait actuellement toute distribution moderne):
Tout d’abord, créez 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 --server.port=8081
SuccessExitStatus=143
TimeoutStopSec=10
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
Deuxièmement, notifiez systemd du nouveau fichier de service:
systemctl daemon-reload
et l'activer, donc il s'exécute au démarrage:
systemctl enable javaservice.service
Vous pouvez éventuellement utiliser les commandes suivantes pour démarrer/arrêter votre nouveau service:
systemctl start javaservice
systemctl stop javaservice
systemctl restart javaservice
systemctl status javaservice
À condition que vous utilisiez systemd, il s'agit de la méthode la plus non intrusive et la plus propre pour configurer une application Java en tant que service système.
Ce que j'aime particulièrement dans cette solution, c'est le fait que vous n'avez pas besoin d'installer ni de configurer un autre logiciel. Le systemd livré fait tout le travail à votre place et votre service se comporte comme tout autre service système. Je l'utilise en production depuis un moment, sur différentes distributions, et il fonctionne comme prévu.
Un autre avantage est que, en utilisant /usr/bin/Java, vous pouvez facilement ajouter jvm paramètres tels que -Xmx256m.
Lisez également la partie systemd de la documentation officielle de Spring Boot: http://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html
Vous pouvez également utiliser supervisord , un démon très pratique pouvant être utilisé pour contrôler facilement des services. Ces services sont définis par de simples fichiers de configuration définissant ce qu'il faut exécuter avec quel utilisateur, dans quel répertoire et ainsi de suite, il existe une multitude d'options. supervisord a une syntaxe très simple, ce qui en fait une très bonne alternative à l'écriture de scripts d'initialisation SysV.
Voici un simple fichier de configuration supervisord pour le programme que vous essayez d'exécuter/de contrôler. (mettez ceci dans /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
Pour contrôler l'application, vous devez exécuter supervisorctl , qui vous présentera une invite de démarrage, d'arrêt, de statut de votre application.
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 de votre service 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 possibilités que vous auriez avec les scripts SysV Init, mais faciles à utiliser et à contrôler. Jetez un coup d'œil à la documentation .
Je viens juste de le faire moi-même, alors voici où j'en suis en termes de script de contrôleur de service init.d CentOS. Cela fonctionne assez bien jusqu'à présent, mais je ne suis pas un pirate informatique, alors je suis sûr qu'il y a place à l'amélioration, alors toute réflexion sur l'amélioration est la bienvenue.
Tout d’abord, j’ai un bref script de configuration /data/svcmgmt/conf/my-spring-boot-api.sh pour chaque service, qui configure les 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. Pour que mes services soient démarrés après le 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 $1
exit 0
Comme vous pouvez le constater, cela appelle le script de configuration initial pour configurer les variables d'environnement, puis un script partagé que j'utilise pour redémarrer tous mes services Spring Boot. Ce script partagé est l'endroit où la viande de tout cela peut être trouvée:
#!/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
Lors de l’arrêt, il essaiera d’utiliser Spring Boot Actuator pour effectuer un arrêt contrôlé. Toutefois, si l'actionneur n'est pas configuré ou ne parvient pas à s'éteindre dans un délai raisonnable (je lui donne 5 secondes, ce qui est un peu court en réalité), le processus sera interrompu.
En outre, le script suppose que le processus Java exécutant l'application sera le seul à comporter "my-spring-boot-api.jar" dans le texte des détails du processus. Ceci est une hypothèse sûre dans mon environnement et signifie que je n'ai pas besoin de suivre les PID.
Si vous souhaitez utiliser Spring Boot 1.2.5 avec Spring Boot Maven Plugin 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>
Ensuite, compilez comme suit: mvn clean package, créez un lien symbolique ln -s /.../myapp.jar /etc/init.d/myapp, rendez-le exécutable chmod +x /etc/init.d/myapp et démarrez-le service myapp start (avec Ubuntu Server)
Je sais que c'est une question plus ancienne, mais je voulais présenter encore une autre manière qui est la appassembler-maven-plugin . Voici la partie pertinente de mon POM qui comprend de nombreuses valeurs d’options supplémentaires que nous avons trouvées 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>
EN TANT QUE SERVICE WINDOWS
Si vous voulez que cela fonctionne sous Windows, téléchargez le fichier winsw.exe à partir de
http://repo.jenkins-ci.org/releases/com/Sun/winsw/winsw/2.1.2/
Après cela, renommez-le en jar nomfichier (par exemple: votre-application. Jar)
winsw.exe -> your-app.exe
Maintenant, créez un fichier XML your-app.xml et copiez le contenu suivant dans ce fichier
<?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>
Assurez-vous que les exe et xml avec jar dans un même dossier.
Après cela, ouvrez Invite de commandes dans Administrator previlege et installez-le sur le service Windows.
your-app.exe install
eg -> D:\Springboot\your-app.exe install
Si cela échoue avec
Error: Registry key 'Software\JavaSoft\Java Runtime Environment'\CurrentVersion' has value '1.8', but '1.7' is required.
Ensuite, essayez ce qui suit:
Delete Java.exe, javaw.exe and javaws.exe from C:\Windows\System32
c'est ça :) .
Pour désinstaller le service dans Windows
your-app.exe uninstall
Pour voir/exécuter/arrêter le service: win + r et tapez Outils d'administration, puis sélectionnez le service parmi celui-ci. Puis clic droit choisissez le option - exécuter/arrêter
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 "$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 $?
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
J'essaie de créer des applications springboot présentées sous la forme d'un script Shell de type "init.d" avec une application compressée Java ajoutée à la fin.
En liant ces scripts de /etc/init.d/spring-app à /opt/spring-app.jar et en modifiant le fichier jar pour qu'il soit exécutable, il est possible de créer "/etc/init.d/spring-app start "" /etc/init.d/spring-app stop "et d'autres possibilités comme le travail sur le statut
Vraisemblablement, comme les scripts de style init.d de Springboot semblent avoir les chaînes magiques nécessaires (comme # Default-Start: 2 3 4 5), chkconfig pourrait l'ajouter en tant que "service".
Mais je voulais le faire fonctionner avec systemd
Pour que cela fonctionne, j'ai essayé beaucoup de recettes dans les autres réponses ci-dessus, mais aucune d'entre elles n'a fonctionné pour moi sur Centos 7.2 avec Springboot 1.3. La plupart du temps, ils démarraient le service mais ne pouvaient pas suivre le pid
En fin de compte, j’ai trouvé que ce qui suit fonctionnait pour moi, lorsque le lien /etc/init.d était également en place. Un fichier similaire à celui ci-dessous devrait être installé en tant que /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
Voici un script qui déploie un fichier jar exécutable en tant que service systemd.
Il crée un utilisateur pour le service et le fichier .service, place le fichier jar sous/var et crée un verrouillage de base des privilèges.
#!/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
Exemple: 
Dans cette question, la réponse de @PbxMan devrait vous aider à démarrer:
Exécuter une Java Application en tant que service sous Linux
Modifier:
Il existe un autre moyen, moins agréable, de démarrer un processus au redémarrage en utilisant cron:
@reboot user-to-run-under /usr/bin/Java -jar /path/to/application.jar
Cela fonctionne, mais ne vous donne aucune interface Nice Start/Stop pour votre application. Vous pouvez toujours simplement kill le quand même ...
J'ai fini par faire le service systemd pour la mise en page WAR/JAR
J'appelle Java -jar parce que c'est plus flexible. J'ai également essayé de mettre ExecStart = spring-mvc.war, mais même si c'est exécutable, j'ai eu 'Erreur de format Exec'
Quoi qu'il en soit, ces derniers jours, systemd est présent sur toutes les distributions et offre une solution intéressante pour rediriger les journaux (syserr est important lorsque le service ne démarre même pas, l'emplacement du fichier log4j sera vide :)).
cat /etc/systemd/system/spring-mvc.service
[Unit]
Description=Spring MVC Java Service
[Service]
User=spring-mvc
# The configuration file application.properties should be here:
WorkingDirectory=/usr/local/spring-mvc
# Run ExecStartPre with root-permissions
PermissionsStartOnly=true
ExecStartPre=-/bin/mkdir -p /var/log/spring-mvc
ExecStartPre=/bin/chown -R spring-mvc:syslog /var/log/spring-mvc
ExecStartPre=/bin/chmod -R 775 /var/log/spring-mvc
#https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStart=
ExecStart=/usr/bin/Java \
-Dlog4j.configurationFile=log4j2-spring.xml \
-DLog4jContextSelector=org.Apache.logging.log4j.core.async.AsyncLoggerContextSelector \
-Dspring.profiles.active=dev \
-Denvironment-type=dev \
-XX:+UseConcMarkSweepGC \
-XX:CMSInitiatingOccupancyFraction=80 \
-XX:NewSize=756m \
-XX:MetaspaceSize=256m \
-Dsun.net.inetaddr.ttl=5 \
-Xloggc:/var/log/spring-mvc/gc.log \
-verbose:gc \
-verbosegc \
-XX:+DisableExplicitGC \
-XX:+PrintGCDetails \
-XX:+PrintGCDateStamps \
-XX:+PreserveFramePointer \
-XX:+StartAttachListener \
-Xms1024m \
-Xmx1024m \
-XX:+HeapDumpOnOutOfMemoryError \
-jar spring-mvc.war
SuccessExitStatus=143
StandardOutput=journal
StandardError=journal
KillSignal=SIGINT
TimeoutStopSec=20
Restart=always
RestartSec=5
StartLimitInterval=0
StartLimitBurst=10
LimitNOFILE=500000
LimitNPROC=500000
#https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LimitCPU=
#LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=, LimitRTTIME=¶
SyslogIdentifier=spring-mvc
[Install]
WantedBy=multi-user.target
# https://www.freedesktop.org/software/systemd/man/journalctl.html
#check logs --- journalctl -u spring-mvc -f -o cat
rsyslog - redirige les entrées syslog de l'application vers un dossier/fichier spécifique
cat /etc/rsyslog.d/30-spring-mvc.conf
if $programname == 'spring-mvc' then /var/log/spring-mvc/spring-mvc.log
& stop
logrotate
cat /etc/logrotate.d/spring-mvc.conf
/var/log/spring-mvc/spring-mvc.log
{
daily
rotate 30
maxage 30
copytruncate
missingok
notifempty
compress
dateext
dateformat _%Y-%m-%d_%H-%M
delaycompress
create 644 spring-mvc syslog
su spring-mvc syslog
}
logrotate gc
cat /etc/logrotate.d/spring-mvc-gc.conf
/var/log/spring-mvc/gc.log
{
daily
rotate 30
maxage 30
copytruncate
missingok
notifempty
compress
dateext
dateformat _%Y-%m-%d_%H-%M
delaycompress
create 644 spring-mvc syslog
su spring-mvc syslog
}
Je ne connais pas de moyen "standard" de le faire avec une application Java, mais c'est une bonne idée (vous souhaitez bénéficier des fonctionnalités de maintien en activité et de surveillance du système d'exploitation système si elles sont là). Il est prévu dans la feuille de route de fournir quelque chose à partir du support de l'outil Spring Boot (maven et gradle), mais pour le moment, vous allez probablement devoir le faire vous-même. La meilleure solution que je connaisse actuellement est Foreman , qui a une approche déclarative et des commandes à une ligne pour empaqueter les scripts init pour différents formats de système d'exploitation standard (monit, sys V, upstart, etc.). Il existe également des preuves montrant que des personnes ont commencé à travailler avec Gradle (par exemple, ici ).
Utilisez-vous Maven? Ensuite, vous devriez essayer le plugin AppAssembler:
Application Assembler Plugin est un plug-in Maven permettant de générer des scripts permettant de lancer des applications Java. ... Tous les artefacts (dépendances + l'artefact du projet) sont ajoutés au chemin de classe dans les scripts bin générés.
Plateformes supportées:
Variantes Unix
Windows NT (Windows 9x n'est pas supporté)
Java Service Wrapper (JSW)
Voir: http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/index.html
Dans les fichiers d'unité systemd, vous pouvez définir le répertoire des variables d'environnement ou via un EnvironmentFile. Je proposerais de faire les choses de cette façon car cela semble être le moins frottant.
Exemple de fichier d'unité
$ 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
Ensuite, configurez un fichier sous /etc/sysconfig/hello-world contenant les noms en majuscules de vos variables de démarrage Spring. Par exemple, une variable appelée server.port suivrait la forme SERVER_PORT en tant que variable d'environnement:
$ cat /etc/sysconfig/hello-world
SERVER_PORT=8081
Le mécanisme exploité ici est que les applications Spring Boot prennent la liste des propriétés, puis les traduisent, en mettant tout en majuscule et en remplaçant les points par des traits de soulignement. Une fois que l'application Spring Boot a traversé ce processus, elle recherche ensuite les variables d'environnement qui correspondent et utilise celles trouvées en conséquence.
Ceci est mis en évidence plus en détail dans cette SO Q & R intitulée: Comment définir une propriété Spring Boot avec un trait de soulignement dans son nom via des variables d'environnement?
Références
Suite à l'excellente réponse de Chad, si vous obtenez une erreur de "Erreur: Impossible de trouver ou de charger la classe principale" - et que vous passiez quelques heures à essayer de la résoudre, que vous exécutiez un script Shell lance votre application Java ou à partir de systemd elle-même - et vous savez que votre chemin d'accès aux classes est correct à 100%, par exemple L'exécution manuelle du script Shell fonctionne aussi bien que ce que vous avez dans systemd execstart. Assurez-vous vous utilisez le bon utilisateur! Dans mon cas, j'avais essayé différents utilisateurs, après un certain temps de dépannage - j'avais enfin un pressentiment, mis root en tant qu'utilisateur - voila, l'application a démarré correctement. Après avoir déterminé qu’il s’agissait d’un problème d’utilisateur incorrect, je chown -R user:user le dossier et les sous-dossiers et l’application s’exécutait correctement en tant qu’utilisateur et groupe spécifiés; il n’était donc plus nécessaire de l’exécuter en tant que root (sécurité incorrecte).
Cela peut être fait en utilisant le service Systemd dans Ubuntu
[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
Vous pouvez suivre ce lien pour une description plus élaborée et différentes façons de le faire. http://www.baeldung.com/spring-boot-app-as-a-service