We are using spring-boot with the embedded launcher-script in service mode, to have daemonized/init.d behavior.
We however do not have an /etc/init.d symlink to the spring-boot jar as that would require using sudo. we avoid sudo to pass a profile-environmental like -Dspring.profiles.active=$APP_PROFILE in the JAVA_OPTS
(this won't work when started via sudo but defined in /home/appuser/.bashrc (?) )
We have this directory-layout with some indirections. basically app.jar => current/app.jar => build-xx/app.jar
appuser#host:~/apps/services$ ls
app.jar -> /home/appuser/apps/services/current/services-1.0-SNAPSHOT.jar
current -> /home/appuser/apps/services/services-1298
services-1298
When starting the application with app.jar start the launch-script generates an additional pid-subdirectory in the pid-folder based on the "identity" of the program. For us this can look like this:
/home/appuser/apps/services/run/services-1.0-SNAPSHOT_homeappuserappsservicesservices-1298/services.pid
Unlike when used with an symlinked /etc/init.d which gets special treatment and the pid-subdir services-1.0-SNAPSHOT_homeappuserappsservicesservices-1298 is omitted/stays stable.
This dynamic pid-subdir makes it very hard for us to check the daemon's status or start/stop during deployment because you have to always get the sequence right and nobody is stopping you from starting a process twice (the old instance and now a new instance with a new identity-subdir).
So, does anyone know why this pid-subdir-identity stuff must exist and what would be our best way to deal with it?
Do we have a bad setup?
Any advice appreciated.
You can control the identity by using the APP_NAME environment variable.
I'd recommend configuring your service's environment variables using a .conf file next to the jar file. For example, if your app is called app.jar, you conf file should be named app.conf and be placed in the same directory as the jar. You can then configure APP_NAME and JAVA_OPTS etc for your application. This should allow you to use init.d if you so wish.
Related
I have an application. It has multiple external (yaml) configuration files (ex; mongo.yml, redis.yml, etc). I would like Spring Boot to load these, so that they are accessible as expected inside the code base (aka, mongo.host, redis.port, etc).
This (directory) pattern is non-negotiable, as every other service in our architecture can handle it (and is currently using it).
How can I do this?
Notes:
The documentation leads me to believe that this:
java -jar app.jar \
--spring.config.location=config/ \
--spring.config.name=mongo,services
should do what I want: I'm specifying to look in the config/ directory for the mongo and services files (presumably, checking for both mongo.properties and mongo.yml?). However, this is not working; the values are still what appear to be the defaults. Also, it isn't what I want; each file has to be specified, instead of just the directory.
Is there a way to do this? Is there a way to get close?
Thanks!
I want to override certain properties during deployment of my spring boot application.
when I try the following it works
sudo /etc/init.d/myapp start --app.env=prod
I see the app.env is correctly set to prod (my /health just echoes this values)
however when I set more than one property it did not work,
sudo /etc/init.d/myapp start --app.env=prod --version=2.3.4
I see only app.env is correctly set. the version value is not overridden.
why is it so? what is the right way to pass multiple parameters.
NOTE: I want to pass username and password for datasources. but for testing purposes, I kept it simple to override these properties.
You would want to read the section around Customizing the startup script. Specifically that you can include a myapp.conf file beside the jar file. In that .conf file is a JAVA_OPTS variable. You would then use -Dapp.env=prod -Dversion=2.3.4
I have a Play application (2.3.4) that is getting build with activator like this:
$ activator stage
This will build the project and generate startup script: target/universal/stage/bin/<project name in lowercase>.
Now, I need to get run that startup script from another bash script on my production server.
My question is - how do I get the project name (in lowercase) from activator or sbt (since activator wraps sbt) from bash, so I could run the startup script?
Or, maybe there is a better way to figure out the name of the startup script generated by activator stage.
A project name is concatenation of two keys name and version separated with a dash. Whit a little bit of parsing you can get a value of any key using the SBT show <key> command. I'm not really familiar with writing bash scripts but I hope this hint can give you enough information to solve your problem.
I am working on setting up a load balancing cluster on windows server 2012 and have a shared drive where I want the configuration files for Apache to exist at. This way each member of the LB can load the exact same config files. How do I change where the config file is located independently of where the ServerRoot is?
Start the Apache process with the -d parameter and give your alternative ServerRoot as an argument, though I'd imagine it would be a much better idea for you to use some mechanism to sync the files locally to each server.
Also read http://httpd.apache.org/docs/2.4/mod/core.html#mutex, as it's advised if you're running from a networked file system.
If you just want to specify the main config file, start the process with the -f parameter and the path to the config file as an argument.
According to Meteor's documentation, we can include a settings file through the command line to provide deployment-specific settings.
However, the --settings option seems to only be available through the run and deploy commands. If I am running my Meteor application on my own infrastructure - as outlined in the Running on Your Own Infrastructure section of the documentation - there doesn't seem to be a way to specify a deployment-specific settings file anywhere in the process.
Is there a way to access Meteor settings in a production environment, running on my own infrastructure?
Yes, include the settings contents in an environmental variable METEOR_SETTINGS. For example,
export METEOR_SETTINGS='{"privateKey":"MY_KEY", "public":{"publicKey":"MY_PUBLIC_KEY", "anotherPublicKey":"MORE_KEY"}}'
And then run the meteor app as normal.
This will populate the Meteor.settings object has normal. For the settings above,
Meteor.settings.privateKey == "MY_KEY" #Only on server
Meteor.settings.public.publicKey == "MY_PUBLIC_KEY" #Server and client
Meteor.settings.public.anotherPublicKey == "MORE_KEY" #Server and client
For our project, we use an upstart script and include it there (although upstart has a slightly different syntax). However, if you are starting it with a normal shell script, you just need to include that export statement before your node command. You could, for example, have a script like:
export METEOR_SETTINGS='{"stuff":"real"}'
node /path/to/bundle/main.js
or
METEOR_SETTINGS='{"stuff":"real"}' node /path/to/bundle/main.js
You can find more information about bash variables here.