Managing Dev, Test, Training Apex environment with Docker

For sure DevOps operation are great with help from Docker technology and obviously Apex developers can get good stuff from it on any OS (Linux/Windows/Mac) too.

My latest post was about how to get a Docker image ready with latest Apex 5.1.2, now some tips on what and how a Docker image including Oracle XE/Apex can help you on a day to day basics.

Development environments

First typical usage is Docker for development, now is possible to get an Apex environment in one click or command:

docker run -d — shm-size=1g — name apex — hostname apex \
-p 1521:1521 -p 8080:8080 \
-v $PWD/apex-as-postscripts:/u01/app/oracle/scripts/setup \
-v apex-5.1.4:/u01/app/oracle/oradata \
oracle/database:11.2.0.2-xe

above command will launch an Oracle XE with Apex 5.1.2 ready to use at http://localhost:8080/apex/apex_admin log using admin/{pwd} where {pwd} is defined during first run, see it using:

docker logs apex|more

Image for post
Image for post
Sample output of XE/Apex log

at the example we are using an Docker volume for our Oracle datafiles (-v apex-5.1.4:/u01/app/oracle/oradata) later, if we stop/remove apex container there is a possibility to re-create it again using same datafiles (no data lost), but if we execute docker volume rm apex-5.1.2 or docker volume prune these datafiles will be destroyed and our Apex application will be deleted too.

During our Apex development time this docker container can be stopped (docker stop apex) and started again (docker start apex) many times, stop means shutdown the database and start means startup.

Apart from http://localhost:8080/apex/apex_admin web access you have access using SQLPlus to the port 1521 for importing/exporting application's data, for example.

If you wanna to start and isolated Dev environment from the previous one simple execute another run with different storage, port and name for your container, for example:

docker run -d — shm-size=1g — name apex1 — hostname apex \
-p 15121:1521 -p 8081:8080 \
-v $PWD/apex-as-postscripts:/u01/app/oracle/scripts/setup \
-v apex-5.1.4-app1:/u01/app/oracle/oradata \
oracle/database:11.2.0.2-xe

and that's all, port 8080 stand for apex container and port 8081 for apex1, remember that before destroy your docker container and volume you could export your Apex application from the web interface, for example:

Image for post
Image for post
Export/Import sample screen from Apex App. builder

Testing Apex applications

Testing scenarios are different from Development because We need a fresh and repeatable Apex installation, for a fresh installation you could use a docker run like:

docker run -d — shm-size=1g — name apex — hostname apex \
-p 1521:1521 -p 8080:8080 \
-v $PWD/apex-as-postscripts:/u01/app/oracle/scripts/setup \
oracle/database:11.2.0.2-xe

Note that we removed a docker volume association (-v flag), so once you run this container it will recreated as a new Oracle XE instance with Apex installed, but it will take a long time and you have an admin password randomly generated each time.

To solve that We can get help for a Copy On Write file-system such as BTRFs or ZFS. A COW file-system usually have a simple way to take an snapshot of a directory (or volume), so is easily to create a fresh Apex installation, take an snapshot and re-create a container many times.

For this example I'll use a btrfs plugin which is simple and consistent with my installation:

Image for post
Image for post

To start using BTRFs plugin run this command:

once you have this plugin running you can start a new container as:

note that We added — volume-driver=btrfs to replace the default driver, once your Apex/XE instance start and shows that your database is ready to use you can change the random generated password and set a new one, for example Apex!2017

Image for post
Image for post
Change initial random generated password

now you have a fresh Apex installation, lets do an snapshot using BTRFs plugin, first shutdown your database using docker stop apex:

once you have the snapshot, you can create as many new volume as you want, for example:

above operations are too fast because a COW file-system do not actually copy (2.3Gb datafiles) all blocks until a block have changes, to start a new container using some of the above volume use:

note that we are changing containers names, ports and volume for each new container, now you have for new Apex instances for testing running at port 8081 and 8082. If you are CI/CD environment and want to re-create this process again every day simple follow this sequence:

Training Apex on Docker

Above use case have a particular useful variation when you have to do course, having a fresh instance and multiples clones of that for each student is great, for example, assuming that you have apex-5.1.4 BTRFs volume ready and apex container stopped a shortcut commands are:

each course student will have http://server:808[1..N]/apex/apex_admin URL access using his own private Apex installation, if you need to do some pre-course installation first apply on apex container and then create the snapshots, remember that snapshot creation is very fast and the Apex startup time will depend on how many blocks changed from the base image.

That's all, happy Apex on Docker for all your need!!!

Instead of using btrfs command line for creating an snapshot I sent a patch for BTRFs plugin and once it will approved you can operate it using btrfs_plugin command:

with similar functionalities.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store