|
|
Subscribe / Log in / New account

The future of Docker containers

This article brought to you by LWN subscribers

Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

May 15, 2019

This article was contributed by Sean Kerner

Michael Crosby is one of the most influential developers working on Docker containers today, helping to lead development of containerd as well as serving as the Open Container Initiative (OCI) Technical Oversight Chair. At DockerCon 19, Crosby led a standing-room-only session, outlining the past, present and — more importantly — the future of Docker as a container technology. The early history of Docker is closely tied with Linux and, as it turns out, so too is Docker's future.

Crosby reminded attendees that Docker started out using LXC as its base back in 2013, but it has moved beyond that over the past six years, first with the docker-led libcontainer effort and more recently with multi-stakeholder OCI effort at the Linux Foundation, which has developed an open specification for a container runtime. The specification includes the runc container runtime which is at the core of the open source containerd project that Crosby helps to lead. Containerd is a hosted project at the Cloud Native Computing Foundation (CNCF) and is one of only a handful of projects that, like Kubernetes, have "graduated", putting it in the top tier of the CNCF hierarchy in terms of project stability and maturity.

Docker 19.03

Docker has both a slow moving enterprise edition and a more rapidly released community edition. At DockerCon 19, Docker Enterprise 3.0 was announced based on the Docker Community Edition (CE) 18.09 milestone. Docker developers are currently working on finalizing the next major release of Docker CE with version 19.03.

The time-based nomenclature for Docker CE release would imply that 19.03 should have been a March release, but that's not the case. Docker has been somewhat delayed with its numbered release cycle, with recent release dates not matching up with actual general availability. For example, the current Docker CE 18.09 milestone became generally available in November 2018, not September [Michael Crosby] 2018 as 18.09 would seem to imply. The current Docker CE number is, however, more closely aligned with the feature-freeze date for releases. The GitHub repository for Docker CE notes that the feature freeze for the 19.03 release did not occur until March 22. The beta 4 release is currently scheduled for May 13, with the final general availability release date listed as "to be determined" sometime in May 2019.

Crosby said that among the big new features that are set to land in Docker CE 19.03 is full support for NVIDIA GPUs, marking the first time that Docker has had integrated GPU support in a seamless manner. Crosby added that NVIDIA GPU support will enable container workloads to take full advantage of the additional processing power offered by those GPUs, which is often needed for artificial intelligence and machine learning use cases.

Containerd is also getting a boost, advancing to version 1.2 inside Docker CE. Containerd 1.2 benefits from multiple bug fixes and performance gains. Among the new capabilities that have landed in this release is an updated runtime that integrates a gRPC interface that is intended to make it easier to manage containers. Overall, Crosby commented that many of the common foundational elements of Docker have remained the same over time.

"Even though we've had kind of the same primitives from back in 2013 in Docker, they've been optimized and matured," Crosby said.

The future of Docker

Docker containers were originally all about making the best use possible of Linux features. Just as Docker containers started out based on a collection of Linux kernel features, the future of Docker is about making the best use of newer kernel features. "Containers are made up of various kernel features, things like cgroups, namespaces, LSMs, and seccomp," he said. "We have to tie all those things together to create what we know of now as a container.

Looking forward to what's next for containers and Docker, Crosby said that it's all about dealing with the different requirements that have emerged in recent years. Among those requirements is the need to take advantage of modern kernel features in Linux 5.0 and beyond, as well as dealing with different types of new workloads, including stateful workloads, which require a degree of persistence that is not present in stateless workloads. Edge workloads for deployments at the edge of the network, rather than just within a core cloud, are another emerging use case. Internet of Things (IoT) and embedded workloads in small footprint devices and industrial settings are also an important use case for Docker in 2019.

One of the Linux kernel features that Docker will take full advantage of in the future is eBPF, which will someday be usable to write seccomp filters. Crosby explained that seccomp and BPF allow for flexible system call interception within the kernel, which opens the door for new control and security opportunities for containers.

Control groups (cgroups) v2 is another Linux feature that Docker will soon benefit from. Cgroups v2 has been in the kernel since the Linux 4.5 release, though it wasn't immediately adopted as a supported technology by Docker. The project isn't alone in not immediately supporting cgroups v2, Red Hat's Fedora community Linux distribution also has not integrated cgroups v2, though it plans to for the Fedora 31 release that is currently scheduled for November. Crosby said that cgroups v2 will give Docker better resource isolation and management capabilities.

