Containers

“So what’s the difference between a container and a virtual machine?” I get this question a lot. And the answer usually involves terms like “hypervisor,” “kernel sharing,” and “hardware abstraction” — which just creates more questions. But there’s actually a deeper question lurking here: what’s the difference between simulation, emulation, virtualization, and containerization? These four concepts are often confused, but they’re fundamentally different approaches to solving the same problem: running something in an environment it wasn’t originally designed for. ...

You can’t secure what you don’t understand. And with container images, understanding means knowing exactly what’s inside — every package, every library, every potential vulnerability. Most teams treat their container images as black boxes. They pull a base image, add their code, and push it to production. But that base image? It contains hundreds of packages you didn’t explicitly choose. Any of them could have known vulnerabilities. Trivy makes the invisible visible. It’s an open-source vulnerability scanner that tells you exactly what’s in your images and what risks they carry. ...

I run GitLab self-hosted. Not because it’s trendy, but because I want to own my CI/CD pipeline. No vendor can change pricing, deprecate features, or access my code without my knowledge. This is sovereignty applied to CI/CD. And GitLab makes it practical. Let me show you how to build a complete pipeline: from code commit to running in Kubernetes. Why Self-Hosted GitLab? Before we dive into pipelines, the “why” matters: Data sovereignty: Your code, your builds, your artifacts stay on your infrastructure No usage limits: Unlimited CI minutes, unlimited storage, unlimited users Network locality: Builds run close to your clusters, faster artifact transfers Customization: Configure runners exactly how you need them Air-gap capable: Works in offline environments The trade-off is operational overhead. You maintain GitLab. For me, that’s worth it. ...