Skip to main content

Bootstrapping gitops automation

The gitops controller is a small piece of software running in your Kubernetes cluster. It monitors your gitops git repository for changes and applies them on the cluster.

To bootstrap the gitops controller

  • first, create a new git repository and check it out locally
  • then use the gimlet gitops bootstrap command to put the controller's deploy manifests in the GitOps repository
  • finally, apply the newly created manifests on the cluster

Any further changes to the GitOps repository will be automatically applied to the cluster. This is GitOps.🙌

gimlet gitops bootstrap \
  --env staging \
  --gitops-repo-path <<path-to-a-working-copy-of-the-gitops-repo>> \
  --gitops-repo-url git@github.com:<user>/<repo>.git

Notice that you have to provide a logical environment name to the bootstrap command. Gimlet prefers a central gitops repository, one that hosts multiple environments in one git repo.

Follow the steps from the command output to bootstrap the GitOps loop:

⏳ Generating manifests
⏳ Generating deploy key
✔️ GitOps configuration written to gitops/staging/flux


👉 1) Push the configuration to git
👉 2) Add the following deploy key to your Git provider

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1593b2v[...]

👉 3) Apply the gitops manifests on the cluster to start the gitops loop:

kubectl apply -f gitops/staging/flux/flux.yaml
kubectl apply -f gitops/staging/flux/deploy-key.yaml
kubectl wait --for condition=established --timeout=60s crd/gitrepositories.source.toolkit.fluxcd.io
kubectl wait --for condition=established --timeout=60s crd/kustomizations.kustomize.toolkit.fluxcd.io
kubectl apply -f gitops/staging/flux/gitops-repo.yaml

         Happy Gitopsing🎊

Deploy your first app with GitOps​

To see gitops in action, deploy a dummy application with GitOps.

To do so, you need to place application manifests in the GitOps repository and push your commit.

First, find some dummy yaml to deploy an Nginx container. Gimlet's OneChart Helm chart is perfect for this:

helm template dummy-app -n staging onechart/onechart > manifest.yaml

Then commit and push the files to the gitops repo under staging/dummy-app.

After pushing your changes, the gitops controller will try to match the cluster state to the git state, so it will deploy the git changes and the dummy application will pop up in the cluster.

If it isn’t deployed, you can crosscheck the GitOps loop logs with:

kubectl logs -n flux-system -f deploy/source-controller
kubectl logs -n flux-system -f deploy/kuatomize-controller

Adding a second gitops repository to a cluster​

If a cluster already has the Flux gitops controller deployed but you want it to pull from another gitops repo, you can use the gimlet gitops bootstrap commands --no-controller option.

With this option, Gimlet will not provision the Flux gitops controller, only the gitops repository CRDs.

Using a one repo per cluster model​

Gimlet favors packing multiple environments in the same gitops repo. It uses folders to organize manifests into environments.

But you may want to dedicate an entire git repository to a single environment.

In that case, you can use the --single-env option of gimlet gitops bootstrap to place everything in the root of the git repository.