3 - PCF Environments

Updated 3 months ago by Michael Cretzman

In this step of the tutorial, you will add a description of the target PCF infrastructure where Harness will deploy the PCF apps you defined in your Harness PCF Service.

In this topic:

PCF Environments Overview

Environments represent one or more of your PCF deployment infrastructures, such as Dev, QA, Stage, Production, etc.

In the PCF Environments you create, you will add a description for each of the different PCF infrastructures where you want to deploy your apps. In Harness, these descriptions are called Infrastructure Definitions. Infrastructure Definitions are described later in this topic.

To set up your PCF deployment Environment, do the following:

  1. In your Harness Application, click Environments.
  2. Click Add Environment. The Environment dialog appears.

  1. In Name, enter a name for the PCF Environment, such as Staging. You will use this name later when you create your Workflow and select this Environment.
  2. In Environment Type, select Production or Non-Production.
  3. Click SUBMIT. The Environment is created.

Next, you will add Infrastructure Definitions to describe the deployment environments where you want to deploy your PCF apps.

PCF Infrastructure Definitions

Infrastructure Definitions are a feature-flagged replacement for Service Infrastructure.

In the Environment, you create Infrastructure Definitions that describe your target deployment environments. PCF Infrastructure Definitions specify the following:

  • The PCF deployment type.
  • The PCF Cloud Provider that you added, as described in Add Cloud Providers.
  • The PCF organization to use.
  • The target PCF space that the app you are deploying is scoped to.
  • Any specific Harness Services that you want to scope the Infrastructure Definition to. If you choose not to scope to specific Services, the Infrastructure Definition may be used with any PCF Service.

To add an Infrastructure Definition, do the following:

  1. In your Environment, click Add Infrastructure Definition. The Infrastructure Definition dialog appears.

The Infrastructure Definition dialog has the following fields.

Fields

Description

Name

Enter a name for your Infrastructure Definition. You will use this name to select this Infrastructure Definition when you create Harness Workflows.

Cloud Provider Type

Select Pivotal Cloud Foundry.

Deployment Type

Select Pivotal Cloud Foundry.

Cloud Provider

Select the Cloud Provider to use to connect to the foundation. This will be one of the PCF Cloud Providers you set up in Add Cloud Providers.

The roles associated with the PCF user account used in the Cloud Provider determine what orgs will appear in the Organization setting.

Organization

The active PCF orgs available to the PCF user account used in the Cloud Provider are listed. Select the PCF org for the development account.

Space

Select the space where the application you are deploying is scoped.

Scope to Specific Services

Select this option to scope this Infrastructure Definition to the Harness PCF Service you want to deploy.

If you do not select this setting, you can select this Infrastructure Definition when you create a Workflow for any PCF Service.

When you are finished configuring your Infrastructure Definition, it will look something like this:

Click Submit. The Infrastructure Definition is displayed in the Environment page:

Using Variables in the Infrastructure Definition

You can use Service variables in the PCF Infrastructure Definition Organization and Space settings:

This allows you to set the orgs and spaces in a Service, and have the Infrastructure Definition act as a template that multiple Services can use.

The orgs specified must be available to the PCF user account used to set up the PCF Cloud Provider used in the Infrastructure Definition.

Service Configuration Overrides

A PCF Service and Environment are used together when you set up a Harness Workflow to deploy your PCF app. You can configure your Environment to override settings of the Harness PCF Services that use the Environment, thereby making the Environment dictate PCF manifest values.

For example, a PCF Service uses a manifest.yml file that specifies specific routes, but an Environment might need to change the routes because it is deploying the app in the manifest to a QA space.

Variable Override

You can overwrite Service variables when one or more Services are paired with this Environment in a Workflow.

To overwrite a Service variable, do the following:

  1. In the Harness Service, note the name of the Service variable in Config Variables.

  2. In the Harness Environment, click Service Configuration Override. The Service Configuration Override dialog appears.

  3. In Service, select the Harness Service that contains the variable you want to overwrite. If you select All Services, you will have to manually enter the name of the variable you want to overwrite. The following steps use a single Service.

    When you have selected a Service, the Override Type options appear.

  4. Click Variable Override.
  5. In Configuration Variable, select the variable you want to overwrite.
  6. In Override Scope, the only option is Entire Environment, currently.
  7. In Type, select Text or Encrypted Text.
  8. In Override Value, if you selected Text in Type, enter a new value. If you selected Encrypted Text, select an existing Encrypted Text secret. Encrypted Text secrets are set up in Harness Secrets Management.

    When you are done, the dialog will look something like this:

  9. Click Submit. The override is added to the Environment:

File Override

File override is not currently used in PCF deployments.

PCF Manifests Override

The most commonly-used override is for PCF manifests. You can override the entire manifest.yml of a Service or any of its values.

To overwrite any property in an inline or remote manifest, the manifest.yml must use vars.yml for the property value.

For example, if you hardcode route: example.com in your inline or remote manifest.yml, you cannot overwrite it in Service Configuration Overrides. You must use a variable like route: ((ROUTE1)) in manifest.yml and then provide a value for the variable like ROUTE1: example.com in vars.yml.

For example, here are inline manifest.yml and vars.yml files using variables for routes. These variables are then overwritten in Service Configuration Overrides:

You can only perform one overwrite of a single Service. If you attempt to add a second overwrite of the same Service, you will receive this error: Can’t add, this override already exists. Please use the edit button to update.

To overwrite a PCF manifest, do the following:

  1. In the Harness Service, note the name(s) of the Service vars.yml property in Manifests that you want to overwrite. If you are using remote manifest files, go to your remote repro and note the name(s).
  2. In the Harness Environment, click Service Configuration Override. The Service Configuration Override dialog appears.

  3. In Service, select the Harness Service that contains the variable you want to overwrite. If you select All Services, you will have to manually enter the name of the variable you want to overwrite. The following steps use a single Service.

    The Override Type options appear.

  4. Click PCF Manifests.
  5. Click Local or Remote. The steps for each option are below.
Overwrite using Local Values

You can overwrite values in the vars.yml configured in your Service. It does not matter if the vars.yml in your Service is inline and remote.

To overwrite the variable values configured in your Harness Service, you can simply enter the vars.yml variables you want to overwrite, and enter new values. Here is an example overwriting routes in an inline vars.yml:

Overwrite using Remote Values

Typically, a single manifest.yml is used in a Service and then remote vars.yml files are used to supply different variable values.

To overwrite manifest property values using remote files, you simply point to a remote Git folder that contains the manifest.yml or vars.yml files containing the new values.

For example, here is a Service with an inline manifest.yml and vars.yml, and it uses the remote Git repo folder pcf-dev to overwrite the vars.yml values:

The remote vars.yml file does not need to supply all of the variables for the vars.yml file it is overwriting. You can simply overwrite the variables you want.

As you can see in the above example, the remote vars.yml file only overwrites the routes in the inline vars.yml file.

Variable Precedence

If multiple variables of the same name are defined in different places, such as a Service's Manifests or Config Variables sections or an Environment's Service Configuration Overrides section, the variables get overwritten according to the following precedence, from greatest to least:

  1. Service Configuration Overrides variables for a specific Service are of the greatest precedence, and override all others.
  2. Service Configuration Overrides variables for all Services.
  3. Variables in a Service Config Variables section.
  4. Variables defined in inline or remote files in Service Manifests section.

For more information, see Override a Service Configuration.

Next Step


How did we do?