Alek's Blog - go

ClickHouse Use Case: Vector, Istio, nginx, Java on OVH MKS

2026-05-14T00:00:00+00:00

The first four parts of this series compared Elasticsearch, OpenSearch, Loki, Quickwit, and ClickHouse across storage models, operations, security, and UX. This part shows what a concrete production setup looks like when the decision has been made: ClickHouse as the log store, Vector as the ingestion agent, running on OVH Managed Kubernetes Service (MKS) with OVH Object Storage as the cold tier.

This is Part 5 of a five-part series:

Full guide: Elasticsearch vs. OpenSearch vs. Loki vs. Quickwit vs. ClickHouse: The Complete Guide</a></li>
Part 1</a> — storage models, compression, resource consumption, and SaaS options</li>
Part 2</a> — cluster setup, Kubernetes operations, backup and disaster recovery</li>
Part 3</a> — encryption, RBAC, and WORM compliance</li>
Part 4</a> — UI layers, dashboards, alerting, and cold-tier query behaviour</li>
Part 5 — this post</li> </ul>

cert-manager-webhook-libdns: One Webhook, Many DNS Providers

2026-03-03T00:00:00+00:00

cert-manager-webhook-libdns: One Webhook, Many DNS Providers 🔗</a></h1>
Managing DNS-01 challenges with cert-manager often means choosing one provider-specific integration and staying tightly coupled to it. cert-manager-webhook-libdns</a> takes a different approach: it uses the libdns</a> ecosystem so one webhook can support many DNS providers through a shared interface.
If you run mixed infrastructure, migrate between DNS vendors, or just want a cleaner operational model, this project is built for that.
Why this project exists 🔗</a></h2>
In many Kubernetes setups, certificate automation becomes harder than it should be because DNS integrations are fragmented:

Every provider has different APIs, credentials, and operational quirks.</li>
Switching providers often means switching tooling.</li>
Testing and maintenance can become provider-specific and brittle.</li> </ul>
cert-manager-webhook-libdns</a> solves this by exposing a single cert-manager webhook that delegates DNS record operations to pluggable libdns providers.
What it does 🔗</a></h2>
At a high level, the webhook:

Receives DNS-01 challenge requests from cert-manager.</li>
Loads provider credentials from Kubernetes Secrets.</li>
Resolves and writes challenge TXT records through the selected libdns provider.</li>
Cleans up records after validation.</li> </ul>
It supports important real-world behaviors, including:

Handling multiple TXT values for wildcard + apex certificate requests.</li>
Safer fallback logic when record listing fails.</li>
Provider-specific TTL handling (for example, deSEC minimum TTL enforcement).</li>
Deterministic provider listing in CLI output.</li> </ul>
Operational improvements in recent iterations 🔗</a></h2>
Several practical improvements were added to make this project easier to run and maintain:

