I want to be able to override
spring.datasource.url
spring.datasource.user
spring.datasource.password
on each application start using environment variables;
That's because I'm trying to dockerize application and database.
I want to specify url, user, password in .env file (for docker-compose)
and share them with application container (connect to db) and db-container (to be able to connect).
I tried
export SPRING_DATASOURCE_URL=${url}
export SPRING_DATASOURCE_USER=${user}
export SPRING_DATASOURCE_PASSWORD=${password}
./mvnw spring-boot:run
But it seems to pick up only the last param (password in this case)
Also i tried
./mvnw spring-boot:run \
-Dspring.datasource.url=${url} \
-Dspring.datasource.user=${user} \
-Dspring.datasource.password=${passwrod} \
but this one seem to care only about the first one (url in this case).
I really want to know if there is any viable method to achieve that
via terminal or do I actually have to override properties file each time?
UPDATE
The problem was indeed in me.
It's spring.datasource. username, not user. Really sorry for waisting time on that.
You are using maven to execute your spring boot app which is the cause of at least some of your problems.
When you specify a -D argument while using maven it is passing system arguments to maven not to your spring app. If you read https://docs.spring.io/spring-boot/docs/current/maven-plugin/examples/run-system-properties.html it shows you need to use the syntax
mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Dproperty1=overridden"
The easy answer is dont use maven to execute your spring boot app. Produce a jar and execute it with java -jar
Do any of your values contain perhaps a space, or other shell busting character? Quotes are your friend here
Does a more basic java -jar target/project.jar -Dspring.datasource.url=... do anything different?
On the export SPRING_DATASOURCE_URL ... variant, can you properly echo $SPRING_DATASOURCE_URL and get the expected value back? For all the env variables?
If you use simple values like XXX and YYY instead of real values, does that do anything different?
Trying to distinguish between the mechanism and the data...
Are the ${url}, ${user} and ${password} (or ${passwrod} even) literal (eg: env variables themselves) or just elided here for brevity?
There just was a typo. It's spring.datasource. username, not user (or SPRING_DATASOURCE_USERNAME). Really sorry for waisting time on that.
Related
I want to execute some old code in java, but it's becoming complicated with old versions of it. Therefore, I wanted to create my "Java aliases" so the command "java11" would execute the java 11 binary command. Unfortunately, on mac, I was not successful.
I tried to follow tutorials wanting to add an alias part in your ~/.zshrc. I did that, and it works perfectly, but it doesn't work for bash scripts, which is really annoying.
Here is the line for my java11 alias in the .zshrc:
alias java11="/Library/Java/JavaVirtualMachines/jdk-11.0.11.jdk/Contents/Home/bin/java $#"
(I don't know if it would do anything, but I also added the alias lines in my .bashrc)
Aliases have limited usefulness for things like this. They need to be configured in a shell initialization file (and which file is used depends on the shell, what mode it's started in, etc), they're disabled by default in scripts, and they aren't available at all when the command is executed by something other than a shell (e.g. in sudo java11 ..., it's sudo that does the execution, and it doesn't know anything about aliases).
I'd recommend creating an actual command instead. Since this is just another name for an existing binary (/Library/Java/JavaVirtualMachines/jdk-11.0.11.jdk/Contents/Home/bin/java), you can just use a symbolic link to the original binary (for something more complex, it might make sense to create a wrapper script instead). /usr/local/bin doesn't exist by default in macOS, but it is in the default PATH (in most contexts except cron jobs, grrr), so if you create it, it'll be searched automatically. So something like this should work:
sudo mkdir -p /usr/local/bin
sudo ln -s /Library/Java/JavaVirtualMachines/jdk-11.0.11.jdk/Contents/Home/bin/java /usr/local/bin/java11
In your running zsh sessions, you'll probably have to run rehash to get them to notice the new binary. And remove the alias, to keep it from overriding the new command.
i'm very new to this world.. so forgive me for silly explanations.
I've installed maven and all the setting is done. Also i created a maven.sh
Content:
# Apache Maven Environment Variables
# MAVEN_HOME for Maven 1 - M2_HOME for Maven 2
export JAVA_HOME=/usr/lib/jvm/java-11
export M2_HOME=/opt/apache-maven
export MAVEN_HOME=/opt/apache-maven
export PATH=${M2_HOME}/bin:${PATH}
At this point everything is working as expected, but every time i close the terminal it seems to forget some settings..
I have to open the terminal and execute the following commands to make it work again:
~$ cd /etc/profile.d
~$ source maven.sh
I don't know if it is just the way to use maven or i'm missing something, but it's kind of annoying writting the same commands every single time i want to execute maven.. so i would appreciate if you can explain me a way to automate it.
Some extra information:
OS : Ubuntu 20.0.4
JDK : 11
Not first time creating JAVA_HOME variable
After executing those commands above, it shows the correct JAVA_HOME, but it's forgotten after closing the terminal and shows the wrong JAVA_HOME again
Let me tell you guys, this is my first question on stackoverflow, so i will understand if you want to correct me about my manners and my bad english (it's not my mother tongue, i have to get used to it)
Thank you in advance!
I can think of a couple of ways you could resolve this problem given your situation, which is not maven-specific but rather terminal-specific --
Add a reference to your maven.sh script to your profile so that it runs when you start a terminal session. This can typically be accomplished by creating (or adding to) the .bash_profile file in your home directory. You could either add the contents of your maven.sh script to that file, or add source /etc/profile.d/maven.sh to it. From that point forward when you start a terminal session, the script gets run automatically and your variables are set correctly. See https://joshstaiger.org/archives/2005/07/bash_profile_vs.html or the bash man page for some more details about the login shell
If you've already done the first step and it didn't work, consider checking to see if those environment variables are being set in another place (check ~/.bashrc, ~/.bash_profile, and anywhere your particular shell distribution / OS checks for startup scripts
Lastly, I recommend using SDKMan! to manage maven installs without these headaches -- but your mileage may vary. It handles keeping track of the environment variables, java version, &c and allows multiple Java/Maven versions to be installed and managed. https://sdkman.io
Sources:
https://joshstaiger.org/archives/2005/07/bash_profile_vs.html
https://linux.die.net/man/1/bash
https://sdkman.io
You can add these properties to individual user settings file. This file will be available in home directory
vi $HOME/.bash_profile
So everytime, you login to terminal, all these settings will be executed.
I solved the problem by doing a logout and login in Ubuntu
I'm trying to run spring boot app with systemd service of ubuntu.
In my service file, I have ExecStart variable
ExecStart=/bla/run.sh
And variables:
Environment="DB_HOSTNAME=ip"
Environment="DB_PORT=5432"
...
(I have tried both variants: with and without braces)
My sh file looks like:
#!/bin/sh
echo jdbc:postgresql://${DB_HOSTNAME}:${DB_PORT}/${DB_NAME}
sudo /usr/bin/java -jar bla.jar
Inside sh variables are available as well, but spring application does not deal with them. The same with the active profile variable.
I thought that the problem is about the scope of variables and I tried to pass them to another sh from the main one. But in another script they are available, so the problem only with spring app.
Update
Trick with export does not help
Maybe it will helpful for somebody.
The main problem was using sudo for starting java app.
After removing sudo variables become available.
I have a spring-boot based application that uses log4j2.xml in a dockerized environment.
When I launch the docker I pass -e "LOG4J_PATH=/tmp/app.log" to specify where the logs should go to.
Next, in the log4j2.xml I use fileName="${env:LOG4J_PATH}" but this doesn't work. I searched the web for hours and thus tried double $ and tried sys instead of env... nothing.
This System.getenv("LOG4J_PATH") and (new EnvironmentLookup()).lookup("LOG4J_PATH") work fine, so I know that the variable is being passed to the running image ok, but from some reason the log4j doesn't seem to pick it up.
If I run this not via a docker and set the LOG4J_PATH environment variable in my .bash_profile it works fine so this is something between docker and log4j.
What am I doing wrong?
I believe you need to change the key value structure a bit for your passed environment variable. Can you try
docker run -e LOG4J_PATH='/tmp/app.log'
I'm creating a Dockerfile for our Spring Boot application. The application takes a couple of command line parameters. At the end of Dockfile:
CMD java -jar Application.jar --bucket=bucket.list --key=lost
But is it a best practice to hardcode the values for bucket and key in the Dockfile?
If it is ok, then I can live with that. Otherwise, I would like to know how to parameterize the Dockfile.
The application will be deployed on AWS, if that opens the door for more suggestions.
Docker design focused in being independent as far as possible of Host environment, including when building a Docker image. There were a request to let Docker build accessing to host environmental variables but it was rejected looking for independence of host machine. There it is also commented some workaround that could fit your problem.
Anyway, what is supposed to do Application.jar? If it's an application supposed to be running inside the container (and not in building time) the correct way to launch it is using a custom script run when you start the container. There you can set your credential or any other information you wish to be accessed from a environment variable, that can be set when launching the container: docker run -e "MYKEY=secret" -e "MYBUCKET=bucket" myuser/myapp /my/custom/script
You can use environment variables or build arguments.
Build arguments allow you to specify parameters that are applied at buildtime when you execute docker build using the --build-arg ARG_NAME=ARG_VALUE command line parameter.
Environment variables allow you to specify parameters that are applied at runtime when you execute docker run using the -e "ENV_NAME=ENV_VALUE" command line parameter.