Secure Application Deployments in Azure Arc with Flux GitOps

Azure Arc offers developers and administrators a seamless and robust GitOps process by leveraging the Flux extension, enabling efficient management and security.

In my previous post “Manage your Kubernetes Resources with Kustomize” I delved into the utilization of Kustomize for generating configuration files tailored to your Kubernetes cluster and applications.

Today, we will explore the utilization of Flux to deploy these meticulously crafted configurations to an on-premises k3s cluster. This integration of Azure Arc, Kustomize, and Flux empowers organizations with enhanced control and flexibility in their deployment workflows.

This post is part of “Azure Arc Series - Manage an on-premises Kubernetes Cluster with Azure Arc”.

Understanding Flux

Flux is a widely adopted open-source GitOps provider that serves as the GitOps operator for Azure Arc-enabled Kubernetes clusters. As an extension installed within your cluster, the Flux GitOps operator operates autonomously. It establishes an outbound connection, ensuring the security of your cluster without requiring any inbound connections. This modern approach empowers you to manage your deployments effectively.

The Flux extension leverages Kustomize for configuring your deployments. If you would like to delve deeper into Kustomize, I invite you to refer to my previous post where I explored its intricacies and benefits. By combining the capabilities of Flux and Kustomize, you can streamline your deployment processes while adhering to best practices in the field of Kubernetes management.

Introducing the Demo Application

You can find the code of the finished demo application on GitHub.

The demo application is designed with simplicity in mind and comprises a YAML file located in the repository’s root folder. This YAML file encompasses a Deployment and a Service, forming the core components of the application.

In addition to the application YAML file, I have also included a kustomization file in my last post. This kustomization file instructs the Flux agent on which files to apply.

By leveraging the code and the kustomization file, you can effortlessly deploy and manage the demo application using the power of Azure Arc, Flux, and Kustomize. Feel free to explore the GitHub repository for a comprehensive understanding of the demo application’s implementation.

Installing the Flux Extension

To integrate the Flux operator as an extension with Azure Arc, you need to connect to the Master node of your on-premises Kubernetes cluster and execute the following command for installation:

This command configures the installation of the Flux extension within the cluster-config namespace, granting access to the entire cluster through the scope parameter. It also sets up a Git repository and branch for Flux to interact with. The last line configures the kustomization configuration, specifying a name, path, and enabling the prune feature. When enabled, Kustomize will remove associated resources if their corresponding kustomization file is deleted, ensuring cluster cleanliness.

The cluster-config namespace will contain a configuration map and several secrets used for communication with Azure. These secrets also enable connectivity to private Git repositories. In my next post, I will guide you on configuring a private Git repository as the source.

The installation process may take a few minutes. Once completed, navigate to your Azure Arc resource, open the Extensions pane, and you should find the Flux extension listed there.

The Flux extension has been installed

If you review the installation output, you’ll notice an error indicating that the namespace was not found. The error message states: “namespace not specified, error: namespaces gitopsdemo not found.”

The namespace was not found

This error occurs because the YAML file specifies the gitopsdemo namespace, which hasn’t been created yet. Consequently, the application installation fails.

To view the configuration of the previously installed GitOps operator, you can use the following command:

Alternatively, in the Azure portal, navigate to the GitOps pane within your Azure Arc resource, click on the configuration, and if you used the same name, you should see “gitopsoperator.” Clicking on it will display the same error message as shown above in the CLI output.

Let’s resolve this issue by deleting the current GitOps configuration and rectifying it. Execute the following command to delete the GitOps operator:

Fixing the Failed Deployment

To address the problem mentioned earlier, we need to create the namespace before deploying the application. Instead of adding the namespace directly to the existing YAML file, let’s adopt a more scalable approach. We’ll create separate folders for different deployment types, such as “App” and “Infrastructure,” and include a kustomization file in each folder. This organization ensures modularity, easy maintenance, and the ability to apply individual configurations.

First, let’s create a YAML file in the “Infrastructure” folder to establish the new namespace:

Next, open a terminal and execute the following commands to create a kustomization file in each folder:

Make sure that you have the Kustomize CLI installed.

To establish the dependency between the application deployment and the namespace creation, utilize the “dependsOn” attribute in the kustomization file:

Wait a moment, and this time the deployment should succeed. In the Azure portal, open the GitOps pane within your Azure Arc resource, and you should observe the deployment status as “succeeded.”

The deployment succeeded

If you make any changes to your Git repository, such as modifying the image tag, the Flux operator will fetch and deploy those changes automatically.

Check the pods in the gitops namespace to ensure that one pod of the application is running there.

The application runs in the cluster

The Flux operator ensures seamless updates whenever changes are made to the Git repository, providing a robust and automated deployment process.

Deleting the GitOps Configuration

When you delete the GitOps operator, the Azure CLI will prompt you to confirm the deletion. Additionally, it informs you that the prune flag has been enabled for this deployment. By confirming these messages, the GitOps operator and all associated resources will be deleted. In the case of this demo, it means that the namespace, application, and service will also be deleted. Once the deletion command completes, you will observe that no resources exist anymore.

All resources got deleted

Please note that although the prune flag is enabled, there might be instances where the prune operation doesn’t function as expected. At present, the cause of this behavior remains unknown, and there are no available logs or error messages for further analysis.

Using Private Repositories for GitOps

In the demo, a public Git repository was used to host the deployment files. However, in enterprise scenarios, applications are typically hosted on private Git repositories. In my next post, I will guide you on securely connecting to a private repository in Azure DevOps or GitHub using Personal Access Tokens and the Flux GitOps operator.

Conclusion

In summary, this article highlights the importance of secure application deployments in Azure Arc with Flux GitOps. By integrating Flux, Azure Arc, and Kustomize, developers and administrators can streamline Kubernetes deployments and enhance configuration management.

The article introduces a demo application and provides installation steps for the Flux extension. It emphasizes the scalability of organizing deployments and mentions future topics such as deleting the GitOps configuration and using private repositories. Overall, Azure Arc, Flux GitOps, and Kustomize offer a robust solution for secure and efficient application deployments in Kubernetes clusters.

This post is part of “Azure Arc Series - Manage an on-premises Kubernetes Cluster with Azure Arc”.