Deploy Manifests Separately using Apply Step
By default, the Harness Kubernetes Workflow will deploy all of the resources you have set up in the Service Manifests section.
In some cases, you might have resources that you do not want to deploy as part of the main Workflow deployment, but want to apply as another step in the Workflow. For example, you might want to deploy an additional resource only after Harness has verified the deployment of the main resources in the Service Manifests section.
Workflows include an Apply step that allows you to deploy any resource you have set up in the Service Manifests section.
In this topic:
- Before You Begin
- What Kubernetes Workloads Can I Include?
- Option 1: Ignore the Workload
- Step 1: Add the Apply Step
- Step 2: Enter the Path and Name of the Manifest
- Apply Step Examples
- Next Steps
Before You Begin
- Ignore a Manifest File During Deployment
- Define Kubernetes Manifests
- Kubernetes Versioning and Annotations
Review: What Workloads Can I Deploy?
Harness Canary and Blue/Green Workflow default steps support a single Deployment workload as a managed entity.
In Harness, a managed workload is a Deployment, StatefulSet, or DaemonSet object deployed and managed to steady state.
Rolling Workflow default steps support Deployment, StatefulSet, or DaemonSet as managed workloads, but not Jobs.
You can deploy any Kubernetes workload in any Workflow type by using a Harness annotation to make it unmanaged (
The Apply Step can deploy any workloads or objects in any Workflow type as a managed workload.
OpenShift: Harness supports OpenShift DeploymentConfig in OpenShift clusters as a managed workload across Canary, Blue Green, and Rolling deployment strategies. Please use
apiVersion: apps.openshift.io/v1 and not
Option 1: Ignore the Workload
Typically, you will instruct Harness to ignore the workload that you want to deploy separately using the Apply Step.
To have a Workflow ignore a resource file in a Service Manifest section, you add the comment
# harness.io/skip-file-for-deploy to the top of the file. For example, here is a ConfigMap file using the comment:
Now, when this Service is deployed by a Workflow, this ConfigMap resource will not be applied by default.
# harness.io/skip-file-for-deploymust be at the top of the file. If it is on the second line it will not work and the resource will be deployed as part of the main Workflow rollout.
Step 1: Add the Apply Step
In your Kubernetes Workflow, click Add Step, and then select Apply.
Step 2: Enter the Path and Name of the Manifest
The Workflow Apply step will apply any resource in a Service Manifest section explicitly. You must provide the path and name of the file in Apply, and Harness will deploy the resource.
For example, the following image shows a Jobs resource in a Service Manifest section that uses the ignore comment
# harness.io/skip-file-for-deploy so that the Workflow does not apply it as part of its main Deploy steps, and the Apply step that specifies the same Jobs resource:
The File paths field in the Apply step must include the folder name and the file name. In the above example, the folder templates is included with the file name jobs.yaml:
You can include multiple resource files in the Apply step File paths field by separating them with commas, for example:
# harness.io/skip-file-for-deployto a resource but do not use the resource in an Apply step, the resource is never deployed.
If you use a remote manifest in your Harness Service, in File paths enter a path relative to the path you specified for the manifest in the Harness Service.
Skip Dry Run
By default, Harness uses the
--dry-run flag on the
kubectl apply command, which prints the object that would be sent to the cluster without really sending it. If the Skip Dry Run option is selected, Harness will not use the
Apply Step Examples
Deploying a resource out of sync with the main resource deployment in a Workflow can be useful if a specific resource requires some external service processing that is orchestrated around your main rollout, such as database migration.
One reason why a Job controller object is a good use of the Apply step is that represents a finite task that runs to completion rather than managing an ongoing desired state. You can run a Job to do perform work outside of the primary object deployment, such as large computation and batch-oriented tasks.
In another example, let's say you have two services, serviceA calls serviceB to populate a product page. The main Workflow rollout deploys serviceB successfully and then the Apply step deploys serviceA next, ensuring serviceA only calls serviceB after serviceB is deployed successfully.
Another example of the use of the Apply step is service mesh traffic shifting. Your main Workflow rollout can deploy your services and then an Apply step can apply the resource that modifies the service mesh for the deployed services (for example, in an Istio-enabled cluster,
- The Apply step applies to Service Manifests that are local or added remotely using the Kubernetes Resource Specs in YAML format option. See Link Resource Files or Helm Charts in Git Repos.
- The Apply step does not version ConfigMap and Secret objects. ConfigMap and Secret objects are overwritten on each deployment. This is the same as when ConfigMap and Secret objects are marked as unversioned in typical rollouts (
harness.io/skip-versioning: "true"). See Kubernetes Versioning and Annotations.