Live data from Hacker News

Are Package Registries Holding Open-Source Hostage?

about.scarf.sh

11–20 of 78 posts

Re: Are Package Registries Holding Open-Source Hostage?

#11
This is a common pattern how to break pricing mechanism and prevent competition - separate choosers of the service from payers of the service. In this case free hosting is offered to publishers, they choose to host their images there and then users who download them are asked to pay. Had publishers been asked to pay, they would select appropriate registry and perhaps self-host one rather than to use third-party one.

Re: Are Package Registries Holding Open-Source Hostage?

#12

Question: What keeps an organization from hosting it's own package mirror internally and only periodically fetch the diffs from the central registry?

Someone would have to support it 24x7 and we could never get the uptime of DockerHub/ACS/ECS. Since a Production k8s deployment could spin up an instance at any time of day, some type of 5-9 or at least 4-9 uptime is pretty important.

Re: Are Package Registries Holding Open-Source Hostage?

#13
post #8

Question: What keeps an organization from hosting it's own package mirror internally and only periodically fetch the diffs from the central registry?

There are tools for doing this, but it's a matter of cost and complexity to deal with them. Artifactory seems to have a pretty big chunk of this vertical. It supports a few different repository protocols, so it serves as a bit of a one-stop shop that survives technology changes.

If you are fetching multiple GB of images over the network it kinda make sense.

Re: Are Package Registries Holding Open-Source Hostage?

#15

Relying on generosity when there are infrastructure costs does not seem to be a workable model. It's somewhat amazing that it has survived so long.

> Relying on generosity when there are infrastructure costs does not seem to be a workable model. It's somewhat amazing that it has survived so long.

I too was initially surprised but then I thought of github (this was also the case pre-microsoft acquisition), sourceforge, gitlab, etc who all seem fine with me downloading/cloning as many repos as I want without charge.

Re: Are Package Registries Holding Open-Source Hostage?

#16

Question: What keeps an organization from hosting it's own package mirror internally and only periodically fetch the diffs from the central registry?

Someone would have to support it 24x7 and we could never get the uptime of DockerHub/ACS/ECS. Since a Production k8s deployment could spin up an instance at any time of day, some type of 5-9 or at least 4-9 uptime is pretty important.

I see.

I guess you could still fall back to the main package source if the local mirror is down.

Re: Are Package Registries Holding Open-Source Hostage?

#17
post #6

The problem with Docker Hub is that they don't let you choose the pricing model. In the end, bandwidth and CPUs are not free, so someone has to pay. For a while it was VCs hoping for growth, but we all know that giving stuff away for free is not sustainable forever. The problem with Docker Hub's pricing model is there are actually two use cases for Docker Hub. One is where some random entity makes some software -- th…

There are publisher pays plans available for Docker Hub, email pricingquestions@docker.com for details.

Re: Are Package Registries Holding Open-Source Hostage?

#18

Question: What keeps an organization from hosting it's own package mirror internally and only periodically fetch the diffs from the central registry?

AWS has a managed service CodeArtifact that supports all the common code package repos and allows caching of upstream repos. Granted it doesn't work with Docker Images, but you asked about packages.

Re: Are Package Registries Holding Open-Source Hostage?

#20

Earlier quoted context omitted.

Someone would have to support it 24x7 and we could never get the uptime of DockerHub/ACS/ECS. Since a Production k8s deployment could spin up an instance at any time of day, some type of 5-9 or at least 4-9 uptime is pretty important.

I see. I guess you could still fall back to the main package source if the local mirror is down.

As long as you're not doing push stuff:

1) set up a series of N docker registry mirrors in pull-through mode (https://docs.docker.com/registry/recipes/mirror/, it's as simple as "docker run --rm --name registry -d -p 5000:5000 -e REGISTRY_STORAGE_DELETE_ENABLED=true -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io -v /mnt/persistentdata/registry:/var/lib/registry registry")

2) expose them on the same domain name (multiple A records, loadbalancers, whatever you want)

3) set them as mirrors in each machine's docker daemon

In case one of your mirrors go down, take them out of the DNS/LB rotation. That's it.

Post reply on HN