Containers

“So what’s the difference between a container and a virtual machine?” I get this question a lot, usually from someone smart who has been nodding along in meetings without quite wanting to admit they’re fuzzy on it. And the honest answer is that most explanations make things worse. They reach for “hypervisor,” “kernel sharing,” and “hardware abstraction” in the first sentence, and now the person has four new terms to be confused about instead of one. ...

Pull a base image, copy in your code, push it to production. That’s the loop most of us run on autopilot. The part nobody looks at is the base image itself, which quietly drags in a few hundred packages you never chose. Any one of them could carry a known CVE, and you’d have no idea. That bothers me. I don’t like running things I can’t inspect, and a container image you haven’t scanned is exactly that: a black box you’re trusting because looking inside felt like too much effort. ...

For a long time my CI lived on someone else’s servers. Push code, wait for a hosted runner, watch the minutes tick down against a monthly quota, hope the provider doesn’t change the rules next quarter. It worked, right up until I started asking where my source code actually sat while it was being built, and who else could see it. So I moved GitLab in-house. I run it self-hosted now, on my own hardware, next to the clusters it deploys to. That’s sovereignty applied to CI/CD: my code, my builds, my artifacts, no vendor that can change pricing, deprecate a feature I depend on, or read my repositories without me knowing. ...