Introduction

For JS7 - Automated Deployment use of a Deployment Area is recommended.

The Deployment Area is used for the following purposes:

• to hold the script environment for JS7 - Automated Installation and Update and the JS7 - Deployment Packaging Script,
• to hold the configuration files and certificates for deployment of JS7 components,
• to hold the JS7 installations per JS7 release and component such as JOC Cockpit, Controller, Agent,
• to hold the archive of deployment packages per JS7 releases and target machine,
• to operate a JS7 Agent that is used to perform the JS7 - Deployment Workflow.

Preparing the Deployment Area

Setting up the Deployment Area

Download of Deployment Area Tarball

A tarball for the directories and scripts of the Deployment Area is provided:

Download tarball: 

curl "https://download.sos-berlin.com/JobScheduler/js7_deploy.tar.gz" --output "js7_deploy.tar.gz"

Extracting the Deployment Area Tarball

Extract the Deployment Area tarball to an arbitrary directory. The tarball includes the top-level directory js7.deploy, therefore the following command will extract to $HOME/js7.deploy.

cd $HOME
tar -xzf js7.deploy.tar.gz

After extraction users find the following directory layout:

• js7.deploy
  • archive (empty, holds the resulting Deployment Packages)
  • bin (holds Scripts)
  • ca (holds the Certificate Authority)
  • config (holds configuration templates)
  • desc (holds JS7 - Deployment Descriptor Examples)
  • release (empty, used for JS7 installation tarballs)
  • work (empty, used for temporary installation)
  • env.sh (Environment Script)

Find more details about included directories and files from the JS7 - Deployment Area - Directory Layout article.

Users can rename and relocate the top-level folder js7.deploy at their will.

Setting up the Environment Script

The env.sh Environment Script is extracted to the js7.deploy top-level folder. The script creates a number of environment variables that indicate the directories in use.

Adjusting Locations in the Environment Script

Users can adjust the location of directories to their needs:

#!/bin/sh

SCRIPT_HOME=${HOME}/js7.deploy

DEP_ARCHIVE="${DEP_ARCHIVE:-$SCRIPT_HOME/archive}"
DEP_BIN="${DEP_BIN:-$SCRIPT_HOME/bin}"
DEP_CA="${DEP_CA:-$SCRIPT_HOME/ca}"
DEP_CONFIG="${DEP_CONFIG:-$SCRIPT_HOME/config}"
DEP_DESC="${DEP_DESC:-$SCRIPT_HOME/desc}"
DEP_RELEASE="${DEP_RELEASE:-$SCRIPT_HOME/release}"
DEP_WORK="${DEP_WORK:-$SCRIPT_HOME/work}"

JAVA_HOME="/usr/lib/jvm/jdk-11.0.2"
PATH=${JAVA_HOME}/bin:${PATH}

export JAVA_HOME PATH DEP_ARCHIVE DEP_BIN DEP_CA DEP_CONFIG DEP_DESC DEP_RELEASE DEP_WORK

Explanation:

• Line 3: The top-level directory of the Deployment Area is specified. By default the js7.deploy directory in the user's home directory is assumed.
• Line 5-11: The environment variables indicate the location of the directories extracted from the Deployment Area tarball. Users who wish a different location adjust the variables to their needs.
  • The default values act as a fallback if one of the DEP_* environment variables is not set.
  • Users can specify an absolute path, for example: DEP_RELEASE=/mnt/releases/js7 if the location of JS7 installation tarballs should be different from the default location.
• Line 13-14: The location of the Java JDK is specified with the JAVA_HOME environment variable. Users have to adjusts the environment variable to the location of their Java JDK.
  • Typically Java LTS releases 11 and newer can be used. For Agent and Controller Java 1.8 can be used. For details see Which Java versions is JobScheduler available for?
  • The PATH environment variable is adjusted to point to the location of the bin sub-directory of Java.
• Line 16: The environment variables are exported and made available for use with the Deployment Area scripts.

Running the Environment Script

The Environment Script has to be executed to make environment variables know to the Deployment Area scripts.

The script has to be sourced, this means the call to the script is preceded by a dot and a space like this:

. ./env.sh

Creating the Root Certificate Authority

