4 ms·

Because I actually want it to serve 10GB container images to our "enthusiastic" users over the Internet. Oh, and our "enthusiastic" users want to pull it on 10

• lstamour 2y ago
  I should preface this by saying that I figure you know all this, but I'm laying it out anyway. :) Theoretically (I haven't read the parent article yet) it's just GET and HEAD requests for a Docker Registry[1], so if CloudFlare or another CDN supports large binary files, you could cache the images from the low cost box. That said, obviously I'm suggesting adding "cloud" CDN infrastructure to your tiny ARM box. In a more normal scenario, most would probably pick a free Docker Registry and just upload a mirror of the images to multiple registries to spread out the bandwidth load. E.g. Docker Hub, GitHub, etc. For a better solution, don't serve 10GB container images. Instead, start from someone else's 10GB container image and add the layers you need on top of it. Or consider a solution where you don't need to ship 10GB of data in your application, but could perhaps side-load only the necessary data. Another workaround: because Docker images can be pushed and pulled with identical signatures, it's also possible to encourage your end users to keep their own Docker registry of the image and refer to it from an internal or private copy of the image. This is a best practice for pretty much every kind of production deployment of a Docker container, so you don't have 100s of boxes pulling from your shared infrastructure, and leads to more reliable Docker deployments. An example is, in fact, pulling an image - because it stores a copy locally that you can refer to and run multiple containers at the same time from one local image. Pretty much every container image deployment I refer to in production, I prefer to use a privately mirrored copy instead of pulling from a source repository directly. Maybe it's just me? :) [1]: https://ochagavia.nl/blog/using-s3-as-a-container-registry/ https://ochagavia.nl/blog/using-s3-as-a-container-registry/
  • rfoo 2y ago
    > For a better solution, don't serve 10GB container images. Instead, start from someone else's 10GB container image and add the layers you need on top of it. This is assuming I'm not shipping 10GB of novel bytes, but in (2024's) reality quite some people ship model files in container image, guess how large they are :p > it's also possible to encourage your end users to keep their own Docker registry of the image and refer to it from an internal or private copy of the image Of course. Or I can just piggy back on Cloudflare until they decided to stop the party. Sounds much easier for my casual users. For serious users they setup internal mirror anyway so I don't need to encourage someone over the Internet which is hard.
    • msq22 2y ago
      Honest question: why don't you just handle the upload part using a $5 VPS instead of workers?
  • djbusby 2y ago
    Not just you. I use a vendored on-prem copy for all kinds of stuff. CPAN, PECL, NPM, bespoke binaries and docker images. All the upstream vendor deps get caches in this corp-main type repo that we all use internally.
  • ljm 2y ago
    Docker gives you everything you need to cache a build and keep the final image small: multi-stage builds, layer caching, build caching (cache-from/cache-to). It's more recent of course, so there are a lot of docker images out there that don't contain any of that. As to my original point, for purely internal purposes you can self-host for a pitiful cost. You're not going to open that to the internet and start running a public registry from it, but it's a trivial setup, easy to integrate with (not abstracted through cloud IAM setups) and cheaper than paying SaaS for it.
• 10000truths 2y ago
  The specs of the box are the least of your worries at that point. You tell your enthusiastic customers to set up a pull-through cache, because with that kind of traffic, you're going to pay through the nose for egress on typical cloud providers, unless you can guarantee that your users are collocated.