Live data from Hacker News

What has Docker become?

tuananh.net

221–230 of 286 posts

Re: What has Docker become?

#221
post #63

Earlier quoted context omitted.

It didn't help them that they rejected the traditionally successful ways of monetizing open source software. Which is, selling support contracts to large corporate users. Corporate customers didn't like the security implications of the Docker daemon running as root, they wanted better sandboxing and management (cgroups v2), wanted to be able to run their own internal registries, didn't want to have docker trying to f…

Unfortunately even podman etc.. are still limited by OCIs decision to copy the Docker model. Crun just stamp couples security profiles as an example, so everything in the shared kernel that is namespace incompatible is enabled. This is why it is trivial to get in-auditable communication between pods on a host etc…

> Crun just stamp couples security profiles

I don't understand any of this :-)

Re: What has Docker become?

#222
I suspect the timing of this and comments is not coincidental.

I pay for Docker licenses, even though not meeting the criteria for business size requiring it, as I wanted reliable image fetching for my self hosted container CI/CD pipelines failing docker hub image fetches.

But as of now, my oAuth logins to Docker expire within hours now, and I’ve been left with no choice but to scatter in search of diffuse container image alternative sources for my Dockerfiles to stop this madness.

My one way permanent migration from Docker Hub sourced images has finally left me with no reason to keep paying for Docker licenses due to whatever this misguided or blundered rate limit implementation is.

Re: What has Docker become?

#223

"The problem is that Docker the technology became so successful that Docker the company struggled to monetize it. When your core product becomes commoditized and open source, you need to find new ways to add value." No, everything was already open source, other had done it before too, they just made it in a way a lot of "normal" users could start with it, then they waited too long and others created better/their own…

> but swarm was never intended to be a kubernetes contender. Your comment is accurate for the original Swarm project, but a bit misleading regarding Swarm mode (released later on and integrated into docker). I have worked on the original Swarm project and Swarmkit (on the distributed store/raft backend), and the latter was intended to compete with Kubernetes. It was certainly an ambitious and borderline delusional st…

Thanks for chiming in, I was questioning that assertion myself.

I think the problem was giving up on swarm TBH. At some point it was clear k8s would be dominant, but there was still room for that streamlined and integrated experience.

Re: What has Docker become?

#224

"The problem is that Docker the technology became so successful that Docker the company struggled to monetize it. When your core product becomes commoditized and open source, you need to find new ways to add value." No, everything was already open source, other had done it before too, they just made it in a way a lot of "normal" users could start with it, then they waited too long and others created better/their own…

For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.

I mean, isn't that just about what happened to Docker?

They wrote a really nice wrapper around cgroups/ns/tarball hosting and then struggled to monetize it because a large portion of their users are exactly the kind of people who could set up a curlftpfs document cloud.

Re: What has Docker become?

#225

"The problem is that Docker the technology became so successful that Docker the company struggled to monetize it. When your core product becomes commoditized and open source, you need to find new ways to add value." No, everything was already open source, other had done it before too, they just made it in a way a lot of "normal" users could start with it, then they waited too long and others created better/their own…

Arrogance was what actually killed them. They picked fights with Google and RedHat and then showing up at conferences with shirts that said "we don't accept pull requests" tipped the scales so that RedHat and Google both went their own way and their technology was now pushed out of 2 of their biggest channels.

Re: What has Docker become?

#226
post #181
post #148

Earlier quoted context omitted.

What are your thoughts on Podman?

Imitation is the highest form of flattery! Obviously there was demand for an alternative to Docker that was native to the Red Hat platform. We couldn't offer that (although we tried in the early days) so it made sense that they would. In the early days we tried very hard to accommodate their needs, for example by implementing support for devicemapper as an alternative to aufs. I remember spending many hours in their…

There was probably a lot going on behind closed doors, but from the outside, it appeared that RedHat was trying to improve the security and technical details of containers, but Docker was just refusing pull requests and not playing nice. This eventually drove RedHat to make their own implementation (i.e. Podman), so it was a self created enemy and not necessarily one that was built-in/inevitable. I'm definitely not a fan of RedHat's moves since being acquired, but at least from the outside, this looked like Docker being arrogant and problematic and not a "RedHat problem".

Re: What has Docker become?

#227
post #169

> Docker’s journey reads like a startup trying to find product-market fit, except Docker already had product-market fit - they created the containerization standard that everyone uses. The problem is that Docker the technology became so successful that Docker the company struggled to monetize it. When your core product becomes commoditized and open source, you need to find new ways to add value. I would argue the rev…

Well, technically the technology was originally built by IBM folks, as that's where LXC came from. But otherwise yes, your point makes sense.

Google developed linux cgroups. IBM developed linux namespaces. Docker developed a completely new application runtime and delivery system, built on cgroups, namespaces, aufs, and tar. This required lots of original design and engineering work. Prior to Docker, there was no runtime contract for distinguishing the portable application bits from the non-portable host-specific bits. You just got a machine, and then had to provision, configure and templatize it - then upload application bits into it yourself.

