8.1 Cloud Configuration
Applications built for the Cloud often need to adapt to running in a Cloud environment, read and share configuration in a distributed manner, and externalize configuration to the environment where necessary.
Micronaut’s Environment concept is by default Cloud platform-aware and makes a best effort to detect the underlying active environment.
You can then use the Requires annotation to conditionally load bean definitions.
The following table summarizes the constants in the Environment interface and provides an example:
Constant | Description | Requires Example | Environment name |
---|---|---|---|
The application is running as an Android application |
|
| |
The application is running within a JUnit or Spock test |
|
| |
The application is running in a Cloud environment (present for all other cloud platform types) |
|
| |
Running on Amazon EC2 |
|
| |
Running on Google Compute |
|
| |
Running on Kubernetes |
|
| |
Running on Heroku |
|
| |
Running on Cloud Foundry |
|
| |
Running on Microsoft Azure |
|
| |
Running on IBM Cloud |
|
| |
Running on Digital Ocean |
|
| |
Running on Oracle Cloud |
|
|
Note that you can have multiple environments active, for example when running in Kubernetes on AWS.
In addition, using the value of the constants defined in the table above you can create environment-specific configuration files. For example if you create a src/main/resources/application-gcp.yml
file, it is only loaded when running on Google Compute.
Any configuration property in the Environment can also be set via an environment variable. For example, setting the CONSUL_CLIENT_HOST environment variable overrides the host property in ConsulConfiguration. |