...

• 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 is initially installed, is 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 in the target machine. 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 too relevant 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 Controllers 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 Controllers and Agents on separate machines 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 Server. 
  • 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 Server. This might not include for example to run jobs with a JS7 Agent as the job environment might not be available with the Deployment Server. 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 Server 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 Server users can initiate the fallback procedure to deploy a previous release within seconds.
  • Error handling in Deployment Workflow 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 is retried.

Prerequisites

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

No additional No specific software requirements apply to a Deployment Server. The following factors should be considered:

...