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

161–170 of 293 posts

Re: Run More Stuff in Docker

#161

Post by sdepablos »

physicsgraph wrote: post #6
sdepablos wrote: post #4

I'm in the same situation: until I figure (if ever) how to use NixOS and control version my OS, I tend to use Docker for any application with lots of dependencies, specially Python related ones

Did you try the Docker-based approach after trying Python's virtualenv? Or did you go directly to Docker?

No, I've using virtualenv for quite some time and I still use it when I'm the person in control of the dependencies, though I'm moving little by little to the docker way. Why? Because sometimes the problem is not only on the dependencies, but in Python itself. As an example, as of today gcloud does not support Python 3.9.

Re: Run More Stuff in Docker

#162

Post by sdepablos »

setheron wrote: post #19
sdepablos wrote: post #4

I'm in the same situation: until I figure (if ever) how to use NixOS and control version my OS, I tend to use Docker for any application with lots of dependencies, specially Python related ones

Reach out to me if you want to learn Nix I'm always happy to help people climb the steep learning curve

Thanks setheron. If I find the time (the eternal issue) I may to take you on your word )

Re: Run More Stuff in Docker

#163

Post by sverhagen »

knowhy wrote: post #147
systemvoltage wrote: post #42

Let's not. I don't want to install Chrome which is already 73 MB, now bloated up with a whole lotta bullshit that's 500 MB+ image. Imagine downloading every application as a docker container. WTF. Docker is for distribution of applications when deploying them to servers. As a developer, it's amazing at that and have brought peace and joy in devops. Let's leave it there, shall we?

Docker has a layer file system. Meaning if you do it right, that Chrome container will share the same 500 MB base image layer with the Gimp container, or whatever, making it less bloated than it appears when looking only at the footprint of the first image. I'm not stating that I believe it is a good idea to run desktop apps in Docker containers. It is not a good idea. But it is also not true that if someone would do…

I fully agree with the original premise (to run more stuff in Docker). But if I maintain two tools, both using Docker, let's say they're both built in Python, they'll both be in their own Git repository, and their build pipelines will come up with independent Docker images for whomever wants to use those tools, and it seems like frivolous maintenance, if not an anti-pattern, to make sure that these tools are always using the same base image. And yes, if bandwidth and disk space were constraint for me, I'd probably reconsider (even on the original premise), but they are not.

By the way, while I think you should run more stuff in Docker, I also think it is still totally reasonable to have your "main language stuff" installed "normally" (not in Docker). If I'm a Java developer, I'm "happy" to deal with Java's dependency b.s. on my normal system. Meanwhile, if I ever have to touch Ruby, I do not want to deal with Ruby's dependency b.s. on my normal system (rather run that in Docker). And vice versa, as I'm sure.

Re: Run More Stuff in Docker

#164

Post by sverhagen »

m463 wrote: post #152
systemvoltage wrote: post #42

Let's not. I don't want to install Chrome which is already 73 MB, now bloated up with a whole lotta bullshit that's 500 MB+ image. Imagine downloading every application as a docker container. WTF. Docker is for distribution of applications when deploying them to servers. As a developer, it's amazing at that and have brought peace and joy in devops. Let's leave it there, shall we?

I disagree. I think the beauty of docker - and this should spread elsewhere - is that everything starts with one text file. The crufty part is all the crap that has to be added to the docker run commandline.

> one text file.

That! It is codified. If people had their main machine codified, Docker would maybe be less of a benefit. And I'm sure a lot of people here have that. But a lot of my colleagues don't. So, I give them a Docker image... instead of explaining the same Java developer for the umptied time how to make a virtual environment for my Python program.

Re: Run More Stuff in Docker

#165

Post by masa331 »

This brings only mess and another indirection layers to your system which is hardly an advantage in my opinion. It will take more time to setup, more space on disk, it will be slower and harder use. And all the normal tools(like awk and others in the article) are easily instalable in all distros. I will rather spend time learning these tools directly instead of infinitely fiddling with docker.

Re: Run More Stuff in Docker

