7 ms·

TL;DR It's too damn complicated if you're not Google/Twitter/Netflix. Most people would be fine just deploying OS packages and keeping their stacks as simple as

by zaargy 11y ago

TL;DR It's too damn complicated if you're not Google/Twitter/Netflix. Most people would be fine just deploying OS packages and keeping their stacks as simple as possible.

shepardrtc 11y ago
Yes, exactly. I really can't recommend that my company use this right now because of the complexity. The Hello World image is easy, but after that, there's quite a bit involved. And my company is already happy enough with spinning up VMs.
huskyr 11y ago
I have a feeling this is not just a problem with Docker. People tend to choose technologies not because they solve their problem, but because it's hip to be using the newest stuff, even if it's far too big and complicated for their simple usecase.
- mseri 11y ago
  In this regard I think the remarks of McKinley's "Choose Boring Technology" [1,2] is quite relevant. [1]: http://mcfunley.com/choose-boring-technology-slides http://mcfunley.com/choose-boring-technology-slides [2]: http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology
  - therealmarv 11y ago
    Big thanks for this links. Actually this is really true for Docker and DevOps. There are proven concepts and known unknown but for Docker the unknown unknown part is really scary especially regarding security for production. Maybe for bigger companies this is no problem but for small dev teams this is very risky and time consuming. Just one non trivial example: I can secure Ubuntu against sshd attacks pretty good and easy with `sudo apt-get install fail2ban`. Now try to secure CoreOS against sshd attacks. There are guys out there who tried to run fail2ban in a container (without luck) and so far I've only found one hacky script which tries to do the same oO https://github.com/ianblenke/coreos-vagrant-kitchen-sink/blob/master/tested/blackhole.cloud-init https://github.com/ianblenke/coreos-vagrant-kitchen-sink/blo...
    - jayfk 11y ago
      CoreOS is not docker. You can run docker on ubuntu and install fail2ban on it. I don't see the problem here.
zaargy 11y ago
I still love Docker and do think it solves a genuine problem. But yes, where to put your logs, how to manage state, how to schedule containers on machines, how to coordinate processes, how to inspect an app when something goes wrong, how to measure performance, how to manage security, how to keep consistency across your docker containers... are all problems you need to solve from the get go with Docker and they are all non-trivial! Ain't nobody got time for that.
- joslin01 11y ago
  I'm not sure how much you know about docker, so to anyone in whom this list scares: > Where to put logs Well, I just throw them aside and use `docker logs [container]` > How to manage state One container should perform one service. I haven't run into a problem here. > How to schedule containers ECS :) But honestly, I subscribe to the approach that containers = services and thus should just always be running. > How to inspect app `docker exec -it [ container id ] bash` ("ssh" into container) `docker logs` `docker -f logs` (follow logs) > How to measure performance Probably same way you measure system performance > How to manage security Everything of mine is in a VPN; some services can talk to certain services over certain ports... Personally, I don't really understand all this talk about security. Protect your systems and that should protect your containers. Why is it that isolated processes are causing people to throw up their arms like security is an unimaginable in such a world? There are ways.. > Consistency across docker containers This can be a pain if you need this, yea. They see to be adding better & better support to allow containers to talk to one another (and ONLY to one another). > Ain't nobody got time for that. Hmm, personally I don't have time to go thru what Puppet, Chef, and even Ansible require to get your systems coordinated. I see this as far more work than creating a system specification within a file and finding a way to run it on some system. All comes down to requirements though and where your technical stack currently is at. To any newcomers who are also plowing into the uncertain fields of a dockerized stack, fear not! You are in good company and if I can make it work, you can too.
  - ploxiln 11y ago
    The problem(s) with "docker logs" is that, without getting logs out of docker you can't see multiple containers' logs interleaved, and without a separate logrotate setup they're not rotated (the files in /var/lib/docker/containers/ grow indefinitely).
LoSboccacc 11y ago
Same here. AMI with direct from git updates when they start. Docker as part of the build and deploy process of upgrades is gonna be too costly anyway, because setting up the first configuration takes time, moving the containers take time etc.
d23 11y ago
That's what you got from the article? I got the opposite. It works fine until you start to have large, complex images where build time becomes a factor and the fundamental design of Docker starts to get in the way (e.g. how it manages diffing of images, the lack of caching, and the inability to build different parts of the image in parallel). These shouldn't be as big of a deal at smaller scale. That's not to say you're wrong; containers probably aren't that useful to most small shops. But that summary doesn't make any sense for this article.
- dlandis 11y ago
  A number of issues discussed in the article would be factors regardless of the scale: --logging, secrets, edgy kernel features, security Also, see https://titanous.com/posts/docker-insecurity https://titanous.com/posts/docker-insecurity
phunkystuff 11y ago
Is it too complicated because people already have complicated set ups? or just in general?
patsplat 11y ago
More accurate TL;DR: Docker and containerized architectures generally would be improved by solving this list of problems.

