Scope
- JobScheduler Master is operated with a Docker container.
- Prerequisites
- The JobScheduler Master requires a database to be available from any physical or virtual host or from a Docker container.
- Consider to prepare the files indicated with chapter Build.
Build
The following files are required for the build context:
Dockerfile
- Installer Response file
jobscheduler_install.xml
with individual installation settings. A template of this file is available when extracting the installer tarball. - Start Script
start_jobscheduler.sh
- JobScheduler Master installer tarball as available from SOS for download.
Dockerfile
Download: Dockerfile
- Explanations
- Line 1: We start from an Alpine image that includes JDK 8. Newer Java version can be used, see Which Java versions is JobScheduler available for?
- Line 5: Consider that $UID provides the numeric ID of the account that the JobScheduler Master installation inside the Docker container is performed for. This numeric ID typically starts above 1000 and should correspond to the account that is used on the Docker host, i.e. the account on the Docker Host and the account inside the container should use the same numeric ID. This mechanism simplifies exposure of the Docker container's file system.
- Line 8-9: Adjust the JobScheduler release number as required.
- Line 12-16: The installer tarball is copied and extracted to the container.
- Line 22-23: The installer response file is copied to the container, for details of this file see next chapter. Then the installer is executed for the current user.
- Line 26-28: An account and group "jobscheduler" is created that is handed over ownership of installed files.
- Line 31-32: The start script is copied to the container, see below chapter Start Script.
- Line 35: A volume is indicated for later mapping to a mount point at run-time.
- Line 38: Port 40444 is exposed for later mapping. This port is used for the connection between JOC Cockpit and JobScheduler Master.
- Line 41: The account "jobscheduler" that is the owner of the installation is exposed for later mapping. This account should be mapped at run-time to the account in the Docker Host that will mount the exposed volume.
- Line 43: The start script is executed to launch the JobScheduler Master daemon.
Installer Response File
Download: jobscheduler_install.xml
- Explanations
- The above installer response file works for releases 1.13. Other releases ship with different versions of this file. You should pick-up a template of this file that matches your JobScheduler release by extracting the installer tarball.
- Generally all defaults of the response file can be maintained.
- This includes use of port 40444 for the connection of JOC Cockpit to the Master. At run-time this port can be mapped, see Dockerfile.
- Line 182-233: The database connection makes use of a hostname "mysql-5-7" that is assumed to be the hostname of a Docker container in the same Docker network running the MySQL database.
- Modify the database connection settings as required for use with your DBMS and access credentials.
Start Script
Download: start_jobscheduler.sh
Start Script#!/bin/sh /opt/sos-berlin.com/jobscheduler/testsuite/bin/jobscheduler.sh start without-change-user && tail -f /dev/null
- Explanations
- Line 3: The standard start script
jobscheduler.sh
is used. Thetail
command prevents the start script from terminating in order to keep the container alive. The sub-directorytestsuite
represents the JobScheduler ID that is specified with the above installer response file.
- Line 3: The standard start script
Build Command
There are a number of ways how to write a build command, find the following example:
A typical build command could look like this:
Build Command#!/bin/sh IMAGE_NAME="master-1-13" docker build --no-cache --rm --tag=$IMAGE_NAME --file=./build/Dockerfile --network=js --build-arg="USER_ID=$UID" ./build
- Explanations
- Using a common network for JobScheduler components allows direct access to resources such as ports within the network. The network is required at build time to allow the installer to create and to populate the JobScheduler database.
- Consider use of the
--build-arg
that injects theUSER_ID
environment variable into the image with the numeric ID of the account running the build command. This simplifies later access to the volume exposed by the Dockerfile as the same numeric user ID and group ID inside and outside of the container are used.
Run
There are a number of ways how to write a run command, find the following example:
- Before starting the container consider to create a Docker volume to persistently store configuration files in the
live
folder of the JobScheduler Master installation:- Create Docker Volume
#!/bin/sh IMAGE_NAME="master-1-13" docker volume create --name=$IMAGE_NAME ln -s /var/lib/docker/volumes/$IMAGE_NAME/_data/ ./live sudo chmod o+r /var/lib/docker sudo chmod o+rx /var/lib/docker/volumes sudo chown -R $USER:$USER /var/lib/docker/volumes/$IMAGE_NAME
- Explanations
- Create the Docker volume with an arbitrary name, e.g. the image name.
- Create a symlink
live
that points to the Docker volume - Adjust permissions to allow the current user to read/execute from docker volumes. Make the current user the owner of the newly created volume.
- This configuration will expose the Master's live directory to the Docker volume and allows the current user to add/update/delete configuration files to the
live
folder.
A typical run command could look like this:
Run Command#!/bin/sh IMAGE_NAME="master-1-13" RUN_USER_ID="$(id -u $USER):$(id -g $USER)" mkdir -p /some/path/logs docker run -dit --rm --user=$RUN_USER_ID --hostname=$IMAGE_NAME --network=js --publish=50444:40444 --mount="type=volume,src=$IMAGE_NAME,dst=/var/sos-berlin.com/jobscheduler/testsuite/config/live" --volume=/some/path/logs:/var/log/sos-berlin.com/jobscheduler/testsuite:Z --name=$IMAGE_NAME $IMAGE_NAME
- Explanations
- Using a common network for JobScheduler components allows direct access to resources such as ports within the network.
- The
RUN_USER_ID
variable is populated with the numeric ID of the account and the group that executes the run command. This value is assigned the--user
option to inject the account information into the container (replacing the account specified with theUSE jobscheduler
instruction in the Dockerfile). - Port 40444 for access to JobScheduler Master by JOC Cockpit can optionally be mapped to some outside port. This is not required if a network is used.
- Specify a
logs
directory to be created that is referenced with the--volume
option to expose the log directory of the JobScheduler Master for reading. Consider that thetestsuite
sub-directory is created from the value of the JobScheduler ID that is specified with the installer response file. Avoid to modify log files in this directory and to add new files. - The
--mount
option is used in order to map a previously created Docker volume (assumed to be the value of thesrc=
option) e.g. to the JobScheduler Master'slive
folder. This allows to read and to write job related files to this directory that will automatically be picked up by JobScheduler Master.