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

241–250 of 293 posts

Re: Run More Stuff in Docker

#241

Post by scaryclam »

pjmlp wrote: post #178
XorNot wrote: post #170

Earlier quoted context omitted.

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".

Many people are basically misusing Docker to work around Python and Ruby dependency problems.

9/10 times I see the problems getting solved in the same way you can do without docker, except now the application is also running as root and several more containers are added to work around other issues created by running in docker :(

Re: Run More Stuff in Docker

#242

Post by Jugurtha »

physicsgraph wrote: post #5

A few years ago I set a goal to minimize the number of applications installed bare-metal on my laptop. Everything is containerized, just as the blog describes. There is some initial overhead, and some extra work associated with maintaining the infrastructure, but overall I can report improved reproducibility (due to an isolated and static environment per app). I use a bash alias for each common application. For examp…

>For example, "jup" launches a jupyter notebook.

Would you be willing to share what you do with Jupyter notebooks, your workflow, how you collaborate with your team, your frustrations?

Re: Run More Stuff in Docker

#243

Post by ogre_codes »

tedk-42 wrote: post #187
ogre_codes wrote: post #131

> Running a program in a container is a lot like running it normally, but the user doesn’t need to jump through hoops to configure the system, build and install. Docker is itself a complex build tool which requires a bunch of install steps. If you are going to ship software to end users there is almost always a better way to bundle and ship than send someone a Docker container . Docker is not a distribution tool, if…

Sorry but you're wrong. A vast majority of software ships after it has been built as a stand alone application as well as a Docker container so that it can be run in container environments. A lot of CI systems natively support Docker because of the variety of tools and images you have available to run you CI steps in. Docker is an excellent distribution tool because it only requires Docker. You can send someone some…

> You can send someone some python code and ask them to run it, only to find they're missing a bunch of C libs required to build and run the code which is a pain to help them figure out how to solve.

You can send someone a Docker file only to figure out they've never heard of Docker. Let alone don't have it installed and aren't interested in setting up a container system to your 500 line Docker script.

All you've done is move your problem upstream. Unless your consumer is a web developer, you are out of luck.

Re: Run More Stuff in Docker

#244

Post by ogre_codes »

t-writescode wrote: post #199
ogre_codes wrote: post #131

> Running a program in a container is a lot like running it normally, but the user doesn’t need to jump through hoops to configure the system, build and install. Docker is itself a complex build tool which requires a bunch of install steps. If you are going to ship software to end users there is almost always a better way to bundle and ship than send someone a Docker container . Docker is not a distribution tool, if…

> In no case is "Making it into a Docker Image" a simpler/ better distribution mechanic. For my home server setup, I have docker containers for: * PiHole * NextCloud * Home Assistant If I had to install each of those manually, I probably wouldn't have installed them. This is especially true of NextCloud, which almost certainly would have required me to learn how to run nginx on my own, install php or whatever applica…

It's a fair point and a good example of why there are no absolutes, but hardly addresses the bigger point.

If you have an app that formats JSON files, are you shipping it as a Docker container? Or a linter? How about a text editor?

The number of applications where it makes sense to bundle them as VMs is quite small.

Re: Run More Stuff in Docker

#245

Post by gigel82 »

nyellin wrote: post #119
gigel82 wrote: post #73

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.

I'm looking at startup ideas in this area. Would you be interested in describing your pain points and use case?

I just want Docker containers for Windows with a reasonable size. They do have a Server Core (at about 1.5Gb) and a much slimmer NanoServer (100Mb), but the NanoServer is not capable of running the Visual C++ compiler for example.

Just look at something like this which tries to compile C++ for VcPkg: https://hub.docker.com/r/hripko/vcpkg/tags?page=1&ordering=l... (the Linux images are all < 300Mb, but the Windows one is 5Gb compressed).

Re: Run More Stuff in Docker

#246

Post by ogre_codes »

m463 wrote: post #154
ogre_codes wrote: post #132

Earlier quoted context omitted.

A MacOS App is just what you need to run the app on MacOS. A Docker Image is essentially a mini operating system in a can. Most Docker images contain shells, the entire Python install, an init sequence... piles and piles of redundant stuff. If you are running a Docker image on MacOS or Windows, you first have to start docker which is itself a Linux Virtual machine. Docker is a great dev tool, but if you don't need it…

I think you are responding too literally to his comment, which is spot on. A macos app is running in a sandbox and runs in a conceptually similar way to docker. Go look in ~/Library/Containers also look at the filesystem under .app

> I think you are responding too literally to his comment, which is spot on.

Should I respond metaphorically?

> A macos app is running in a sandbox and runs in a conceptually similar way to docker.

A Mac App fundamentally has access to system libraries and leverages those. A Docker container is designed to ignore the system and builds its own environment.

If you run a Docker container on a Mac or Windows, you are now running 3 operating systems. The host OS, the VM, and the Docker image.

This is not the same as a Mac App. Literally, figuratively, or hypothetically.

Re: Run More Stuff in Docker

#247

Post by boublepop »

jillesvangurp wrote: post #239
u801e wrote: post #219

Earlier quoted context omitted.

> What's the alternative to docker? And by that, I mean a solution that a team can reasonably use across Linux, Windows, and Mac. Virtual Machines. VirtualBox in combination with vagrant works reasonably well cross-platform.

Doesn't solve the same problem. You can use that to run docker of course.

Care to elaborate on your point? How is that not the same problem?

Re: Run More Stuff in Docker

#248

Post by u801e »

jillesvangurp wrote: post #239
u801e wrote: post #219

Earlier quoted context omitted.

> What's the alternative to docker? And by that, I mean a solution that a team can reasonably use across Linux, Windows, and Mac. Virtual Machines. VirtualBox in combination with vagrant works reasonably well cross-platform.

Doesn't solve the same problem. You can use that to run docker of course.

What problem does Docker solve that using a VM cannot solve?

Re: Run More Stuff in Docker

#249

Post by Kwpolska »

sverhagen wrote: post #163
knowhy wrote: post #147

Earlier quoted context omitted.

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 u…

Both of your Python projects will likely have `python:latest` (or such) as their base image. Sure, they will diverge after that (with further layers for dependencies and your code), but at least the base system will be shared.

Re: Run More Stuff in Docker

#250

Post by cmckn »

RedShift1 wrote: post #192
cmckn wrote: post #188

Earlier quoted context omitted.

Totally agree that Docker is made for deploying to servers. But the disk space critique doesn’t hit for me. Even very nice SSD’s are cheap enough that 500 MB is negligible. My internet connection also makes downloading a large docker image no bigger of a deal than downloading Chrome, YMMV. I think the necessity of a VM when using Docker on Mac and Windows is the primary reason that running your “normal” apps in a con…

The problem isn't 500 MB disk footprint, it's all the RAM memory going to waste when loading in redundant libraries. Chrome already is a memory hog on its own, imagine all applications suddenly bringing in their versions of their libraries.

RAM is the same situation as disk for me — I have plenty to waste.

Again, not advocating Chrome in a container, I don’t even run Chrome outside of a container. I just think it’s odd to get hung up on these sorts of resource requirements given the state of computing.

Post reply on HN