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

221–230 of 293 posts

Re: Run More Stuff in Docker

#221

Post by u801e »

rhn_mk1 wrote: post #139
hendry wrote: post #30

Just some counter arguments to @jbergknoff's well put together page! Docker is the best medium for distributing - A static file is far easier to share / distribute. Cross-platform - You need an arguably complex and unstable Linux interface to run Docker images, cgroups et al Sandboxed - security claims about Docker have always been controversial. Simple Unix/BSD constructs like chroot/jails are far simpler and they a…

> You need an arguably complex and unstable Linux interface to run Docker images, cgroups et al What is unstable about it? As far as I can tell, only the Linux kernel interface is needed, and keeping that stable is an explicit goal of the kernel.

I believe there was a period of about a year where it wasn't possible to run Docker on Fedora 31 or higher because the former did not support the cgroups v2 interface.

Re: Run More Stuff in Docker

#222

Post by antoinealb »

eptcyka wrote: post #176
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…

This requires you to give your normal user the ability to execute stuff via docker. This means that given the ability to execute code as the user, an attacker can trivially gain root access.

I think in this context that's not a real concern, as on most laptop the human user has root equivalent permissions anyway (via sudo). In addition, Docker supports user namespaces, allowing you to have root in container being mapped to a non root user.

Re: Run More Stuff in Docker

#223

Post by Frost1x »

cobbzilla wrote: post #191
d3nj4l wrote: post #179

Earlier quoted context omitted.

You could have other, self-hosted services there. That's my setup: I have self hosted trilium and used to self host matrix. The personal nginx served website was just a cherry on top of the cake.

> I have self hosted trilium and used to self host matrix. Wait, you’re self hosting multiple apps on one system, and not using K8?!? Your apps can’t autoscale or do blue/green upgrades or any of the cool stuff you are now mandated to do by the cargo cult. How do you sleep at night?? /s

>or any of the cool stuff you are now mandated to do by the cargo cult.

This is ultimately what drives me insane about the tech sector: so many choices are trend based and cult like when any sort of technical discipline shouldn't be.

Re: Run More Stuff in Docker

#224

Post by bayindirh »

pavlus wrote: post #215

TLDR: 1. You already have that on Linux. 2. Make your builds portable. If you are running mainstream Linux(Debian-based/Arch-based, probably other), most of the Docker profits can be achieved with already installed and configured systemd and your distro's package manager. Sandboxed? systemd. Simple, uniform interface? Your distro has packages, and most likely services that can and should be sandboxed already run in s…

I want to add another point to this TL;DR: 3. Do your research before writing these blog posts.

I don't want to put down anyone for writing these blog posts. The idea is nice from a distance, but the reality doesn't work like that.

It's shoehorning something not suitable for this situation. There's singularity which runs on non-root environments, however it's not for desktop systems, but multi-tenant clusters.

I really get frustrated when people advocate expensive abstractions for minimal gains. We can use our processing power much more efficiently while keeping almost the same properties without the costly abstractions.

Piling everything on top of each other to create impenetrable and immutable abstractions is not the way to achieve this. Docker already makes debugging very hard by being immutable and impenetrable as is.

Re: Run More Stuff in Docker

#225

Post by tomrod »

pferde wrote: post #194
tomrod wrote: post #104

Earlier quoted context omitted.

Basic steps. Welcome to the long September of Docker. Whereas most folks who use it regularly know basic maintenance patterns, new users (myself included) must wade through inscrutable documentation or (worse) poorly written blogfarm posts in order to bootstrap up to a level of proficiency that passes interview smell tests.

Do you have any documentation (or blogs) on a higher level that you would recommend? I too have been using Docker for a while, and recently also for certain programs on my desktop (mainly firefox, github cli, azure cli, aws cli, terraform). I like to think I am somewhat proficient in using Docker correctly by now, but I am still discovering new tidbits of practical knowledge, tips and good practices every few weeks.…

I do not. I'm a new user who has found resource identification difficult.

Re: Run More Stuff in Docker

#226

Post by [deleted] »

pavlus wrote: post #215

TLDR: 1. You already have that on Linux. 2. Make your builds portable. If you are running mainstream Linux(Debian-based/Arch-based, probably other), most of the Docker profits can be achieved with already installed and configured systemd and your distro's package manager. Sandboxed? systemd. Simple, uniform interface? Your distro has packages, and most likely services that can and should be sandboxed already run in s…

[deleted]

Re: Run More Stuff in Docker

#227

Post by AnIdiotOnTheNet »

oefrha wrote: post #211
m463 wrote: post #154

Earlier quoted context omitted.

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

Except Mac apps don’t each ship a libSystem.

Because unlike Linux they don't have to, since MacOS actually defines the concept of a stable base system that can be targeted by applications. Docker exists in part because the Linux world has no such concept.

Re: Run More Stuff in Docker

#228

Post by AnIdiotOnTheNet »

jillesvangurp wrote: post #186
hendry wrote: post #30

Just some counter arguments to @jbergknoff's well put together page! Docker is the best medium for distributing - A static file is far easier to share / distribute. Cross-platform - You need an arguably complex and unstable Linux interface to run Docker images, cgroups et al Sandboxed - security claims about Docker have always been controversial. Simple Unix/BSD constructs like chroot/jails are far simpler and they a…

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.

Re: Run More Stuff in Docker

#229

Post by bayindirh »

cmckn wrote: post #188
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?

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…

> 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 and almost LAN-speed access to rest of the world. My office workstation's network is limited by my network card but, my home has a much slower connection.

I wish that internet on this planet to be a full-fat-tree network but, we're not there yet.

Re: Run More Stuff in Docker

#230

Post by djhworld »

tomcam wrote: post #83
johnsoft wrote: post #43

I appreciate the sentiment, but I wouldn't be able to put up with the slow container boot time for regular use. The author mentions this at the bottom. He claims 1sec delay. Last month I benchmarked it on new-ish hardware at 560ms, or 290ms if you disable namespaces (and so disable isolation). I wanted to also benchmark bocker[1] (docker written in bash) for a baseline comparison, but it no longer runs and I threw in…

> curl | jq | grep | less OK I didn’t know about this. Does each one of the piped commands cause the creation of a new container? And why?

Assuming you've bound an alias to these commands to run them individually, each in their own container
Post reply on HN