[alias_neo]

My experience agrees with this.

I'm a huge fan of Docker, I've actively taken part since the early days, attending meetups and using it actively day to day.

Unfortunately, when I brought several issues to GitHub, or +1'd other people's issues that were affecting the usability within our company, the attitude was very much "f* you and your problems" because Docker want things to be one way and that's how it'll be.

There were issues raised 4+ years ago and are still open, for solutions to problems that would have mooted a need for us to use something like K8s (which doesn't work anyway for our requirements).

I believe Docker locking the community out of valuable features had also done harm and (possibly) failed to be the monitiser they'd hoped for.

After so long, I no longer go to Docker to solve problems that could be solved in Docker (secrets anyone? without the "hacks"), and just look towards the other tools solving the problems.

I'll continue to use Docker, but I don't consider it a friend.

[pacala]

I wonder how much of that attitude was caused by an overstretched team with no effective scaling mechanism in place. No, "open source" does not automatically mean "scalable team". Part of Kubernetes success is its ability to scale up the community, empowering multiple entities to meaningfully contribute.

[faitswulff]

Scaling is an issue with any company, but judging by a friend's description of working there, there's almost certainly a large company culture / attitude factor as well.

[alias_neo]

I don't have an answer to the why, but I can say that in the 5+ years I've been using it daily, the issues I've faced have been reciprocated by others others, and GitHub reflects this.

Some of the issues are solved by the likes of K8s, but many of us don't want or need K8s for our use cases. Other issues are resolved by other told, and yet still others are only resolved with effort (you still can't expose/bind a port range, e.g. 10000 UDP ports in Docker without killing your server).

[0xDEFC0DE]

At the same time, I gather it's really, really hard to write software that satisfies a lot of use cases across a lot of businesses without having to be somewhat opinionated.

[pacala]

True! Another part of Kubernetes success is the fact that it's core architecture is sound, scalable for both workloads and features.

[clinta]

I maintain a couple of docker network plugins. One day Docker devs decided that they would bundle an internal DNS resolver inside the docker daemon and take over the resolv.conf in every container. But here's the most amazing part. It only did this for custom networks. If you just used docker out of the box you would never see this. But if you used custom networks, and custom network drivers, it did this. And the docker team refused to allow any configuration options to disable it.

I now maintain a daemon who's sole job is to undo Docker's meddling with resolv.conf until I can get the bandwidth to explore migrating to Kubernetes.

[Spivak]

I ran into a piece of software that was basically impossible to containerize because of this weirdness.

It wanted to ‘mv’ over resolv.conf but couldn’t so we had to run it outside the container because it was proprietary and we couldn’t readily modify it.

[zwarag]

> ..., I no longer go to Docker to solve problems that could be solved in Docker (secrets anyone? without the "hacks"), and just look towards the other tools solving the problems.

Are you talking about k8s or do you mean something like bitnamis sealed secrets?

[alias_neo]

Hashicorp's Vault and a bunch of your own code, and/or some of their other tools, e.g. Consul.