Nowadays, Alpine Linux is one of the most popular options for container base images. Many people (maybe including you) use it for anything and everything. Some people use it because of its small size, some because of habit and some, just because they copy-pasted a Dockerfile from some tutorial. Yet, there are plenty of reasons why you should not use Alpine for your container images, some of which can cause you great amount of grief…

Podman Desktop installs, configures and keeps Podman up to date on your local environment. It provides a system tray, to check status and interact with your container engine without losing focus from other tasks. The desktop application provides a dashboard to interact with containers, images, pods and volumes but also configures your environment with your OCI registries and network settings. Podman Desktop also provides capabilities to connect and deploy pods to Kubernetes environments.

Adam Gordon Bell:

There are many ways to understand how containers work, but most useful explanations are actually simplifications….

But for me, containers are just chrooted processes. Sure, they are more than that: Containers have a nice developer experience, an open-source foundation, and a whole ecosystem of cloud-native companies pushing them forward. But, let me show you why I think chroot is the key.

I like this framing. It makes a lot of sense to me. More than ‘lightweight VM’, which is how I’ve thought about them previously. The rest of this article is Adam stepping through the process of building a container runtime using only the chroot system call.

In today’s episode, we talk about distroless, ko, apko, melange, musl and glibc. The context is Wolfi OS, a community Linux OS designed for the container and cloud-native era. If you are looking for the lightest possible container base image with 0 CVEs and both glibc and musl support, Wolfi OS & the related chainguard-images are worth checking out.

Ariadne Conill is an Alpine Linux TSC member & Software Engineer at Chainguard.

Ryan Dahl describes the JavaScript sandbox as a higher level container for server software:

This container isn’t meant to address the same breadth of problems that Linux containers target. Its emergence is a result of its simplicity. It minimizes the boilerplate for web service business logic. It shares concepts with the browser and reduces the concepts that the programmer needs to know.

People like Ryan and his colleagues at Deno are exploring this future, but it’s not quite here yet.

This page is built by the Nomad folks, so keep that in mind when reading through the comparison;

Kubernetes is an orchestration system for containers originally designed by Google, now governed by the Cloud Native Computing Foundation (CNCF) and developed by Google, Red Hat, and many others. Kubernetes and Nomad support similar core use cases for application deployment and management, but they differ in a few key ways. Kubernetes aims to provide all the features needed to run Linux container-based applications including cluster management, scheduling, service discovery, monitoring, secrets management and more. Nomad only aims to focus on cluster management and scheduling and is designed with the Unix philosophy of having a small scope while composing with tools like Consul for service discovery/service mesh and Vault for secret management.

I’m just excited to see strong competition in this space, and had never heard of Nomad prior to today. If you’ve used it and have experience/opinions, I’d love to hear ’em!

Earthly is language agnostic, “steals” good ideas from Makefiles and Dockerfiles and combines them into one spec, and makes your builds self-contained, repeatable, portable and parallel.

Here’s a ~5 minute video demoing how to buil a simple Go app with Earthly

Thomas Ptacek writing on Fly’s blog:

Even though most of our users deliver software to us as Docker containers, we don’t use Docker to run them. Docker is great, but we’re high-density multitenant, and despite strides, Docker’s isolation isn’t strong enough for that. So, instead, we transmogrify container images into Firecracker micro-VMs.

This is a fun, technical read about how they’re converting Docker’s OCI images (turns out they’re just a stack of tarballs) into Firecracker VMs. It’s much simpler to accomplish than I would’ve thought! Money quote:

You’re likely of one of two mindsets about this: (1) that it’s extremely Unixy and thus excellent, or (2) that it’s extremely Unixy and thus horrifying.

About 18 months ago I started a project which had to develop directly against containerd with a full Linux system.

This presented a problem which I’d not really encountered before - Docker and Kubernetes on my Mac were no longer enough, I needed a full Linux environment, and so did the community.

This is how it went and what we learned along the way.

Securing containers is a complex task. The problem space is broad, vendors are on fire, there are tons of checklists and best practices and it’s hard to prioritize solutions. So if you had to implement a container security strategy from where would you start?

Fedora CoreOS is a container-focused (mostly) immutable Linux distribution designed to be lightweight and secure. It features Ignition as an early-boot-provisioning systems that alleviates all post-boot configuration, OSTree as an atomic-update mechanism, and podman as a secure and daemon-less container runtime.

If you’ve ever asked yourself WHY you need to SSH in to configure a system, why your cloud server OS comes with inkjet printer packages, or how you can get out of the burden of critical but uninspired kernel updates… then check out Fedora CoreOS!

If you’ve been following along in the open source news cycle lately, you’ve probably heard that Red Hat has dropped the docker container runtime engine from both its Red Hat Enterprise Linux (RHEL) and CentOS Linux distributions.

I must not be following along, because that’s news to me.

That being the case, what do you do when you need to deploy containers? Fortunately, they’ve created a near drop-in replacement for docker, called Podman.

Podman is a rename from kpod, sorta. The new thing is actually called libpod, and Podman exists as the CLI for that library. It’s all a bit confusing, but what’s cool is none of this requires a daemon like the Docker Engine.

If you’d like to give it a go, this walk-through by The New Stack will get you started.

Containerization technologies are one of the trendiest topics in the cloud economy and the IT ecosystem. The container ecosystem can be confusing at times, this post may help you understand some confusing concepts about Docker and containers. We are also going to see how the containerization ecosystem evolved and the state of containerization in 2019.

Put on your swimming suit, because this is a deep dive. 🏊‍♀️🏊

Andre Marcelo-Tanner:

