Hacker News Reader

Comment by mfer | Hacker News Reader

Docker Hub is a massive expense when you consider the data storage and egress. To do that for open source projects you have to wither (a) have a lot of income to cover such an expense, (b) a pile of VC funding to cover the expense, or (c) pile on the debt paying for it while you grow. (b) and (c) can only live on so long.

View on HN

That's a self inflicted problem by docker hub squatting the root namespace, though.

Getting out of a self inflicted problem isn't so easy. They have spent a long time trying. For example, putting distribution in the CNCF, working with the OCI on specs (like the distribution spec), making it possible to use other registries while not breaking the workflows for existing folks, and even some cases of working with other registries (e.g., their MCR integration with Docker Hub that offloads some egress and storage).

The root namespace problem was created by an early stage startup many years ago. I feel for the rough spot they are in.

It's a self inflicted problem they've doubled down on, though, and that self inflicted problem is also the reason for their success. If docker hub could be removed in a config, the value add of docker the company is significantly diminished. It's hard to feel sorry for a company who actively pursued lock-in, and didn't make any real attempts at avoiding it (you know what would help? A setting to not use docker hub, or to use a specific repo by default), and who have built an enormous company on a value add that is a monkey's paw, and they've known that all along.

edit: https://github.com/moby/moby/pull/10411 this is the change that would _actually_ solve the problem of docker squatting the root namespace, and they've decided against it because it would make dockerfiles less portable (or really, it would neuter docker.io's home as the default place images live)

I fail to follow. If DockerHub is the part that actively burns money, why stick with it? If, say, Docker Desktop is the part that actively brings profits, why would it be afflicted if the users used a different image registry? Most companies, except the smallest ones, use their own registry / mirror anyway.

Even better, the registry may continue to exist, but would (eventually) stop storing the images, and start storing .torrent files for the actual downloads. Seeing an image from the GitHub release page would be enough for most smaller projects (yes, BT supports HTTP mirrors directly).

I suspect that dockerhub isn't the part that bleeds money, I suspect like many tech companies the part that bleeds money is sales costs and developer costs (see gitlab). Unfortunately I can't prove that though.

Docker downsized from 400(!) to 60 people a few years back, and a quick search on Google says they're now back up at 600 employees again. They have ARR of $50M [0] , which is probably a little short of paying 60 people SV salaries, but it's nowhere near enough to pay for 600 people.

As regards to the registry problem, "most companies" I suspect don't follow best practices and in fact do end up using docker hub for things like public images, but more importantly _there is no way to enforce this in the tool, and docker have refused to implement this when given a PR_.

[0] https://techcrunch.com/2022/02/01/docker-makes-comeback-reac...

> I feel for the rough spot they are in.

I don't. Because there is this pattern from VCs to fund business models that involve dumping millions in resources as Open Source on the world and then owning a part of the ecosystem.

Docker originally wanted to "own" everything, if CoreOS hadn't pushed for the OCI spec, debalkanizing containers, Docker would have a near monopoly on the container ecosystem.

At this point Docker is just the command, and it is a tire fire of HCI gaffs.

This was the initial pebble that lead to Podman existing via Red Hat. No Red Hat customer wanted to pull or push to DockerHub by default due to a typo. No PRs would be accepted to change it and after dealing with customer frustration over and over...

I'm not familiar with the 'root namespace squatting' or the typo issue. Do you mean the image namespace as described here: https://www.informit.com/articles/article.aspx?p=2464012&seq... or is there something else? What sort of typo would cause problems?

Yeah, this is a good summary of the problem. If I write a dockerfile with

    FROM ubuntu:20.04 
    WORKDIR /app
    ADD mySecretAppBinary .

it will pull the base image from hub.docker.io, and there is no way to stop it from doing so. If I run:

    image_tag = test-app
    docker build -t $image_tag .
    docker push $image_tag

it will push a container with my secret application to the public docker hub, assuming I am logged in (which of course I am, because docker rate limits you if you don't). I don't ever want to do that, ever, under any circumstances, and it's just not possible to opt out of whiel using docker.

This was the proposed PR that is summarized in that article: https://github.com/moby/moby/pull/10411

if you did `docker tag supersecret/app:latest && docker push` instead of `docker tag registry.corp.com/supersecret/app:latest` guess where your code just went?

Same on the pull side, if you wanted your corp's ubuntu base rather than just `docker pull ubuntu`.

I wonder if they would have a much smaller bill if they were running on physical hardware instead of renting infrastructure from AWS.

This is really not much different from https://news.ycombinator.com/item?id=35133510 case.

Reply on news.ycombinator.com