Enhanced user namespace support is also on the roadmap for Docker as part of a broader effort for rootless containers; it will help to improve security by not over-provisioning permissions by default to running containers. The idea of running rootless Docker containers with user namespaces is not a new one, but it's one that is soon to be a technical reality. "Finally, after all these years, user namespaces are in a place where we can really build on top of them and enable unprivileged containers," he said.

More kernel security support is also headed to Docker in the future. Crosby said that SELinux and AppArmor are no longer the only Linux Security Modules (LSMs) that developers want. Among the new and emerging LSMs that Docker developers are working to support in the future is Landlock. Crosby added that developers will also have the ability to write their own custom LSMs with eBPF. Additionally, he highlighted the emergence of seccomp BPF.

Making containers more stateful

One of the areas that Crosby is most interested in improving is the stateful capabilities of Docker, which in his view are currently relatively limited. Better stateful capabilities include backup, restore, clone, and migrate capabilities for individual containers. Crosby explained that stateful management today in Docker typically relies on storage volumes and not the actual containers themselves.

"We kind of understand images now as being portable, but I also want to treat containers as an object that can be moved from one machine to another," Crosby said. "We want to make it such that the RW [read/write] layer can be moved along with the container, without having to rely on storage volumes." Crosby added that he also wants to make sure that not only the container's filesystem data is linked, but also the container configuration, including user-level data and networking information.

Rethinking container image delivery

Container images today are mostly delivered via container registries, like Docker Hub for public access, or an internal registry deployment within an organization. Crosby explained that Docker images are identified with a name, which is basically a pointer to content in a given container registry. Every container image comes down to a digest, which is a content address hash for the JSON files and layers contained in the image. Rather than relying on a centralized registry to distribute images, what Crosby and Docker are now thinking about is an approach whereby container images can also be accessed and shared via some form of peer-to-peer (P2P) transfer approach across nodes.

Crosby explained that a registry would still be needed to handle the naming of images, but the content address blobs could be transferred from one machine to another without the need to directly interact with the registry. In the P2P model for image delivery, a registry could send a container image to one node, and then users could share and distribute images using something like BitTorrent sync. Crosby said that, while container development has matured a whole lot since 2013, there is still work to be done. "From where we've been over the past few years to where we are now, I think we'll see a lot of the same type of things and we'll still focus on stability and performance," he said.

A video of this talk is available.

Index entries for this article
GuestArticlesKerner, Sean
ConferenceDockerCon/2019


(Log in to post comments)

The future of Docker containers

Posted May 15, 2019 18:28 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

How about fixing the IPv6 support?!?

It's been a total disaster. There are community-made patches ready for merge and Docker developers have just given up on them.

In particular:
1) NAT support needs to be added to IPv6 to mirror the IPv4 functionality. This is needed for Docker on AWS instances that only get a /128 address.
2) CNI needs to support IPv6.
3) Port exposure needs to be consistent between IPv6 and IPv4. Right now enabling IPv6 exposes all the container ports unconditionally.

The future of Docker containers

