Deploy Manifests Separately using Apply Step

Updated 1 day ago by Michael Cretzman

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

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 (harness.io/direct-apply).

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 apiVersion: v1.

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.

The comment # harness.io/skip-file-for-deploy must 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.
If you want to ignore a remote manifest of Helm chart, use the Skip Versioning for Service in Remote Manifests. See Option: Skip Versioning for Service.

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.yamltemplates/jobs.yaml.

You can include multiple resource files in the Apply step File paths field by separating them with commas, for example: templates/jobs.yaml, templates/statefulSet.yaml:

If you apply the ignore comment # harness.io/skip-file-for-deploy to 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.

Harness variables such as Workflow variables are supported in the File Paths setting.

Option: Delegate Selector

If your Workflow Infrastructure Definition's Cloud Provider uses a Delegate Selector (supported in Kubernetes Cluster and AWS Cloud Providers), then the Workflow uses the selected Delegate for all of its steps.

In these cases, you shouldn't add a Delegate Selector to any step in the Workflow. The Workflow is already using a Selector via its Infrastructure Definition's Cloud Provider.

If your Workflow Infrastructure Definition's Cloud Provider isn't using a Delegate Selector, and you want this Workflow step to use a specific Delegate, do the following:

In Delegate Selector, select the Selector for the Delegate(s) you want to use. You add Selectors to Delegates to make sure that they're used to execute the command. For more information, see Select Delegates with Selectors.

Harness will use Delegates matching the Selectors you add.

If you use one Selector, Harness will use any Delegate that has that Selector.

If you select two Selectors, a Delegate must have both Selectors to be selected. That Delegate might also have other Selectors, but it must have the two you selected.

You can use expressions for Harness built-in variables or Account Default variables in Delegate Selectors. When the variable expression is resolved at deployment runtime, it must match an existing Delegate Selector.

For example, if you have a Delegate Selector prod and the Workflow is using an Environment also named prod, the Delegate Selector can be ${env.name}. This is very useful when you match Delegate Selectors to Application component names such as Environments, Services, etc. It's also a way to template the Delegate Selector setting.

Option: 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 --dry-run flag.

Option: Skip Steady State Check

If you select this, Harness will not check to see if the workload has reached steady state.

Apply Step Examples

The Apply Step is primarily used for deploying Jobs controllers, but it can be used for other resources. Typically, when you want to deploy multiple workloads (Deployment, StatefulSet, and DaemonSet) you will use separate Workflows for each.

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, VirtualService).

Notes

  • 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.
  • You can use Harness variables in your manifests and values.yaml files. For example, Harness Workflow variables.

Next Steps


How did we do?