Entities often need some amount of per-environment customization. When the default configurations bundled with your releases, Apollo’s Config capabilities can be used to override parts of your default configurations.
Config overrides can be specified from the Config tab of an Entity. These overrides may be interpreted differently based on the Entity type. Configuration changes go through change requests and must be approved by an Entity operator. This creates a robust historical record of configuration changes, a clear audit and compliance trail for production Environments, and opportunities for validation.
Config overrides are applied to ranges of versions for a Product. Apollo will never deploy a release of a Product without a config override defined for that release. That means that at minimum, an empty override block declaring support for a major version of a Product must be provided if you would like it to be deployed.
The top level keys of the config relate to the starting version in the major version range for which this config would apply. This example below declares basic support for any Product release for major version 2. Note that no releases of major version 1 or 3, or any other number would be able to deploy without an override block specifically for those major versions.
2.0.0:
overrides: {}
Different overrides can be provided for ranges of releases of the Product. When a release is deployed, the most specific override range for that release is selected. This config resolution happens at the same time as an upgrade plan is recommended, so you can ensure that the most appropriate config is deployed along with the release to avoid race conditions and edge cases with varying support for config values or feature flags.
In this example, there is declared support for any release of the Product for major version 1 that is greater than or equal to 1.2.0
. There’s also declared support for any release of major version 2. Some additional config override values will be provided to the Entity for any release within major version 2 of 2.6.0
or later.
2.6.0:
overrides:
debug-logging-enabled: true
2.0.0:
overrides: {}
1.2.0:
overrides: {}
This system of declaring support for versions of software and providing config values ahead of time ensures Apollo can always safely upgrade or downgrade your releases based on new available releases or updated Product recalls. This is also how you can remove support for an Entity for older releases of your Product, or prevent installation of a new major version.
We recommend that you follow the Helm naming conventions. Variable names should begin with a lowercase letter and words should be separated with camelcase.
For Helm charts, the overrides
for each range of versions will be provided as part of the Helm values overrides along with other Apollo Entity data. In addition, any Environment Config defined for the Helm chart Entity's Environment will also be provided as part of the overrides for Helm values. For example:
# Entity overrides
0.1.0:
overrides:
newerFeature: enabled
# Environment Config
domainName: my-domain-name.com
numConnectionsAllowed: 5
The overrides
block above declares specific values for any release greater than or equal to 0.1.0
. For a release 0.1.2
, the overrides along with the Environment Config would yield the following value overrides provided during Helm install.
apollo:
entity:
id: aeid:my-dev-environment:helm-chart:my-helm-chart
product:
group: com.palantir.apollo-test
name: my-helm-chart
version: 0.1.2
environment:
id: my-dev-environment
domainName: my-domain-name.com
numConnectionsAllowed: 5
newerFeature: enabled
The apollo
block is injected by the Helm agent to ensure your chart always has access to Entity and Environment data that may be critical. The top-level keys of the overrides
block will be injected as top-level keys within the Helm values overrides. You can use any of these keys within your Helm chart templates. For example, to reference the name of your product in a chart template, you can use the syntax {{ .Values.apollo.product.name }}
.