Semantic version output via --version</code> (currently v0.5.0</code>).</li>
No etcd/envtest dependency in the default make test</code> path.</li>
Cleaner container workflow with Containerfile</code> support.</li>
Release workflow hardening:</li>
tests run before image release</li>
latest</code> is only published for stable tags</li>
release creation happens after successful image push</li>
concurrency guard to prevent overlapping tag releases</li> </ul> These are the kinds of changes that reduce surprises in CI/CD and day-to-day operations.Provider compatibility is now automated🔗</a></h2> A major maintenance challenge with libdns-based projects is knowing which upstream provider modules are actually compatible with your pinned libdns</code> version. This repository now includes an automated compatibility process: Script: scripts/check_libdns_provider_compat.sh</code></li> Workflow: .github/workflows/libdns-provider-compat.yml</code></li> Report snapshot: docs/01_provider-compat-latest.md</code></li> Historical snapshots: docs/YYYY-MM-DD_provider-compat.md</code></li> </ul> The check uses gh api</code> to scan provider repositories, inspect their go.mod</code>, and classify compatibility against the libdns version used in this project. That gives maintainers a repeatable compatibility signal instead of manual guesswork. Quick start🔗</a></h2> 1. Build and publish the image🔗</a></h3> Use your preferred container runtime (Podman is preferred, Docker fallback is supported): make container-build make container-push IMAGE_TAG=v0.5.0 REGISTRY=ghcr.io/<your-org></code></pre>2. Deploy the Helm chart🔗</a></h3> helm install libdns-webhook ./deploy/libdns-webhook \ --namespace cert-manager \ --set image.repository=ghcr.io/<your-org>/cert-manager-webhook-libdns \ --set image.tag=v0.5.0 \ --set groupName=acme.yourdomain.com</code></pre>3. Create provider credentials secret🔗</a></h3> Example for token-based providers: apiVersion: v1 kind: Secret metadata: name: dns-provider-credentials namespace: cert-manager type: Opaque stringData: api_token: "<YOUR_API_TOKEN>"</code></pre>4. Configure ClusterIssuer🔗</a></h3> apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: your-email@example.com privateKeySecretRef: name: letsencrypt-prod-account solvers: - dns01: webhook: groupName: acme.yourdomain.com solverName: libdns config: provider: cloudflare secretRef: name: dns-provider-credentials namespace: cert-manager</code></pre>Useful CLI checks🔗</a></h2> Before deployment, you can quickly inspect the binary: ./webhook --version ./webhook --list-providers</code></pre> This is helpful for validating exactly what was compiled into your image. Who should use this🔗</a></h2> This project is a strong fit if you: Run cert-manager and use DNS-01 challenges.</li> Need flexibility across multiple DNS providers.</li> Want one consistent webhook integration instead of many provider-specific implementations.</li> Care about release discipline and compatibility visibility.</li> </ul> Final thoughts🔗</a></h2> cert-manager-webhook-libdns</a> is not just a DNS integration layer. It is an operational strategy: keep cert-manager integration stable while letting providers vary underneath. If your platform team wants fewer moving parts and more predictable certificate automation, this is a practical approach worth adopting.
Building a native file upload handler for Caddy v2 2022-03-01T00:00:00+00:00 When Caddy v2</a> was released in 2020, it introduced a new concept of handlers that use Go’s native module features. In 2022 one of our customers needed to upload files, and at that time none of the available web servers could handle this natively without an extra program. So I decided to create a new handler for Caddy v2 — caddyv2-upload</a> was born. I was not aware of any other tool which can handle file uploads natively in just one binary which can be used in Kubernetes or OpenShift, or I have not searched hard enough 😁. I also wanted to learn go, so I decided to create a new handler for the go based webserver caddyserver</a>. In May 2022 dufs</a>, a Rust-based server, was created — so that might be another option worth considering. 🤷 Any how I wanted to learn go in the pre AI Area and at that time I looked into the docs of go modules, into the source of caddy servers own handlers and created step by step a new handler. Luckily there was already podman and buildah, so I was able to create container images to run and test locally. Building something real turned out to be the most effective way to learn Go. Diving into Caddy’s own handler source code, understanding the module system, and iterating with containers made the concepts stick far better than any tutorial would have. A minimal Caddyfile configuration looks like this: { order upload before file_server } :2015 { root . file_server browse @mypost method POST upload @mypost { dest_dir /var/uploads max_filesize 4MB } }</code></pre> Build with xcaddy</a>: xcaddy build --with github.com/git001/caddyv2-upload</code></pre> Today caddyv2-upload</a> (v0.20.0) supports file uploads via HTTP multipart form, configurable destination directories, UUID-based subdirectory creation per upload, fixed filenames, pass-through mode to continue to the next Caddy handler after upload, configurable file size limits, an HTTP notification callback after successful uploads, and a /health</code> endpoint. It integrates with Caddy’s variable system and works in Kubernetes and OpenShift environments. Authentication is handled by Caddy’s own security layer rather than the module itself.

Alek's Blog - go

ClickHouse Use Case: Vector, Istio, nginx, Java on OVH MKS

cert-manager-webhook-libdns: One Webhook, Many DNS Providers

Why this project exists🔗</a></h2> In many Kubernetes setups, certificate automation becomes harder than it should be because DNS integrations are fragmented:</p> Every provider has different APIs, credentials, and operational quirks.</li> Switching providers often means switching tooling.</li>

What it does🔗</a></h2> At a high level, the webhook:</p> Receives DNS-01 challenge requests from cert-manager.</li> Loads provider credentials from Kubernetes Secrets.</li> Resolves and writes challenge TXT records through the selected libdns provider.</li>

Who should use this🔗</a></h2> This project is a strong fit if you:</p> Run cert-manager and use DNS-01 challenges.</li> Need flexibility across multiple DNS providers.</li> Want one consistent webhook integration instead of many provider-specific implementations.</li>

Building a native file upload handler for Caddy v2