All three companies contributed significantly to the modern container stack. As the co-founder of Docker, and someone who spent 10 years toiling away at container technology before it finally became cool, I wish people had more appreciation for the amount of engineering and design work that went into that. Google and IBM contributed the primitives that made Docker possible. But Docker made genuine contributions of its own.

Re: What has Docker become?

#228
post #193

Earlier quoted context omitted.

quadlets fully depend on systemd doing its work. So, assuming you are running rootless, if you change your quadlets, you will need systemctl --user daemon-reload to let systemd ingest the changes. And, if you have configured to start your container on boot, then still you have to start the container by hand, as you typically won't reboot during development. If you have multiple containers, it might be easiest to have…

yeah, that's exactly what every tutorial says. And I know systemd more or less, daemon-reload is no stranger to me. That was not sufficient. Both for global o user setup.

The biggest problem with the `systemctl daemon-reload (--user)` workflow to register quadlets with systemd is it hides any generation errors in journald instead of giving immediate feedback. It's a real pain in the ass, and I say this from a place of love.

Quadlets are just a systemd generator: all `daemon-reload` is doing is running `podman-system-generator` which looks at the Quadlet files and turns them into systemd unit files with a big honking `podman run --rm --blah container:tag` as the `ExecStart` property. There's nothing else to it, no daemons or what not

If you ever feel like bothering to give it another shot check journalctl to see if there's any generator errors. Or run the generator directly: on my OpenSUSE box it's at `/usr/lib/systemd/system-generators/podman-system-generator` , Run it with `--dry-run` to just output to stdout and `--user` to get user quadlets.

Re: What has Docker become?

#229

"The problem is that Docker the technology became so successful that Docker the company struggled to monetize it. When your core product becomes commoditized and open source, you need to find new ways to add value." No, everything was already open source, other had done it before too, they just made it in a way a lot of "normal" users could start with it, then they waited too long and others created better/their own…

I think what Docker should have done, is charge for Docker Desktop from the start... even $5/mo/user as a discount rate for non-open-source usage... similar for container storage, had a commercial offering for private containers from very early on. The former felt like a rug pull when they did it later, and the latter should have been obvious from the start. But it wasn't there in the beginning and too many alternati…

They could have invested more into docker desktop as well. I pay for orbstack, because docker desktop is trash on macos

Re: What has Docker become?

#230

I used to be very enthusiastic about docker compose, but I've been playing around with nix + process-compose lately and its pretty great. I can have k3s and tilt in there only when it's necessary--which it's usually not.

Nix is wonderful for reproducible and declarative infrastructure, but how do you manage multiple server instances with it? I have a handful of projects active at any time, and am currently running four web servers, three mysql instances, two postgres, and a partridge in a pear tree. Should I run Nix in Docker, Docker from Nix, or is there a nix-only solution for this?

You just plug Nix into a service manager that you have Nix bring along for you. Many years ago, I did this for a proof-of-concept at work with supervisord[1] and flake.nix. Devenv[2] builds in[3] support for process-compose[4], which GP mentioned. A few years ago, one long-time Nixer even created[5] a framework, nix-processmgmt[6] that abstracts over various service managers including supervisord and s6[7], which can both be used in a self-contained way regardless of the init system on the host.

There are a ton of other open-source process supervisors you can use to manage long-lived processes in a portable way, too, notably Foreman[8] and various clones written in languages other than JS, and GNU Shepherd[9]. In the course of writing this post, I discovered one called dinit[10] which looks sort of similar to s6 and the GNU Shepherd in that it supports both pure usermode operation as well as functioning as an OS's init system. Anyway, all of 'em are in Nixpkgs, so you can pick them up and use them without any packaging work, too.

Service orchestration and containers are basically orthogonal concerns. Before Docker was born, there were already plenty of portable tools for standalone "process supervision", "service management", whatever you wanna call it. So it is after Docker, as well.

If I needed this for one of my dev environments I would take a look at process-compose to decide if it's acceptable to me. If it isn't, then after surveying the contemporary landscape of usermode service managers, I'd then write a devenv module that generates configs for it, and use that.

> Should I run Nix in Docker, Docker from Nix, or is there a nix-only solution for this?

I'd do this in a "Nix-only" way if possible, but if it's convenient for you to run a service via Docker (or Podman or any other container runtime), you can still do that.

If you can safely assume that all of your devs have it available, you can ship the client (`docker` or `podman` CLI or whatever) as part of your Nix environment, then have your process manager launch it via that command line interface. I'd avoid running Nix from within Docker for the purposes of development environments.

--

1: https://supervisord.org/

2: https://devenv.sh/

3: https://devenv.sh/supported-process-managers/process-compose...

4: https://f1bonacc1.github.io/process-compose/

5: https://sandervanderburg.blogspot.com/2020/02/a-declarative-...

6: https://github.com/svanderburg/nix-processmgmt

7: https://skarnet.org/software/s6/

8: https://github.com/ddollar/foreman

9: https://shepherding.services/

10: https://davmac.org/projects/dinit/

Post reply on HN