Live data from Hacker News

Run More Stuff in Docker

jonathan.bergknoff.com

201–210 of 293 posts

Re: Run More Stuff in Docker

#201

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?

My disdain for docker is not so much disk usage (I consider that battle lost in modern Software Engineering) but all the other crud that it does - such as re-implement an entire network device and routing and all. I’ve seen this cause teams countless hours of downtime with things like IP address collisions with VPCs etc, and I’ve never really been given a satisfactory answer as to why this is useful. So now we’ve solved dependency hell and have to faff around with networking and all. Great.

Also the engine runs as root and takes commands from normal users which I always thought was a no-no but I guess docker is ‘special’ - and should be able to do whatever it likes. Containerisation is a fine idea and concept - but I think there are still big caveats.

I’ve been using podman a lot and I hope it becomes more commonplace. I hear that there’s a lot of SV politics and drama going around surrounding the various companies and backers which I have exactly 0 interest in though...

Re: Run More Stuff in Docker

#202
post #130
post #45

Earlier quoted context omitted.

> It might not be obvious, but the app will have access to all your other open windows. Fun fact, most docker hosts will allow access to all your files anyway! (specially true on docker for mac, which all the cool kids(tm) here are using). Even if you restrict container host-FS access to a source repo dir, mind rogue code changing your .git hook scripts in there or you might run code outside of the container when com…

> and to most virtualbox machines (including the hidden one running the fake docker linux host on docker-for-mac) docker-for-mac does not use virtualbox.

Docker For Mac does use a virtual machine to run the Docker machine, though. It's complicated to access the automatically generated mount point on Docker's mac when you create a virtual folder but don't bind it anywhere.

Re: Run More Stuff in Docker

#203

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…

Using that pattern, can you still easily run Black automatically on file save in IntelliJ or similar?

There were a few configuration steps the last time I configured regular black in IntelliJ, but the documentation wasn't too bad to follow.

Re: Run More Stuff in Docker

#204

Earlier quoted context omitted.

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.

It's arguable that it's not quite the same. It all comes down to consequences.

If a distro messes up the trustworthiness of an application, they, the big and important company loses clout.

If the application developer messes up, they also lose clout - people may stop using their software.

Chances are, if you're using a third party for a third party piece of software that isn't officially dockerized by the company that developed it, nor a major distro, there's no real backlash if it doesn't work or if they get hacked, etc: "it was a third party trick, so _of course_ it wasn't trustworthy" would be the statement everyone makes.

Debian messing up, or Cisco or Oracle, etc, is a much bigger deal.

Re: Run More Stuff in Docker

#205

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

On linux just use the system package tool to declare your dependencies.

Yes, you may end up making a deb and an rpm but honestly, it's not an earth-shattering amount of work, lots of companies do it, and then the tool will tell the user "requires libjpeg".

Re: Run More Stuff in Docker

#206

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

Only if you're already skilled at docker.

Re: Run More Stuff in Docker

#207

Earlier quoted context omitted.

> Slow startup time for the first docker app you run each time you reboot, as it boots the linux VM. This, and the other VM-related criticism, is true, but only on Mac & Windows. Running a Docker container on a native Linux system carries very little overhead.

Yep. My comment was mostly made in the context of running macos desktop apps in docker. Windows would be largely the same, though the existence of WSL might make some things easier. Linux desktop apps running in docker would work better because there's no VM in between the native environment and the application. You'd still need to forward GUI calls across the LXD container boundary. That used to be easy with X11 for…

WSL2 mostly solves the problem of manual memory partitioning.

Re: Run More Stuff in Docker

#208
post #152

Earlier quoted context omitted.

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.

Most package manager formats are simple text files as well.

Also, docker doesn’t solve the DLL hell problem, just pushes it out of sight. The nix package manager is something that actually solves it and it should be promoted and leave docker to things it is good at - containerization.

Re: Run More Stuff in Docker

#209
Docker has on the order of 1 second startup time doesn't it? I don't understand why someone would willingly subject themselves to that for things being manually run multiple times per day without an extremely compelling reason.

Re: Run More Stuff in Docker

#210
Because of various org restrictions I attempted to create a developers image on Windows 10. I got the container running but mounting the volumes back to my host workspace was not performant. A build that took 10 seconds on the host took 90 seconds in the container.
Post reply on HN