5 ms·

I love Docker; it's solved a lot of problems for me. But this article highlights the laziness that it can enable: there has to be a middle ground between tradit

by csirac2 11y ago

I love Docker; it's solved a lot of problems for me. But this article highlights the laziness that it can enable: there has to be a middle ground between traditional package management and all of the curation/QA that goes into getting stable releases out to multiple distributions, versus chucking shit over the wall into a git repo with a Dockerfile and calling it done. It's a better, more isolated mess - but for anyone trying to enforce configuration policy into all of the running services in their environment, untangling gortesquely basic shit like not granting superuser privs on a database to your webapps - which would never fly in a traditional distro package - becomes even more work than the old source tarballs with INSTALL.txt.

ownagefool 11y ago
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.
- csirac2 11y ago
  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.
  - ownagefool 11y ago
    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.
jahnu 11y ago
> 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.
- csirac2 11y ago
  > 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.
wpietri 11y ago
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?

by csirac2 11y ago

ownagefool 11y ago

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.

csirac2 11y ago
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.
- ownagefool 11y ago
  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.

jahnu 11y ago

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

csirac2 11y ago
> 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.

wpietri 11y ago

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?