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

261–270 of 293 posts

Re: Run More Stuff in Docker

#261

Post by piaste »

XorNot wrote: post #170
pjmlp wrote: post #158

Earlier quoted context omitted.

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

A Docker container is a lot simpler to maintain than a VM, for just about any task you care to mention.

A static binary is much better than a Docker container, I agree. Unfortunately a lot of useful apps can't or won't ship as a static binary (Java, Python, PHP apps), and Docker makes them behave much more like a static binary.

Re: Run More Stuff in Docker

#262

Post by rleigh »

remexre wrote: post #145
josephg wrote: post #90

Earlier quoted context omitted.

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…

> Its called a statically linked executable. They work great. Doesn't this make OpenGL, Vulkan, and parts of glibc break?

Yes. In the case of glibc, it's long past time that flaw was corrected by moving NSS modules out of process and using a pipe or socket to run queries. IIRC OpenBSD already does this. They already cause problems with pulling in their transitive dependencies into your process' address space and potentially causing nasty conflicts. Same goes for PAM modules.

Re: Run More Stuff in Docker

#263

Post by sclevine »

Many comments here point out how difficult it is to manage a separate dependency stack for each container when you use Dockerfiles to build them. This problem is just as difficult, time-intensive, and security-critical for microservice apps running on K8s as it is for CLI tools and graphical apps.

