Page History

...

• to hold the script environment for JS7 - Automated Installation and Update and the JS7 - Deployment Packaging,
• to hold the configuration files and optionally certificates for deployment of JS7 componentsproducts,
• to hold the JS7 installation per JS7 release and component product such as JOC Cockpit, Controller, Agent,
• to hold the archive of Deployment Packages per JS7 releases and target host,
• 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 hosts.
  • 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 product 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 hosts for the purpose of restoring JS7 components in products in case of data loss. Instead, deployment is repeated in case that a target host has to be set up from scratch. Consider which data will be lost in case that a target host's file system will crash:
    • Log Data: retention of older JS7 component product 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 in consistently backing up 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 install JS7 components products in a temporary work directory 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 in products in 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 product will perfectly start - using the expected configuration items such as certificates - and will terminate normally. In addition it includes to check the JS7 componentproduct's log files for warnings and errors on start-up and termination.
•  Parallelism
  • During upgrade to newer JS7 releases users might find an inconsistent status of JS7 components products for a short period of time.
    • 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 Agent instances during the deployment procedure 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 host fails. Such situations frequently do not suggest lengthy analysis of problems with the target host but require immediate action to roll back the installation and to fall back to a 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 hosts should be retried.

...

• Storage
  • Storage capacity has to match the number of Deployment Packages that are stored per JS7 release, per JS7 component product and target host.
    • Example
      • Assume that the Deployment Area is used to deploy JS7 Agents to 100 target hosts.
      • The average disk space consumption of a JS7 Agent package is around 175 MB.
      • If users intend to keep the latest three JS7 releases then this will make 300 packages with an overall disk space consumption of approx. 53 GB.
  • The work directory in the Deployment Area is used to temporarily store JS7 installations. A rough estimate of 10 GB will be sufficient for most purposes.
  • Storage for JS7 release installation files should be considered. For Unix environments the tarballs for JOC Cockpit, Controller and Agent require approx. 600 MB per release.
• Computing Power
  • Speed matters when it comes to packaging. However, this process is performed only once per new JS7 release that should be deployed.
  • It can be considered a waste of resources having a powerful server being used <1% of the time as computing power is required for the packaging step only. Users should identify a way how to allocate computing resources exclusively in case that they are needed.
• Network
  • The host operating the Deployment Area requires decent connectivity as it has to connect to any target hosts to which JS7 components products should be deployed.
    • Network connections are established from the Deployment Area's server to the target hosts, not vice versa.
    • Considering firewalls users might think about "opening the gates" for the timeslot of deployment only.
  • Transfer of tarball packages to target hosts preferably happens in parallel to have a short period of time in which mixed releases of JS7 components products are in place.
    • Parallelism of transfer can be specified with the JS7 - Deployment Workflow.

...

• Security is the basic reason why the JS7 deployment scripts ship as shell scripts and not from a high level programming language that might require installation and updates. Transparency and adjustability are key. Users are free to modify deployment scripts at their will and to request changes within the scope of SOS professional services.
• The source of JS7 installation tarballs is a major concern. Basically the installer scripts for JS7 components products offer to download components products from the SOS Web Site on demand. Users are discouraged to make use of this feature for automated deployment. Instead, the JS7 components products should be separately downloaded and checked that no tampered versions of the files have been downloaded.
• Good understanding of the deployment process and of the working of deployment scripts is key for security.

...