> the laziness that it can enable

This is the entire value proposition of all successful technology. Dubious business practices notwithstanding, all successful yet imperfect technology is successful because more people found it let them be lazier than the competition. But in reality of course it's not laziness, it's efficiency. They can get on with other tasks sooner than before.

> But in reality of course it's not laziness, it's efficiency. They can get on with other tasks sooner than before.

Indeed, and I use Docker myself to improve my own efficiency, and I've seen great stuff built with Docker that has been architected well.

However, it is painfully obvious that without the pressures that used to force most developers to keep their shit sane, there's now more workload for serious users that actually need to untangle this mess in order to support, secure and get stuff deployed.

Very few of the problems described are actually docker issues besides the security concern which is described here is that you're a) already on the host and b) have permission to start docker containers, which c) allows you to root the host.

The other security issue mentioned, piping curl into sh isn't really that big a deal. As long as you're a) using HTTPS and b) you resonably trust the source you were probably never going to read the script anyways.

Well yes, the fact they chose to require that the webapp have a superuser database account is not docker-specific, but the manner (and it should be said: ease) with which docker is used to neatly package an opaque ball of string creates a trend of ever more difficult-to-untangle software making it way harder than it should be to properly deploy apps conforming to your environment's security, config management standards.

I mean, when I first evaluated this app, it didn't even have a sane launcher script. Instead, ~15 lines of ruby config and a ruby script that I had to follow just to discover it was a weird, idiosyncratic way of executing "docker run".

Edit: I am not saying that Docker is somehow inherently flawed in this respect. It's solved a lot of problems for me and you can build great, well-architected stuff with it. But there is a trend to use it to wallpaper over poor development and deployment practices.

All that stuff could probably be done with apt, yum, dnf or any other package manager though. The reason they're better is because you have some fairly skilled contributors acting as the gatekeeper of the projects.

Now the nice thing about docker is you could have spent about 5 minutes to trivially docker run the app, decide if it's actually worth the effort, then untangle the mess beneath.

That's a net win in my eyes, though by the time I actually run something in production, I generally try and untangle the mess before I do. I also find it's easier to get help developers deliver something legible as sadly many of them often don't even know which packages they installed to get something running.

Listen, I'm not saying it's perfect. I specifically really don't like that Docker is basically root without Selinux (which is often turned off). I'm happy to see docker be replaced. I am however, not really interested in returning to puppet modules to handle dependencies when a container is, in my opinion, so much better.

Could you say more about this? I agree the app described is a mess. If a database is a shared resource, I think it's important for a single app not to have massive privileges in the database. But if the database is also containerized, then I'd rather the app just have its own isolated database. So it seems to me that problem is that the app has been only partly containerized, not fully. Would that approach solve your concerns just as well?