Linux Handbook

Even after all these years, some people still have a strong dislike for systemd. My colleague, Umair, stopped hating systemd after realizing its automation capabilities. He has created two courses on systemd: Systemd playbook: A hands-on, text-based course to turn you into a confident systemd user. Systemd automation: Learn to schedule, monitor, sandbox, and optimize automated workflows. The best way to learn anything on Linux is by getting your hands on the system.

Watching DevOps tutorials is easy. Actually knowing what to do when a server is broken at in production is not. The gap between the two is hands-on practice and if you have been searching for structured, interactive DevOps labs, you have probably run into the same problem: most good platforms cost money, and the free ones are scattered across a dozen different sites with no clear path connecting them.

This lesson is for paying subscribers only This post is for paying subscribers only Already have an account?

Don't we learn something new everyday? Something that might be obvious to others but feels like discovery to you? I had that feeling when I learned about the concept of compose override in Docker. In my self-hosted Ghost CMS deployment, I made modifications in the compose file to introduce log rotation. But now the compose file was modified and any upstream change would complain about modified file. Git stash comes to rescue, but it's an additional pain.

I was skeptical about AI tools in a DevOps workflow for a long time. Every demo I saw showed someone asking AI Agent to write a Hello World Dockerfile. That's not a DevOps use case, that's a simple chat. What changed my mind was using Claude for things that actually slow me down at work.

This lesson is for paying subscribers only This post is for paying subscribers only Already have an account?

This lesson is for paying subscribers only This post is for paying subscribers only Already have an account?

This lesson is for paying subscribers only This post is for paying subscribers only Already have an account?

Have you ever deployed an app to Kubernetes and later realized you don't really know what changed, who changed it, or how to roll it back safely? Maybe dev looked fine, staging looked stable, and production still broke at midnight, right when nobody wanted to touch it. This is exactly the problem GitOps exists to solve. GitOps isn't just another DevOps trend. It's a deployment model where Git becomes the single source of truth for your infrastructure and applications.

If editing your docker-compose.yml directly is breaking git pull from upstream, here's the fix: move your customizations into a separate compose.override.yml file instead of editing the original. The fix: use a compose override file Create a compose.override.yml in the same folder as your compose.yml, and use the exact service names from your original file (ghost and caddy, in my case).