Connections between the JS7 JOC Cockpit, Controller and Agents can be secured by TLS/SSL certificates used for HTTPS connections.

Users who do not wish to use HTTPS connections or who are provided certificates from their organization can skip this step.

Creating the Root CA Certificate

A Root CA Certificate is created and is later on used to create self-signed certificates

The script is included with the ca directory and is executed without arguments.

./ca/create_root_ca.sh

Explanation:

• When the script is executed it prompts for a number of options. Find more details about use of the script with the JS7 - How to create self-signed Certificates article.
• The following files will be created:
  • ./ca/private/root-ca.key: This file holds the Root CA private key.
  • ./ca/certs/root-ca.crt:  This file holds the Root CA Certificate.

Download JS7 Release

It is good practice to download the installation .tar.gz files for the desired JS7 releases from the SOS Web Site and to store them to a directory hierarchy like this:

• js7.deploy
  • release
    • 2.4.0
      • js7_agent_unix.2.4.0.tar.gz
      • js7_controller_unix.2.4.0.tar.gz
      • js7_joc_linux.2.4.0.tar.gz
    • 2.5.0
      • js7_agent_unix.2.5.0.tar.gz
      • js7_controller_unix.2.5.0.tar.gz
      • js7_joc_linux.2.5.0.tar.gz

Users are free to choose the directory hierarchy at their will.

Download JS7 Installation Archives

Download can be performed in a number of ways. The curl utility can be used for this purpose.

curl "https://download.sos-berlin.com/JobScheduler.2.5/js7_agent_unix.2.5.0.tar.gz" --output "js7_agent_unix.2.5.0.tar.gz"
curl "https://download.sos-berlin.com/JobScheduler.2.5/js7_controller_unix.2.5.0.tar.gz" --output "js7_controller_unix.2.5.0.tar.gz"
curl "https://download.sos-berlin.com/JobScheduler.2.5/js7_joc_linux.2.5.0.tar.gz" --output "js7_joc_linux.2.5.0.tar.gz"

Creating Certificates

Users who do not wish to use HTTPS connections or who are provided certificates from their organization can skip this step.

#!/bin/sh

set -e

SCRIPT_HOME=$(cd "$(dirname "$0")" >/dev/null && pwd)

DEP_CA=${DEP_CA:-$(dirname "${SCRIPT_HOME}")/ca}
DEP_BIN=${DEP_BIN:-$(dirname "${SCRIPT_HOME}")/bin}
DEP_CONFIG=${DEP_CONFIG:-$(dirname "${SCRIPT_HOME}")/config}

create_self_signed_certs()
{
  server=$1
  config=$2

  ${DEP_CA}/create_certificate.sh --dns=${server},${server}.sos --days=365

  if [ ! -d "${config}" ]
  then
      mkdir -p "${config}"
  fi

  cp ${DEP_CA}/certs/${server}.crt ${config}/

  ${DEP_BIN}/js7_create_certificate_store.sh \
    --keystore=${config}/https-keystore.p12 \
    --truststore=${config}/https-truststore.p12 \
    --key=${DEP_CA}/private/${server}.key \
    --cert=${DEP_CA}/certs/${server}.crt \
    --alias=${server} \
    --password=jobscheduler \
    --ca-root=${DEP_CA}/certs/root-ca.crt \
    --chain \
    --make-dirs
}


# Function               Host                 Location
create_self_signed_certs centostest-primary   ${DEP_CONFIG}/agents/instances/agent_001/config/private
create_self_signed_certs centostest-secondary ${DEP_CONFIG}/agents/instances/agent_002/config/private

create_self_signed_certs centostest-primary   ${DEP_CONFIG}/controllers/instances/standalone/config/private
create_self_signed_certs centostest-primary   ${DEP_CONFIG}/controllers/instances/cluster.primary/config/private
create_self_signed_certs centostest-secondary ${DEP_CONFIG}/controllers/instances/cluster.secondary/config/private

create_self_signed_certs centostest-primary   ${DEP_CONFIG}/joc/instances/standalone/resources
create_self_signed_certs centostest-primary   ${DEP_CONFIG}/joc/instances/cluster.primary/resources
create_self_signed_certs centostest-secondary ${DEP_CONFIG}/joc/instances/cluster.secondary/resources

Creating Deployment Packages