Table of Contents

Introduction

This article explains a simplified build process for JOC Cockpit images which is extracted from the SOS build environment.
Users can build their own Docker container images for JOC Cockpit.

Build Environment

The following directory hierarchy is assumed for the build environment:

...

The joc root directory can have any name. The build files listed above are available for download. Note that the build script described below will, by default, use the directory name and release number to determine the resulting image name.

Dockerfile

Download: Dockerfile

Docker Container images for JS7 JOC Cockpit 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 JOC Cockpit tarball directly from the SOS web site or you can store the tarball with the build directory and copy from this location.
Line 13 - 15: The tarball is extracted.

Line 18: the joc_install.xml response file is copied to the image. This file includes settings for headless installation of the JOC Cockpit, see JS7 - JOC Cockpit Installation On Premises. In fact a JOC Cockpit installation is performed when building the image.

Code Block

language	xml
title	JOC Cockpit Installer Response File
linenumbers	true
collapse	true

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!--
     XML configuration file for JOC

If you call the installer with this XML file then
you accept at the same time the terms of the
licence agreement under GNU GPL 2.0 License
(see http://www.gnu.org/licenses/gpl-2.0.html)
-->
<AutomatedInstallation langpack="eng">
    <com.izforge.izpack.panels.UserInputPanel id="home">
        <userInput/>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.HTMLLicencePanel id="gpl_licence"/>
    <com.izforge.izpack.panels.TargetPanel id="target">

        <!-- SELECT THE INSTALLATION PATH
                          It must be absolute!
             For example:
             /opt/sos-berlin.com/joc on Linux
             C:\Program Files\sos-berlin.com\joc on Windows -->
        <installpath>/opt/sos-berlin.com/js7/joc</installpath>

    </com.izforge.izpack.panels.TargetPanel>
    <com.izforge.izpack.panels.UserInputPanel id="jetty">
        <userInput>

            <!-- JOC requires a servlet container such as Jetty.
                                  If a servlet container already installed then you can use it.
                 Otherwise a Jetty will be installed in addition if withJettyInstall=yes.
                 You need root permissions to install JOC with Jetty. -->
            <entry key="withJettyInstall" value="yes"/>
            <entry key="jettyPort" value="4446"/>
            <!-- Specify the name of the Windows service or Linux Daemon (default: joc).
                                  Only necessary for multiple instances of JOC on one server. It must be
                 unique per server. This entry is deactivated by a comment because it
                 MUST NOT BE CHANGED DURING OVER-INSTALLATION! -->
            <!--
                             <entry key="jettyServiceName" value="joc"/>
            -->
            <!-- Only necessary for Windows -->
            <entry key="jettyStopPort" value="44446"/>
            <!-- Only necessary for Unix (root permissions required) -->
            <entry key="withJocInstallAsDaemon" value="yes"/>
            <!-- To enter a JOC User (default=current User).
                                  For Unix only (root permissions required)!!! -->
            <entry key="runningUser" value="jobscheduler"/>
            <!-- Path to Jetty base directory
                                  For example:
                 /home/[user]/sos-berlin.com/joc on Linux
                 C:\ProgramData\sos-berlin.com\joc on Windows -->
            <entry key="jettyBaseDir" value="/var/sos-berlin.com/js7/joc"/>

            <!-- Choose (yes or no) wether the JOC's Jetty should be (re)started at the end of the installation -->
            <entry key="launchJetty" value="no"/>

            <!-- Java options for Jetty. -->
            <!-- Initial memory pool (-Xms) in MB -->
            <entry key="jettyOptionXms" value="128"/>
            <!-- Maximum memory pool (-Xmx) in MB -->
            <entry key="jettyOptionXmx" value="512"/>
            <!-- Thread stack size (-Xss) in KB -->
            <entry key="jettyOptionXss" value="4000"/>
            <!-- Further Java options -->
            <entry key="jettyOptions" value=""/>

        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="joc">
        <userInput>

            <!-- JOC can be installed in a cluster. Please type a unique title to identify the cluster node,
                 e.g. hostname. Max. length is 30 characters -->
            <entry key="jocTitle" value="PRIMARY JOC COCKPIT"/>

            <!-- Choose yes if JOC is a standby node in a cluster -->
            <entry key="isStandby" value="no"/>

            <!-- Security Level for the signing mechanism: possibly values are 'LOW', 'MEDIUM' and 'HIGH'
                 HIGH:
                    public PGP keys are stored for verification only
                    all signing will be done externally outside of JOC Cockpit
                 MEDIUM:
                    a private PGP key will be stored for signing
                    signing will be done automatically with the provided key
                 LOW:
                    no keys will be stored
                    signing will be done internally with default keys -->
            <entry key="securityLevel" value="LOW"/>

        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="database">
        <userInput>
            <!-- Reporting Database Configuration -->

            <!-- Database connection settings can be specified with following entries such as
                                  databaseHost, databasePort, ... or by a hibernate configuration file
                 Posible values are 'withoutHibernateFile' (default) and 'withHibernateFile'. -->
            <entry key="databaseConfigurationMethod" value="withoutHibernateFile"/>

            <!-- Choose the database management system. Supported values are 'mysql' for MySQL,
                                  'oracle' for Oracle, 'mssql' for MS SQL Server, 'pgsql' for PostgreSQL.

                 Only if databaseConfigurationMethod=withoutHibernateFile -->
            <entry key="databaseDbms" value="mysql"/>

            <!-- Path to a hibernate configuration file if databaseConfigurationMethod=withHibernateFile -->
            <entry key="hibernateConfFile" value=""/>

           <!-- You can choose between 'on' or 'off' to create the database tables.
                 If you have modified the initial data of an already existing installation,
                 then the modifications will be undone. Data added remains unchanged.
                 This entry should be only 'off', when you sure, that all tables are already created. -->
            <entry key="databaseCreateTables" value="off"/>

        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="dbconnection">
        <userInput>
            <!-- Database Configuration if databaseConfigurationMethod=withoutHibernateFile -->

            <!-- Enter the name or ip address of the database host
                                  This entry can also be used to configure the URL(s) for Oracle RAC databases.
                 For example:
                 <entry key="databaseHost" value="(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=OFF)(FAILOVER=ON)
                    (ADDRESS=(PROTOCOL=TCP)(HOST=tst-db1.myco.com)(PORT=1604))
                    (ADDRESS=(PROTOCOL=TCP)(HOST=tst-db2.myco.com)(PORT=1604)))
                    (CONNECT_DATA=(SERVICE_NAME=mydb1.myco.com)(SERVER=DEDICATED)))"/>
                 The "databaseSchema" and "databasePort" entries should then be left empty. -->
            <entry key="databaseHost" value=""/>

            <!-- Enter the port number for the database instance. Default ports are for MySQL 3306,
                                  Oracle 1521, MS SQL Server 1433, postgreSQL 5432. -->
            <entry key="databasePort" value=""/>

            <!-- Enter the schema -->
            <entry key="databaseSchema" value=""/>

            <!-- Enter the user name for database access -->
            <entry key="databaseUser" value=""/>

            <!-- Enter the password for database access -->
            <entry key="databasePassword" value=""/>

        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="jdbc">
        <userInput>
            <!-- Database Configuration -->

            <!-- You can specify an external JDBC connector then set internalConnector = no
                                  For license reasons MySQL, MS SQL Server and Oracle ojdbc7 JDBC
                 drivers are not provided.
                 Alternatively you can use the mariadb JDBC Driver for MySQL and
                 the jTDS JDBC Driver for MS SQL Server which is provided.
                 An Oracle ojdbc6 JDBC driver is also provided. -->

            <!-- You can choose between 'yes' or 'no' for using the internal JDBC connector
                                  or not -->

            <entry key="internalConnector" value="yes"/>

            <!-- Select the path to JDBC Driver -->
            <entry key="connector" value=""/>

        </userInput>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.UserInputPanel id="end">
        <userInput/>
    </com.izforge.izpack.panels.UserInputPanel>
    <com.izforge.izpack.panels.InstallPanel id="install"/>
    <com.izforge.izpack.panels.ProcessPanel id="process"/>
    <com.izforge.izpack.panels.FinishPanel id="finish"/>
