If you’ve stumbled across my previous post

ā€œOperating Community Nextcloud Instances with Ansible, AlmaLinux, SELinux and a Podman-based Collabora Stackā€
,
you already know this started as a totally reasonable idea.(Narrator voice: It was not a totally reasonable idea.)

The Original Planā„¢: Leave Debian, Embrace SELinux

At some point I thought: ā€œHey, why not move from Debian to AlmaLinux?ā€

Main reason? SELinux.
Because nothing says ā€œfun weekend projectā€ like debugging security contexts at 2 AM.

During that phase I figured out how to integrate Collabora via containers — and it felt
way more stable and predictable.

Phase 2: ā€œLet’s Just Add Kubernetesā€ šŸ¤¦ā€ā™‚ļø

Naturally, this escalated.

ā€œI should probably install Kubernetes.ā€

Enter K3s — lightweight, simple, and just dangerous enough to deploy on a VPS.

The current idea:

  • Run core services (MariaDB, Redis) natively
  • Run applications inside K3s
  • Convince myself this is ā€œarchitectureā€ and not curiosity

Ansible: From Tool to Obsession

What used to be ā€œjust a playbookā€ is now basically a small framework.

Two main playbooks:

  • Nextcloud
  • WordPress

Shared components everywhere:

  • Repos
  • fail2ban
  • MariaDB
  • K3s
  • Firewall rules

Current status: ~16 roles.
Emotional status: also 16 roles.

AI Pair Programming is Real šŸ¤–

Using Claude AI inside VS Code feels like:

ā€œSenior DevSecOps engineer joins your session.ā€

  • Requests command outputs
  • Debugs errors
  • Refactors playbooks
  • Actually explains problems

Slightly terrifying. Extremely useful.

Now With Monitoring šŸ“Š

  • Prometheus
  • Grafana

I can now watch my system fail in real time — but beautifully.


šŸ”§ Deep Dive: From ā€œSimple Blogā€ to Full Infrastructure

Running a WordPress blog on a VPS sounds trivial — until you start thinking about:

  • TLS certificates
  • Firewalls
  • Updates
  • Security monitoring

So naturally, I automated everything.

Infrastructure as Code (a.k.a. YAML everywhere)

The entire setup is defined in Ansible:

ansible-playbook blog.yml --limit meinserver

Reproducible. Idempotent. Slightly addictive.

Architecture: K3s vs Host

Inside K3s:

  • WordPress (PHP-FPM)
  • Nginx (Sidecar)
  • MariaDB
  • ingress-nginx
  • cert-manager (Let’s Encrypt)
  • WordPress CronJob

On the Host:

  • Prometheus
  • Grafana
  • Node Exporter
  • fail2ban
  • rkhunter
  • auditd
  • msmtp

The Playbook Flow

  1. Base System
  2. SELinux
  3. K3s
  4. Deployment
  5. Monitoring

Security: Defense in Depth

  • iptables firewall
  • fail2ban
  • Rate limiting
  • HTTPS via Let’s Encrypt
  • SELinux enforcing
  • auditd
  • Auto security updates
  • rkhunter scans

Final Thoughts: Work in Progress šŸ”§

What started as:

ā€œLet’s try AlmaLinuxā€

Became:

  • Kubernetes
  • Containers
  • Ansible framework
  • Monitoring stack
  • AI-assisted ops

At this point, I’m basically running a tiny cloud on a VPS.

But: I’m still in the middle of refining, testing and breaking things again.

The Ansible code is not published yet — mainly because I’m still tweaking roles, cleaning things up,
and making sure it doesn’t completely explode on a fresh system.

(a.k.a. ā€œone more quick changeā€ — famous last words)

I plan to publish the full playbook on GitHub in the next few days — once I’m confident that it’s
somewhat reusable and not just tailored chaos.

The bigger picture behind all of this: I’m considering migrating the existing Nextcloud instances
for two local clubs into this architecture.

But right now, that’s still a bit too risky — moving production data plus introducing K3s at the same time
feels like a great way to ruin a weekend (or several).

The technology is still relatively new territory for me, and I’d like to gain more real-world experience
before trusting it with actual user data.

Maybe that’s a project for autumn šŸ‚

Stay tuned šŸ˜„

By raphael

Leave a Reply