Environments

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

Once you've added a Service to your Application, you can define Environments where your Service can be deployed. In an Environment, you specify the following:

  • A Harness Service, such as a Service with a Docker image artifact you configured.
  • A deployment type, such as Kubernetes.
  • A Cloud Provider, such as a Kubernetes cluster or Google Cloud Platform that you added in Add Cloud Providers.

An Environment can be a Dev, QA, Production, or other environment. You can deploy one or many services to each Environment.

In this topic:

Intended Audience

  • DevOps

Before You Begin

Video Summary

Add an Environment

The following procedure creates an Environment for a single Service.

To add an environment, do the following:

  1. Click Setup.
  2. Click an Application.
  3. Click Environments.
  4. Click Add Environment. The Environment dialog appears.
  5. Enter a name and description for the Environment. For example, the name DEV with the description, This is the development environment for example.com.
  6. In Environment Type, choose Production or Non-Production.
  7. Click SUBMIT. The Environment Overview appears. Here you can add the Service Infrastructure and overrides to the configurations of the Services that use this Environment.

Add a Service Infrastructure

Infrastructure Definition replaces Service Infrastructure as the method for defining your target infrastructure. Currently, Infrastructure Definition is behind a feature flag. Contact Harness Support to migrate to Infrastructure Definitions.

The Service Infrastructure for an Environment is where you specify a deployment infrastructure, using a Cloud Provider you added in Add Cloud Providers, a deployment type, such Kubernetes, and the specific infrastructure details for the deployment, like VPC settings.

To add a Service Infrastructure, do the following:

This example covers platforms that use clusters, such as Kubernetes and ECS, but the steps are similar for other platforms.
  1. In an Application, open an Environment.
  2. In Service Infrastructure, click Add Service Infrastructure. The Service Infrastructure dialog appears.
  3. In Service, click the name of the Service that will deploy to this Environment.
  4. In Deployment Type, click a deployment type such as Kubernetes.
  5. In Cloud Provider, click the cloud provider where you will deploy the service.
  6. Click Next. Harness will retrieve the cluster information from the cloud provider you selected.
  7. In Cluster Name, click the name of the cluster where you want to deploy the service.
  8. In Namespace, select the name of the cluster namespace.
  9. Click SUBMIT. The infrastructure is listed under Service Infrastructure.

For some Service Infrastructures, you will need to select VPC details and enter Connection Attributes. Connection Attributes are SSH keys used to connect to hosts in the VPC. This authentication is different from that performed by the Cloud Provider you select, which is used for API communication.

Connection Attributes use SSH keys set up in Harness Secrets. For more information, see Secrets Management.

For information about how a Service Infrastructure is used in specific deployments, see Deployments Overview.

Add an Infrastructure Definition

Infrastructure Definition replaces Service Infrastructure as the method for defining your target infrastructure. Currently, Infrastructure Definition is behind a feature flag. Contact Harness Support to migrate to Infrastructure Definitions.

The Infrastructure Definition is where you specify the target infrastructure for your deployment. The target infrastructure can be an existing infrastructure or an infrastructure provisioner, such as Terraform or CloudFormation, set up as a Harness Infrastructure Provisioner.

When you create a Harness Workflow, you pick the Infrastructure Definition you want to use as the target deployment environment.

To add an Infrastructure Definition, do the following:

  1. In your Harness Application, open or create an Environment.
  2. In the Environment, you can see the Infrastructure Definition section.

  1. Click Add Infrastructure Definition. The Infrastructure Definition dialog appears.

  1. In Name, enter the name that will identify this Infrastructure Definition.
  2. In Cloud Provider Type, select the type of Cloud Provider for Harness to use when connecting to the target infrastructure you will define. For example, if the target infrastructure is in AWS, select Amazon Web Services.

    Which Type do I Use? Pick the same type of Cloud Provider as the Cloud Provider you want this Infrastructure Definition to use to connect to your target infrastructure.
  3. In Deployment Type, select the type of deployment that matches the target infrastructure type. For example, if you are defining an infrastructure for AWS Lambda, then your Deployment Type would be AWS Lambda. If you are defining a Kubernetes cluster, then the Deployment Type would be Kubernetes.

That's the initial configuration of the Infrastructure Definition. The remaining settings depend on the Cloud Provider Type and Deployment Type you selected. If you selected AWS-related types, the remaining settings are AWS-related. If you select Kubernetes-related types, you will have Kubernetes cluster settings to provide.

