Environments

Users with Owner or Developer Roles can create new or change existing Environments on their own without support.

The Platform Orchestrator allows developers to easily create, manage, and delete Environments. Developers can specify the configuration and resources needed for each Environment, such as the type and size of compute instances, the amount of storage, and the type of database.

An Environment is a space where an instance of an Application can be deployed. Environments consist of a Kubernetes namespace and any shared Resources (as configured by relevant Matching Rules).

An Application can serve many Environments.

Use Environment Types #

The Platform Orchestrator has a concept of Environment Types. These allow Environments to be specialized for different purposes. Typical types of Environment are development, staging, pre-production, and production. You can define Environment Types to group and manage Environment for your team. Every Environment in the Platform Orchestrator has exactly one Environment Type.

Environment Types can be used with Resources Definitions to manage where resources such as databases are provisioned or even which Kubernetes cluster to deploy to.

For information on Environment Types constraints, see Constraints. For information on using ephemeral Environments with your pipeline, see Deploy ephemeral Environments

Example #

Let’s look at a simple example of how Environment Types can be used when building an Internal Developer Platform. It is common to use different infrastructure for development vs. production environment. Let’s assume a team wants to use the infrastructure listed below in their day-to-day work.

The easiest way to achieve this setup in Humanitec is to use two different Environment Types (for example, development and production) to define the infrastructure that should be used/provisioned depending on the type of environment. The following sections explain how to achieve this step by step.

Manage Environments #

Each new Application in Humanitec is created with a default Environment called Development. You can add as many other Environments to the App as you need.

Default Environment cannot be deleted without deleting the entire App. This section explains how to create a new Environment based on an existing Environment.

To create or delete Environments, you must be signed into a role with elevated permission, like the Owner or Developer role.

Create an Environment #

When creating a new Environment, you may either create an empty Environment or choose to clone from an existing one. Only Environments with an existing Deployment can be cloned from.

Cloning will create a Draft Delta in the new Environment which is a copy of the latest Deployment of the source Environment. It will not immediately perform a Deployment in the new Environment.

• Portal
• CLI
• API
• Terraform

humctl create env $ENV_ID --type=${ENV_TYPE} --name="${ENV_NAME}" --from=${FROM_ENV_ID}

curl "https://api.humanitec.io/orgs/${HUMANITEC_ORG}/apps/${APP_ID}/envs" \
  -X POST \
  -H "Authorization: Bearer ${HUMANITEC_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
  "id": "'${ENV_ID}'",
  "name": "'${ENV_NAME}'",
  "type": "'${ENV_TYPE}'",
  "from_deploy_id": "'${FROM_DEPLOY_ID}'"
}'

Delete an Environment #

Delete an Environment to remove it from the Application.

• Portal
• CLI
• API
• Terraform

humctl delete env production --app ${APP_ID}

curl "https://api.humanitec.io/orgs/${HUMANITEC_ORG}/apps/${APP_ID}/envs/${ENV_ID}" \
  -X DELETE \
  -H "Authorization: Bearer ${HUMANITEC_TOKEN}"

Pause an Environment #

Pause an Environment to scale the Kubernetes Deployments of all Workloads down to 0 replicas.

Pausing and then resuming the Environment is a way to restart all Pods of the Environment controlled by Kubernetes Deployments. To restart an individual Workload only, you can use the Replicas Feature in the Portal.

To pause and resume Environments, the user must have at least the Developer role on the Application and Deployer role on the Environment Type.

• Portal
• CLI
• API
• Terraform

humctl api put "/orgs/${HUMANITEC_ORG}/apps/${APP_ID}/envs/${ENV_ID}/runtime/paused" -d 'true'

curl "/orgs/${HUMANITEC_ORG}/apps/${APP_ID}/envs/${ENV_ID}/runtime/paused" \
  -X PUT \
  -H "Authorization: Bearer ${HUMANITEC_TOKEN}" \
  -H "Content-Type: application/json" \
  -d 'true'

When an Environment is paused, you can’t:

• Deploy the environment within Humanitec.
• Scale the number of replicas running of any workload.

Resume an Environment #

On resume requests, all the Kubernetes Deployment resources are scaled up to the number of replicas running before the environment was paused.

• Portal
• CLI
• API
• Terraform

humctl api put "/orgs/${HUMANITEC_ORG}/apps/${APP_ID}/envs/${ENV_ID}/runtime/paused" -d 'false'

curl "/orgs/${HUMANITEC_ORG}/apps/${APP_ID}/envs/${ENV_ID}/runtime/paused" \
  -X PUT \
  -H "Authorization: Bearer ${HUMANITEC_TOKEN}" \
  -H "Content-Type: application/json" \
  -d 'false'

Schedule an Environment to Pause or Resume #

The following example shows how to schedule an Environment to pause and resume using a the default-cronjob Workload Profile.

Create a new Workload based on that Workload Profile:

• Portal

To actively pause or resume the schedule, use the commands shown above to pause or resume an Environment.

Set Environment variables #

In Humanitec, Environment Variables can be defined at different levels. This allows developers to manage and organize their environment variables and secrets in a more flexible and scalable way.

• Application level: Available to all Workloads in the Application, regardless of which Environment they are running in. This can be useful for defining variables and secrets that are shared across all Workloads in the Application, such as database credentials or API keys.

• Environment level: Available to Workloads running in that specific Environment. This can be useful for defining variables and secrets that are specific to a particular Environment, such as test or production environments.

• Workload level: Available to a specific Workload, regardless of which Environment it is running in. This can be useful for defining variables and secrets that are specific to a particular Workload, such as configuration settings or resource requirements.

The hierarchical nature of Environment Variables allows developers to manage and organize their variables and secrets in a flexible and scalable way.

Clone Environments #

The Platform Orchestrator makes it easy to promote or clone individual Workloads or entire Applications between Environments. This involves updating the target Environment with all environment agnostic configuration from the source Environment.

• Promote implies moving up the Environment release train: for example, from a development, to test to UAT to production.
• Clone is used to describe the general updating of Environments with Workload configuration from other Environments.

By cloning a deployment, you can create a separate Environment where you can test and make changes without affecting the original production environment.

Clone a deployment to an existing Environment #

• Portal
• CLI
• API
• Terraform

Clone an Environment from a deployment #

When cloning an Environment from a deployment, select all or some Workloads.

• Portal
• CLI
• API
• Terraform

Depending on the size and complexity of your Application, it may take some time for the new Environment to be created and deployed. You can monitor the progress of the deployment from the Environments’ section of your Application’s overview page. Once the deployment is complete, you will be able to access the new Environment and begin using it.