7 ms·

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

by 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).
  - juliangregorian 11y ago
    If this is what it takes to get procrastinators onto a real logging stack I'm not sure I see it as a problem.
- TheDong 11y ago
  If this is your advice then you shouldn't give advice. 1) 'docker logs' relies on using the json logdriver which means the log file is stored in /var/lib/docker/..... and grows forever. No rollover. No trimming. FOREVER. 2) What if your container dies? What if your host dies? Do you have any state at all or have you abstracted that out? Are your systems distributed 3) Always running does not answer finding where to run them 4) That only works if the container is running. What if it died? Also, docker logs is a fool's game 5) bingo, that's right at least 6) ....
  - kordless 11y ago
    > If this is your advice then you shouldn't give advice. Stop with the blaming statements.
    - toomuchtodo 11y ago
      Do you have a better way to say "your advice is bad. stop spreading misinformation"?
      - amouat 11y ago
        There's no need to say that at all. Just address the points and let everyone form their own opinions.
        deleted 11y ago
        [deleted]
        toomuchtodo 11y ago
        Because opinions are not the same as facts/best practices (nor is everyone's opinion equal). If you want to argue "this is the right way", be prepared to bring data and defend your statements. People here might be making critical decisions based on knowledge shared here, and they deserve the most accurate information possible.
        11y ago
- zaargy 11y ago
  Well I used Docker on top of Mesos so I have quite a bit of experience and the above were all problems I faced. They're not impossible problems obviously but they take time and thought to solve. From your responses, I am not sure you fully appreciate the problem to be honest. You have to remember that you containers and coming and going all the time, which is one of the biggest challenges. It basically means you have to have everything centralised and that means a lot of additional infrastructure/complexity.
  - joslin01 11y ago
    Wouldn't it be fair to say these are all problems faced with any / all deployments? When are logs never going to be a problem or security or state? I appreciate the problems (honestly!), but when it's presented as docker-specific, I get confused. Yes.. all these things need to be managed.. at the end of the day you're changing your stack from running 5 systems to running 5 processes acting like 5 systems. This is going to take some thought, but I genuinely believe there's a greater reward at the end of the tunnel in this realm than there is the old world of puppet master / slave.
- deleted 11y ago
  [deleted]
exelius 11y ago
As far as logs go, you should just be doing network logging with Docker to either a syslog server or something like LogStash or Splunk. If you are big enough to have a genuine need for containers, you also are big enough for a centralized logging system. At the end of the day, you have to view it as building a reliable system that performs a function. Docker is one tool you can use to do that. Virtual machines are another tool. They don't solve all the problems you describe, nor are they intended to. If you're a tiny startup, you can just go the AWS route, but that leaves you beholden to AWS and their pricing. That's fine early on, but eventually you'll want to go full-stack for one reason or another.
dalyons 11y ago
There's a few projects out now that do most of this for you; there's a lot of rapid innovation in higher-level docker tools. eg https://github.com/remind101/empire https://github.com/remind101/empire (built ontop of EC2/ECS) You get a 12 factor compatible PaaS out of it, pretty easy.
- feld 11y ago
  The funny part is that Docker was supposed to be higher level.
  - dalyons 11y ago
    it is? its one more step up the chain towards the ultimate goal: being able to run M isolated instances of N different apps automatically distributed across Y physical hosts (and being able to deploy app A without caring about any of this) We're almost there.

by zaargy 11y ago

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).
- juliangregorian 11y ago
  If this is what it takes to get procrastinators onto a real logging stack I'm not sure I see it as a problem.
TheDong 11y ago
If this is your advice then you shouldn't give advice. 1) 'docker logs' relies on using the json logdriver which means the log file is stored in /var/lib/docker/..... and grows forever. No rollover. No trimming. FOREVER. 2) What if your container dies? What if your host dies? Do you have any state at all or have you abstracted that out? Are your systems distributed 3) Always running does not answer finding where to run them 4) That only works if the container is running. What if it died? Also, docker logs is a fool's game 5) bingo, that's right at least 6) ....
- kordless 11y ago
  > If this is your advice then you shouldn't give advice. Stop with the blaming statements.
  - toomuchtodo 11y ago
    Do you have a better way to say "your advice is bad. stop spreading misinformation"?
    - amouat 11y ago
      There's no need to say that at all. Just address the points and let everyone form their own opinions.
      - deleted 11y ago
        [deleted]
      - toomuchtodo 11y ago
        Because opinions are not the same as facts/best practices (nor is everyone's opinion equal). If you want to argue "this is the right way", be prepared to bring data and defend your statements. People here might be making critical decisions based on knowledge shared here, and they deserve the most accurate information possible.
        11y ago
zaargy 11y ago
Well I used Docker on top of Mesos so I have quite a bit of experience and the above were all problems I faced. They're not impossible problems obviously but they take time and thought to solve. From your responses, I am not sure you fully appreciate the problem to be honest. You have to remember that you containers and coming and going all the time, which is one of the biggest challenges. It basically means you have to have everything centralised and that means a lot of additional infrastructure/complexity.
- joslin01 11y ago
  Wouldn't it be fair to say these are all problems faced with any / all deployments? When are logs never going to be a problem or security or state? I appreciate the problems (honestly!), but when it's presented as docker-specific, I get confused. Yes.. all these things need to be managed.. at the end of the day you're changing your stack from running 5 systems to running 5 processes acting like 5 systems. This is going to take some thought, but I genuinely believe there's a greater reward at the end of the tunnel in this realm than there is the old world of puppet master / slave.
deleted 11y ago
[deleted]

exelius 11y ago

As far as logs go, you should just be doing network logging with Docker to either a syslog server or something like LogStash or Splunk. If you are big enough to have a genuine need for containers, you also are big enough for a centralized logging system. At the end of the day, you have to view it as building a reliable system that performs a function. Docker is one tool you can use to do that. Virtual machines are another tool. They don't solve all the problems you describe, nor are they intended to. If you're a tiny startup, you can just go the AWS route, but that leaves you beholden to AWS and their pricing. That's fine early on, but eventually you'll want to go full-stack for one reason or another.

dalyons 11y ago

There's a few projects out now that do most of this for you; there's a lot of rapid innovation in higher-level docker tools. eg https://github.com/remind101/empire https://github.com/remind101/empire (built ontop of EC2/ECS) You get a 12 factor compatible PaaS out of it, pretty easy.

feld 11y ago
The funny part is that Docker was supposed to be higher level.
- dalyons 11y ago
  it is? its one more step up the chain towards the ultimate goal: being able to run M isolated instances of N different apps automatically distributed across Y physical hosts (and being able to deploy app A without caring about any of this) We're almost there.