2 - Service and Azure Artifact Source

Updated 2 months ago by Michael Cretzman

This topic describes how to set up the Harness Kubernetes Service and Artifact Source for an Azure deployment:

Application Setup

The following procedure creates a Harness Application for a AKS Kubernetes deployment using an ACR repository.

An Application in Harness represents a logical group of one or more entities, including Services, Environments, Workflows, Pipelines, Triggers, and Infrastructure Provisioners. Applications organize all of the entities and configurations in Harness CI/CD. For more information, see Application Components.

To create the Harness Application, do the following:

  1. In Harness, click Setup.
  2. Click Add Application. The Application dialog appears.
  3. Give your Application a name that describes your microservice or app. For the purposes of this guide, we use the name ACR-to-AKS.
  4. Click SUBMIT. The new Application is added.
  5. Click the Application name to open the Application. The Application entities are displayed.

Harness Service Setup

There are different types of Harness Services for different deployment platforms. The Kubernetes type includes Kubernetes-specific settings.

To add the Kubernetes Service, do the following:

  1. In your new Application, click Services. The Services page appears.
  2. In the Services page, click Add Service. The Service dialog appears.

  3. In Name, enter a name for your Service, such as Todolist-ACR.
  4. In Description, enter a description for your service.
  5. In Deployment Type, select Kubernetes.
  6. Click the Enable Kubernetes V2 checkbox. This setting configures the Service with the latest Harness Kubernetes Service settings.
  7. Click SUBMIT. The new Service is displayed.

Next, we will walk through how to set up the Kubernetes manifest file and use the Service features.

Add ACR Artifact Source

An Artifact Source in a Service is the microservice or application artifact you want to deploy.

For this Azure deployment, the Artifact Source uses the Azure Cloud Provider you set up for your Harness account to connect to ACR (as described in Azure Cloud Provider), and selects a Todo List sample app Docker image as the artifact.

To add an Artifact Source to this Service, do the following:

  1. In the Service, click Add Artifact Source, and select Azure Container Registry. The Artifact Source dialog appears.
  2. Configure the following fields and click SUBMIT.
  • Cloud Provider - Select the Azure Cloud Provider we set up earlier.
  • Subscription - Select the Subscription set up in your ACR container registry. To locate the Subscription in ACR, click Overview, and see Subscription.

  • Azure Registry Name - Select the registry you want to use.
  • Repository Name - Select the repository containing the Docker image you want to use.

When you are finished, the Artifact Source dialog will look something like this:

You can add multiple Artifact Sources to a Service and view the build history for each one by clicking Artifact History.

Add Manifests

The Manifests section of Service contains the configuration files that describe the desired state of your application in terms of Kubernetes object descriptions.

What Can I Add in Manifests?

You can add any Kubernetes configurations files, formatted in YAML, such as object descriptions, in one or more files.

As you can see, you can use Go templating and Harness built-in variables in combination in your Manifests files. For information about the features of Manifests, see Add Manifests in the Harness Kubernetes Deployments doc.

For this guide, we will use the default manifests, with one important change for ACR: we will edit the Kubernetes imagePullSecret setting.

Modify ImagePullSecret

To pull the image from the private ACR registry, Kubernetes needs credentials. These credentials are in the Azure Cloud Provider you set up, and used to configure the Artifact Source for the Service.

The createImagePullSecret setting in the Harness Service values.yaml file determines if the Secret manifest is used:

image: ${artifact.metadata.image}
dockercfg: ${artifact.source.dockerconfig}

createImagePullSecret: false

When createImagePullSecret is set to true, the Secret manifest in the deployment.yaml configuration file is used, and specifies that Kubernetes should get the credentials from the dockercfg file:

{{- if .Values.createImagePullSecret}}
apiVersion: v1
kind: Secret
metadata:
name: {{.Values.name}}-dockercfg
annotations:
harness.io/skip-versioning: true
data:
.dockercfg: {{.Values.dockercfg}}
type: kubernetes.io/dockercfg
{{- end}}
If you are new to Kubernetes Secrets, see Pull an Image from a Private Registry from Kubernetes.

Since we use Go templating in Manifests, the name and dockercfg values reference the parameters in the values.yaml file in Manifests:

name: harness-example
replicas: 1

image: ${artifact.metadata.image}
dockercfg: ${artifact.source.dockerconfig}

At runtime, these values will be replaced with the Docker image name and dockercfg file. This tells Kubernetes where to obtain the Docker image and dockercfg for deployment using the Artifact Source you set up in Service. Most importantly, it passes the Secret needed to access the remote registry, ACR.

By default, the Secret setting is disabled:

createImagePullSecret: false

To enable the Secrets setting and tell Kubernetes to use the credentials in the dockercfg file to pull the Docker image from ACR, do the following:

  1. In Manifests, click values.yaml, and then click Edit.
  2. Change the createImagePullSecret label to true:

    createImagePullSecret: true
  3. Click Save.

That's it. In your AKS cluster at deployment runtime, Kubernetes will use the dockercfg credentials to obtain the Docker image from ACR.

When you create an AKS cluster, Azure also creates a service principal to support cluster operability with other Azure resources. You can use this auto-generated service principal for authentication with an ACR registry. If you can use this method, then only the Kubernetes Cloud Provider is needed and the createImagePullSecret setting can be left as false. In this guide, we create separate connections for AKS and ACR because, in some instances, you might not be able to assign the required role to the auto-generated AKS service principal granting it access to ACR. For more information, see Authenticate with Azure Container Registry from Azure Kubernetes Service from Azure.

Now we can set up the deployment Environment to tell Harness where to deploy the Docker image.

Namespace Variable

Before we set up the deployment Environment, let's look at one more interesting setting, click values.yaml and locate the namespace setting:

namespace: ${infra.kubernetes.namespace}

Next, click the namespace.yaml file to see the variable referenced in values.yaml:

{{- if .Values.createNamespace}}
apiVersion: v1
kind: Namespace
metadata:
name: {{.Values.namespace}}
{{- end}}

The ${infra.kubernetes.namespace} variable is a Harness built-in variable and it references the Kubernetes cluster namespace value enter in the Harness Environment, which you will create later.

The ${infra.kubernetes.namespace} variable let's you enter any value in the Environment Namespace setting and, at runtime, the Kubernetes Namespace manifest uses that name to create a namespace.

Config Variables and Files

For the purpose of this guide, we don't use many of the other Service settings you can use. For information on the Config Variables and Files settings, see Configuration Variables and Files.

Next Step


How did we do?