Oracle Essbase Docker June Update

The Oracle Essbase on Docker open source project continues to evolve and be refined. For some background, please check out the original announcement. Briefly, this open source project gives you the ability to combine Oracle’s Essbase installer files along with the Docker technology to build a lean, mean, fully configured Essbase server (for development and testing purposes).

The following improvements have been made:

  • Ability to apply patches
  • Out of the box configuration of SQL ODBC data source (for load rules)
  • Further reductions in image size and number of Docker layers
  • Add convenience variables


This is the major feature in this release. The previous version of the Dockerfile would generate a perfect Essbase server – version to be precise. I’ve now added the ability to also include patches and have them be applied in an arbitrary order. For instance, the typical files that you need to combine with the scripts in this project would be Oracle’s installation media for EPM, which is, similar files for Parts 2, 3, 4, and updated Java JDK files. You can now include a folder named /patches with a subdirectory for a given patch level that contains the patches from Oracle. For example, here is my cloned docker-essbase Git repository to which I have added the EPM installation files from Oracle:

-rwxrwxr-x 1 jason jason        442 May 31 02:05
 -rwxrwxr-x 1 jason jason       6057 May 31 02:15
 -rw-rw-r-- 1 jason jason        966 Jan  7 20:57
 -rw-rw-r-- 1 jason jason       1020 May 17 02:25 docker-compose.yml
 -rw-rw-r-- 1 jason jason       7377 May 23 15:25 Dockerfile
 -rwxrwxr-x 1 jason jason 1368259501 Dec 28 21:25
 -rw-rw-r-- 1 jason jason      13700 May 17 02:24 essbase-config.xml
 -rw-rw-r-- 1 jason jason        939 Jan  3 19:28 essbase-install.xml
 -rwxrwxr-x 1 jason jason         47 Jan  3 19:29
 -rwxrwxr-x 1 jason jason        177 Jan  3 19:20
 -rwxrwxr-x 1 jason jason 1174052554 Dec 28 21:22
 -rwxrwxr-x 1 jason jason 1516370785 Dec 28 21:22
 -rwxrwxr-x 1 jason jason  980505762 Dec 28 21:22
 -rwxrwxr-x 1 jason jason 1529284475 Dec 28 21:22
 -rw-r--r-- 1 jason jason  145798191 Feb  6 20:14 jdk-7u211-linux-x64.tar.gz
 -rw-r--r-- 1 jason jason  153530841 Jan  8 06:47 jdk-7u80-linux-x64.tar.gz
 -rwxr-xr-x 1 jason jason     611504 Dec 31 21:19 jtds12.jar
 -rw-rw-r-- 1 jason jason       1058 Mar 18 18:21 LICENSE
 -rw-rw-r-- 1 jason jason        607 Jan 15 05:42 load-sample-databases.msh
 -rw-r----- 1 jason jason       1312 May 31 02:16 odbc.ini
 drwxrwxr-x 4 jason jason       4096 May 14 21:50 patches
 -rw-rw-r-- 1 jason jason      14792 Mar 20 17:23
 -rwxrwxr-x 1 jason jason        523 Jan  9 19:03
 -rwxrwxr-x 1 jason jason         51 Jan  9 18:57
 -rw-rw-r-- 1 jason jason       5049 Jan  9 19:48
 drwxrwxr-x 2 jason jason       4096 Mar  4 16:23 start_scripts
 -rw-rw-r-- 1 jason jason         80 Jan 14 20:03
 -rw-rw-r-- 1 jason jason        148 May 31 02:19

Notice the /patches folder. In my case it contains two subfolders:

drwxrwxr-x 2 jason jason 4096 May 14 21:50 000
drwxrwxr-x 2 jason jason 4096 May 31 02:01 031

Inside the 031 folder I have the patches for EPM downloaded from Oracle, although I have prepended them with 01-, 02-, 03- and so on in order to force them to be applied in a particular order. There are multiple patches because in total they update the Essbase server itself, EAS, APS, and runtime files. Here is the contents of my 031 folder:

-rw-r--r-- 1 jason jason 61727995 May  7 15:12
 -rw-r--r-- 1 jason jason  9542502 May  7 15:12
 -rw-r--r-- 1 jason jason 71810346 May  7 15:12
 -rw-r--r-- 1 jason jason 13241287 May  7 15:57
 -rw-rw-r-- 1 jason jason      629 May 31 02:01 README.txt

The Dockerfile now has a build argument called PATCH_LEVEL that accepts a three-digit code to indicate which folder of patches to apply. So to build the Essbase image for patch level 031, I can run the following:

docker build --build-arg PATCH_LEVEL=031

How we’re using this internally is that we now create the image for any given patch level and then just tag it accordingly. For instance, we can run any given version of Essbase by using a container name of essbase: or just essbase:latest as the case may be (which currently points to .031).

Out of the box SQL ODBC Configuration

In order for Essbase load rules to load data from a SQL data source (especially on Linux) a little bit of file configuration needs to be performed. This is the odbc.ini file. Now, on startup, this file is configured with the proper database name and credentials, allowing you to use it in a load rule. For the time being I just configured the default database to be the HSS database that is created during configuration. This gives you a working database and configuration that works for testing or playing around and you can use it as the basis of a ‘real’ ODBC connection.

Further Image Size Reductions

The very original version of the Docker Essbase image from two years ago (and from my first presentation on this!) was around 40GB (!). This was the old ‘monolithic’ image that included a full install of an Oracle RDBMS as well as taking an image size hit because of copying over the large Essbase installation zip files. When this project went open source, it was after one of the major improvements was made to it, which was to use docker-compose to separate out the relational database from the Essbase server. Further, I configured the image to use an ‘off the shelf’ Microsoft SQL Server (on Linux) Docker image, which simplified setup/configuration since there isn’t/wasn’t a comparable Oracle Docker image. This got the image size down to 10GB or so. Also as part of the open source project I used Docker’s relatively new ‘multi-stage build’ feature in order to break the image build in to two major pieces. This allowed me to avoid the penalty from copying over the Essbase installer .zip files. All this got the image size down to around 6GB.

From there the image size has slowly been whittled down a bit here and a bit there. The entire system has been consolidated down to a single Java JDK (versus three full copies) and numerous files and directories that are obviously unneeded (probably) have been deleted. In this latest version of the image, a few more things are tossed overboard in the interest of having a smaller image size. The overall image size has been sitting around 4GB for the last few months but I found a few more patch storage locations that aren’t needed. That’s kind of the great thing about Docker: these images are meant to be used and thrown away. So it’s not like we need to keep around some inventory of patches in case we need to rollback (rollback? More like roll out a new image!).

Summary / See You At Kscope

I’ll be presenting on Docker & Essbase at Kscope19 in Seattle later this month. I’ll cover how to get up and running with your own Docker Essbase instance in the easiest way possible, as well as general updates and other fun things going on in this realm. Hope to see you there!

Leave a Reply

Your email address will not be published. Required fields are marked *