LWN: Comments on "The future of Docker containers"

The future of Docker containers

mijo — Fri, 31 May 2019 15:41:32 +0000

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.

The future of Docker containers

Cyberax — Tue, 21 May 2019 02:28:57 +0000

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

foom — Tue, 21 May 2019 02:18:07 +0000

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

drag — Sat, 18 May 2019 23:41:48 +0000

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

Cyberax — Sat, 18 May 2019 02:18:08 +0000

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

farnz — Fri, 17 May 2019 21:02:36 +0000

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

Cyberax — Fri, 17 May 2019 20:47:32 +0000

?? 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

flussence — Fri, 17 May 2019 20:29:14 +0000

>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

Cyberax — Fri, 17 May 2019 15:33:24 +0000

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

zlynx — Fri, 17 May 2019 13:50:45 +0000

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

kfox1111 — Thu, 16 May 2019 21:23:25 +0000

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

That causes a whole set of other problems...

The future of Docker containers

kfox1111 — Thu, 16 May 2019 21:22:26 +0000

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

rahulsundaram — Thu, 16 May 2019 20:52:41 +0000

> 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

jccleaver — Thu, 16 May 2019 19:30:11 +0000

> 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

jeremy — Thu, 16 May 2019 10:38:07 +0000

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

hyuwang — Thu, 16 May 2019 06:04:55 +0000

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

foom — Thu, 16 May 2019 02:23:21 +0000

> 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

Cyberax — Wed, 15 May 2019 18:28:28 +0000

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.