Environment-specific configuration
On this page
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.
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.
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.