Add Artifact Servers

Harness integrates with many different types of repositories and artifact providers. We call these Artifact Servers, and they help you pull your artifacts into your Harness Application.

In this article:

To connect to an artifact server, do the following:

  1. Click Setup.
  2. Click Connectors.
  3. Click Artifact Servers.
  4. Click Add Artifact Server.
  5. In Type, click the artifact source you want to use.
  6. In URL, enter the URL of the artifact server. Consult the provider's documentation to determine what URL and URL format to use.
  7. In Authentication Mechanism, click UserName/Password or Token (if available), and provide the credentials.
  8. In Display Name, provide a name for the Artifact Server. This is the name you will use to identify this connection when adding an Artifact Source to a Harness Service.
    If you want to restrict the use of an artifact source to specific applications and environments, do the following:
  9. In Usage Scope, click the drop-down under Applications, and click the name of the application.
  10. In Environments, click the name of the environment.
  11. Click Submit.
A useful resource for repositories and their features is available at Binary Repository Manager Feature Matrix.

AWS S3 and Google Cloud Storage

Amazon AWS and Google Cloud Platform are added to Harness as Cloud Providers, but they may also be used as artifact servers in a Harness Service. You simply add them as Cloud Providers, and then when you are adding an artifact in a Harness Service, the AWS S3 and Google Cloud Storage options will be available.

Here is what the Artifact Source list looks like in a Harness service when AWS S3 and Google Cloud Storage have been as added as Cloud Providers:

For information on how to add AWS and GCP as Cloud Providers, see Add Cloud Providers.

Jenkins

The Jenkins dialog has the following fields:

  • Jenkins URL - Enter the URL of the Jenkins server. If you are using the Jenkins SaaS (cloud) edition, the URL is in your browser's location field. If you are using the standalone edition of Jenkins, the URL is located in Manage Jenkins, Jenkins Location:
  • Authentication Mechanism - Enter the credentials to authenticate with the server. I
    • Username/Password - Enter the Jenkins API token or password in the Password field.
    • Bearer Token(HTTP Header) - Enter the OpenShift OAuth Access Token in Bearer Token (HTTP Header). For more information, see Authentication from OpenShift. For token-based authentication, go to http://Jenkins-IP-address/jobs/me/configure to check and change your API access token. The token is added as part of the HTTP header.

Jenkins Permissions

  • Overall: Read.
  • Job: Build (if you plan to trigger a build as part of your workflow)

For token-based authentication, go to http://Jenkins-IP-address/jobs/me/configure to check and change your API access token. The token is added as part of the HTTP header.

See Jenkins Matrix-based security.

If you add Jenkins as an Artifact Server, it is automatically added as a Verification Provider, and is a single account. Changes made to the Jenkins Artifact Server settings, such as username or Display Name, will also apply to the Jenkins Verification Provider settings, and vice versa.

Bamboo

Build Permissions
  • View plan.
  • Build plan (if you plan to trigger a build as part of your workflow).

See Bamboo Permissions.

Docker Registry

Do not use Docker Registry to connect to a Docker resource on Artifactory. See Artifactory.

The Docker Registry URL for Docker Hub is https://registry.hub.docker.com/v2/.

The Docker Registry Artifact Server does not require a username and password because you might use it to connect to a public repo.

Docker Registry Permissions

  • Read permission for all repositories.

User needs:

  • List images and tags
  • Pull images

See Docker Permissions.

If you are using anonymous access to a Docker registry for a Kubernetes deployment, then imagePullSecrets should be removed from the container specification. This is standard Kubernetes behavior and not related to Harness specifically.

Nexus

Nexus Versions

The Version field in the dialog lists the supported Nexus versions, 2.x and 3.x.

For Nexus 2.x, Harness supports repository formats Maven, npm, and NuGet. See Sonatype's website at Supported Formats.

For Nexus 3.x, Harness supports repository formats Docker 3.0 and greater, Maven, npm, NuGet.

Nexus Permissions

  • All repositories: Read.

If used as a Docker Repo, the user needs:

  • List images and tags
  • Pull images

See Nexus Managing Security.

Artifactory

Harness supports both cloud and on-prem versions of Artifactory.

In the Artifactory URL field, ensure that you enter in your base URL followed by your module name: https://mycompany.jfrog.io/module_name.

Artifactory Permissions

  • Privileged User is required to access API, whether Anonymous or a specific username (username and passwords are not mandatory).
  • Read permission to all Repositories.

If used as a Docker Repo, user needs:

  • List images and tags
  • Pull images

