Writing this as a matter of record, this process was much harder than it should have been so remembering the steps is crucial.

Register the Extensions

Note, the quickest way to do most of this step is the activate the GitOps blade after AKS has been created. This does not activate everything however, as you still need to run

az provider register –namespace Microsoft.Kubernetes.Configuration

This command honestly took around an hour to complete, I think – I actually went to bed.

Install the Flux CLI

While AKS does offer an interface through which you can configure these operations, I have found it out of date and not a good option for getting the Private Repo case to work, at least not for me. Installation instructions are here: https://fluxcd.io/flux/installation/

On Mac I just ran: brew install fluxcd/tap/flux

You will need this command to create the necessary resources that support the flux process, keep in mind we will do everything from command line.

Install the Flux CRDs

Now you would think that activating the Flux extension through AKS would install the CRDs, and you would be correct. However, as of this writing (6/13/2023) the CRDs installed belong to the v1beta1 variant; the Flux CLI will output the v1 variant so, it will be a mismatch. Run this command to install the CRDs:

flux install –components-extra=”image-reflector-controller,image-automation-controller”

Create a secret for the GitRepo

There are many ways to manage the secure connection into the private repository. For this example, I will be using a GitHub Personal Access Token.

Go to GitHub and create a Personal Access Token – reference: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

For this example, I used classic, though there should not be a problem if you want use fine-grained. Once you have the token we need to create a secret.

Before you do anything, create a target namespace – I called mine fastapi-flux. You can use this command:

kubectl create ns fastapi-flux

Next, you need to run the following command to create the Secret:

flux create secret git <Name of the Secret> \

–password=<Raw Personal Access Token> \

–username=<GitHub Username> \

–url=<GitHub Repo Url> \

–namespace=fastapi-flux

Be sure to use your own namespace and fill in the rest of the values

Create the Repository

Flux operates by monitoring a repository for changes and then running YAML in a specific directory when a change occurs. We need to create a resource in Kubernetes to represent the repository it should listen to. Use this command:

flux create source git <Name of the Repo Resource> \

–branch main \

–secret-ref <Name of the Secret created previously> \

–url <URL to the GitHub Repository> \

–namespace fastapi-flux

–export > repository.yaml

This command will create the GitRepository resource in Kubernetes to represent our source. Notice here, we use the –export to indicate we only want the YAML from this command and we are directing the output to the file repository.yaml. This can be run without –export and it will create the resource without providing the YAML.

I tend to prefer the YAML so I can run it over and over and make modifications. Many tutorials online make reference to this as your flux infrastructure and will have a Flux process to apply changes to them automatically as well.

Here, I am doing it manually. Once you have the YAML file you can use kubectl apply to create the resource.

Create the Kustomization

Flux referes to its configuration for what build when a change happens as a kustomization. All this is, is a path in a repo to look for, and execute, YAML files. Similar to the above, we can create this directly using the Flux CLI or us the same CLI to generate the YAML; I prefer the later.

flux create kustomization <Name of Kustomization> \

    –source=GitRepository/<Repo name from last step>\

    –path=”./<Path to monitor – omit for root>” \

    –prune=true \

    –interval=10m \

    –namespace fastapi-flux –export > kustomization.yaml

Here is a complete reference to the command above: https://fluxcd.io/flux/components/kustomize/kustomization/

This will create a Kustomization resource that will immediately try to pull and create our resource.

Debugging

The simplest and most direct way to debug both resources (GitRepository and Kustomization) is to perform a get operation on the resources using kubectl. For both, the resource will list any relevant errors preventing it from working, The most common for me were errors were the authentication to GitHub failed.

If you see no errors, you can perform a get all against the fastapi-flux (or whatever namespace you used) to see if you items are present. Remember, in this example we placed everything in the fastapi-flux namespace – this may not be possible given you use case.

Use the reconcile command if you want to force a sync operation on a specific kustomization.

Final Thoughts

Having used this now I can see why ArgoCD (https://argoproj.github.io/cd/) has become so popular as. a means for implementing GitOps. I found Flux hard to understand due its less standard nomenclature and quirky design. Trying to do it using the provided interface from AKS did not help either as I did not find the flexibility that I needed. Not saying it isn’t there, just hard to access.

I would have to say if I was given the option, I would use ArgoCD over Flux every time.