An environment is a running application instance with the configuration and supporting resources needed for a particular purpose. A packaged application can run in a local or cloud Kubernetes cluster; the cluster where it runs can serve as an environment. section 2.5
Environments serve different stages of delivery:
- Development and staging give teams places to deploy and test changes; QA can support manual testing; production serves real users. section 4.1
- An environment pipeline keeps each environment’s configuration in sync with what runs there. Promoting a release means updating configuration to select a new service or version. section 4.1
Development environments can also be requested on demand through a platform API. Provisioning must account for the application, its databases and other infrastructure, and a way for the team to connect. An isolated instance lets a team test changes without disrupting another team’s setup. section 6.1.1 section 6.3.2
Provision an environment for the Conference application
A team submits an Environment Kubernetes resource to the platform API. A Crossplane composition uses vcluster to create a virtual Kubernetes cluster and installs the Conference application Helm chart. The team can then connect to its cluster and work against the running application. section 6.3 section 6.3.2
Listing 6.2 Environment definition as a Kubernetes resource
apiVersion: salaboy.com/v1alpha1
kind: Environment
metadata:
name: team-a-dev-env #1
spec:
compositionSelector:
matchLabels:
type: development #2
parameters: #3
installInfra: true
The Kubernetes resource shows a named environment request selecting a development composition and requesting infrastructure installation. section 6.3.2
At larger scope, GitOps tooling can sync environment configurations to live clusters, while Crossplane can provision environments on cloud providers. That adds operational responsibilities: repositories for platform configuration, credentials, and access to cloud accounts. section 6.2.2
