Azure Arc allows developers and administrators to implement a simple but secure GitOps process with the Flux extension.
My last post explained how you can use Kustomize to create configuration files for your Kubernetes cluster and applications and today I will use Flux to deploy these configurations to an on-premises k3s cluster.
This post is part of “Azure Arc Series - Manage an on-premises Kubernetes Cluster with Azure Arc”.
What is Flux?
Flux is a popular open-source GitOps provider and is used by Azure as the GitOps operator for Azure Arc enabled Kubernetes cluster. The Flux GitOps operator will be installed as an extension and will run inside your cluster. Once the Flux agent runs, it can send information to Azure and also connect to a Git repository. All this is done with an outbound connection, no inbound connection is needed. Therefore, your cluster will be safe, and additionally, you can use a modern approach to manage your deployments.
The Flux extension uses Kustomize for the configuration of your deployments. For more information on Kustomize, see my last post.
Introducing the Demo Application
You can find the code of the finished demo application on GitHub.
The application is very simple and consists only of a YAML file in the root folder of the repository that contains a Deployment and a Service.
Additionally, I have added a kustomization file in my last post. This kustomization file will tell the Flux agent files it should apply.
Install the Flux Extension
The Flux operator can be installed as an extension with Azure Arc. Connect to the Master node of your on-premises Kubernetes cluster and use the following command to install the extension:
This command configures the Flux extension to be installed in the namespace cluster-config, allows access to the whole cluster with the scope parameter, and configures a Git repository and branch. The last line configures the kustomization configuration. This line sets a name, the path, and enables prune. If prune is enabled, Kustomize will delete all associated resources of the kustomization file when the file gets deleted. This should help to keep your cluster clean.
The configured namespace “cluster-config” will contain a config map and several secrets which will be used for the communication to Azure. Additionally, these secrets allow you to connect to a private Git repository. I will show you in my next post, how to configure a private Git repository as your source.
The installation should take a couple of minutes. After it is finished, go to your Azure Arc resource, open the Extensions pane and you should see your Flux extension there.
The Flux extension has been installed
If you scroll up to the output of the installation, you will see that something went wrong. The error message says: “namespace not specified, error: namespaces gitopsdemo not found.
The namespace was not found
The application in the YAML file has the gitopsdemo namespace specified but you have not created the namespace yet. Therefore, the installation of the application fails.
To display the configuration of the previously installed GitOps operator, use the following command:
Alternatively, open the GitOps pane in your Azure Arc resource in the Azure portal and click on the configuration. If you used the same name as I did, you should see the name “gitopsoperator”. Click on it and you should see the same error message as in the CLI above.
Let’s delete this GitOps configuration and fix it. Use the following command to delete the GitOps operator.
Fix the failed Deployment
To fix the problem above, you have to create the namespace before the application is deployed. The first approach that comes to mind is to add the namespace to the already existing YAML file. Adding more and more resources to one file might work for this demo application but is impractical in the real world. The file size would explode and you wouldn’t be able to find anything.
Another approach would be to create another YAML file for the namespace and then add this new file to the kustomization file. The problem with this approach is that you can not guarantee that the namespace will be created before the application is deployed.
The solution to the problem is to have the namespace created first and only then start the deployment of the application. Additionally, it is a good practice to have different folders for the type of deployment you want to do. For the demo application, create two folders, App and Infrastructure. Each folder should contain its own kustomization file which also helps to keep the file small and also allows you to apply individual configurations for each folder.
Add the following YAML file in the Infrastructure folder to create a new namespace:
Open a terminal and use the following code to create a new kustomization file in each of the folders
Make sure that you have the Kustomize CLI installed.
To tell Kustomize about this dependency, use the “dependsOn” attribute of the kustomization flag. The following code shows how to add two kustomization files to the deployment and have a dependency of the application deployment to the namespace one.
Wait a bit and the deployment should succeed this time. You can open the GitOps pane in the Azure Arc resource in the Azure portal and should see the state as succeeded.
The deployment succeeded
If you make any changes to your Git repository, for example, changing the tag of the image, the Flux operator will fetch and deploy these changes.
Check the pods of the gitops namespace to see that one pod of the application runs there.
The application runs in the cluster
Delete the GitOps Configuration
When you delete the GitOps operator, the Azure CLI asks you if you really want to delete it and also tells you that prune has been enabled for this deployment. Acknowledging both messages will delete the GitOps operator and due to the prune flag also all resources associated with it. This means that the namespace, application, and service of this demo will be deleted. You will see that nothing exists anymore after the delete command has finished.
All resources got deleted
I have noticed that the prune does not always work but so far I could not find out a reason for that behavior nor am I able to gather any logs or error messages to analyze the problem.
Using Private Repositories for GitOps
Today’s demo used a public Git repository to host the files for the deployment. Almost all enterprise applications are hosted on a private Git repository though. Therefore, I will show you in my next post how to securely connect to a private repository in Azure DevOps or GitHub using SSH keys and the Flux GitOps operator.
Conclusion
The Flux GitOps extension for Azure Arc allows you to implement an easy and secure GitOps process. The installed Flux agent polls a configured Git repository and automatically installs any changes in the repository. Since the agent pulls the changes, no inbound connection to your cluster or network is necessary. Additionally, the Flux GitOps extension uses the popular open-source tool Kustomize to manage the configuration for applications and deployment.
This post is part of “Azure Arc Series - Manage an on-premises Kubernetes Cluster with Azure Arc”.
Comments powered by Disqus.