#166

Post by Too »

visarga wrote: post #125
antoinealb wrote: post #26

Earlier quoted context omitted.

Serious question: Why do you believe that to be insane? The Dockerfile for a simple application such as black must be very short (probably 3-4 lines), the alias is probably quite short and the container overhead time is minimal for native docker (the story might be different for things like docker mac). On the other hand, you get some benefits from installing black through docker rather than through the system packag…

But can you still trigger the containerized Black from VS Code?

Yes. Only caveat is depending on how it's invoked you might need some --volume tweaking in your alias. If it's just being sent stdin then there shouldn't be any problem. Mounting whole project is probably best anyway for it to find tox.ini or whatever other config files needed. Also make sure the image doesn't contain any excessive output that uncontainerized black doesn't print.

Re: Run More Stuff in Docker

#167

Post by siscia »

I am trying to go in the opposite direction offering a read-only, mountable file system that offer a well crafted set-up of tools and utilities.

The idea is that you mount the filesystem and you got all the tools you need, and more, well installed, and that are lazily pulled from the network.

You win on the space side, but you need a bit more of trust.

You can find more info here: http://packages.redbeardlab.com

On the GitHub repo where you can ask for more packages to be installed:

https://github.com/RedBeardLab/packages.redbeardlab.com/

And in this pair or articles for specific languages

Golang: https://redbeardlab.com/2020/12/21/packages-redbeardlab-com-...

And for JavaScript/node: https://redbeardlab.com/2020/12/23/packages-redbeardlab-com-...

Re: Run More Stuff in Docker

#168

Post by dimitar »

knowhy wrote: post #147
systemvoltage wrote: post #42

Let's not. I don't want to install Chrome which is already 73 MB, now bloated up with a whole lotta bullshit that's 500 MB+ image. Imagine downloading every application as a docker container. WTF. Docker is for distribution of applications when deploying them to servers. As a developer, it's amazing at that and have brought peace and joy in devops. Let's leave it there, shall we?

Docker has a layer file system. Meaning if you do it right, that Chrome container will share the same 500 MB base image layer with the Gimp container, or whatever, making it less bloated than it appears when looking only at the footprint of the first image. I'm not stating that I believe it is a good idea to run desktop apps in Docker containers. It is not a good idea. But it is also not true that if someone would do…

That is if you are using one base base image. Most likely you will be using Alpine, Ubuntu, Debian, Centos, Red hat, Oracle Linux and who knows what else in different containers, unless of course you have the patience to repackage all then versions you need for your favorite base image.

Re: Run More Stuff in Docker

#169

Post by sverhagen »

josephg wrote: post #90
systemvoltage wrote: post #49

Earlier quoted context omitted.

Jumping from 73 MB -----> 500 MB or whatever. Have you been running Docker on your system? Have you tried running: `docker system prune -a`? It's gonna print something like Total reclaimed space: 31.2GB .

Its worse than just the size jump. Every application would also need to run all its code inside a linux VM. So that means: - Dedicated RAM for all your docker apps (which you have to partition manually) - Slow startup time for the first docker app you run each time you reboot, as it boots the linux VM. - All syscalls run through the VM's emulation layer, which is way slower than native - No access to the system's nat…

Just want to call out: this is on Windows and macOS. So, these remarks are certainly true for probably a majority of Hacker News readers, but if you were on Linux these limitations do not exist. I'm also not sure how much these limitations hinder you in reality, I hear few complaints from the macOS users around me, and we use Docker a lot.

Re: Run More Stuff in Docker

#170

Post by XorNot »

pjmlp wrote: post #158
pram wrote: post #110

Earlier quoted context omitted.

Now talk about deploying something NOT using Kubernetes. The double whammy. Now you're looking like an insane 100 year old graybeard fossil.

Fossil here, happily using VMs.

I guess that makes me fossilizing, because this is the direction I think we should really be heading.

When I stare at docker long enough I wind up at "why couldn't this be a static binary" or "this would be easier to secure if it was it's own VM".

Post reply on HN