3 ms·
Docker does this a lot. For example, we were trying to turn off gzipping images on the wire when pulling because it actually cost more when done from the intran
by junon 5y ago
Docker does this a lot. For example, we were trying to turn off gzipping images on the wire when pulling because it actually cost more when done from the intranet.
You can't. And modifying the source was so convoluted that we gave up.
Then we needed to clean up docker (before there were commands to do that) when it started to eat up all of the disk space.
To our (un)surprise, Docker uses 3 (!!) different storage formats, many of them having redundant information, and editing one of them would cause the other to be corrupted.
One was a binary database format that was specific to Go and didn't have any utility CLI to work with, so you had to write a programmatic interface with it just to edit it.
Or how about the fact that even if you issue commands directly to docker over the HTTP Unix socket, it will deadlock if you issue too many commands to it? This became our nightmare when trying to implement one of the first iterations of custom deployment backends at ZEIT. In fact, the entire project failed because of docker (there was no great alternative at the time).
- wernerb 5y agoI am honestly wondering more about your specific use case. Does the CPU cost outweigh the storage cost? Is it a timing problem (speedup) or are you at such large scale (on premise)? Maybe where I'm getting at is, I can think of 99 problems but docker gzip ain't one :) how was this a priority (at some point)
- infogulch 5y agoPretty sure it's CPU vs network not CPU vs storage. A fast internal network can be cheap compared to the cpu required to pack/unpack images on every download. I wonder if choosing a fast-to-decompress algorithm like zstd would change that.
- junon 5y agoAs we were a deployment company (ZEIT) our usecase was quite different. And yes, as the other person mentioned, it was on the wire GZIP, not storage concerns.