Posted May 16, 2019 2:23 UTC (Thu) by foom (subscriber, #14868) [Link]

> NAT support needs to be added to IPv6

Blargh...I really hope not. That's so backwards...

It seems like a bug in aws if you cannot easily assign multiple ipv6 addresses to a host.

The future of Docker containers

Posted May 17, 2019 20:29 UTC (Fri) by flussence (subscriber, #85566) [Link]

>It seems like a bug in aws if you cannot easily assign multiple ipv6 addresses to a host.

It's price scalping, is what it is. OVH does the same thing with its cheaper dedi offerings, even though they already have the infra to allocate you a /56 on the rest.

The future of Docker containers

Posted May 17, 2019 20:47 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

?? You are not charged on a per-IP basis at Amazon. It's more like an architectural limitation, Amazon readily assigns a /56 prefix to your VPCs.

The future of Docker containers

Posted May 21, 2019 2:18 UTC (Tue) by foom (subscriber, #14868) [Link]

Looks like it's *possible* with aws, if not easy:
https://medium.freecodecamp.org/how-to-run-ipv6-enabled-d...

The future of Docker containers

Posted May 21, 2019 2:28 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

It basically manually assembles a network out of multiple individual IPv6 addresses. This is doable, but not at all nice. I'm not sure a simple IPv6 NAT is worse than that.

The better way is to just use a CNI plugin to dynamically create ENI (Amazon's virtual network interfaces) and assign them to containers directly.

You also still need a stateful firewall because you do NOT want to expose all containers' ports automatically.

The future of Docker containers

Posted May 16, 2019 10:38 UTC (Thu) by jeremy (guest, #95247) [Link]

4) Turning IPv4 off should be possible. Currently (to my knowledge; happy to be corrected) containers can either be IPv4–only or dual–stack. Removing the IPv4 subnet options just causes Docker to auto–allocate an IPv4 subnet, even if that is undesired.

The future of Docker containers

Posted May 17, 2019 13:50 UTC (Fri) by zlynx (guest, #2285) [Link]

NAT and overlay networks and all of that other "cloud" garbage needs to die and not infect IPv6. They only exist to handle the limitations of IPv4.

Docker and Kubernetes and the like need to go back to basics and rewrite their networking from scratch for IPv6. Disable IPv4 entirely and only use it for gateways to the world.

If AWS can't get IPv6 right then get Amazon to fix it.

The future of Docker containers

Posted May 17, 2019 15:33 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Overlay networks are not going away, you still need them for services to speak with each other securely and without worrying about DDOS from the open Internet.

NATs or statefull firewalls that amount to the same are needed to protect inbound connections.

So nope, IPv6 support for Docker should basically mirror the IPv4. An ability to use delegated prefixes is awesome, but not always needed.

The future of Docker containers

Posted May 17, 2019 21:02 UTC (Fri) by farnz (subscriber, #17727) [Link]

Out of curiosity (I don't work in this area, and my employer's networks team makes IPv6 Just Work for my needs), what do you think of ILA as a mechanism to run an IPv6 overlay network between containers? It looks to me like something that Docker/Kubernetes et al should be able to implement, and it replaces the need for NAT with a need for a /64 for the ILA overlay, plus a /64 for each container host.

The future of Docker containers

Posted May 18, 2019 2:18 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

ILA is honestly not that different from the current crop of overlay networks.

The major advantage of ILA over some over methods is that it doesn't use encapsulation and instead rewrites source/destination addresses directly. This avoids issues with PMTU which STILL is not working correctly everywhere (even in a datacenter).

And the disadvantage is that the lower portion of the address basically becomes a client ID, so datacenter tenants won't be able to use the private IPv6 address space or ULAs.

Other than that, it's just yet another way to organize a datacenter-level SDN.

The future of Docker containers

Posted May 16, 2019 6:04 UTC (Thu) by hyuwang (guest, #130110) [Link]

That's a lot feature planned, I hope they could make better stability while moving ahead.

We have being suffer from docker bugs that affects production, some of them are very primitive and fundamental feature.

Like container stuck in removing state, or deadlock in containerd-shim cause data not read from container's stdio pipe cause process hang.

Many of these bugs didn't exists before docker swarm came in.

Overall, the design of docker daemon result in less availability in production, we start looking at daemonless container solution.

The future of Docker containers

Posted May 16, 2019 19:30 UTC (Thu) by jccleaver (subscriber, #127418) [Link]

> Overall, the design of docker daemon result in less availability in production, we start looking at daemonless container solution.

Another option: Just... running code on a server.

The future of Docker containers

Posted May 16, 2019 21:23 UTC (Thu) by kfox1111 (subscriber, #51633) [Link]

> Another option: Just... running code on a server.

That causes a whole set of other problems...

The future of Docker containers

Posted May 18, 2019 23:41 UTC (Sat) by drag (guest, #31333) [Link]

Containers are the only way forward without breaking a huge amount of old Unix assumptions that applications depend on without sacrificing the modern features that Linux can offer.

I've seen what happens when organizations struggle to run and manage dozens of applications side by side on a single system without containers or virtualization to try to efficiently take advantage of the capacities offered by modern hardware. It isn't pretty. A 'nightmare' would describe it better.

The future of Docker containers

Posted May 16, 2019 20:52 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

> Overall, the design of docker daemon result in less availability in production, we start looking at daemonless container solution.

No reason not to do that right now. Podman for devs and cri-o for production (if you are using a Kubernetes based implementation) seems a good choice at this point.

The future of Docker containers

Posted May 16, 2019 21:22 UTC (Thu) by kfox1111 (subscriber, #51633) [Link]

Thats one of the pushes for containerd separate from docker. You can run Kubernetes backended with containerd and skip the rest of the swarm stuff.

The future of Docker containers

Posted May 31, 2019 15:41 UTC (Fri) by mijo (guest, #111447) [Link]

Absolutely, we need a new way of container image delivery. All the current registries I am familiar with are not future proven. So far I haven't seen any peer-to-peer implementation, or did I miss one? If not, I am pretty sure that this will change latest by 2020, depending on the time I can spend writing code ... :)
I've shared the need for a P2P Docker registry with Patrick Devine from Docker Inc. back in 2016. As far as I remember he told me that they did also at least think about it, not sure if they also had already any code in place.


Copyright © 2019, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds