DevOps

Configuring a Datasource in a Docker Container

In this post I am going to show how to configure a datasource consumed by an ADF application running on Tomcat in a Docker container.

Docker Container

So, there is a Docker container sample-adf with a Tomcat application server preconfigured with ADF libraries and with an ADF application running on top of Tomcat. The ADF application requires a connection to an external database.

The application is implemented with ADF BC and it’s application module is referring to a datasource jdbc/appDS.

Docker Container

This datasource is configured inside a container in Tomcat /conf/context.xml file. The JDBC url, username and password are provided by environment variables:

<Resource name="jdbc/appDS" auth="Container"
type="oracle.jdbc.pool.OracleDataSource"
factory="oracle.jdbc.pool.OracleDataSourceFactory"
url="${DB_URL}"
user="${DB_USERNAME}"
password="${DB_PWD}"
...

These variables are propagated to the application server in Tomcat / bin/setenv.sh file:

CATALINA_OPTS='-DDB_URL=$DB_URL -DDB_USERNAME=$DB_USERNAME -DDB_PWD=DB_PWD ...

Having these configurations set, we can run a container providing values of the variables:

docker run –name adf -e DB_URL=”jdbc:oracle:thin:@myhost:1521:xe” -e DB_USERNAME=system -e DB_PWD=welcome1 sample-adf

If we are about to run a container in a K8s cluster we can provide variable values in a yaml file:

spec:
spec:
      containers:
      - image: sample-adf
        env:
        - name: DB_URL
           value: "jdbc:oracle:thin:@myhost:1521:xe"
        - name: DB_USERNAME
          value: "system"
        - name: DB_PWD
          value: "welcome1"

In order to make this yaml file portable we would avoid providing exact values and refer to K8s  ConfigMaps and Secrets instead of that

ConfigMap is a named K8s resource that allows us to decouple configuration artifacts from image content to keep containerized applications portable. This is just a simple set of key-value paires. And obviously those values in each K8s cluster, in each environment are different.

Similar approach is used when it comes to sensitive data like user names and passwords. Only in this case instead of configmaps we use a special resource which is called
Secret. The data is encoded and it is only sent to a node if a pod on that node requires it. It is deleted once the pod that depends on it is deleted.

We can create ConfigMaps and Secrets out of key-value files or just by providing the values in a command line:

kubectl create configmap adf-config  
from-literal=db.url="jdbc:oracle:thin:@myhost:1521:xe"

kubectl create secret generic adf-secret 
--from-literal=db.username="system" 
--from-literal=db.pwd="welcome1"

Having done that we can specify in the yaml file that values for the environment variables should be fetched from adf-config ConfigMap and adf-secret Secret:

spec:
containers:
- image: sample-adf
env:
- name: DB_URL
valueFrom:
configMapKeyRef:
name: adf-config
key: db.url
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: adf-secret
key: db.username
- name:
DB_PWD
valueFrom:
secretKeyRef:
name: adf-secret
key: db.pwd

That’s it!

Published on Java Code Geeks with permission by Eugene Fedorenko , partner at our JCG program. See the original article here: Configuring a Datasource in a Docker Container

Opinions expressed by Java Code Geeks contributors are their own.

Eugene Fedorenko

I am a Senior Architect at Flexagon focusing on ADF and many other things.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Back to top button