Page History

...

• A typical build command could look like this:
  
  

  Code Block
  language bash title Build Command linenumbers true
  #!/bin/sh IMAGE_NAME="Mastermaster-1-13" docker build --no-cache --rm --tag=$IMAGE_NAME --file=./build/Dockerfile --network=js --build-arg="USER_ID=$UID" ./build

...

• A typical run command could look like this:
  
  

  Code Block
  language bash title Run Command linenumbers true
  #!/bin/sh IMAGE_NAME="Mastermaster-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 the USE jobscheduler instruction in the Dockerfile.
  • 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 the testsuite sub-directory is created from the value of the JobScheduler ID that is specified with the installer response file.
  • The --mount option is used in order to map a previously created Docker volume (assumed to be the value of the src= option) e.g. to the JobScheduler Master's live folder. This allows to read and write job related files to this directory that will automatically be picked up by JobScheduler Master.

...