Environment-specific configuration

This page is a chapter of the Quickstart learning path. Make sure to progress through the chapters in the order set in the main navigation. To start out, go to Introduction .

The Workload specification #

You have already seen how the “message of the day” displayed in the Application UI is being sourced from the variables declared in the Score file. The currently hardcoded value means that the same message will be displayed in every Environment the Score file is being deployed into.

To apply environment-specific configuration, you can use a special resource type environment that is declared in the Score specification for this purpose. Edit your score.yaml and add another entry to the resources section:

resources:
   ...
  env:
    type: environment

Refer to this resource and change the variables specification for the OVERRIDE_MOTD variable like this:

OVERRIDE_MOTD: ${resources.env.MOTD}

This value now references the env resource to retrieve its property MOTD. It is not defined anywhere just yet, but will be in the next section.

If you want to check for correctness of your edits or skip the self-editing, you can find a preconfigured file in the solutions subdirectory. To use it, execute:

cp solutions/env_deployment_score.yaml score.yaml

Set Shared Values #

The Platform Orchestrator fulfills the Score spec’s environment resource type through Shared Values which can be set on the Application and/or Environment level.

Set a Shared Value on the Application level matching the name of the value requested in the Score file ("MOTD"):

humctl create value MOTD "Default MOTD set as shared value" --env ""

This value will be the default unless overridden for a specific Environment. Let’s do just that for the staging Environment:

humctl create value MOTD "Staging MOTD set as override" --env staging

If you take a look at the Application in the Platform Orchestrator UI, you will see notices about outdated values. Take care of that by re-deploying your workload once more.

The Deployment #

Deploy your Score file into both development and staging Environments:

humctl score deploy
humctl score deploy --env staging

Check the application UI in development through executing

kubectl port-forward service/${HUMANITEC_APP} 8080:8080 -n ${NAMESPACE_DEVELOPMENT}

and opening http://localhost:8080 . Note that the “Default” message content is shown, sourced from the Application-level Shared value.

Close the port forwarding via Cmd-C or Ctrl-C and repeat for staging:

kubectl port-forward service/${HUMANITEC_APP} 8080:8080 -n ${NAMESPACE_STAGING}

Open http://localhost:8080 once more. You will see the Environment specific “Staging” value of the variable.

Close the port forwarding via Cmd-C or Ctrl-C.

The Platform Orchestrator UI lets you view and manage Shared Values in the “Values & Secrets” tab on the Application level, and in the “Values & secrets overrides” tab on the Environment level. Read more in the Shared Values documentation.

Inspect the Kubernetes objects of the staging Environment once more:

kubectl get all -n $NAMESPACE_STAGING

The latest Score Deployment has created the PostgreSQL database objects for staging as well.

You can easily configure the Platform Orchestrator to provision a different kind of PostgreSQL than the in-cluster variant, e.g. a managed cloud service, for staging, and yet another kind for production. All you need to do is provide another Resource Definition using a different IaC source, and configure its matching criteria. Doing so is out of scope for the Quickstart, but we have added some hints to the final Next Steps chapter.

Recap #

And that concludes this chapter. You have:

• ✅ Added the environment resource to your Workload specification
• ✅ Tapped into the environment to populate a container variable
• ✅ Provided environment specific values for the variable
• ✅ Inject those values into your container through another Deployment

Your setup now looks like this:

%%{ init: { 'flowchart': { 'curve': 'linear' } } }%%
flowchart LR
  subgraph scoreFile[Score file]
    direction TB
    subgraph scoreWorkload[Workload]
      workloadVariable(Variable)
    end
    scoreWorkload ~~~ scoreDb(Resource\npostgres)
    scoreDb ~~~ scoreEnv(Resource\nenvironment)
  end
  subgraph platformOrchestrator[Platform Orchestrator]
    cloudAccount(Cloud Account)
    subgraph application[Application]
      sharedValueApp(Shared Value\nApplication)
      envDevelopment(Environment\n"development")
      subgraph envStaging[Environment "staging"]
        sharedValueStaging(Shared Value\nStaging)
      end
    end
    resDefCluster(Resource Definition\nCluster)
    resDefNamespace(Resource Definition\nNamespace)
    resDefDb(Resource Definition\nPostgreSQL)
  end
  subgraph cloudInfrastructure[Cloud Infrastructure]
    subgraph k8sCluster[Kubernetes Cluster]
      subgraph namespaceDev[Namespace development]
        workloadDev(Workload\nwith env var\nfrom Application) --> dbDev(PostgreSQL)
      end
      subgraph namespaceStaging[Namespace staging]
        workloadStaging(Workload\nwith env var\nfrom staging) --> dbStaging(PostgreSQL)
      end
    end
  end
  scoreFile -->|humctl score deploy| envDevelopment
  scoreFile -->|humctl score deploy| envStaging
  envDevelopment --> namespaceDev
  envStaging --> namespaceStaging
  resDefCluster -.- k8sCluster

  %% Using the predefined styles
  class workloadVariable,sharedValueApp,sharedValueStaging,workloadDev,workloadStaging highlight
  class scoreWorkload,application,k8sCluster nested

Note that the staging namespace now has the PostgreSQL provisioned following the deployment into staging.

Continue to see how to make more than one Workload come together .