Gimlet has a client-server architecture.
The agent runs inside your Kubernetes cluster. It gathers realtime information and ships it to the Gimlet server. This information is used to power the realtime cluster view in the Gimlet UI and to determine error states in your cluster.
You run as many Gimlet Agents as many environments you have.
Runs either hosted on https://gimlet.io or you self-host it in your infrastructure.
The Gimlet Server
- powers the Gimlet UI
- aggregates environment information received from the Gimlet Agents
- processes webhooks from git
- runs the GitOps event handlers and updates the GitOps Repository
The GitOps Repository holds the Kubernetes manifests of your applications.
FluxCD is the GitOps controller. It continuously applies manifest changes to the Kubernetes cluster.
How components interact
When a Gimlet deployment is triggered - either on-demand from the UI, or by a workflow trigger - the Gimlet Server looks for the deployment configuration and generates an updated application manifest, which it then puts in the GitOps repository.
FluxCD is deployed in the deployment environment and listens for changes in the GitOps repository's releasees folder. If it sees a change, it will apply it on the cluster.
The Gimlet Agent is also running in the deployment environment, and streams a realtime Kubernetes state to the Gimlet Server. Which then streams to the UI.
To learn more about the GitOps repository, see the The GitOps repository page
To learn more about on-demand deploys and service configuration, see the Deploying a new service page
To learn more about workflow triggers, see the Deployment workflows page