2 - Services for PCF

Updated 1 month ago by Michael Cretzman

The topic describes how to create a Harness Application with a PCF Service containing your artifact and PCF manifest and variable files.

In this topic:

Add a Harness Application

A Harness Application represents your PCF apps, their deployment pipelines, and all the building blocks for those pipelines.

To add a Harness Application for PCF, do the following:

  1. Ensure you have set up a PCF Cloud Provider connection in Harness, as described in Add Cloud Providers. This connection will log into the foundation.
  2. Ensure you have set up an Artifact Server connection in Harness, as described in Add Artifact Servers. You will use the Artifact Server to pull the artifact for your app at deployment runtime.
  3. Create a Harness Application. The PCF deployment release process is managed within a Harness Application, along with its Environment, Workflows, Pipelines, etc. For more information, see Application Components.
    1. In Harness, click Setup, and then click Add Application. The Application dialog appears.
    2. Enter a name for your Application, such as PCF_App, and click SUBMIT. The Application is created.
    3. Click your Application’s name. The Application entities appear. Next, add the PCF Service to your Application, including its artifact sources, manifest, and configuration variables and files.

Add the PCF Service

Services represent your PCF apps. You define where the artifacts for those apps come from, the PCF manifest, and configuration variables for those apps.

First, we'll create the Harness Service for PCF, and then in further sections we'll discuss the artifact Harness will deploy, and the manifest files that will define the application and routes.

  1. In your Harness Application, click Services. On the Services page, click Add Service. The Service dialog appears.
  2. In Name, enter a name for your service. Typically, the name is the same as the app you are going to deploy.
  3. In Artifact Type, select Pivotal Cloud Foundry. Once you select an artifact type, Harness will only present configuration options related to that type. When you are finished, the dialog will look something like this:
  4. Click SUBMIT. The new Service is added.

Next, we'll add your application artifact to the Service.

Add an Artifact

The artifact source for your Harness Service is taken from one of the Artifact Servers set up in Add Artifact Servers and is compatible with PCF.

For this example, we'll use an AWS S3 artifact source. Harness supports the following PCF artifact servers/types:

  • Docker Registry
  • Jenkins
  • AWS S3
  • Google Container Service (GCS)
  • Amazon Elastic Container Registry (Amazon ECR)
  • Artifactory (includes Docker)
  • Nexus
  • Bamboo
  • SMB
  • SFTP
  • Custom Repository

To use one these Artifact Sources, you need to add a Harness Artifact Server for it. See Add Artifact Servers or Using Custom Artifact Sources.

To add an application artifact, do the following:

  1. In your Service, click Add Artifact Source, and select the artifact source.
  2. Configure the settings for the Artifact Source. For our AWS S3 example, the dialog will look something like this:

The Metadata Only option indicates that Harness stores the metadata in the Harness Cloud. During runtime, Harness passes the metadata to the target host(s) where it is used to obtain the artifact. Ensure that the target host has network connectivity to the Artifact Server. For more information, see Service Types and Artifact Sources.
  1. Click Submit. The artifact is added to the Service.

Next we will describe our application and PCF routes using the Service Manifests section.

Docker Support in Artifact Sources

The following Harness Artifact Sources support Docker:

  • Artifactory
  • Google Container Registry (GCR)
  • Amazon Elastic Container Registry (Amazon ECR)
  • Docker Registry

For Artifactory, ensure you select the Use Docker Format option:

PCF treats Artifactory as private registry. Harness supports no authentication and Basic authentication. You can use either in your Artifactory repos.

For more information on how PCF supports Docker, see Push a Docker Image from a Registry from Pivotal.

Manifest and Variable Files

Manifests provide consistency and reproducibility, and help automate in deploying apps. For more information about manifest files, see Deploying with Application Manifest from Pivotal.

When you create the PCF Service, the Manifests section is created and the default manifest.yml and vars.yml files are added.

Harness uses a manifest file (manifest.yml) and variables file (vars.yml) for defining the PCF application, instances, and routes. Both files must be in YAML format and can use the .yaml or .yml extension.

Let's look at these files:

  • manifest.yml - This file describes your application, host requirements, and routes. For example, the default name, memory limit, and number of instances. You can hardcode values or use variables defined in vars.yml.
    This file follows the PCF app manifest requirements described in Deploying with App Manifests and Example Manifest from Pivotal.
  • vars.yml - This file is used to maintain variables used in the manifest.yml file.

Here is an example showing how the variables in manifest.yml are given values in vars.yml:

You can also use variables for partial values. For example, you can specify host in your vars.yml file and - route: ((host)).env.com in your manifest.yml file.

PCF Manifest deployments are a common PCF strategy. You can learn more about it in Deploying with App Manifests from Pivotal.

Harness supports all of the typical features of PCF manifests, as described in Deploying with App Manifests from Pivotal, but to deploy multiple apps, you will need to use multiple Harness Services.

