GitOps

As a followup of my post about the use of argocd-autopilot I’m going to deploy various applications to the cluster using Argo CD from the same repository we used on the previous post. For our examples we are going to test a solution to the problem we had when we updated a ConfigMap used by the argocd-server (the resource was updated but the application Pod was not because there was no change on the argocd-server deployment); our original fix was to kill the pod manually, but the manual operation is something we want to avoid. The proposed solution to this kind of issues on the helm documentation is to add annotations to the Deployments with values that are a hash of the ConfigMaps or Secrets used by them, this way if a file is updated the annotation is also updated and when the Deployment changes are applied a roll out of the pods is triggered. On this post we will install a couple of controllers and an application to show how we can handle Secrets with argocd and solve the issue with updates on ConfigMaps and Secrets, to do it we will execute the following tasks: Deploy the Reloader controller to our cluster. It is a tool that watches changes in ConfigMaps and Secrets and does rolling upgrades on the Pods that use them from Deployment, StatefulSet, DaemonSet or DeploymentConfig objects when they are updated (by default we have to add some annotations to the objects to make things work).Deploy a simple application that can use ConfigMaps and Secrets and test that the Reloader controller does its job when we add or update a ConfigMap.Install the Sealed Secrets controller to manage secrets inside our cluster, use it to add a secret to our sample application and see that the application is reloaded automatically....

For a long time I’ve been wanting to try GitOps tools, but I haven’t had the chance to try them for real on the projects I was working on. As now I have some spare time I’ve decided I’m going to play a little with Argo CD, Flux and Kluctl to test them and be able to use one of them in a real project in the future if it looks appropriate. On this post I will use Argo-CD Autopilot to install argocd on a k3d local cluster installed using OpenTofu to test the autopilot approach of managing argocd and test the tool (as it manages argocd using a git repository it can be used to test argocd as well). Installing tools locally with arkadeRecently I’ve been using the arkade tool to install kubernetes related applications on Linux servers and containers, I usually get the applications with it and install them on the /usr/local/bin folder. For this post I’ve created a simple script that checks if the tools I’ll be using are available and installs them on the $HOME/.arkade/bin folder if missing (I’m assuming that docker is already available, as it is not installable with arkade): #!/bin/sh # TOOLS LIST ARKADE_APPS="argocd argocd-autopilot k3d kubectl sops tofu" # Add the arkade binary directory to the path if missing case ":${PATH}:" in *:"${HOME}/.arkade/bin":*) ;; *) export PATH="${PATH}:${HOME}/.arkade/bin" ;; esac # Install or update arkade if command -v arkade >/dev/null; then echo "Trying to update the arkade application" sudo arkade update else echo "Installing the arkade application" curl -sLS https://get.arkade.dev | sudo sh fi echo "" echo "Installing tools with arkade" echo "" for app in $ARKADE_APPS; do app_path="$(command -v $app)" || true if [ "$app_path" ]; then echo "The application '$app' already available on '$app_path'" else arkade get "$app" fi done cat <<EOF Add the ~/.arkade/bin directory to your PATH if tools have been installed there EOF...