Worth pointing out that there is an incubating CNCF project that tries to solve this problem by forgoing Dockerfiles entirely: Cloud Native Buildpacks (https://buildpacks.io)

CNB defines safe seams between OCI image layers so that can be replaced out of order, directly on any Docker registry (only JSON requests), and en-mass. This means you can, e.g., instantly update all of your OS packages for your 1000+ containers without running any builds, as long as you use an LTS distribution with strong ABI promises (e.g., Ubuntu 20.04). Most major cloud vendors have quietly adopted it, especially for function builds: https://github.com/buildpacks/community/blob/main/ADOPTERS.m...

You might recognize "buildpacks" from Heroku, and in fact the project was started several years ago in the CNCF by the folks who maintained the Heroku and Cloud Foundry buildpacks in the pre-Dockerfile era.

[Disclaimer: I'm one of the founders of the project, on the VMware (formerly Cloud Foundry) side.]

Re: Run More Stuff in Docker

#264

Post by bayindirh »

piaste wrote: post #260
bayindirh wrote: post #229

Earlier quoted context omitted.

> Even very nice SSD’s are cheap enough that 500 MB is negligible. However a nice SSD with a respectable TBW value is not still cheap. a 860 Pro is almost twice the cost of a 860 Evo. Pro provides twice the TBW value. > My internet connection also makes downloading a large docker image no bigger of a deal than downloading Chrome, YMMV. Not everyone of us has pipes that fat to our homes which provide sub 10ms pings an…

> However a nice SSD with a respectable TBW value is not still cheap. a 860 Pro is almost twice the cost of a 860 Evo. Pro provides twice the TBW value. TBW is almost never a concern for desktop users. The Evo has 600 TBW endurance per TB of storage, that would be a full disk rewrite every day for two years. You will never download enough Docker images for personal use to burn out your 860 Evo before you would have r…

> TBW is almost never a concern for desktop users.

You're right however, most of the people who'll use this kind of setup is not ordinary desktop users.

My desktop has 4 disks (2 SSDs and 2 HDDs). My write rate for "Home" SSD is 3TB/yr. To keep the value low, I've moved VMs, big downloads and other stuff to one of the HDDs. System is on another SSD and it's cumulative write was about 3TB in 8 years but, I moved logs and high-write portions to another HDD to keep that value low.

3-4TB / year on the other hand is pretty in line with a Windows 10 installation's behavior when used by a normal desktop user, as intended.

>You will never download enough Docker images for personal use to burn out your 860 Evo before you would have replaced it anyway.

Considering other stuff I do, I could easily double or triple the amount of writes in my Home SSD, but VMs and other stuff already can sit on the RAM once running so there's no speed problem.

While write amplification is not a big concern anymore, building software and other small file operations can accumulate fast, so I still can't trust a SSD blindly.

On the replacing of drives, while a dd or rsync is pretty straightforward for a seasoned Linux user, I don't prefer to change hardware just for the sake of it, or abuse it because it's cheap and can be replaced on a whim. At the end of the day, I'd rather use my system efficiently rather than recklessly both in terms of resources and endurance, because being able to rely on your system is underrated imho.

Because of my Job, we torture systems up to and beyond their design limits and a little optimization can go a long way in these scenarios. I like to apply that knowledge to my systems to extend their useful life.

Re: Run More Stuff in Docker

#265

Post by jillesvangurp »

u801e wrote: post #248
jillesvangurp wrote: post #239

Earlier quoted context omitted.

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?

The infrastructure for creating and sharing e.g. virtual box images does not exist. With docker I can run just about any server product you can name with a single command line invocation. Those commands don't exist for vmware, virtual box or other common virtual machine. That infrastructure simply does not exist.

Re: Run More Stuff in Docker

#266

Post by jillesvangurp »

AnIdiotOnTheNet wrote: post #228
jillesvangurp wrote: post #186

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. The simple reality is that, there is Docker and absolutely nothing else that comes close to working everywhere. Yes, it's not perfect but everything else is far less perfect. Static binaries are far too limited; most software requires lots of files spread all around the file system. I did a…

> Static binaries are far too limited; most software requires lots of files spread all around the file system. In my experience that is entirely and ludicrously false. That is merely how a lot of unix software does things by convention, but there are a lot of ways to make even poorly-thought-out unix software behave as a self-contained entity.

Well, yes that's exactly what docker does.

In contrast, most linux package managers seem to make a big deal about doing all of this slightly different on just about every linux distribution and even between different versions of the same distributions. The fact package managers exist proves my point: deciding which files go where is a big deal and there seem to be an awful lot of opinionated package managers making different choices here. Whatever standards and conventions exist here seem to leave an awful lot of choice and wiggle room.

Re: Run More Stuff in Docker

#267

Post by solarengineer »

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…

As a Ruby, Node or Python language user, you may want to try rbenv, nodenv or pyenv respectively.

Re: Run More Stuff in Docker

#268

Post by tedk-42 »

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

Earlier quoted context omitted.

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

The learning curve for docker is minimal. As I mentioned before it's very useful in CI systems where you want to be building and testing your code in a clean environment that is reproducible across machines.

Trying to debug when a core library or header dependency is missing to build your code requires far more skills and differ between operating systems and versions of operating systems.

The problem isn't moved upstream, it's tackled in a very clever and well packaged manner.

Re: Run More Stuff in Docker

#269

Post by AnIdiotOnTheNet »

jillesvangurp wrote: post #266
AnIdiotOnTheNet wrote: post #228

Earlier quoted context omitted.

> Static binaries are far too limited; most software requires lots of files spread all around the file system. In my experience that is entirely and ludicrously false. That is merely how a lot of unix software does things by convention, but there are a lot of ways to make even poorly-thought-out unix software behave as a self-contained entity.

Well, yes that's exactly what docker does. In contrast, most linux package managers seem to make a big deal about doing all of this slightly different on just about every linux distribution and even between different versions of the same distributions. The fact package managers exist proves my point: deciding which files go where is a big deal and there seem to be an awful lot of opinionated package managers making d…

> The fact package managers exist proves my point: deciding which files go where is a big deal and there seem to be an awful lot of opinionated package managers making different choices here.

Consider that "package managers" only really existed in the UNIX world until relatively recently. Other OSs just didn't make everything so complicated to begin with.

"which files go where" just isn't really a problem if you don't make dependencies some third party's problem.

Re: Run More Stuff in Docker

#270

Post by edbob »

cratermoon wrote: post #149
edbob wrote: post #124

Earlier quoted context omitted.

I'm not an expert in this area, but I've seen plenty of accounts of how Docker can be very insecure. Perhaps it's possible to configure Docker so that it is very secure, but even Google has had people break out of their containers, so these claims about container security should probably come with a disclaimer: "Docker is very secure as long as you are one of the top 0.1% in the field and never mess up". VMs seem to…

I think the experts in docker would note that sandboxing and privilege isolation are technical features which have many uses, but that is not at all the same as making broad-based claims about the security of docker or the virtual machine and host operating system technology upon which it runs.

It's obvious that any system with faulty sandboxing or privilege isolation is quite likely to be insecure. If the default "sandboxing" of Docker allows access to nearly everything of importance on the host, then we can indeed make "broad-based claims" about the insecurity of the system as a whole.
Post reply on HN