These manifest.yml and vars.yml files can be added to the Harness Service in the following ways:

  • Inline - The default method is to use the files in the Harness editor and edit them inline.
  • Local - You can upload local files to replace the inline files. Once they are uploaded, you edit them inline.
  • Remote - You can link to files in a remote Git repo and Harness will pull them at runtime. You can link to the latest files by branch or by commit ID.

File Requirements

Harness allows one manifest file and one or more variable files in Manifests. At runtime, Harness will evaluate the files to identify which is the manifest file and which are the variable files.

If there are other files in Manifests that are not manifest or variable files, Harness will ignore these other files.

Required Values

The definition of your app in manifest.yml and vars.yml is the same in Harness as it is in standard PCF app manifests, as described in App Manifest Attribute Reference from Pivotal.

The comments in the default manifest.yml file identify the required fields and their placeholders, but here is a summary of the defaults:

  • name - The name of the PCF app.
  • memory - The memory requirements of the app. The default memory limit is 1G. You might want to specify a smaller limit to conserve quota space if you know that your app instances do not require 1G of memory.
  • instances - The number of app instances.
  • random-route - Generate a unique route and avoid name collisions. See random-route from Pivotal.
  • routes - Provide multiple HTTP and TCP routes. Each route for this app is created if it does not already exist. See routes from Pivotal.

Here is the default manifest.yml:

- name: ((PCF_APP_NAME))
memory: ((PCF_APP_MEMORY))
instances : ((INSTANCES))
random-route: true

Here are the values for placeholders in vars.yml:

PCF_APP_NAME: ${app.name}__${service.name}__${env.name}

You can use all of the PCF manifest attributes supported in typical PCF manifests, as described in Application Attributes from Pivotal.

Overriding Files and Values

The manifest.yml and vars.yml files can be overwritten in the Harness Environments that use the Service. Each of of the values in the manifest.yml and vars.yml files can also be overwritten.

Details on overwriting files and values is covered in the PCF Environments topic.

Inline Manifest and Variable Files

The default manifest.yml and vars.yml files can be edited inline in the Harness editor.

Simply click Edit, make any changes, and then click Save.

Local Manifest and Variable Files

You can upload manifest.yml and vars.yml files from your local drive into your Harness Service.

Harness allows one manifest file and one or more variable files. At runtime, Harness will evaluate the files to identify which is the manifest file and which are the variable files.

From the options menu, click Upload Local Manifest Files.

The Upload Local Manifest Files dialog appears.

Choose the local folder or files using your file explorer or drag and drop the files into the dialog. The selected files are listed.

Click Submit to add the files.

If you are uploading a manifest.yml or vars.yml file into the same folder with the default manifest.yml and vars.yml files, you will see the following warning.

Simply click Overwrite All and then Submit to replace the default files.

Remote Manifest and Variable Files

Once you have set up a Harness Source Repro Provider using your remote Git repo, you can use PCF files from the remote repo in your PCF Service Manifests section.

To use remote files, do the following:

  1. Create a Harness Source Repro Provider that connects to the branch where your remote files are located.

    When you set up the Source Repro Provider, you specify the repo URL and branch name:
  2. In the PCF Service, in Manifests, click the options button, and then click Link Remote Manifests.
    The Remote Manifests dialog appears.
  3. In Source Repository, select the Source Repo Provider you set up, and that points to the remote Git repo containing your manifest files.
  4. In Commit ID, select Latest from Branch or Specific Commit ID.

    Which one should I pick? Make your selection based on what you want to happen at runtime. If you want to always use the latest files from a repo branch at runtime, select Latest from Branch. If you want to use the files as they were at a specific commit, select Specific Commit ID. Any changes from additional commits will not be used at runtime. To use changes from additional commits, you will have to update commit ID.
  5. If you selected Latest from Branch, specify the Branch and File/Folder path to the remote manifest files.
  6. If you selected Specific Commit ID, specify the Commit ID and File/Folder path to the remote manifest files.

Click Submit. Your remote git repo is added as the source for Manifests.

Configuration Variables and Files

Configuration variables and files enable you to specify information in the Service that can be referenced in other parts of the Harness Application.

For example, you can specify a variable in the Service once, and then use it in multiple Workflows without having to manage multiple values.

  • Config Variables - You can create Service variables to use in your Manifests files, and in Environments and Workflows. Any Service variables are added as environment variables when the app is created in the Pivotal environment (cf push). Later, when you want to reference a Service variable, you use the syntax ${serviceVariable.var_name}.
  • Config Files - You can upload config files with variables to be used when deploying the Service. Later, when you want to reference a Service config file, you use the syntax ${configFile.getAsString("fileName")} for unencrypted text files and ${configFile.getAsBase64("fileName")} for encrypted text files.

For details on configuration variables and files, see Configuration Variables and Files.

Using Config Variables in Manifests

You can use Config Variables in your Service in place of values in manifest.yml and vars.yml.

You can then overwrite this variable in a Harness Environment's Service Configuration Overrides, and the new value is used when the Service and Environment are used for deployment.

Overwriting Service variables is described in more detail in PCF Environments.

Next Step

How did we do?