Bootstraping without the cli

[tuxpeople]

Hi

I'm not able to find the guide on how to deploy Fluxv2 into my cluster without the flux bootstrap git command. I just need the yamls, not the cli.

Thanks!

[stefanprodan]

Form the install docs:

kubectl apply -f https://github.com/fluxcd/flux2/releases/latest/download/install.yaml

[stefanprodan]

@jonaskello you don't need to do any of this manually on GitLab, use flux bootstrap git --private-key-file=./your-deploy-private-key, no token required, just the SSH deploy key locally.

[jonaskello]

I did not know that :-). But in that case, how does bootstrap add the deploy key public part to gitlab? Or that would be a manual step in this case? In my experience if I use bootstrap with gitlab and access token it both creates the keypair and adds the public part to gitlab.

[jonaskello]

Also if you do it this way and the local deploy-key (--private-key-file) only has read-access, then flux bootstrap will not push the changes to the repo? (I think it does push changes when run with access token IIRC).

In general my concern about flux bootstrap is that it feels (to me) a bit unpredictable what will happen when I run it. I'm happy to trade the automation for more manual work so that I can have insight into what happens and learn how things are setup. I only manage a few clusters but I can definitely see how automation like flux bootstrap would be useful when you have a lot of clusters to manage. IMHO both ways should be documented and supported.

@tuxpeople What was your reason/scenario for wanting to do the bootstrapping manually?

[egorksv]

Same here. Trialling flux as a way to offload helm charts management from terraform as it gets cumbersome past 10-15 charts, the whole thing spins off a single terraform run (AWS VPC / EKS / k8s extensions / charts), there's no we will allow "now stop the world and run some 3rd party CLI before proceeding"

[choeffer]

This breaks as soon as you define a kustomize.yaml in the flux-systems folder which patches parts of the gotk-components.yaml file. As this kustomize.yaml would also reference the gotk-sync.yaml file to enable the self-sync of flux (default behavior).

In detail: You would have to deploy flux via kubectl apply -k ./clusters/demo/flux-system/ to apply all defined patches to flux. But this will fail as the CRDs in gotk-components.yaml are not applied before the CRs GitRepository or Kustomization defined in the gotk-sync.yaml, as kubectl tries to apply everything at the same time

I still not have a solution for this chicken egg problem. The only solution I can think of is to put the gotk-sync.yaml outside the flux-system folder. Then, you can apply kubectl apply -k ./clusters/demo/flux-system/ (to have all patches applied), and later on the gotk-sync.yaml, which depends on the before created CRDs.

kubectl apply -f flux/flux-system/gotk-components.yaml
kubectl apply -f flux/flux-system/gotk-secret.yaml
kubectl apply -f flux/flux-system/gotk-sync.yaml

9. Done!

[stefanprodan]

Bootstrapping without the Flux CLI is now supported by using Flux Operator. Docs: https://fluxcd.io/flux/installation/#bootstrap-with-flux-operator

[choeffer]

Maybe a dumb question, but how does this solve the issue?
Then I have the bootstrapping process and getting things self-synced and running problem just pushed to another component, which features I currently do not need. Who watches and bootstrapps the watcher, the flux operator?
The charm of Flux after bootstrapping is the self-sync and self-management. And that you can control and manage the whole flux installation via git after that point.
Your suggestion means we have to learn CRs to control, install, and manage flux, and on top manage a whole new component, the operator.

[fmiqbal]

Flux Operator act as deployer for Flux Instance, it then make the "initial" GitRepository and flux-system Kustomization (the component which if using cli will be included in flux-system directory, the gotk-sync). On my personal experience, this is cleaner approach as i can deploy it using terraform, (or natively its just a helm release), 2 helm release to be exact

1. flux operator, a simple helm install (no value is fine)
2. flux instance, just a wrapper to deploy FluxInstance CRD (the value of which is described more cleanly than end-result of gotk-sync yaml)

[matheuscscp]

Our recommendation/battle-tested approach to self-syncing is deploying a Flux HelmRelease for the operator. This way the operator manages Flux, and Flux manages the operator. People are really happy with how much boilerplate reduction they get with Flux Operator

[mloskot]

the operator manages Flux, and Flux manages the operator

I bet my head that if classic Flux non-power users stumble upon this, it will make their knees shake :)

This is such a genius yet counter-intuitive idea, that it should be stated in bold in motivation paragraph of the FO documentation, I think.

[choeffer]

Thanks for all your hints and thoughts. I might have a look at the operator in the future. As we currently do not want to deal with the operator, or see a need for it, I have found a much simpler solution based on a single kustomization.yaml. This also removes the dependency on the flux bootstrap command, if you have a more complex setup, e.g. included SOPS encrypted SSH keys.

I have added a new bootstrap folder besides the flux-system folder in each cluster. This folder only contains the following kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../flux-system/
patches:
  - patch: |
      $patch: delete
      apiVersion: source.toolkit.fluxcd.io/v1
      kind: GitRepository
      metadata:
        name: flux-system
        namespace: flux-system
  - patch: |
      $patch: delete
      apiVersion: kustomize.toolkit.fluxcd.io/v1
      kind: Kustomization
      metadata:
        name: flux-system
        namespace: flux-system

Bootstrapping the cluster is then as simple as

kubectl apply -k ./clusters/staging/bootstrap/

to include all patches etc. and afterwards adding the sync via

kubectl apply -f ./clusters/staging/flux-system/gotk-sync.yaml

With that, we can stick to the proposed folder structure, do not have to manage a complete second component (the operator and its Helm layer), have no need to use CRs to manage Flux, and so on.