Deploying a base container image to multiple instances with unique database connection

Support
#1

We are attempting to design a deployment procedure that will allow us to maintain a single master Docker Image for our application that we can use to deploy to many customers. We are also planning on deploying to Tomcat but this is not a requirement nor set in stone at this point. The limitation I am running into is configuring the connection string to the database per container instance. When deploying a container you can pass through environment variables into the container however it does not appear that the context.xml file used in Tomcat to define the connection string is properly replacing the environment variables used in the file with the values defined in the environment. I have seen some reference on other forums stating this is known behavior and that the context.xml file is static and will not use environment variables.

Does any one have any experience with this or have any suggestions on how to accomplish what we are trying to do?

#2

Hi Corey,

this is possible. I created an blog post around that topic when i deployed an application to amazon:

the basic idea is to create a bash script that will translate the ENV variables form docker to property values in the catalina.properties file.

If you have any questions, don’t hesitate to ask :slight_smile:

Bye
Mario

#3

Thanks for the reply. You know I must not have been paying enough attention to that blog post the first time I read it as I actually did read through it once before. I see you explain how to set the DB.Host property, is it also possible to set the actual database name and credentials used to connect to the db in this properties file as well? This may be getting a little too deep into Tomcat territory now but what it the difference between setting these things at the Catalina.properties level vs in the context.xml level?

Good stuff on your blog by the way keep it up. I had previously posted this question on Stack Overflow, do you mind if I post a link to your blog as an answer to my own question over there?
Thank you,
Corey

#4

Hi,

In case of Uber JAR deployment you can provide custom jettyEnvPath: UberJAR Deployment - CUBA Platform. Developer’s Manual But I cannot say how to use it with Docker, since it requires additional file with settings.

#5

hi,
good that it works. Actually i found that we already had this discussion:
[url=https://www.cuba-platform.com/discuss/t/one-build-for-multiple-applications]https://www.cuba-platform.com/discuss/t/one-build-for-multiple-applications[/url]
there are actually several options to do it. You can read more in the topic.
The catalina.properties worked out for me, i’m not 100% sure where the difference is. One thing is that this setting is for the whole tomcat while context.xml is the context for aparticular war. But since i used tomcat only for one war per container & tomcat it does not really matter.
You can set any property you want (see [url=https://github.com/mariodavid/cuba-ordermanagement/blob/cuba-on-aws-ecs/deployment/docker-image/app-core/container-files/start.sh#L11]cuba-ordermanagement/start.sh at cuba-on-aws-ecs · mariodavid/cuba-ordermanagement · GitHub for more examples). You just have to pick it up in the context.xml as well: [url=https://github.com/mariodavid/cuba-ordermanagement/blob/cuba-on-aws-ecs/deployment/docker-image/app-core/container-files/context.xml#L11]cuba-ordermanagement/context.xml at cuba-on-aws-ecs · mariodavid/cuba-ordermanagement · GitHub
The only thing that is problematic is the dbms type (like switching from oracle to postgres), because you need the driver jars somehow (you could embed them into the war file, this would probably work…
Bye
Mario