Posts

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...

As promised on my previous post, on this entry I’ll explain how I’ve set up forgejo actions on the source repository of this site to build it using a runner instead of doing it on the public server using a webhook to trigger the operation. Setting up the systemThe first thing I’ve done is to disable the forgejo webhook call that was used to publish the site, as I don’t want to run it anymore. Note: For now I’ve just removed the Active flag from the webhook, just in case I want to use it again in the future. I’ve left the system based on the json2file server running as it does nothing if no webhook is called, if we want to use it again it would be a good idea to disable actions to avoid conflicts if something is pushed, but it can be executed manually if needed and nothing will break, as both systems use the same directories to publish things). After that I added a new workflow to the repository that does the following things: build the site using my hugo-adoc image.push the result to a branch that contains the generated site (we do this because the server is already configured to work with the git repository and we can use force pushes to keep only the last version of the site, removing the need of extra code to manage package uploads and removals).uses curl to send a notification to an instance of the webhook server installed on the remote server that triggers a script that updates the site using the git branch....

Last week I decided I wanted to try out forgejo actions to build this blog instead of using webhooks, so I looked the documentation and started playing with it until I had it working as I wanted. This post is to describe how I’ve installed and configured a forgejo runner, how I’ve added an oci organization to my instance to build, publish and mirror container images and added a couple of additional organizations (actions and docker for now) to mirror interesting actions. The changes made to build the site using actions will be documented on a separate post, as I’ll be using this entry to test the new setup on the blog project. Installing the runnerThe first thing I’ve done is to install a runner on my server, I decided to use the OCI image installation method, as it seemed to be the easiest and fastest one. The commands I’ve used to setup the runner are the following: $ cd /srv $ git clone https://forgejo.mixinet.net/blogops/forgejo-runner.git $ cd forgejo-runner $ sh ./bin/setup-runner.sh...

With all the recent buzz about DeepSeek and its capabilities, I’ve decided to give it a try using Ollama and Open WebUI on my work laptop which has an NVIDIA GPU: $ lspci | grep NVIDIA 0000:01:00.0 3D controller: NVIDIA Corporation GA107GLM [RTX A2000 8GB Laptop GPU] (rev a1) For the installation I initially I looked into the approach suggested on this article, but after reviewing it I decided to go for a docker only approach, as it leaves my system clean and updates are easier. Step 0: Install dockerI already had it on my machine, so nothing to do here. Step 1: Install the nvidia-container-toolkit packageAs it is needed to use the NVIDIA GPU with docker I followed the instructions to install the package using apt from the NVIDIA website. Step 2: Run the Open WebUI container bundled with OllamaI could install ollama directly on linux or run it on docker, but I found out that there is a container with Open WebUI bundled with Ollama, so I decided to use it instead. To start the container I’ve executed the following command: docker run -d \ -e OLLAMA_HOST="0.0.0.0:11434" -p 127.0.0.1:11434:11434 \ -p 127.0.0.1:3000:8080 \ -v ollama:/root/.ollama \ -v open-webui:/app/backend/data \ --gpus=all --name open-webui --restart always \ ghcr.io/open-webui/open-webui:ollama...