Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Run More Stuff in Docker

jonathan.bergknoff.com

Post reply on HN
Print view View original

71–80 of 293 posts

Re: Run More Stuff in Docker

#71

Post by FartyMcFarter »

hendry wrote: post #68
FartyMcFarter wrote: post #34

Earlier quoted context omitted.

Static linking is nice, but there are some licenses (notably the GPL and LGPL, which glibc uses) which don't easily allow that for closed-source software. On the technical side, as soon as some code needs to 'dlopen' something (e.g. a plugin or a system driver), you can run into trouble due to multiple instances of glibc or other dependencies running together. But if none of those are a requirement for your use case…

Golang makes it pretty painless to build static binaries. go:embed expected in 1.16 even more so.

If you're building on Linux, does it usually embed glibc in them? If it does, you'll need to comply with the LGPL when you distribute your statically linked binary.

Re: Run More Stuff in Docker

#72

Post by foolmeonce »

FartyMcFarter wrote: post #67
foolmeonce wrote: post #63

Earlier quoted context omitted.

You can statically link whatever you like, you just can't distribute it as one work. One of the crazy one executable docker containers strikes me as one work to whatever extent a static linked binary is.

> You can statically link whatever you like, you just can't distribute it as one work. How do you distribute it then? Let's assume your statically linked binary contains both closed-source code and GPL/LGPL code. > One of the crazy one executable docker containers strikes me as one work to whatever extent a static linked binary is. I'm not a lawyer, but that's not my understanding. A docker image is a glorified colle…

> How do you distribute it then?

You distribute a script and whoever runs the potential violation assembles it themselves, like with zfs on Linux.

I don't really get the demarcations typically made since a proprietary media could conceivably be as hard to pull apart as using linking tools to break apart sections of a static binary again..

I get the general sense that people work around examples of what one interpretation says isn't allowed without getting many opinions on the work around.

Re: Run More Stuff in Docker

#73

Post by gigel82 »

I wish there were real / usable Windows containers out there. I'd love to spin up a quick sandbox to run a MSVC / MSBuild, but the smallest "image" in Windows-land for that is 12Gb.

Still use Docker alongside WSL2 for purely-Linux stuff like some node.js scripts or python things that don't need GPU.

Re: Run More Stuff in Docker

#75

Post by fantod »

peteretep wrote: post #69
fantod wrote: post #65

Earlier quoted context omitted.

I mean it could just be very many containers that add up. And in many cases you'll have loads of images close to 1GB unless you go to great lengths to try and shrink them (e.g. anything that uses Python).

I can get an Alpine Linux container running Perl with a chunk of CPAN on it to 60MB by just stripping the build tools once I've installed everything I want. Is Python really a GB bigger, or are people not taking the most basic of steps?

So maybe I was quick to comment, but I glanced at the images I have sitting around and python:3.7 is 876MB. However, python:3.7-slim is 112MB (still nearly twice the size of the image you describe, though). But it's conceivable that many people running into limitations with the slim image would just opt for the full Python image instead.

Maybe a better example is the Tensorflow image, which is close to 4GB for the GPU version. It's also the kind of thing that would be a pain to rebuild from scratch if you wanted to find a way to save space.

Re: Run More Stuff in Docker

#76

Post by peteretep »

fantod wrote: post #75
peteretep wrote: post #69

Earlier quoted context omitted.

I can get an Alpine Linux container running Perl with a chunk of CPAN on it to 60MB by just stripping the build tools once I've installed everything I want. Is Python really a GB bigger, or are people not taking the most basic of steps?

So maybe I was quick to comment, but I glanced at the images I have sitting around and python:3.7 is 876MB. However, python:3.7-slim is 112MB (still nearly twice the size of the image you describe, though). But it's conceivable that many people running into limitations with the slim image would just opt for the full Python image instead. Maybe a better example is the Tensorflow image, which is close to 4GB for the GP…

Do you also understand that once you have any image built on top of python:3.7 then that 876MB doesn't need to be downloaded again for subsequent images?

> the Tensorflow image is really big

This is kind of meaningless without comparing it to how large Tensorflow is with related dependencies if you just install it centrally?

Re: Run More Stuff in Docker

#78

Post by fantod »

peteretep wrote: post #76
fantod wrote: post #75

Earlier quoted context omitted.

So maybe I was quick to comment, but I glanced at the images I have sitting around and python:3.7 is 876MB. However, python:3.7-slim is 112MB (still nearly twice the size of the image you describe, though). But it's conceivable that many people running into limitations with the slim image would just opt for the full Python image instead. Maybe a better example is the Tensorflow image, which is close to 4GB for the GP…

Do you also understand that once you have any image built on top of python:3.7 then that 876MB doesn't need to be downloaded again for subsequent images? > the Tensorflow image is really big This is kind of meaningless without comparing it to how large Tensorflow is with related dependencies if you just install it centrally?

Yes, I understand that Docker caches layers. Like I said, if docker system prune is clearing a huge amount of space, it's like a large number of different images and containers that might not share layers. If you're build, running, starting, and stopping containers all day, you might not be terribly careful about exactly what you're doing each time. That's why system prune is so useful.

Re: Run More Stuff in Docker

#79

Post by hendry »

FartyMcFarter wrote: post #71
hendry wrote: post #68

Earlier quoted context omitted.

Golang makes it pretty painless to build static binaries. go:embed expected in 1.16 even more so.

If you're building on Linux, does it usually embed glibc in them? If it does, you'll need to comply with the LGPL when you distribute your statically linked binary.

I think you can escape that with CGO_ENABLED=0

Re: Run More Stuff in Docker

#80

Post by cortesoft »

harryruhr wrote: post #38
cortesoft wrote: post #25

Earlier quoted context omitted.

Hmmm... what alternative does not either take time or trust?

It's all relative, of course. But getting a signed package from the repo of the distro I'm using for years is something different than using a random image from hub.docker.com.

Sure, but you are still relying on trust, and you are choosing to limit yourself to things released by your chosen distro. This is the same as if you were to pick a specific docker publisher that you trust, and only use their images.
Post reply on HN