Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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.

...

  • Desired State Configuration
    • The JS7 - Deployment Descriptor specifies the desired state of the installation and configuration on a number of target machines.
    • The concept includes not to deploy individual files or configuration items but to view an installation holistically with all installation files and configuration files being deployed to guarantee consistency.
  • Provisioning
    • Considering Desired State Configuration it makes no difference if a JS7 component will be initially installed, will be updated, upgraded or patched.
    • Deployment processes are repeatable at any time. This suggests not to rely on backups of target machines for the purpose of restoring JS7 components in case of data loss. Instead, deployment is repeated in case that a target machine has to be newly set up. Consider which data will be lost in case that a target machine's file system will crash:
      • Log Data: retention of older JS7 component log files might not be your primary concern in a crash situation. At the same time most recent additions to log files might anyway be lost. Consider that log data exclude job logs and order logs that are streamed in near real-time from Agents via Controller instances to the JOC Cockpit database.
      • Transaction Data: due to the ephemeral nature of JS7 - Order State Transitions there is no way to consistently backup a Controller's or Agent's journal. Instead, clustering of Controller and Agent instances on separate hosts brings the required redundancy.
      • For details see JS7 - How to backup the job scheduling environment.
  • Probing
    • The deployment process includes to temporarily install JS7 components in the working area of the Deployment Area. 
    • This allows users to check if all required configuration files including certificates are in place.
    • In most situations it will be possible to start up the JS7 components on the Deployment Area. This might not include for example to run jobs with a JS7 Agent as the job environment might not be available with the Deployment Area. However, it allows to check if the JS7 component will perfectly start - using the expected configuration items such as certificates - and will terminate normally. In addition it includes to check the JS7 component's log files for warnings and errors on start-up and termination.
  •  Parallelism
    • During upgrade to newer minor JS7 releases users might find an inconsistent status of JS7 components.
      • This applies to upgrading, for example from a 2.2.1 release to a 2.4.1 release. 
      • This does not apply to updating, for example from a 2.2.1 release to a 2.2.3 release.
    • A newer Controller release 2.5.1 might not work with an older Agent release 2.2.3. As the Controller has to be upgraded before Agents are upgraded users might find a period during which no jobs are executed on Agents using older releases. In fact the related orders will not be lost, however, they will be put to the BLOCKED state until the Agent is upgraded. It is therefore preferable to have the duration for upgrading a larger number of Agents as short as possible.
    • The JS7 - Deployment Workflow provides unlimited parallelism for deployments as it can run thousands of tasks in parallel on the same Agent.
      • Typically the time to shut down a JS7 Agent, to replace its installation and to restart the JS7 Agent requires less than 60s.
      • When stopping Agents this will allow an individual Agent to delay termination until any running tasks are completed. This includes to delay the update/upgrade process. At the same time this guarantees that no running tasks are killed. However, users can force immediate termination of Agents during deployment, see JS7 - Agent Command Line Operation.
  • Fallback
    • Though use of a Deployment Area allows probing to some extent there might be situations when deployment to a target machine fails. Such situations frequently do not suggest lengthy analysis of the target machine but immediate action to roll back the installation and to fall back to the previous release.
    • With Deployment Packages and Deployment Descriptors for previous releases being available from the Deployment Area users can initiate the fallback procedure to deploy a previous release within seconds.
    • Error handling in Deployment Workflows allows to decide if deployments are considered being failed for example with a single Agent not being successfully deployed or if user intervention is required to decide if processing of the Deployment Workflow should be cancelled or if execution for individual target machines should be retried.

Prerequisites

The JS7 - Deployment Packaging Script requires the jq utility to be installed and available from the operating system. 

...

  1. Create a .json file as the JS7 - Deployment Descriptor.
  2. Run the JS7 - Deployment Packaging Script indicating the .json Deployment Descriptor file. This step will create related Deployment Packages in the <archive>/<deployment-descriptor> directory.
  3. Run the JS7 - Deployment Workflow
    • Import the js7_import.tar.gz Deployment Workflow file available from the <archive>/<deployment-descriptor> directory to JOC Cockpit, for details see JS7 - Inventory Export and Import.
    • Check the imported workflow and adjust to your needs, for example assignment of an Agent with access to the deployment directories in the Deployment Area.
    • Adjust the imported schedule to your needs should you want to schedule execution of deployments to a specific date and time. Alternatively you can add an ad hoc order to the Deployment Workflow from the JOC Cockpit's Workflows view. This step offers to copy the parameterization available from the schedule to the current order.
    • Run the Deployment Workflow from a scheduled order or from an ad hoc order and check results.