by zaargy 11y ago

TL;DR It's too damn complicated if you're not Google/Twitter/Netflix. Most people would be fine just deploying OS packages and keeping their stacks as simple as possible.

shepardrtc 11y ago

Yes, exactly. I really can't recommend that my company use this right now because of the complexity. The Hello World image is easy, but after that, there's quite a bit involved. And my company is already happy enough with spinning up VMs.

huskyr 11y ago

I have a feeling this is not just a problem with Docker. People tend to choose technologies not because they solve their problem, but because it's hip to be using the newest stuff, even if it's far too big and complicated for their simple usecase.

mseri 11y ago
In this regard I think the remarks of McKinley's "Choose Boring Technology" [1,2] is quite relevant. [1]: http://mcfunley.com/choose-boring-technology-slides http://mcfunley.com/choose-boring-technology-slides [2]: http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology
- therealmarv 11y ago
  Big thanks for this links. Actually this is really true for Docker and DevOps. There are proven concepts and known unknown but for Docker the unknown unknown part is really scary especially regarding security for production. Maybe for bigger companies this is no problem but for small dev teams this is very risky and time consuming. Just one non trivial example: I can secure Ubuntu against sshd attacks pretty good and easy with `sudo apt-get install fail2ban`. Now try to secure CoreOS against sshd attacks. There are guys out there who tried to run fail2ban in a container (without luck) and so far I've only found one hacky script which tries to do the same oO https://github.com/ianblenke/coreos-vagrant-kitchen-sink/blob/master/tested/blackhole.cloud-init https://github.com/ianblenke/coreos-vagrant-kitchen-sink/blo...
  - jayfk 11y ago
    CoreOS is not docker. You can run docker on ubuntu and install fail2ban on it. I don't see the problem here.

zaargy 11y ago

I still love Docker and do think it solves a genuine problem. But yes, where to put your logs, how to manage state, how to schedule containers on machines, how to coordinate processes, how to inspect an app when something goes wrong, how to measure performance, how to manage security, how to keep consistency across your docker containers... are all problems you need to solve from the get go with Docker and they are all non-trivial! Ain't nobody got time for that.

joslin01 11y ago
I'm not sure how much you know about docker, so to anyone in whom this list scares: > Where to put logs Well, I just throw them aside and use `docker logs [container]` > How to manage state One container should perform one service. I haven't run into a problem here. > How to schedule containers ECS :) But honestly, I subscribe to the approach that containers = services and thus should just always be running. > How to inspect app `docker exec -it [ container id ] bash` ("ssh" into container) `docker logs` `docker -f logs` (follow logs) > How to measure performance Probably same way you measure system performance > How to manage security Everything of mine is in a VPN; some services can talk to certain services over certain ports... Personally, I don't really understand all this talk about security. Protect your systems and that should protect your containers. Why is it that isolated processes are causing people to throw up their arms like security is an unimaginable in such a world? There are ways.. > Consistency across docker containers This can be a pain if you need this, yea. They see to be adding better & better support to allow containers to talk to one another (and ONLY to one another). > Ain't nobody got time for that. Hmm, personally I don't have time to go thru what Puppet, Chef, and even Ansible require to get your systems coordinated. I see this as far more work than creating a system specification within a file and finding a way to run it on some system. All comes down to requirements though and where your technical stack currently is at. To any newcomers who are also plowing into the uncertain fields of a dockerized stack, fear not! You are in good company and if I can make it work, you can too.
- ploxiln 11y ago
  The problem(s) with "docker logs" is that, without getting logs out of docker you can't see multiple containers' logs interleaved, and without a separate logrotate setup they're not rotated (the files in /var/lib/docker/containers/ grow indefinitely).

LoSboccacc 11y ago

Same here. AMI with direct from git updates when they start. Docker as part of the build and deploy process of upgrades is gonna be too costly anyway, because setting up the first configuration takes time, moving the containers take time etc.

d23 11y ago

That's what you got from the article? I got the opposite. It works fine until you start to have large, complex images where build time becomes a factor and the fundamental design of Docker starts to get in the way (e.g. how it manages diffing of images, the lack of caching, and the inability to build different parts of the image in parallel). These shouldn't be as big of a deal at smaller scale. That's not to say you're wrong; containers probably aren't that useful to most small shops. But that summary doesn't make any sense for this article.

dlandis 11y ago
A number of issues discussed in the article would be factors regardless of the scale: --logging, secrets, edgy kernel features, security Also, see https://titanous.com/posts/docker-insecurity https://titanous.com/posts/docker-insecurity

phunkystuff 11y ago

Is it too complicated because people already have complicated set ups? or just in general?

patsplat 11y ago

More accurate TL;DR: Docker and containerized architectures generally would be improved by solving this list of problems.