Gloo follows a declarative “intention” based configuration model. YAML (or convenience tools like a CLI or web interface) is used to specify intended state of the system and Gloo’s control plane reifies these intentions. This approach simplifies an otherwise potentially complex configuration scenarios and plays nicely with automation, versioning, and the workflows built on “gitops”. See below for more:
- Declarative Infrastructure and GitOps
- Gloo as Declarative Infrastructure
How to configure Gloo.
Kubernetes was built to support declarative configuration management. With Kubernetes, you can describe the desired state of your application through a set of configuration files, and simply run kubectl apply -f .... Kubernetes abstracts away the complexity of computing a diff and redeploying pods, services, or other objects that have changed, while making it easy to reason about the end state of the system after a configuration change. GitOps Configuration changes inherently create risk, in that the new configuration may cause a disruption in a running application.
At its core, Gloo is a simple product that adheres to the declarative infrastructure model: It watches the current state, known as a snapshot, consisting of proxies, secrets, endpoints, upstreams, and artifacts. It runs an event loop that, when the snapshot changes, reconciles it with the current state and applies any necessary changes. GitOps with Gloo Following the GitOps methodology, custom Gloo configuration can be stored in a version control repo, and controlling how that configuration is reviewed, merged, and deployed can help mitigate operational risk.