...

  • archive (holds Deployment Packages)
    • <deployment-descriptor> (specifies the Deployment Descriptor)
      • agents (holds Agent Deployment Packages)
        • <agent-id>(specifies the Agent ID)
          • js7_deploy_agent_unix.<agent-id>.<release>.config.tar.gz (Deployment Package for the Agent's configuration directory)
          • js7_deploy_agent_unix.<agent-id>.<release>.install.tar.gz (Deployment Package for the Agent's installation directory)
          • run_deploy_agent.sh (deployment script)
          • run_install_agent.sh (wrapper script for the parameterized call to js7_install_agent.sh)
        • <agent-id>(specifies the Agent ID)
        • ...
      • controllers (holds Controller Deployment Packages)
        • <controller-id> (specifies the Controller ID)
          • <instance-type> (specifies the type of the Controller instance which is primary or secondary
            • js7_deploy_controller_unix.<controller-id>.<instance-type>.<release>.config.tar.gz (Deployment Package for the Controller instance's configuration directory)
            • js7_deploy_controller_unix.<controller-id>.<instance-type>.<release>.install.tar.gz (Deployment Package for the Controller instance's installation directory)
            • run_deploy_controller.sh (Deployment Script)
            • run_install_controller.sh (Wrapper Script for the parameterized call to the js7_install_controller.sh Installer Script)
          • <instance-type> (specifies the type of the Controller instance which is primary or secondary
        • <controller-id> (specifies the Controller ID)
        • ...
      • joc (holds JOC Cockpit Deployment Packages)
        • <joc-id>(specifies the JOC Cockpit ID)
          • <instance-type> (specifies the type of the JOC Cockpit instance which is primary or secondary
            • js7_deploy_joc_linux.<joc-id>.<instance-type>.<release>.config.tar.gz (Deployment Package for the JOC Cockpit instance's configuration directory)
            • js7_deploy_joc_linux.<joc-id>.<instance-type>.<release>.install.tar.gz (Deployment Package for the JOC Cockpit instance's installation directory)
            • run_deploy_joc.sh (Deployment Script)
            • run_install_joc.sh (Wrapper Script for the parameterized call to the js7_install_joc.sh Installer Script.
          • <instance-type> (specifies the type of the JOC Cockpit instance which is primary or secondary
        • <joc-id>(specifies the JOC Cockpit ID)
        • ...
      • js7_import_tar.gz (holds the Deployment Workflow for import to JS7 JOC Cockpit)
      • run_deploy.sh (Wrapper Script to run all run_deploy_*.sh Deployment Scripts for Agent, Controller and JOC Cockpit instances)
    • <deployment-descriptor> (specifies the Deployment Descriptor)
    • ...
  • bin (holds executable files, preferably individual scripts, Deployment Scripts and Installer Scripts available from JS7 - Download)
  • ca  (holds the Certificate Authority as explained from  JS7 - How to create self-signed Certificates, not used if an external Certificate Authority is in place)
    • certs (holds CA-signed Certificates)
    • csr (holds Certificate Signing Requests)
    • private (holds Private Keys)
  • config (holds configuration files)
    • agents (holds Agent configuration files)
      • instances (holds configuration files specific for an Agent)
        • <agent-id>(specifies the Agent ID for directories and files that are specific to an Agent)
          • config (general configuration)
            • private (specific configuration)
              • trusted-pgp-keys (optionally holds PGP public key files and keyring files used for signing, see JS7 - Deployment of Scheduling Objects)
                • <pgp-public-key> (public key file or keyring file)
                • <pgp-public-key> (public key file or keyring file)
                • ...
              • trusted-x509-keys (optionally holds X.509 certificate files used for signing, see JS7 - Deployment of Scheduling Objects)
                • <x509-certificate> (X.509 certificate file)
                • <x509-certificate> (X.509 certificate file)
                • ...
              • https-keystore.p12 (optional default location and file name of a PKCS12 keystore)
              • https-truststore.p12 (optional default location and file name of a PKCS12 truststore)
              • private.conf (optional configuration file, for example to specify keystore, truststore and Distinguished Names of Controller certificate, see JS7 - Agent Configuration Items)
              • log4j2.xml (optional log configuration file, see JS7 - Log Levels and Debug Options)
            • agent.conf (optional configuration file, see JS7 - Agent Configuration Items)
        • <agent-id>(specifies the Agent ID for directories and files that are specific to an Agent)
        • ...
      • templates (holds configuration files that act as templates for a number of Agents)
        • <template-name> (an arbitrary directory name for templates can be used)
        • <template-name> (an arbitrary directory name for templates can be used)
        • ...
    • certs (holds certificate files for deployment with Agents and Controllers)
      • ca  (optional Root Certificate Authority used for self-signed certificates)
        • <root-ca-certificate> (the Root CA Certificate file, frequently available with a .pem, .crt extension)
      • server (Server Authentication Certificates)
        • <server-certificate>(Server Certificate file, frequently available with a .pem, .crt extension)
        • <server-certificate>(Server Certificate file, frequently available with a .pem, .crt extension)
        • ...
      • client (Client Authentication Certificates)
        • <client-certificate>(Client Certificate file, frequently available with a .pem, .crt extension)
        • <client-certificate>(Client Certificate file, frequently available with a .pem, .crt extension)
        • ...
    • controllers (holds Controller configuration files)
      • instances (holds configuration files specific for a Controller instance)
        • <controller-id>.<controller-type>(specifies the Controller ID for directories and files that are specific to a Controller instance with the instance type being primary or secondary)
          • config (general configuration)
            • private (specific configuration)
              • trusted-pgp-keys (optionally holds PGP public key files and keyring files used for signing, see JS7 - Deployment of Scheduling Objects)
                • <pgp-public-key> (public key file or keyring file)
                • <pgp-public-key> (public key file or keyring file)
                • ...
              • trusted-x509-keys (optionally holds X.509 certificate files used for signing, see JS7 - Deployment of Scheduling Objects)
                • <x509-certificate> (X.509 certificate file)
                • <x509-certificate> (X.509 certificate file)
                • ...
              • https-keystore.p12 (optional default location and file name of a PKCS12 keystore)
              • https-truststore.p12 (optional default location and file name of a PKCS12 truststore)
              • private.conf (optional configuration file, for example to specify keystore, truststore and Distinguished Names of JOC Cockpit certificate, see JS7 - Controller Configuration Items)
              • log4j2.xml (optional log configuration file, see JS7 - Log Levels and Debug Options)
            • controller.conf (optional configuration file, see JS7 - Controller Configuration Items)
        • <controller-id>.<controller-type>(specifies the Controller ID for directories and files that are specific to a Controller)
        • ...
      • templates (holds configuration files that act as templates for a number of Controllers)
        • <template-name> (an arbitrary directory name for templates can be used)
        • <template-name> (an arbitrary directory name for templates can be used)
        • ...
    • joc  (holds JOC Cockpit configuration files)
      • instances (holds configuration files that are specific for a JOC Cockpit instance)
        • <server>.<instance-type> (holds configuration files for a JOC Cockpit instance running on a specific server with the instance type being primary or secondary)
          • resources (optionally holds configuration files such as the joc.properties file, keystore, truststore files etc.)
          • response (holds response files, mainly the joc_install.xml response file, that are copied to the JOC Cockpit's setup directory)
        • <server>.<instance-type> (holds configuration files for a JOC Cockpit instance running on a specific server with the instance type being primary or secondary)
        • ...
      • templates (holds configuration files that act as templates for a number of JOC Cockpit instances)
        • <template-name> (an arbitrary directory name for templates can be used)
          • resources (optionally holds configuration files such as the joc.properties file, keystore, truststore files etc.)
          • response (holds response files, mainly the joc_install.xml response file, that are copied to the JOC Cockpit's setup directory)
        • <template-name> (an arbitrary directory name for templates can be used)
        • ...
  • desc (holds Deployment Descriptors)
    • <deployment-descriptor>.json (Deployment Descriptor .json file)
    • <deployment-descriptor>.json (Deployment Descriptor .json file)
    • ...
  • logs (holds log files)
    • deployment_package.<deployment-descriptor>.<host>.<timestamp>.log (Packaging Script log files)
    • install_js7_agent.<host>.<timestamp>.log (Agent Installer log files)
    • install_js7_controller.<host>.<timestamp>.log (Controller Installer log files)
    • install_js7_joc.<host>.<timestamp>.log (JOC Cockpit Installer log files)
  • release  (holds the installation tarballs for JS7 releases)
    • ... (users can apply an arbitrary directory hierarchy at this level)
      • js7_agent_unix.<release>.tar.gz (JS7 Agent installation tarball as download from the SOS Web Site)
      • js7_controller_unix.<release>.tar.gz (JS7 Controller installation tarball as download from the SOS Web Site)
      • js7_joc_linux.<release>.tar.gz (JS7 JOC Cockpit installation tarball as download from the SOS Web Site)
  • work (the working area is preferably used to perform installation of JS7 components during packaging)
    • agents (directory for Agent installation during packaging)
      • <agent-id>(specifies the Agent ID for directories and files that are specific to an Agent)
        • ... (sub-directories used for Agent installation)
      • <agent-id>(specifies the Agent ID for directories and files that are specific to an Agent)
      • ...
    • controllers (directory for Controller installation during packaging)
      • <controller-id>(specifies the Controller ID for directories and files that are specific to a Controller)
        • ... (sub-directories used for Controller installation)
      • <controller-id>(specifies the Controller ID for directories and files that are specific to a Controller)
      • ...
    • tmp (temporary files are written to this directory, if the --keep-work switch is used when invoking the JS7 - Deployment Packaging Script then files will remain in this directory which suggests cleanup by the user)
  • env.sh (Environment Script, see next chapter)

...

...

Alternative Directory Layout

The directory layout of the Deployment Area is not carved in stone. Instead, users can modify the env.sh Environment Script to point to different directories.

...

...