Oracle Database Connection in HCL Commerce v9

Photo by Campaign Creators on Unsplash

If you want to deploy HCL Commerce using DB2 and the out-of-the-box database connection credentials, it’s pretty simple using the createSampleConfig section of the provided Helm chart.

But if your company chose Oracle, well that is a different story.

IBM’s Proposed Approach

IBM’s Knowledge Center (that is destined for closure at some point very soon) suggests building a specific Docker image for every Commerce image leveraging the existing entry point mechanism at startup.

There are two important problems to this approach:

• Loss of neutrality of HCL Commerce images
• The need to modify the out-of-the-box run engine commands to specify encrypted database credentials

Photo by Carson Masterson on Unsplash

In particular, if we’re following the IBM guidelines, we’ll be forced to build a different set of HCL Commerce images every time the credentials needs to be changed and execute several run engine commands and adding Oracle driver files, as below:

If you are using the Oracle database, run the add-datasource-oracle command to set the database name, and the user name and password to connect to the database. Run the add-system-property command to set the database type to Oracle:

#!/bin/bash run add-datasource-oracle oracle <database> <dbHost> <dbPort> <dbUser> <dbPass> false <sslConnection> run add-system-property dbtype oracle

Add the following line to the Dockerfile script. The COPY command copies the Oracle JDBC driver to connect to the remote Oracle database.

COPY ojdbc8.jar /opt/WebSphere/Liberty/usr/shared/resources/

The ones that run engine commands like “add-datasource” get the database parameters from a clear text string (dbPass) in the command line. And this is usually not compliant with security patterns.

A different way of connecting to Oracle

The alternative to maintaining image neutrality and managing application secrets like database passwords is to use a Docker startup mechanism:

HCL Commerce container startup logic

IBM suggests choosing “CONFIGURE_MODE” = Vault, which sets Vault to be used for storing secrets like database passwords.

This choice forces us to store all the container parameters (secrets or not) in Vault, following the metadata structure proposed by IBM (we’ll review a different strategy in a new post).

And unfortunately, configuring Vault is not straightforward at all, in particular due to the lack of clarity in existing documentation.

So, we clearly need a new solution!

Practical steps to connect to Oracle

1. Deploy Vault using the Helm chart provided by IBM
2. Get the Vault token from container logs
3. Fill the database credentials in the Vault structure
4. Create a k8s secret called “commerce-vault-token” and add Vault token
5. Specify “vaultTokenSecret” variable to the Helm chart with “commerce-vault-token” value

Don’t forget that Vault is deployed in development mode using ibm-commerce-vaultconsul Helm chart and it cannot be used in production environments.

Your values.yaml in the Helm chart should look like:

You’re then ready to deploy Commerce connecting the instance to a v9 Oracle database!

Commerce images won’t be touched and database credentials will be pulled from Vault during the container startup process.

Nice work!