Integrating a Cloudsmith repository with a Harness CD pipeline

In this blog, we will walk through the process of configuring a private Cloudsmith repository as an artifact source for a Harness Continuous Deployment pipeline.

Harness is a Continuous Deployment platform that allows you to easily automate the deployment of your software to your infrastructure and environments.

The Harness Platform has two main components:

• The Harness Manager: The Harness Manager is where you manage your deployment pipelines and also where you store your deployment configurations. It is available as a SaaS or on-premises running in your own infrastructure.  In this blog, we will use the SaaS version at app.harness.io.  You can use the Harness Manager (or the API, or a trigger in your pipeline) to start and view your pipeline execution.
• Harness Delegate: the Harness Delegate is software you install in your environment (locally or on a cloud platform of your choice), and run as a service. The Delegate connects to the Harness Manager to receive tasks and then executes these pipeline tasks on your chosen platforms.

Installing the Harness delegate and building a pipeline from scratch in the Harness manager is beyond the scope of this blog, but Harness provide excellent documentation and tutorials to get you up and running.

Let’s get started

We are going to set up our Cloudsmith repository as a docker registry in Harness and then use Harness CD to deploy a docker image to AWS Elastic Container Service.

First, we log into the harness manager, and then go to “Setup”:

At this point it’s worth explaining some of the Harness key concepts, particularly Cloud Providers, Connectors and Applications :

Cloud Providers

Cloud Providers describe your infrastructure, such as AWS, GCP, Azure or even your own Physical Data Center.  I’ve configured AWS as my Cloud Provider here and I have provided the AWS Access Key and Secret Access Key. I’ve added my AWS Secret Access Key as an encrypted secret using the included Harness Vault, and it’s always correct to use an encrypted secret and a secrets manager of some sort. Never, ever add your credential or secrets as plain text as part of a deployment pipeline.

Connectors

Connectors are where you integrate repositories, registries, or monitoring tools.  The Connector type we will configure here is an “Artifact Server”. This is the important bit for this blog, as it is where we add our Cloudsmith repository.

This is really simple, as Cloudsmith repositories are fully compatible as a native docker registry. All you need to add is your Cloudsmith registry URL – (docker.cloudsmith.io/v2/), your Cloudsmith username and your encrypted password.

I’ve added my Cloudsmith API key as an encrypted secret, again using the included Harness Vault.

You could also use a Cloudsmith Entitlement Token, and you can see our Docker documentation to find out how to authenticate to a Cloudsmith repository using a token.

Applications

The next thing we configure is an Application.  Applications are how you organize a deployment project in harness and consist of Services, Environments, Workflows, Pipelines, Triggers and Infrastructure Provisioners:

Services

Services represent your applications and microservices, and this is where you declare the artifacts that you wish to use, any configuration variables and container specifications.

This is the first thing we define for our application.

I have selected my Cloudsmith artifact repository as the source server, and for my docker image name I have entered my Cloudsmith organization name “demo”, my repository name “examples-repo”, and my docker image name “cloudsmith-example-app”.  I also choose here to deploy this docker image to AWS ECS:

Environments

An environment represents your deployment infrastructure, such a test, staging or production.  This is the second thing that we define for this application.

We have defined a “TEST” infrastructure here on AWS here, and this is also where wer define things like the region and cluster to be used, and the IAM execution role to use:

Workflows

A workflow includes the Service, Environment, and Infrastructure definitions we have added already, and then uses these for the deployment steps. A workflow is the third thing we define for this application.

There are different types of Workflows, such as basic, canary and blue/green. For this example, we will use a blue/green workflow that configures an AWS load balancer, and then deploys or upgrades the containers running on our ECS cluster.  You can also add things like rollback steps and notifications:

Pipelines

A pipelines model is a collection of one or more stages, containing Workflows for Services and other deployment and verification steps, such as Approvals

We have set up a very simple single-stage pipeline here that just runs the Workflow we defined above:

Triggers

A Trigger is used to automate deployment in response to an event, such as Git events, a new artifact in a repository, a schedule or even the success of another pipeline.

We have set up a trigger here that will start the Pipeline when a new docker image is pushed to our Cloudsmith Repository:

Running the Pipeline.

We have a simple python flask project, that just prints a simple message.  We just need to create a docker image from this project using the ‘’docker build’ command:

docker build -t docker.cloudsmith.io/demo/examples-repo/cloudsmith-example-app:latest -t docker.cloudsmith.io/demo/examples-repo/cloudsmith-example-app:2.0.0 .

This command also adds two tags to the image, a ‘latest’ tag and a ‘2.0.0’’ tag.

Now, we just push this docker image and tags to our Cloudsmith repository, exactly as you would do with any docker registry:

docker push docker.cloudsmith.io/demo/examples-repo/cloudsmith-example-app:latest docker push docker.cloudsmith.io/demo/examples-repo/cloudsmith-example-app:2.0.0

That’s the docker image pushed to Cloudsmith, and we can see it now in our Cloudsmith Repository:

As we have set up a Trigger in Harness, Harness will then poll any configured artifact repositories every 2 minutes for the presence of a new artifact.  As a result, our Pipeline will then start to execute:

We can follow the stages in our pipeline, and the steps in our workflow here, and see the log output. For example, you can see the output of the upgrade containers step here:

Once the deployment has completed successfully, we can hit the address of our AWS Load Balancer in a browser and we can confirm that our docker image has been deployed to our ECS cluster, and the message that this example application prints:

Our automated deployment to AWS ECS was successful, our docker image was pulled from our private Cloudsmith repository, and it was all managed and controlled by Harness CD.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet