No, you don’t need Docker to run containers

When we talk about software, a container is a standard unit that contains an application and all its dependencies. Everything the application needs to run is right there, so it can be moved consistently and reliably between different computing environments. And unless we explicitly let the container be aware of its surroundings, it will be entirely isolated in its own universe.

Virtual machine vs containers

Virtual machines vs containers

Virtual machines and containers complement each other, but they solve different use cases. Virtual machines are large entities, typically measured in gigabytes, that virtualize hardware so that multiple operating systems can be run on the same computer. Containers, on the other hand, are very lightweight, measured in megabytes. A container runtime virtualizes an operating system, making each container think that it has its own operating system. But to the host operating system it’s nothing but another process.

In 2015, the Open Container Initiative® (OCI) was founded by the leaders of the container industry. OCI specifies the container file system structure and how it should then be run as a container.

In 2020, Axis launched the Q1615 MkIII, our first product with container support in the default firmware. Any Axis device with an ARM-based SoC can run containers, and more than 70 of those devices have container support enabled in the default firmware.

All the bits and pieces needed to run containers are found in the Linux® kernel. Since it’s quite tedious to interface with the kernel directly, we have helper programs in user space to facilitate that. Each container runtime depends on the one below it: OCI’s reference implementation for container runtimes, runc, is the most lightweight. Then we have containerd that sits on top of that and it’s more advanced and slightly heavier. Finally, we have Docker®, Kubernetes® and similar on top of containerd.

Illustration of containers

How container runtimes work on Axis devices

Axis devices with container support come with containerd as the container runtime, which makes perfect sense since containerd is the de facto standard container runtime today. If you need to run Docker on your device, depending on your usecase, you can do so by adding an AXIS Camera Application Platform (ACAP) application with Docker. Some ACAP users run containers on our devices directly towards runc on our devices and they say that’s what fits their use case the best.

Explanation of docker

Containers are not dockers

Regardless of the container runtime you choose, you will have container images that become containers at runtime, so please don’t refer to your containers as “dockers”: When you say “dockers” you will talk about either Brits working in the harbor or an American clothing manufacturer. (Personally, I like to wear Dockers®, but they have nothing to do with my OCI containers.)

Recap

We have container images that become containers at runtime. To the host operating system, they’re just another process.
The Open Container Initiative (OCI) provides the container image specification and the container runtime specification.
Everything needed to run a container is in the kernel, but most likely you will choose to use a container runtime to facilitate it for you.

Sometimes you need a heavy toolbox (and yes, I mean Docker and when you need it, a heavy toolbox is nice), but sometimes you need nothing but a small lightweight tool. So don’t get me wrong here, I really like Docker. I use it a lot and almost every day. But no, you don’t need Docker to run containers!

note

Docker and the Docker logo are trademarks or registered trademarks of Docker, Inc. in the United States and/or other countries. Docker, Inc. and other parties may also have trademark rights in other terms used herein.

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

Author: Joakim Roubert

I'm a senior engineer specializing in connecting our user-friendly Linux devices with various systems, which often only requires very thin layers of additional software. Containers and clusters are also part of my expertise and my toolkit for different tasks.