Docker has become synonymous with containers. However, Docker is just one tool that you can use to build images and run them as containers. There are a few alternatives that are gaining popularity. Let's explore what they are and why some in the industry are looking to run their applications as containers without the use of Docker.
The OCI Specification
As the popularity of containers started to grow, a variety of other tools started to emerge to provide capabilities beyond what was provided by Docker. A community was formed that started the Open Container Initiative (OCI) that defines a specification for building images and running them as containers. This standard ensures that images built by any build tool that complies with OCI should be able to run in any runtime that complies to OCI. In fact, the build specification is actually Docker's original image format that they open-sourced (along with the tools to build images and run containers).
Alternatives Ways to Build Images without Docker
Since the OCI is just a specification on how to build an image there are a few open-source projects that provide this capability:
- BuildKit (https://github.com/moby/buildkit)
- Buildah (https://github.com/containers/buildah)
- Podman (https://github.com/containers/podman)
These open-source projects can process instructions from a Dockerfile and build a OCI compliant image. They offer some additional features not provided by Docker that deal with performance improvements to build times, optimizing memory and caching and many more. They also do not require a daemon process to be continually running to work, unlike Docker.
Alternative Ways to Run Containers without Docker
Similar to leveraging the OCI specification to have a common build format there is other software that utilizes the common specification to provide a runtime for running images as containers. Some common open source projects that implement the OCI Runtime Specification are:
- Kata Containers (https://katacontainers.io/)
- Firecracker (https://firecracker-microvm.github.io/)
In fact, Firecracker was developed by Amazon and it is what powers their AWS Lambda and AWS Fargate services.
The CRI Specification
As the popularity of Kubernetes started to grow there was a desire to de-couple it from the Docker Runtime Engine. The Container Runtime Interface (CRI) was created to also provide a standardized specification for container runtime software. This allows for orchestration software to have the ability change what container runtime it uses without the need to recompile or be re-installed. Something called a "shim" can be created that provides an abstraction between the orchestration software and the container runtime.
Conclusion
There are many other examples out there of image build or container runtime software that are not Docker. There are also many articles that debate the pros and cons of switching either to, or away from Docker. Not all use cases are the same so not every tool will be the right solution. Feel free to take a look at the alternatives and judge for yourself, keeping in mind that containers does not also mean Docker.
Top comments (2)
Good post!
I just wanted to share my favorite way of building OCI images: Cloud Native Buildpacks
Think
heroku push, but instead of having your code built for you and running on Heroku it is built and you get an OCI image you can run anywhere you can run Docker images. Especially Kubernetes!Thanks for the post Ed!
I'm of the belief that Docker containers on their own don't provide much more benefit over VMs. In fact, with greater permissions on the docker daemon, I'd say it's worse than running a VM from a security standpoint.
To me, containers only start to shine with orchestrators like kubernetes or nomad which can do autoscaling, load balance, etc.
Hope people learned from your post!