Automated configuration analysis provides visibility into Edge Stack and Emissary-ingress configuration changes before any changes get deployed to your clusters.
The GitHub integration scans pull requests for Edge Stack and Emissary-ingress manifests, and compares the current state of your cluster installation to report any changes to Edge Stack or Emissary-ingress configuration and warn about any conflicts or invalid configuration.
Currently, the integration relays information about:
- New routes created by
- Conflicting routes (e.g. two
Mappings configuring the same
prefixon the same
- Envoy metric names for any new routes
Coming soon, we plan to support:
- Validation for the produced Envoy configuration.
- Validation for
- Validation for
- Support other git providers
Yes, you can configure a repository to support multiple configurations from Ambassador Cloud.
These configurations are managed with the
.a8r.yaml configuration file. For example:
Different directories that get applied to the same clusters can be managed with an
.a8r.yaml configuration file similar to the below:
You can either manually edit your
.a8r.yaml file if you know your
cluster_id, or you can visit the configuration page in the Ambassador
Cloud to register additional
clusters and manifest paths.
Yes, if you configure a
manifest_path, the automated configuration analysis will recursively
search the entire directory structure to find Kubernetes yaml files.
We strongly urge you to separate out files that get applied to different clusters into different directories.
Organizing your manifests in this manner will save you from accidentally applying
manifests to a cluster. When running
kubectl apply -f $DIRECTORY, kubectl will
search the directory and apply all the manifest files in that directory, and
this could have undesired consequences.
For instance, if you have a directory
manifests/prod-app.yaml, it is easy to run
and deploy your test application to your production cluster, or vice versa.
ON THIS PAGE