The most widely used container runtime on High Performance Computing now runs on Mac, allowing any developer to package their entire application into a single container. This has broader implications and possibilities of what exactly is possible by putting everything into a single file with no daemon required on OSX but I would let an expert like Greg Kurtzer talk about that :)

This was a brief topic of conversation when we had Greg on The Changelog a few weeks back.

We’re talking with Greg Kurtzer, the founder of CentOS, Warewulf, and most recently Singularity — an open source container platform designed to be simple, fast, and secure. Singularity is optimized for enterprise and high-performance computing workloads. What’s interesting is how Singularity allows untrusted users to run untrusted containers in a trusted way. We cover the backstory, Singularity Pro and how they’re not holding the open source community version hostage, as well as how Singularity is being used to containerize and support workflows in artificial intelligence, machine learning, deep learning, and more.

One of the most exciting announcements from last week’s AWS re:Invent was Firecracker — an open source project that delivers the speed of containers with the security of VMs.

Firecracker’s focus is transient and short-lived processes, so it differs from containers in that it’s optimized for startup speed.

Why can’t we use containers? The answer is simple — slower cold start. While LXC and Docker are certainly faster and lighter than full-blown virtual machines, they still don’t match the speed expected by functions.

There are also some security wins with how Firecracker is architected:

Firecracker takes a radically different approach to isolation. It takes advantage of the acceleration from KVM, which is built into every Linux Kernel with version 4.14 or above. KVM, the Kernel Virtual Machine, is a type-1 hypervisor that works in tandem with the hardware virtualization capabilities exposed by Intel and AMD.

There’s a lot to be intrigued by here. We should probably line up an episode on Firecracker. In the meantime, click through to go deeper on the topic.

Disclaimer: no servers were harmed in the taping of this show. We hosted a special discussion with Jeremy Daly, Kevin Ball, Nick Nisi, and Christopher Hiller on the ideas around serverless, managed services, Functions as a Service (FaaS), micro-services, nano-services, all-the-services!

CodeSandbox Containers was just announced by Ives van Hoorne on Hacker Noon.

Today we’re happy to announce CodeSandbox Containers. We execute your code on a server, which allows you to work on any JavaScript project that works locally.

But you gotta use it so they can test things and get it right.

We can only test CodeSandbox Containers fully when we have other people using it. … Please don’t use it for any project with files you don’t want publicly exposed. There’s also the chance that the service might be down because of things that we haven’t foreseen yet, in which case you’ll see a nice warning message.

We will dedicate the coming months to squash every bug we can find, when we think that CodeSandbox Containers is stable enough to remove the beta warning we will announce this.

This is the battle cry that started the Open Container Initiative. But in reality, are/was multi-cloud and vendor lock-in true concerns for software teams? Tyler Treat writes on his personal blog:

We want to be cloud-agnostic. We need to avoid vendor lock-in. We want to be able to shift workloads seamlessly between cloud providers. Let me say it again: multi-cloud is a trap. Outside of appeasing a few major retailers who might not be too keen on stuff running in Amazon data centers, I can think of few reasons why multi-cloud should be a priority for organizations of any scale.

Jessie Frazelle:

There seems to be some confusion around sandboxing containers as of late, mostly because of the recent launch of gvisor… There is a large amount of ignorance towards the existing defaults to make containers secure. Which is crazy since I have written many blog posts on it and given many talks on the subject.

Jessie has been doing the yeoman’s work of Linux kernel isolation and making containers secure for awhile now, but much of that work has been overlooked or disregarded by others in the community. I’m on the outside looking in at this situation, so it’s tough to call exactly what’s going on, but according to Jessie:

When you work at a large organization you are surrounded by an echo chamber. So if everyone in the org is saying “containers are not secure,” you are bound to believe it and not research actual facts.

That doesn’t mean Jessie thinks containers are secure (click through to read her take on that). There’s a lot to dig in to here and think about. I’ll pull out one last point:

I am not trying to throw shade at gvisor but merely clear up some FUD in the world of open source marketing. I truly believe that people choosing projects to use should research into them and not just choose something shiny that came out of Big Corp.

Now that’s a sentiment I can get behind! Oh, and listen to this related episode of The Changelog if you haven’t yet. It’s a must-listen for all developers.

Why does this exist?

Containers are not a sandbox. While containers have revolutionized how we develop, package, and deploy applications, running untrusted or potentially malicious code without additional isolation is not a good idea. The efficiency and performance gains from using a single, shared kernel also mean that container escape is possible with a single vulnerability.

gVisor takes a distinct approach to container sandboxing and makes a different set of technical trade-offs compared to existing sandbox technologies, thus providing new tools and ideas for the container security landscape.

Is Netflix Titus open source yet? Yes.

Titus powers critical aspects of the Netflix business, from video streaming, recommendations and machine learning, big data, content encoding, studio technology, internal engineering tools, and other Netflix workloads

So, why is Netflix open sourcing Titus?

…we’ve been asked over and over again, “When will you open source Titus?” It was clear that we were discussing ideas, problems, and solutions that resonated with those at a variety of companies, both large and small. We hope that by sharing Titus we are able to help accelerate like-minded teams, and to bring the lessons we’ve learned forward in the container management community.

The question is, is it too late for Titus to gain traction in a world where Kubernetes has seemingly already won?

This is a big deal. We’ve been tracking CoreOS since the beginning — we’re huge fans of Alex, Brandon and the team behind CoreOS.

Red Hat has signed a definitive agreement to acquire CoreOS, Inc., an innovator and leader in Kubernetes and container-native solutions, for a purchase price of $250 million.

Red Hat is a publicly traded company and while this announcement hasn’t really impacted shareholder value (yet), we, the open source community have been immeasurably impacted by the team behind CoreOS.

Also, check out Alex Polvi’s announcement on the CoreOS blog which includes some details and backstory.