</AutomatedInstallation>

Line 19: The entrypoint.sh script 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:
Download: entrypoint.sh

Code Block

language	bash
title	JOC Cockpit Entrypoint Script
linenumbers	true
collapse	true

#!/bin/sh

JETTY_BASE="/var/sos-berlin.com/js7/joc"

startini_to_startd() {
  # convert once ${JETTY_BASE}/resources/joc/start.ini to ${JETTY_BASE}/resources/joc/start.d
  if [ -d "${JETTY_BASE}/start.d" ]; then
    if [ -f "${JETTY_BASE}/resources/joc/start.ini" ] && [ -d "${JETTY_BASE}/resources/joc/start.d" ]; then
      echo "convert start.ini to start.d ini files"
      for file in "${JETTY_BASE}"/resources/joc/start.d/*.ini; do
        module="$(basename "$file" | cut -d. -f1)"
        echo "processing module ${module}"
        while read -r line; do
          modulevariablekeyprefix="$(echo "${line}" | cut -d. -f1,2)"
          if [ "${modulevariablekeyprefix}" = "jetty.${module}" ] || [ "${modulevariablekeyprefix}" = "jetty.${module}Context" ]; then
            modulevariablekey="$(echo "${line}" | cut -d= -f1 | sed 's/\s*$//g')"
            echo "${line}"
                        sed -i "s;.*${modulevariablekey}\s*=.*;${line};g" "${file}"
          fi
        done < "${JETTY_BASE}/resources/joc/start.ini"
      done
      mv -f "${JETTY_BASE}/resources/joc/start.ini" "${JETTY_BASE}/resources/joc/start.in~"
    fi
  fi
}

add_start_configuration() {
  # overwrite ini files in start.d if available from config folder
  if [ -d "${JETTY_BASE}/start.d" ]; then
    if [ -d "${JETTY_BASE}/resources/joc/start.d" ]; then
      for file in "${JETTY_BASE}"/resources/joc/start.d/*.ini; do
        echo "copy ${file} -> ${JETTY_BASE}/start.d/"
        cp -f "$file" "${JETTY_BASE}/start.d/"
      done
    fi
  fi
}

add_jdbc_and_license() {
  # if license folder not empty then copy js7-license.jar to Jetty's class path
  if [ -d "${JETTY_BASE}/resources/joc/license" ]; then
    if [ -f "${JETTY_BASE}/resources/joc/lib/js7-license.jar" ]; then
      echo "copy ${JETTY_BASE}/resources/joc/lib/js7-license.jar -> ${JETTY_BASE}/lib/ext/joc/"
      cp -f "${JETTY_BASE}/resources/joc/lib/js7-license.jar" "${JETTY_BASE}/lib/ext/joc/"
    fi
  fi
  # if JDBC driver added then copy to Jetty's class path and move exiting JDBC drivers back to avoid conflicts
  if [ -d "${JETTY_BASE}/resources/joc/lib" ]; then
    if [ -n "$(ls "${JETTY_BASE}"/resources/joc/lib/*.jar 2>/dev/null | grep -v "js7-license.jar")" ]; then
      for file in "${JETTY_BASE}"/lib/ext/joc/*.jar; do
        if [ "$(basename "$file")" != "js7-license.jar" ]; then
          echo "move ${file} -> ${JETTY_BASE}/resources/joc/lib/$(basename "$file")~"
          mv -f "$file" "${JETTY_BASE}/resources/joc/lib/$(basename "$file")~"
        fi
      done
      for file in "${JETTY_BASE}"/resources/joc/lib/*.jar; do
        echo "copy ${file} -> ${JETTY_BASE}/lib/ext/joc/"
        cp -f "$file" "${JETTY_BASE}/lib/ext/joc/"
      done
    fi
  fi
}

patch_jars() {
  if [ -d "${JETTY_BASE}/resources/joc/patches" ]; then
    echo "extract patch files if exist"
    ls "${JETTY_BASE}"/resources/joc/patches/*.jar 2>/dev/null
    if [ -n "$(ls "${JETTY_BASE}"/resources/joc/patches/*.jar 2>/dev/null)" ]; then
      if [ -d "${JETTY_BASE}/webapps/joc/WEB-INF/classes" ]; then
        CUR_DIR="$(pwd)"
        cd "${JETTY_BASE}/webapps/joc/WEB-INF/classes"
        for file in "${JETTY_BASE}"/resources/joc/patches/*.jar; do
          echo "extract ${file} -> ${JETTY_BASE}/webapps/joc/WEB-INF/classes"
          unzip -o "${file}"
        done
        cd "${CUR_DIR}"
      fi
    fi
  fi
}

# create Jetty start script
echo "#!/bin/sh" > /usr/local/bin/start-joc.sh
echo "/opt/sos-berlin.com/js7/joc/jetty/bin/jetty.sh start && tail -f /dev/null" >> /usr/local/bin/start-joc.sh
chmod +x /usr/local/bin/start-joc.sh

startini_to_startd
add_start_configuration


if [ ! "$RUN_JS_HTTP_PORT" = "" ]
then
  if [ -f "${JETTY_BASE}/start.d/http.in~" ] && [ ! -f "${JETTY_BASE}/start.d/http.ini" ]; then
    # enable http access in start.d directory
    mv "${JETTY_BASE}/start.d/http.in~" "${JETTY_BASE}/start.d/http.ini"
  fi
  if [ -f "${JETTY_BASE}/start.d/http.ini" ]; then
    # set port for http access in start.d directory
    sed -i "s/.*jetty.http.port\s*=.*/jetty.http.port=$RUN_JS_HTTP_PORT/g" "${JETTY_BASE}/start.d/http.ini"
  fi
else
  if [ -f "${JETTY_BASE}/start.d/http.ini" ]; then
    # disable http access in start.d directory
    mv -f "${JETTY_BASE}/start.d/http.ini" "${JETTY_BASE}/start.d/http.in~"
  fi
fi

if [ ! "$RUN_JS_HTTPS_PORT" = "" ]
then
  if [ -f "${JETTY_BASE}/start.d/https.in~" ] && [ ! -f "${JETTY_BASE}/start.d/https.ini" ]; then
    # enable https access in start.d directory
    mv "${JETTY_BASE}/start.d/https.in~" "${JETTY_BASE}/start.d/https.ini"
  fi
  if [ -f "${JETTY_BASE}/start.d/ssl.in~" ] && [ ! -f "${JETTY_BASE}/start.d/ssl.ini" ]; then
    # enable https access in start.d directory
    mv "${JETTY_BASE}/start.d/ssl.in~" "${JETTY_BASE}/start.d/ssl.ini"
  fi
  if [ -f "${JETTY_BASE}/start.d/ssl.ini" ]; then
    # set port for https access in start.d directory
    sed -i "s/.*jetty.ssl.port\s*=.*/jetty.ssl.port=$RUN_JS_HTTPS_PORT/g" "${JETTY_BASE}/start.d/ssl.ini"
  fi
else
  if [ -f "${JETTY_BASE}/start.d/https.ini" ]; then
    # disable https access in start.d directory
    mv -f "${JETTY_BASE}/start.d/https.ini" "${JETTY_BASE}/start.d/https.in~"
  fi
  if [ -f "${JETTY_BASE}/start.d/ssl.ini" ]; then
    # disable https access in start.d directory
    mv -f "${JETTY_BASE}/start.d/ssl.ini" "${JETTY_BASE}/start.d/ssl.in~"
  fi
fi

if [ -n "$RUN_JS_JAVA_OPTIONS" ]
then
  export JAVA_OPTIONS="${JAVA_OPTIONS} $RUN_JS_JAVA_OPTIONS"
fi


JS_USER_ID=$(echo "$RUN_JS_USER_ID" | cut -d ':' -f 1)
JS_GROUP_ID=$(echo "$RUN_JS_USER_ID" | cut -d ':' -f 2)

BUILD_GROUP_ID=$(cat /etc/group | grep jobscheduler | cut -d ':' -f 3)
BUILD_USER_ID=$(cat /etc/passwd | grep jobscheduler | cut -d ':' -f 4)

add_jdbc_and_license
patch_jars

if [ "$(id -u)" = "0" ]
then
  if [ ! "$BUILD_USER_ID" = "$JS_USER_ID" ]
  then
    echo "JS7 entrypoint script switching ownership of image user id '$BUILD_USER_ID' -> '$JS_USER_ID', group id '$BUILD_GROUP_ID' -> '$JS_GROUP_ID'"
    usermod -u "$JS_USER_ID" jobscheduler
    groupmod -g "$JS_GROUP_ID" jobscheduler
    find /var/sos-berlin.com/ -group "$BUILD_GROUP_ID" -exec chgrp -h jobscheduler {} \;
    find /var/sos-berlin.com/ -user "$BUILD_USER_ID" -exec chown -h jobscheduler {} \;
    find /var/log/sos-berlin.com/ -group "$BUILD_GROUP_ID" -exec chgrp -h jobscheduler {} \;
    find /var/log/sos-berlin.com/ -user "$BUILD_USER_ID" -exec chown -h jobscheduler {} \;
  fi

  echo "JS7 entrypoint script switching to user account 'jobscheduler' to run start script"
  echo "JS7 entrypoint script starting JOC Cockpit: exec su-exec jobscheduler:$JS_GROUP_ID /opt/sos-berlin.com/js7/joc/jetty/bin/jetty.sh start"
  exec su-exec jobscheduler:"$JS_GROUP_ID" /usr/local/bin/start-joc.sh
else
  if [ "$BUILD_USER_ID" = "$JS_USER_ID" ]
  then
    if [ "$(id -u)" = "$JS_USER_ID" ]
    then
      echo "JS7 entrypoint script running for user id '$(id -u)'"
    else
      echo "JS7 entrypoint script running for user id '$(id -u)' cannot switch to user id '$JS_USER_ID', group id '$JS_GROUP_ID'"
      echo "JS7 entrypoint script missing permission to switch user id and group id, consider to omit the 'docker run --user' option"
    fi
  else
    echo "JS7 entrypoint script running for user id '$(id -u)' cannot switch image user id '$BUILD_USER_ID' -> '$JS_USER_ID', group id '$BUILD_GROUP_ID' -> '$JS_GROUP_ID'"
    echo "JS7 entrypoint script missing permission to switch user id and group id, consider to omit the 'docker run --user' option"
  fi

  echo "JS7 entrypoint script starting JOC Cockpit: exec sh -c /opt/sos-berlin.com/js7/joc/jetty/bin/jetty.sh start"
  exec sh -c "/usr/local/bin/start-joc.sh"
fi

Note that the entrypoint script runs the JOC Cockpit start script using exec sh -c. This is required to run the JOC Cockpit inside the current process that is assigned PID 1. A later docker kill <container> command will send a SIGKILL signal to the process with PID 1 only. If JOC Cockpit were started directly as a shell script without use of exec then a new process with a different PID would be created. This means that the docker kill command would not be successful and, for example, would not cause a fail-over between clustered JOC Cockpit containers.

Line 22: The config folder available in the build directory is copied to the appropriate config folder in the image. This can be useful for creating an image with individual settings in configuration files, see the JS7 - JOC Cockpit Configuration Items article for more information.
- The hibernate.cfg.xml specifies the database connection. This file is not used at build-time. However, it is provided as a sample for run-time configuration. You will find details in the JS7 - Database article.
- The default https-keystore.p12 and https-truststore.p12 files are copied that would hold the private key and certificate required for server authentication with HTTPS. By default empty keystore and truststore files are used that users would add their private keys and certificates to at run-time.
Line 35 - 38: 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 41 - 44: 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 55 - 61: The image OS is updated and additional packages are installed (ps, netstat, bash).
Line 62: The most recent Java 11 package available with Alpine is applied. JOC Cockpit 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. For details see Which Java versions is JobScheduler available for?
Line 63 - 64: Java releases might make use of /dev/random for random number generation. This is a bottleneck as random number generation with this file is blocking. Instead /dev/urandom should be used that implements non-blocking behavior. The change of the random file is applied to the Java security file.
Line 65: The jobscheduler user account is created and assigned the user id and group id handed over by the relevant 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 67 - 70: The JOC Cockpit setup is performed.

Line 74 - 75: The keystore and truststore locations are added to the Jetty start.d/ssl.ini file and joc.properties file respectively.

start.d/ssl.ini is used for access e.g. by client browsers:

Code Block

language	bash
title	Jetty HTTPS Configuration File start.d/ssl.ini
linenumbers	true
collapse	true

## Keystore file path (relative to $jetty.base)
jetty.sslContext.keyStorePath=resources/joc/https-keystore.p12

## Truststore file path (relative to $jetty.base)
jetty.sslContext.
trustStorePath=resources/joc/https-truststore.p12

## Keystore password
jetty.sslContext.keyStorePassword=jobscheduler

## KeyManager password (same as keystore password for pkcs12 keystore type)
jetty.sslContext.keyManagerPassword=jobscheduler

## Truststore password
jetty.sslContext.trustStorePassword=jobscheduler

## Connector port to listen on
jetty.ssl.port=4443

joc.properties.add is used for connections to the Controller if such connections require HTTPS mutual authentication:

Code Block

language	bash
title	JOC Cockpit configuration File joc.properties.add
linenumbers	true
collapse	true

################################################################################
### Location, type and password of the Java truststore which contains the
### certificates of eachJobScheduler Controller for HTTPS connections. Path can be
### absolute or relative to this file.

keystore_path = ../../resources/joc/https-keystore.p12
keystore_type = PKCS12
keystore_password = jobscheduler
key_password = jobscheduler

truststore_path = ../../resources/joc/https-truststore.p12
truststore_type = PKCS12
truststore_password = jobscheduler

Line 77: The Jetty servlet container is added the HTTPS module for use with the JOC Cockpit.
Line 106 - 108: The entrypoint script and start script are executed and dynamically parameterized from environment variables which are forwarded when starting the container.

Build Script

The build script offers a number of options to parameterize the Dockerfile:

...

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 id of the user running the build script.
- the HTTP port and HTTPS port: if the relevant port is not specified then the JOC Cockpit will not listen to that port for the protocol in question. 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 container's host. However, you can modify ports as you like.
- Java options: typically you would specify default values for, for example, 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 - 50: The above options can be overwritten by command line arguments like this:
Code Block
language bash
title Running the Build Script with Arguments
linenumbers true
./build.sh --http-port=14445 --https-port=14443 --java-options="-Xmx1G"
Line 54 - 63: The effective docker build command is executed with arguments. The Dockerfile is assumed to be located with the build sub-directory of the current directory.

...

Space shortcuts

Page tree

Versions Compared

Old Version 1

New Version Current

Key

Introduction

Build Environment

Dockerfile

Build Script

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 1

New Version Current

Key

Introduction

Build Environment

Dockerfile

Build Script