I wonder what Docker's peak bandwidth usage is, and how they make it work, financially.

Just imagine the vast number of poorly cached CI jobs pulling gigabytes from Docker hub on every commit, coupled with naive aproaches to CI/CD when doing microservices, prod/dev/test deployments, etc.

It would be lovely to see Bittorrent in this space. Distributing an identical blob to N machines is squarely within its wheelhouse. All those CI machines would make wonderful seeders too.

Uber Engineering open-sourced Kraken [1], their peer-to-peer docker registry. I remember it originally using the BitTorrent protocol but in their readme they now say it is "based on BitTorrent" due to different tradeoffs they needed to make.

As far as I know there aren't any projects doing peer-to-peer distribution of container images to servers, probably because it's useful to be able to use a stock docker daemon on your server. The Kraken page references Dragonfly [2] but I haven't grokked it yet, it might be that.

It has seemed strange to me that the docker daemon I run on a host is not also a registry, if I want to enable that feature.

It's also possible that in practice you'd want your CI nodes optimized for compute because they're doing a lot of work, your registry hosts for bandwidth, and your servers again for compute, and having one daemon to rule them all seems elegant but is actually overgeneralized, and specialization is better.

1 https://github.com/uber/kraken

2 https://d7y.io/