Introduction
The Deployment Workflow is used in the JS7 - Deployment process for rollout of Deployment Packages in a JS7 - Deployment Area
- to run Deployment Scripts per Deployment Package for an instances of JOC Cockpit, Controller and Agent
- to transfer the tarballs of the Deployment Package to the target host,
- to extract the tarballs on the target host,
- to manage a systemd service for automated start-up and shutdown of the JS7 component.
- to parallelize rollout of Deployment Packages.
The Deployment Workflow is available from an import file that is created from the JS7 - Deployment Packaging script.
Import to JOC Cockpit
Identifying the Import File
The Packaging Script creates Deployment Packages and stores them to the js7.deploy/archive
directory.
Find details about directories and files created by the script from the JS7 - Deployment Area - Directory Layout article.
The import file is available in the following directory hierarchy:
archive
(holds Deployment Packages)js7_import_tar.gz
(holds the Deployment Workflow for import to JS7 JOC Cockpit)
Importing the File
The Configuration view in the JOC Cockpit GUI offers the Import button like this:
When clicking the button a popup window will appear like this:
Explanation:
- Users can specify a top-level folder to which the objects of the Deployment Workflow will be imported. The Deployment Workflow includes a sub-folder that is created from the Deployment Descriptor ID.
- Example:
- Using a top-level folder
/Deployment
and the Deployment Descriptor IDjoc-controller-agent-https-2022-12-04
the objects will be imported to the/Deployment/joc-controller-agent-https-2022-12-04
folder.
- Using a top-level folder
- Find more details about import options from the JS7 - Inventory Export and Import article.
Scheduling Objects
With the import being completed the folder hierarchy with the following objects is created:
- the workflow performs execution of rollouts from a job.
- the calendar specifies days for possible execution of the workflow
- the schedule specifies the point in time of workflow execution and its parameterization
Workflow
The imported workflow looks like this:
- No changes to the workflow are required.
- Users can select the Agent that should execute the rollout job. The Agent has to be available on the server node that holds the Deployment Area in order to have access to Deployment Packages.
- Users have to deploy the workflow to make it available to the Agent.
Explanation:
- The workflow makes use of a JS7 - ForkList-Join Instruction
- The instruction is assigned a
deploy
list variable that holds a singlejob
element. This element is populated from the schedule with the rollout scripts per Deployment Package. - The ForkList Instruction will dynamically create branches of the included job for each
job
element that is available from thedeploy
list variable. For example if the list variable holds 10 job entries corresponding to 10 Deployment Packages then 10 child orders will be created that are executed in parallel to perform rollout. - Users can limit parallelism by use of the Job Options sub-tab that offers to specify the parallelism of the given job.
- The instruction is assigned a
- The job is assigned an environment variable that is mapped from the
job
element of thedeploy
list variable.
The job script is fairly simple:
Schedule
The schedule is used to create orders for execution of the workflow. Such orders are parameterized
- from the list of rollout scripts that should be executed.
- from the point in time for which the order should start.
For details see JS7 - Schedules.
Explanation:
- The
deploy
list variable is used from the workflow and is populated withjob
elements that correspond to rollout scripts. - The schedule can be assigned a run-time and can be released for automated execution with the JS7 - Daily Plan.
- Users who wish to manually add an order to the workflow can skip use of the the schedule.
Calendar
The Schedule is assigned a calendar that by default allows any day for execution of deployments.
For details see JS7 - Calendars.
Rollout
As a prerequisite for rollout the workflow has to be deployed and the job included with the workflow being assigned an Agent with access to the directories of the Deployment Area.
Adding an Order to execute the Workflow
- Users navigate to the Workflows view to find the Deployment Workflow from the respective folder hierarchy.
- Users can use the + icon or the workflow's action menu to add an order to the workflow.
A popup window will be displayed like this:
- Users should click the link Assign parameterization from Schedules as this allows to select the previously imported schedule.
- There are no mandatory input fields in this window. However, users are free to schedule the order for a later point in time.
Selecting the schedule populates the deploy
list variable from jobs that execute rollout scripts per Deployment Package like this:
Controlling Orders
When the newly added order enters the ForkList Instruction it will create child orders corresponding to the Deployment Packages that should be rolled out.
- Child orders will not run for a too long time, typically update of JS7 components is performed in less than 50s.
- Users are in control of child orders. Each child order's action menu allows to suspend and to cancel child orders.
- The lower part of the screen shows the Order History and Task History.
Viewing the Order Log
x