Scope to Specific Services

The Scope to specific Services setting in the Infrastructure Definition enables you to scope this Infrastructure Definition to specific Harness Services.

This enables you to create one Infrastructure Definition and apply it to multiple Services. This will make the Infrastructure Definition available whenever a Workflow (or Phase) is set up for one of the Services.

For example, here is an Infrastructure Definition named Lambda-QA scoped to the Service named AWS Lambda. Next is a Workflow where the AWS Lambda Service has been selected.

You can see that since the AWS Lambda Service was selected in the Workflow setup, the Infrastructure Definition Lambda-QA is available in the Infrastructure Definition setting.

This is because the Lambda-QA Infrastructure Definition is scoped to the AWS Lambda Service.

If you create an Infrastructure Definition but do not add a Service using the Scope to specific Services setting, the Infrastructure Definition is available to all Workflows for Services that are of the same type as the Infrastructure Definition Deployment Type. When a Workflow is deployed, the Service deployed by the Workflow is added to the the Scope to specific Services setting in the Infrastructure Definition.

When creating Infrastructure Definitions, you might want to simply leave the Scope to specific Services setting empty until you have set up the Services you want to deploy to the Infrastructure Definition, and then enter the Services in the Scope to specific Services setting.

Scoping and Resource Constraints

When you do not select the Scope to specific Services setting, the Infrastructure Definition is not scoped to any Service, and therefore it can be used with any Service.

When you create a Workflow, any unscoped Infrastructure Definitions (where the Scope to specific Services setting is not selected) are available. The Infrastructure Definitions that appear in the Workflow are still dependent on the type of Service you select in the Workflow settings.

In the following example, the Infrastructure Definition is not scoped to a Service. The Workflow Phase setup dialog allows the Infrastructure Definition to be selected because both the Infrastructure Definition Deployment Type and the Service selected in the Workflow Phase setup are Kubernetes types.

Using Expressions in Infrastructure Definitions

You can use expressions for many Infrastructure Definition settings. This enables you to use a single Infrastructure Definition in multiple Workflows. In each Workflow, you can replace the expression with a specific value.

For example, here is the Infrastructure Definition for a Kubernetes cluster. In the Namespace field we have the expression ${workflow.variables.namespace}:

In each Workflow that uses this Infrastructure Definition, you can add a Workflow variable that replaces the namespace expression with a hardcoded value:

You could also have a non-fixed Workflow variable, and have the value entered during deployment manually...

...or you can have the value passed in by a Trigger.

Override a Service Configuration

For information about how a Service configuration is overwritten in a Kubernetes deployment, see Kubernetes Deployments.

You can configure your Environment to override settings of the Services that use the Environment. For example, a Service might use a specific values.yaml file, but your Environment might need to change the name and namespace of the Deployment object because it is deploying the Service to a QA Environment.

To override a Service configuration, do the following:

  1. In an Application, open an Environment.
  2. Click Add Configuration Overrides. The Service Configuration Override dialog appears.
  3. In Service, click the name of the Service you want to override. Depending on the type of Service you select, the Override Type options will be different. Here is an example of the options available when a Service with Kubernetes type is used.
  4. Click an Override Type option.
  5. Enter the override and click SUBMIT.

24/7 Service Guard

24/7 Service Guard applies Harness Continuous Verification unsupervised machine-learning to detect regressions and anomalies across transactions and events for the service and displays the results in the 24/7 Service Guard dashboard.

For more information, see 24/7 Service Guard.

Troubleshooting Environments

The most common error with environments occurs when an environment's connection to a workflow is changed in such a way as to render it inoperable for a deployment of that workflow. The error is displayed in the Workflows and Continuous Deployment pages:

This error can occur in the following circumstances:

  • A user changes the environment service infrastructure. For example, the user might remove a service infrastructure or change its Deployment Type or Cloud Provider so that the workflow can no longer use the environment to deploy its service(s).
  • A user changes the environment in a workflow. If you open the Workflow dialog and, in Environment, you select a different environment, then a service infrastructure must also be selected in Service Infrastructure.
  • The user clones a workflow to a different application that uses services that cannot deploy to the service infrastructure in that environment.

As a result of these changes, the workflow has no functional service infrastructure specified, and you must select a new service infrastructure for each impacted workflow/phase.

Next Steps

Add a Workflow


How did we do?