When you create a whole FluxCD new setup from zero, it’s really easy: use flux bootstrap. it does “everything” for you. In my case I tried this setup first for last year’s advent calendar. Except back then I had an expedition scheduled for the first half of December, so this took the back seat and was eventually forgotten. Therefore in this year past everything I did back then slowly sank into oblivion, so I again had to start pretty much from zero.

I did set up the repo and a cluster (on Civo) back then, but I quickly tore down the cluster when I realized I wouldn’t be able to test it all out. The repo stayed though, so now i was starting afresh with a k3s cluster spanning three nanodes (that’s a linode referral link with a $100 credit over 60 days) and a repository already set up from last year.

This was an extremely frustrating endeavor. At first I tried to set up using flux bootstrap since that felt natural, but it wouldn’t work:

In this case flux bootstrap wouldn’t work, since it’d try to set everything up from zero. The way to pull this off was to first flux install into my new cluster, and then run the flux create source git command with options to point it to my existing cluster: it’d tell me it “failed to clone repository: authentication required” even though my repository is public.

Next I tried to flux install into creating a git source using the following command:

flux --context flux create source git flux-playground \
  --url=https://github.com/valerauko/flux-playground.git \
  --branch=main \
  --interval=1m

I have multiple contexts (clusters) in my kubeconfig, so I specify that I want to use the one for this playground. The url is my repository for this purpose, the branch hopefully self-explanatory and the interval how often flux should check if there are new updates to the repo.

Since I’m gonna be pushing often to try out how things work, I set this to a shorter (one minute) interval. In production, I’d use something like 30 minutes maybe. Depending on how reliable and automated the deploy process is, if you want a really snappy release experience, use a shorter interval. Then again, using the Flux web UI (or since that was deprecated, some alternative), you can just manually sync if you’re in a rush, so even longer intervals could be fine too.

However, this still wouldn’t work. While I could see the git source in the Flux UI and the Flux resources in the cluster, I couldn’t get it to actually install any of the stuff. In the end I gave in and made a temporary Github Personal Access Token (PAT) to give the flux bootstrap github command and ran the following command that finally did the trick (though not before first typoing the --path which meant I had to do a flux uninstall and force-push the repo back the two commits it made)…

flux --context flux bootstrap github \
  --owner valerauko \
  --repository flux-playground \
  --path clusters/dev \
  --private false \
  --personal true

I couldn’t understand why it demands a PAT to clone a public repository, but I guess it does commit too so it makes sense in retrospect. That’s a big difference from Argo, which is (as far as I’ve seen it in action) read-only with regards to git sources.

With the above command things finally started rolling: I could confirm the Flux resources showing up in the repo, and also that it started reconciling the various components (Prometheus, Grafana etc) I configured in the repo. From here on it’s pretty much “standard”: push to git, sync, enjoy. More on those parts later!