- This article explains a simplified build process for Controller images that is extracted from the SOS build environment.
- Users can build their own Docker images for Controllers.
For the build environment the following directory hierarchy is assumed:
The root directory
controller can have any name. Note that build script listed below will, by default, use the directory name and release number to determine the resulting image name.
The build script
build.sh and entrypoint script
entrypoint.sh are described below.
Docker images for JS7 Controllers provided by SOS make use of the following Dockerfile:
- The build script implements two stages to exclude installer files from the resulting image.
- Line 3: The base image is the current Alpine image at build-time.
- Line 6 - 7: The release identification is injected by build arguments. This information is used to determine the tarball to be downloaded or copied.
- Line 10 - 11: You can either download the Controller tarball directly from the SOS web site or you store the tarball with the build directory and copy from this location.
Line 13 - 15: The tarball is extracted. For Unix Controllers no installer is used.
Line 18: The
entrypoint.shscript is copied from the build directory to the image. Users can apply their own version of the entrypoint script. The entrypoint script used by SOS looks like this:
- Line 21: The
configfolder available in the build directory is copied to the
configsub-folder in the image. This can be useful to create an image with individual default settings in configuration files, see JS7 - Controller Configuration Items.
- Line 34 - 38: Defaults for the Controller ID and user id running the Controller inside the container as well as HTTP and HTTPS ports are provided. These values can be overwritten by providing the respective build arguments.
- Line 41 - 45: 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 54 - 60: The image OS is updated and additional packages are installed (ps, netstat, bash,).
- Line 61: The most recent Java 1.8 package available with Alpine is applied. Controllers can be operated with newer Java releases, however, stick to Oracle, OpenJDK or AdoptOpenJDK as the source for your Java LTS release. Alternatively you can use your own base image and install Java 1.8 or later on top of this.
- Line 62 - 65: The user account
jobscheduleris 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 Controller 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 Controller in mounted volumes with identical permissions.
- Line 66: Java releases < Java 12 make use of
/dev/randomfor random number generation. This is a bottleneck as random number generation with this file is blocking. Instead
/dev/urandomshould be used that implements non-blocking behavior. The change of the random file is applied to the Java security file.
- Line 73-75: The entrypoint script and Controller start script are executed and are dynamically parameterized from environment variables when starting the container.
The build script offers a number of options to parameterize the Dockerfile:
- Line 12 - 23: 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 the release of JS7 that you want to build a Controller for.
- the repository which by default is
- the image name is determined from the current folder name and the release number.
- the user id by default is the user id of the user running the build script.
- the Controller ID can be specified that is a unique identifier for a Controller installation.
- the HTTP port and HTTPS port: if the respective port is not specified then the Controller 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 28 - 53: The above options can be overwritten by command line arguments like this:
- Line 60 - 71: The effective
docker buildcommand is executed with arguments. The Dockerfile is assumed to be located with the
buildsub-directory of the current directory.