Docsright arrowAmbassador Cloudright arrowAutomated Configuration Analysis

3 min • read

Automated Configuration Analysis

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.

What are the current capabilities of the automated configuration analysis integration?

Currently, the integration relays information about:

  • New routes created by Mappings
  • Conflicting routes (e.g. two Mappings configuring the same prefix on the same Host)
  • Envoy metric names for any new routes

Coming soon, we plan to support:

  • Validation for the produced Envoy configuration.
  • Validation for TCPMappings
  • Validation for Hosts
  • Support other git providers

Can I support multiple directories or cluster configurations?

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.

Will the automated configuration analysis recursively search for files?

Yes, if you configure a manifest_path, the automated configuration analysis will recursively search the entire directory structure to find Kubernetes yaml files.

What if I have manifest files for different clusters in the same directory?

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 with manifests/test-app.yaml and manifests/prod-app.yaml, it is easy to run

and deploy your test application to your production cluster, or vice versa.