Introduction
- Users can build their own Docker images for JOC Cockpit.
- This article explains options how to create the JOC Cockpit image.
Build Environment
For the build environment the following directory hierarchy is assumed:
js7-joc
build.sh
build
Dockerfile
start-joc.sh
config
The root directory js7-joc
could have any name. Consider that below build script by default will use the directory name to determine the resulting image name.
The build script build.sh
and JOC Cockpit start script start-joc.sh
are explained below.
Dockerfile
Docker images for JS7 JOC Cockpit provided by SOS make use of the following Dockerfile:
Explanations:
- Line 1: The base image is OpenJDK Java 1.8 (Debian based). You can run JOC Cockpit with newer Java releases, however, stick to Oracle, OpenJDK or AdoptOpenJDK as the source for your Java base image. Alternatively you can use your own base image and install Java 1.8 on top of this. Consider that availability of JDBC Drivers can limit the Java version to be used.
- Line 8 - 9: The release identification is injected by build arguments. This information is used to determine the tarball to be downloaded.
- Line 12 - 15: Defaults for the user id running the JOC Cockpit inside the container as well as HTTP and HTTPS ports are provided. These values can be overwritten by providing the respective build arguments.
- Line 20 - 22: Environment variables are provided at run-time, not at build-time. They can be used to specify ports and Java options when running the container.
- Line 32 - 33: You can either download the JOC Cockpit tarball directly from the SOS web site or you store the tarball with the build directory and copy from this location.
- Line 46: the
joc_install.xml
response file is copied to the image. This file includes settings for headless installation of JOC Cockpit, see JS7 - JOC Cockpit Installation On Premises. In fact when building the image a JOC Cockpit installation is performed. - Line 47: the
hibernate.cfg.xml
configuration file is copied that holds the database connection settings for JOC Cockpit. The database has to be available during build of the Docker image. Users can later on choose a different database connection by modifying/overwriting this file at run-time. Line 48: The
start-joc.sh
script is copied from the build directory to the image. Users can apply their own version of the start script. The start script used by SOS looks like this:- Line 51 - 52: The user account
jobscheduler
is created and is assigned the user id and group id handed over by the respective build arguments. This translates to the fact that the account running the JOC Cockpit inside the container and the account that starts the container are assigned the same user id and group id. This allows the account running the container to access any files created by the JOC Cockpit in mounted volumes with identical permissions. - Line 53: The JOC Cockpit setup is performed.
- Line 59: The Jetty servlet container is added the HTTPS module for use with JOC Cockpit.
- Line 62 - 63: The default keystore and truststore is copied that hold the private key and certificate required for server authentication with HTTPS.
- Line 66 - 69: The keystore and truststore locations are added to the Jetty
start.ini
file andjoc.properties
file respectively.start.ini
is used for access e.g. by client browsers.joc.properties
is used for connections to the Controller should such connections require HTTPS mutual authentication.
- Line 72: if a
config
folder is available in the build directory then its contents is copied to the respectiveconfig
folder in the image. This can be useful to create an image with individual settings in configuration files, see JS7 - JOC Cockpit Configuration Items. - Line 80: The HTTP port and optionally the HTTPS port are exposed to the Docker host. Both ports can be forwarded by environment variables when running the container, overwriting the build-time values. This is relevant only if users want to use ports inside the container that are different from the default values. In most situations the default ports should be fine and are mapped to outside ports on the Docker host when starting the container.
- Line 85: The start script is executed and is dynamically parameterized from environment variables that are forwarded when starting the container.
Build Script
The build script offers a number of options to parameterize the Dockerfile:
Explanations:
- Line 12 - 22: Default values are specified that are used if no command line arguments are provided. This includes values for
- the release number: adjust this value to a current release of JS7.
- the repository which by default is
sosberlin:js7
. - the image name is determined from the current folder name and the release number.
- the user id is by default the user id of the user running the build script.
- the Docker network: the build script assumes a Docker network to be used for which a name is specified.
- the HTTP port and HTTPS port: if the respective port is not specified then the JOC Cockpit will not listen to a port for the respective protocol. You can for example disable the HTTP protocol by specifying an empty value. The default ports should be fine as they are mapped by the run script to outside ports on the Docker host. However, you can modify ports as you like.
- Java options: typically you would specify default values e.g. for Java memory consumption. The Java options can be overwritten by the run script when starting the container, however, you might want to create your own image with adjusted default values.
- Line 27 - 52: The above options can be overwritten by command line arguments like this:Running the Build Script with Arguments
./build.sh --network=js --http-port=14445 --https-port=14443 --java-options="-Xmx1G"
- Line 56 - 66: The effective
docker build
command is executed with arguments. The Dockerfile is assumed to be located with thebuild
sub-directory of the current directory.