6 - Traditional Workflows and Deployments
Once your Service and Environment are set up, you can create the deployment process using a Harness Workflow:
- Basic Workflows
- Templatizing Workflows That use SSH Services
- Next Steps
The Basic deployment Workflow is the most common Workflow type for traditional, package file–based deployments. Basic Workflows simply select nodes in the deployment infrastructure and install a Service.
To create a Basic Workflow for a traditional deployment, do the following:
- In your Harness Application, click Workflows.
- In Workflows, click Add Workflow. The Workflow dialog appears.
- In Name, enter a name for the Workflow.
- In Workflow Type, select Basic Deployment.
- In Environment, select the Environment where the Service Infrastructure/ Infrastructure Definition you defined for your deployment is located.
- In Service, select the Service to be deployed.
- In Service Infrastructure/ Infrastructure Definition, select your target infrastructure.
When you are finished, the dialog will look something like this:
- Click SUBMIT. The Workflow is created.
Let's look at the two default steps in the Workflow, Select Nodes and Install.
The Select Nodes step selects the target hosts from the Service Infrastructure/ Infrastructure Definition you defined. You can choose to select a specific host or simply specify the number of instances to select with the Service Infrastructure/ Infrastructure Definition criteria.
If you choose to set the number of instances, in Select specific hosts?, select No.
In Instances, enter the number of instances to use. Remember that Harness is deploying to existing instances as defined in your Service Infrastructure/ Infrastructure Definition. Ensure that there are enough instances that meet your criteria.
If you choose Yes in Select specific hosts?, click in Host Name(s) to select the specific target hosts for the deployment. Harness will obtain the host names or hosts that match the criteria of your Service Infrastructure/ Infrastructure Definition.
The following image shows an Infrastructure Definition specifying an AWS Region, VPC, and Tags (Name:doc-target), the EC2 instance that meets that criteria, and the host name in the Node Select dialog.
The following image shows a Service Infrastructure specifying an AWS Region, VPC, and Tags (Name:doc-target), the EC2 instance that meets that criteria, and the host name in the Node Select dialog.
Select Nodes and Canary Deployments
While this topic discusses a Basic Workflow deployment, Select Nodes can be used in a Canary Workflow deployment also.
In a Canary Workflow deployment for an SSH Service, you use multiple Phases, each with a Node Select step to deploy to a percentage of target hosts:
- Phase 1: Node Select: Instances: 25%
- Phase 2: Node Select: Instances: 50%
- Phase 3: Node Select: Instances: 75%
- Phase 4: Node Select: Instances: 100%
Node Select will look like this in Phase 1:
And like this in Phase 2:
The Instances setting is cumulative not additive. So using 25% at each phase will not equal 100%. Each successive Node Select incorporates all Node Select Instances settings before it. To reach 100%, your Instances setting at each phase must include the previous percentage (25%, 50%, 75%, 100%).
The same is true for using Count instead of Percentage. If you use multiple Node Select steps in multiple Workflow phases (as in a Canary Workflow) using 1 Count at each of 4 phases will not equal 4 instances. Each successive Node Select incorporates all Node Select Instances settings before it. To reach 4 instances, your Instances setting at each phase must include the previous count (1, 2, 3, 4).
The Install step runs the command scripts in your Service on the target host.
The following image shows the Install step in the deployed Workflow and its corresponding Service commands and scripts.
There are not many causes for a rollback of a Basic Workflow using application packages. Artifact issues are uncommon because the artifact must be available to the Harness Delegate before you deploy. If the Delegate cannot reach the target host, the deployment will fail without changing the target host, and so no rollback is needed.
The Basic Workflow is the most common deployment of Services deploying application packages. Once you've successfully deployed the Workflow, you can click the Install step to see the Service commands and scripts in the Deployments page.
You can expand logs for each script in the Install step to see the log of its execution by the Harness Delegate. For example, here is the Copy Artifact script copying the application package todolist.war to the runtime location set up in Application Defaults (
Begin execution of command: Copy Artifact
Connecting to ip-10-0-0-54.ec2.internal ....
Connection to ip-10-0-0-54.ec2.internal established
Begin file transfer todolist.war to ip-10-0-0-54.ec2.internal:/home/ec2-user/ExampleAppFileBased/WAR/Development/runtime/tomcat/webapps
File successfully transferred
Command execution finished with status SUCCESS
You can SSH into the target host and see the application package:
Templatizing Workflows That use SSH Services
Once you've created your Workflow, you can templatize it so that other users can quickly deploy Harness Services of the same Deployment and Artifact types. Templatizing is described in Workflows.
For example, here is the setup of a Harness SSH Service for the JAR type:
Once you create a Workflow to deploy this type, you can templatize it and other Services of the same Deployment and Artifact Type can use it.
Now that you have deployed your package file-based application, learn about the following Harness features to help you improve, automate, and verify your deployments and live production applications: