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
Related
So, I am learning about microservices (I am a beginner) and I'm facing an issue. I've went through the Spring Cloud Config and Docker docs hoping to find a solution, but I didn't.
I have an app with 3 microservices (Spring Boot) and 1 config server (Spring Cloud Config). I'm using a private Github repository for storing config files and this is my application.properties file for config server:
spring.profiles.active=git
spring.cloud.config.server.git.uri=https://github.com/username/microservices-config.git
spring.cloud.config.server.git.clone-on-start=true
spring.cloud.config.server.git.default-label=master
spring.cloud.config.server.git.username=${GIT_USERNAME}
spring.cloud.config.server.git.password=${GIT_ACCCESS_TOKEN}
I have a Dockerfile based on which I have created a Docker image for config server (with no problems). I created a docker-compose.yml which I use to create and run containers, but it fails because of an exception in my cloud config app. The exception is:
org.eclipse.jgit.api.errors.TransportException: https://github.com/username/microservices-config.git: not authorized
Which basically means that my environment variables GIT_USERNAME and GIT_ACCCESS_TOKEN (that I set up in Intellij's "Edit configuration" and use in application.properties) are not available for the config server to use in a container.
The question is: Do I need to somehow add those environment variables to .jar or to Docker image or to Docker container? Like I'm not sure how do I make them available for the config server to use in a container.
Any help or explanation is welcomed :)
I have a quarkus based webapp that uses Basic Authentication with Embedded Realm Configuration. The webapp runs in a docker container. The authentication properties are specified in application.properties like this:
quarkus.http.auth.basic=true
quarkus.security.users.embedded.enabled=true
quarkus.security.users.embedded.plain-text=true
quarkus.security.users.embedded.users.test=mypass
quarkus.security.users.embedded.roles.test=admin
I would like to override quarkus.security.users.embedded.users.test to specify a password at docker runtime.
I tried to do this by overriding the quarkus property using an environment variable at docker runtime.
docker run -p 9999:9999 -e QUARKUS_SECURITY_USERS_EMBEDDED_USERS_TEST=newpasswd mywebapp
This does not work. When I access mywebapp using http://locahost:9999 I must login using test/mypass. I expected to login using test/newpasswd.
Any help greatly appreciated.
I suggest you report an issue for this problem. While Quarkus won't be able to "enumerate" any new users from environment variables (the correct property names cannot be deduced), I think it should still be possible to override the password of a user that has already been specified in application.properties using an environment variable like you try to do.
First i just want to mention i am very new to docker.
I am using Win 10, "Docker for Windows".
I am using the default linux containers option.
I have downloaded the latest image from here,
https://github.com/camunda/docker-camunda-bpm-platform.
So now, my Docker is online, and the container + image are working. A tomcat server and a Camunda engine are online and working.
My problem is the following,
I need to do some changes and i cant find where Tomcat and Camunda are being stored. I need to edit some XML files both in the Camunda and in the Tomcat ( to setup which database to use for example ).
Can it be that it is not being stored on my local machine?
For example when i open the container with Kitematic ( Docker UI ) i can see environment variables for it, there is a SERVER_CONFIG and its value is /camunda/conf/server.xml ( this is one of the files i need to edit! but i cant find it or anything else anywhere on my local machine ).
you should access container using following command
sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5e978f353734 camunda/camunda-bpm-platform:latest "/sbin/tini -- ./cam…" 4 days ago Up 4 days
the issie
sudo docker exec -it 5e978f353734 /bin/bash
then you will see the container insie via shell command. good luck!
You may want to consider using Camunda BPM RUN, which aims to allow configuration without having to change the WAR deployment or Tomcat. Instead configuration is done as described here:
https://docs.camunda.org/manual/latest/user-guide/camunda-bpm-run/
Config files can be mounted into the docker images, but you may prefer to compose your own docker image based on the Camunda BPM Run base image.
The example here shows another approach which sets Camunda properties from outside the docker image by passing the environment variable SPRING_APPLICATION_JSON into the docker image.
https://medium.com/#robert.emsbach/anyone-can-run-camunda-bpm-on-azure-in-10-minutes-4b4055cc8e9
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.
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.