I'm using Spring 3.1.3 and the new profile feature. When I set the environment in my IDE for spring_profiles_active=NONPROD, it works fine. However, when I deploy to our aPaaS environment which is also using Tomcat, it isn't getting picked up.
Shouldn't I just be able to do the following:
env:
CATALINA_OPTS: -Dspring_profiles_active=NONPROD
If I ssh to the machine, I see this is getting set. Any ideas why Spring isn't picking this up?
Put the following lines to your manifest.yml file to get the Spring profile activated in Stackato:
env:
spring_profiles_active:
default: NONPROD
This will put spring_profiles_active into environment variable and Spring happily reads it from there. Note that you have to use underscores in the variable name, because Stackato doesn't like dots in those. The reason is that Linux environment variable names shouldn't contain dots for shell programs to work correctly with them.
Related
I was looking to externalize application configuration for containerized applications on Google Cloud Run. I know there are environment variables available for cloud run application and I want to have something as Config Server for Cloud Run.
Is there any out of the box support available on GCP?
When setting up your Cloud Run deployment, you can simply inject environment variables into your service:
Because Spring Boot comes with application.properties mechanism, you can easily override those values exactly from the environment variables. Do keep in mind, that the syntax is slightly different:
application.properties
spring.profiles.active=dev
environment variables
SPRING_PROFILES_ACTIVE=dev
Injected env variables will take precedence over the ones defined in your application.properties file.
There are two solutions to it :
If your docker file is "ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/****.jar"]" then use "-Dspring.profiles.active=dev" in the container arguments on the cloud run.
In case your docker file has "CMD ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/***.jar"]" You can do it by setting Environment Variable as SPRING_PROFILES_ACTIVE and value as dev in "Variables & Secrets" tab on cloud run Container Configuration
This question already has answers here:
Externalising Spring Boot properties when deploying to Docker
(6 answers)
Closed 3 years ago.
How can we provide application.properties to spring boot app in a docker? Would normally copying the application.properties to the container work?
you can keep that file at some location and map that location to volume. It will connect the local machine to docker container's world
Refer this
I suggest you build the Image with properties included. If needed, add a startscript and provide environment variables per stage (dev, qa, prod), which symlink the needed files.
The answer to this will be widely opinionated, some folks like to mount the file as a volume while other like to substitute the required configuration by reading it from environment variables through a shell script that is run as the entrypoint of the docker container.
Although if you're using Spring, it allows externalized configuration which can be taken from multiple sources. One of the sources is the environment variables that directly override the default configuration.
The approach I take though is to provide them as command line arguments to the JVM command by making the JVM command the entrypoint and providing the arguments at the end of the docker run command
I have a dockerfile that creates an image that starts a Spring Boot application with -Dspring_profiles_active=test on the command line. Now I want to be able to override the profile based on the environment. I had thought that passing an environment variable like -e SPRING_PROFILES_ACTIVE=dev when starting the container would override the command line setting, but it does nothing. If I pass -e spring_profiles_active=dev I get both as shown in the Spring Boot logs: ... : The following profiles are active: dev,test, not what I wanted.
Why doesn't the uppercase version do anything, and
Why does the lowercase version "include" rather than replace?
I thought the precedence order was OS environment variable, then command line (i.e. -D) then application.properites, as per the documentation: Externalized Configuration
EDIT: Corrected typo above. Also, I'm using Spring Boot v1.5.9.RELEASE, Spring v4.3.13.RELEASE and if I remove the -Dspring_profiles_active=test command line options the OS environment variable then passes into the application as expected.
Cheers,
Matt
Use
-e SPRING_PROFILES_ACTIVE=dev
Instead of
-e SPRING_PROFILE_ACTIVE=dev
It is PROFILES
Tomcat8 is set to run as a service on ubuntu
I have deployed an application in tomcat8, I want the app to load(dev,local,prod)environment specific propety file
Which config file should I set -Dspring.profiles.active=\"prod\" value so the correct property file is read.
I tried in catalina.sh as JAVA_OPTS="$JAVA_OPTS -Dspring.profiles.active=\"prod\""
and also in /etc/default/tomcat8
In setenv.sh
CATALINA_OPTS="-Dspring.profiles.active=prod ...a whole bunch of stuff might already be here"
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