CD pipeline execution walkthrough
This topic explains how a CD pipeline execution uses Harness entities and settings at runtime.
Pipeline example
Let's look at a Kubernetes rolling deployment as an example.
The pipeline consists of:
- A Harness CD Deploy stage.
- A Harness service, environment, and infrastructure definition.
- A rolling deployment strategy that uses execution steps to deploy to an existing Kubernetes cluster.
- A final cleanup step to delete the Kubernetes deployment at the end of the pipeline.
Here's the YAML for the example pipeline:
pipeline:
name: Golden PM Signoff Pipeline
identifier: Golden_PM_Signoff_Pipeline
projectIdentifier: PM_Signoff
orgIdentifier: default
tags: {}
stages:
- stage:
name: deployKubernetes
identifier: Deploy_Kubernetes
description: ""
type: Deployment
spec:
deploymentType: Kubernetes
service:
serviceRef: kubernetes
serviceInputs:
serviceDefinition:
type: Kubernetes
spec:
artifacts:
primary:
primaryArtifactRef: <+input>
sources: <+input>
execution:
steps:
- step:
name: Rollout Deployment
identifier: rolloutDeployment
type: K8sRollingDeploy
timeout: 10m
spec:
skipDryRun: false
pruningEnabled: false
when:
stageStatus: Success
- step:
type: K8sDelete
name: Cleanup Suite
identifier: Cleanup_Suite
spec:
deleteResources:
type: ReleaseName
spec:
deleteNamespace: false
timeout: 10m
rollbackSteps:
- step:
name: Rollback Rollout Deployment
identifier: rollbackRolloutDeployment
type: K8sRollingRollback
timeout: 10m
spec:
pruningEnabled: false
environment:
environmentRef: k8sdev
deployToAll: false
infrastructureDefinitions: <+input>
tags: {}
failureStrategies:
- onFailure:
errors:
- PolicyEvaluationFailure
action:
type: MarkAsSuccess
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
when:
pipelineStatus: Success
- stage:
name: Deploy
identifier: Deploy
description: ""
type: Deployment
spec:
deploymentType: Kubernetes
service:
serviceRef: kubernetes
serviceInputs:
serviceDefinition:
type: Kubernetes
spec:
artifacts:
primary:
primaryArtifactRef: <+input>
sources: <+input>
environment:
environmentRef: k8sdev
deployToAll: false
infrastructureDefinitions:
- identifier: devrancher1
inputs:
identifier: devrancher1
type: KubernetesRancher
spec:
connectorRef: <+input>
cluster: <+input>
namespace: <+input>
execution:
steps:
- step:
name: Rollout Deployment
identifier: rolloutDeployment
type: K8sRollingDeploy
timeout: 10m
spec:
skipDryRun: false
pruningEnabled: false
rollbackSteps:
- step:
name: Rollback Rollout Deployment
identifier: rollbackRolloutDeployment
type: K8sRollingRollback
timeout: 10m
spec:
pruningEnabled: false
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
allowStageExecutions: true
Walkthrough of the execution
Service
The first entity evaluated during pipeline execution is the Harness service. A Harness service represents the microservice or application you want to deploy.
A Harness service is made up of the following entities.
Manifest definition
The manifest definition is used to fetch files from the Harness File Store or a remote source like GitHub, GitLab, Bitbucket, etc.
When the stage's Rollout Deployment step is executed, a Harness Delegate fetches the manifests for deployment.
In this example, Harness uses a Harness BitBucket connector to fetch the manifest.
Here's the process:
Artifact configuration (optional)
You can add an artifact to the service and use the artifact expression image: <+artifacts.primary.image> in your values.yaml file to fetch the image tag information and pass it into the manifest.
Here's the process:
Configuration files (optional)
The service configuration files are fetched during the service evaluation and stored on the delegate.
Harness can fetch JSON, Python Script, XML File, etc., and then Harness can use these files during deployment.
Here's the process:
Variables (optional)
You can configure variables in a service and reference them in the service's values.yaml file or in pipeline execution steps.
You can also override service variables in the environment configured in the stage, as explained in the next section.
Environment and infrastructure definition
The next entities evaluated during pipeline execution are the stage environment and infrastructure definition.
A Harness environment defines where the service will be deployed in terms of Production and Pre-Production environments. Within an environment, you can have multiple infrastructure definitions, and you select the one to use for each pipeline stage.
Each infrastructure definition defines the specific infrastructure where the pipeline will deploy. For example, the cloud platform or Kubernetes cluster.
The infrastructure definition for Kubernetes (including Helm and Kustomize) and Native Helm also contain a Release Name. The release name is used to track the deployed service and to sync instances so users know how many pods are deployed on a cluster.
An infrastructure definition leverages a specific Harness connector, such as Kubernetes Cluster, Physical Datacenter, etc., to connect to the target infrastructure for deployment at pipeline execution.
Here's the process:
Overrides (optional)
When a service that uses variables is added to a pipeline stage, you can override the variables using the environment in that stage.
You can set service variable overrides at the environment level. At runtime, Harness will override the corresponding service variables and compute the values according to the environment variables.
Overrides let you specify different service variable values for different environments (Dev, QA, etc.).
Kubernetes Rollout Deployment step
The next entities evaluated during pipeline execution are the stage execution steps.
In this example, there is Rollout Deployment step to deploy the service to the environment.
When the Rollout Deployment step is executed, the delegate eligible to perform the Kubernetes Rollout Deployment step is assigned the task. Harness evaluates delegates in a round robin style.
The Rollout Deployment step is made up of 2 tasks that Harness provides out of the box:
-
Fetch files task.
- The fetch files task leverages the GitHub connector configured in the service to fetch the manifests.
- Harness will also render and resolve any of the Harness variables defined in the
values.yamlfile of the service and add them to the manifest/Helm chart using Go/Helm templating. - Harness fetches any secrets referenced in the
values.yamlfile and resolves them in the manifest. Harness masks secret output in its logs.
Here's an example deployment log:
-
Rollout deployment task.
- The Kubernetes rollout deployment task leverages the infrastructure definition and Harness Kubernetes Cluster connector to authenticate and deploy into the target cluster.
- The task uses the
kubectl applyanddescribecommands to check for steady state.
Here's an example deployment log:
Here's the delegate selection process:
Here's the deployment process:
Kubernetes Delete step
During execution of the Kubernetes Delete step, Harness selects the delegate that has access to the infrastructure definition connector and performs the Kubernetes delete step within that cluster.
Harness attempts to delete the resources specified in the step according to the delegate's RBAC configured on the cluster.
Here's the process:
Summary
This topic explained how a CD pipeline execution uses Harness entities and settings at runtime.
For more information on creating CD pipelines, go to CD tutorials.