See Managing Permissions: JFrog Artifactory User Guide.

SMB

You can share files and folders on your network and use them for an SMB Artifact Server connection.

The SMB dialog has the following fields:

  • In SMB URL - Ensure a value that contains the smb:\\ scheme followed by the hostname or IP address and folder name. For example, smb:\\23.100.87.22\share.

    If you want to specify a folder in the URL, you can enter the folder using the \myFolder format, such as smb:\\23.100.87.22\myFolder. Typically, you will specify the folder when you use the SMB Artifact Server as an Artifact Source for a Service.
  • Domain - Enter the Windows domain where the host containing the shared folder is located.
  • Username and Password - Use a user account that has permissions to access the shared folder.

When you use the SMB Artifact Server as an Artifact Source for a Service, you can specify a file or a folder for the artifact. This allows a folder to be copied to the deployment target host by the Harness Delegate. Here is the SMB Artifact Source dialog:

In Artifact Path, you can specify a file or folder by name or using wildcards. The following are examples for matching different files and folders:

  • todo-*zip - All matching files, such todo-1.0.zip, todo-2.0.zip.
  • test/*zip - All zip files under test folder.
  • test/1* - All folders under test folder starting with 1.
  • test/* - All folders under test folder.

SFTP

You can share files and folders on your network and use them for an SFTP Artifact Server connection.

The SFTP dialog has the following fields:

  • In SFTP URL - Ensure that the value contains the sftp:\\ scheme followed by the hostname or IP address. For example, sftp:\\23.100.87.22.

    If you want to specify a folder in the URL, you can enter the folder using the \myFolder format, such as sftp:\\23.100.87.22\myFolder. Typically, you will specify the folder when you use the SFTP Artifact Server as an Artifact Source for a Service.
  • Domain - Enter the domain where the SFTP server is located.
  • Username and Password - Use a user account that has permissions to access the SFTP server.

When you use the SFTP Artifact Server as an Artifact Source for a Service, you can specify a file or a folder for the artifact. This allows a folder to be copied to the deployment target host by the Harness Delegate. Here is the SFTP Artifact Source dialog:

In Artifact Path, you can specify a file or folder by name or using wildcards. The following are example for different files and folders:

  • todo-*zip - All matching files, such todo-1.0.zip, todo-2.0.zip.
  • test/*zip - All zip files under test folder.
  • test/1* - All folders under test folder starting with 1.
  • test/* - All folders under test folder.

Helm Repository

You can add a Helm Chart Repository as an Artifact Server and then use it in Harness Kubernetes and Helm Services. See Kubernetes Deployments and Helm Deployments.

A Helm chart repository is an HTTP server that houses an index.yaml file and, if needed, packaged charts. For details, see The Chart Repository Guide from Helm.

From Helm:

Note: For Helm 2.0.0, chart repositories do not have any intrinsic authentication. There is an issue tracking progress in GitHub.
Because a chart repository can be any HTTP server that can serve YAML and tar files and can answer GET requests, you have a plethora of options when it comes down to hosting your own chart repository. For example, you can use a Google Cloud Storage (GCS) bucket, Amazon S3 bucket, Github Pages, or even create your own web server.

The Helm Repository dialog has the following fields:

  • Display Name - This is the name you will use to select this Artifact Server in you Kubernetes and Helm Services.
  • Hosting Platform - The type of server where the repo is hosted. If you select an option other than HTTP Server, such as Amazon S3 or GCS (Google Cloud Storage), you will need a Cloud Provider for that account. For more information, see AWS S3 and Google Cloud Storage and Google Cloud Storage (GCS).
  • Repository URL - The URL of the chart repo.
  • Username and Password - If the charts are backed by HTTP basic authentication, you can also supply the username and password. See Share your charts with others from Helm.

Anonymous Access

The following Artifact Servers support anonymous access for Docker images:

  • Docker Registry
  • Nexus
  • Artifactory

If you are using anonymous access to obtain the artifact for your Service, you should ensure that host running the Harness Delegate has view and read permissions and that the container specification for the deployment platform you are using is set up for anonymous access. For example:

  • Kubernetes - Ensure that imagePullSecrets is removed from the container specification. For more information, see Example 2: Creating ImagePullSecret using Harness Artifact Stream. For Harness version 1 implementation of Kubernetes, imagePullSecrets is added by default. For version 2, imagePullSecrets is not added by default.
  • ECS - By default, ECS uses anonymous access. To use a private registry, you must use the RepositoryCredentials property type in the Container Specification. For more information, see Using Private Docker Registry Authentication.


How did we do?