3 ms·

I've only been working with Docker for a couple of months, and I find this discussion really interesting. The goal of trying to get containers to behave more li

by markbnj 13y ago

I've only been working with Docker for a couple of months, and I find this discussion really interesting. The goal of trying to get containers to behave more like a full system across various lifecycle events is somewhat orthogonal to my own aims, which have been to get my containers as close to stateless as I can. Like some other posters here I view containers less as a lightweight VM, and more as a process sandbox. In the context of a scalable architecture I would like a container to represent a single abstract component, which can be spun up (perhaps in response to autoscaling events), grabs its config, connects to the appropriate resources, streams its logs/events out to sinks, reads and writes files from external volumes, and runs until it faults or you shut it down. Ideally there would be nothing inside the container at shutdown that you care about. After shutdown the container, and potentially the instance it was running on, disappear. Spinning up another one is a matter of launching a new container from a reference image. So far, in cases where I have needed daemons running in the container, I have pointed my CMD at a launch script that starts the appropriate services, and then launches the application components, typically using supervisord. That has worked fine, but I admit to not understanding the PID1 issue well-enough up to this point.

FooBarWidget 13y ago
Baseimage-docker does not imply that your container becomes stateful. Using services like cron and SSH do not imply statefulness. I also think that the container should be as stateless as possible. When state is necessary, it can be saved at a bind mounted directory. The point of baseimage-docker is to ensure that the system works correctly. See its description about the role of PID 1. It has got nothing to do with the statefulness discussion.
- markbnj 13y ago
  Agreed, and a fair point. Statefulness is not a consequence of using Baseimage-docker, and I didn't mean to suggest it was. A clearer way to put it is perhaps to say that aiming for a container that is as simple and stateless as possible makes the "problems" outlined in the OP seem less compelling to me. Take the syslog example. If I am starting processes that log to syslog, and I want syslog running because I care about those messages, then I should be taking steps to ship those messages out of the container, otherwise I am creating state that has to be preserved across system lifecycle events to be of any use. If I am pursuing a stateless container then I will not be blindly running things that create state without deciding how to handle it. Along those lines if you are pursuing this kind of design you want to have a good handle on everything that's running, and what state it produces. I don't know everything that's running and producing output in a full Linux installation. I'm sure I could figure it out, but it seems to me that Docker's minimalistic approach makes it easier to draw lines around this stuff. The OP implied that you could design what looks like a solid container and that it might yet be broken in ways that aren't obvious. I'm very eager to know if that's really the case, as I am considering deploying some production components using the tool. So far the system services argument doesn't seem very compelling to me. I haven't run into any issues launching services from scripts at container start. Examples would be logstash, redis, supervisord, etc. It could be very convenient to have an image already configured with a proper init system, but I am not sure that it is fixing anything that is broken. I don't have enough experience to get deeply into the PID1 issue. All I can say is that I haven't run into any problems . I can't say, for example, whether everything is shutting down cleanly in all cases, but the way I build my containers I don't care that much. Unless I go back in for specific diagnostic reasons a container only gets started once.
  - FooBarWidget 13y ago
    Correct, fully agreed with what you said about syslog. But that's not the problem that baseimage-docker is trying to solve. Suppose that you're building a Docker container, and something fails. Nothing on stdout and stderr. You decide to look in /var/log/syslog, but nothing there too. You scratch your head. If only you knew that /var/log/syslog only works if the syslog daemon is running. That sort of thing is what baseimage-docker solves. Whether you want to ship logs outside the container, that's up to you. Right now I am building a web app in a Docker container. The web app is written in Rails, hosted by Nginx and Phusion Passenger. To make setup as easy as possible for users, the container also contains PostgreSQL. I run Nginx+Passenger and PostgreSQL at the same time by hooking them both on runit. The init system in baseimage-docker ensures that a 'docker stop' properly shuts down both Nginx and PostgreSQL.

by markbnj 13y ago

FooBarWidget 13y ago

Baseimage-docker does not imply that your container becomes stateful. Using services like cron and SSH do not imply statefulness. I also think that the container should be as stateless as possible. When state is necessary, it can be saved at a bind mounted directory. The point of baseimage-docker is to ensure that the system works correctly. See its description about the role of PID 1. It has got nothing to do with the statefulness discussion.

markbnj 13y ago
Agreed, and a fair point. Statefulness is not a consequence of using Baseimage-docker, and I didn't mean to suggest it was. A clearer way to put it is perhaps to say that aiming for a container that is as simple and stateless as possible makes the "problems" outlined in the OP seem less compelling to me. Take the syslog example. If I am starting processes that log to syslog, and I want syslog running because I care about those messages, then I should be taking steps to ship those messages out of the container, otherwise I am creating state that has to be preserved across system lifecycle events to be of any use. If I am pursuing a stateless container then I will not be blindly running things that create state without deciding how to handle it. Along those lines if you are pursuing this kind of design you want to have a good handle on everything that's running, and what state it produces. I don't know everything that's running and producing output in a full Linux installation. I'm sure I could figure it out, but it seems to me that Docker's minimalistic approach makes it easier to draw lines around this stuff. The OP implied that you could design what looks like a solid container and that it might yet be broken in ways that aren't obvious. I'm very eager to know if that's really the case, as I am considering deploying some production components using the tool. So far the system services argument doesn't seem very compelling to me. I haven't run into any issues launching services from scripts at container start. Examples would be logstash, redis, supervisord, etc. It could be very convenient to have an image already configured with a proper init system, but I am not sure that it is fixing anything that is broken. I don't have enough experience to get deeply into the PID1 issue. All I can say is that I haven't run into any problems . I can't say, for example, whether everything is shutting down cleanly in all cases, but the way I build my containers I don't care that much. Unless I go back in for specific diagnostic reasons a container only gets started once.
- FooBarWidget 13y ago
  Correct, fully agreed with what you said about syslog. But that's not the problem that baseimage-docker is trying to solve. Suppose that you're building a Docker container, and something fails. Nothing on stdout and stderr. You decide to look in /var/log/syslog, but nothing there too. You scratch your head. If only you knew that /var/log/syslog only works if the syslog daemon is running. That sort of thing is what baseimage-docker solves. Whether you want to ship logs outside the container, that's up to you. Right now I am building a web app in a Docker container. The web app is written in Rails, hosted by Nginx and Phusion Passenger. To make setup as easy as possible for users, the container also contains PostgreSQL. I run Nginx+Passenger and PostgreSQL at the same time by hooking them both on runit. The init system in baseimage-docker ensures that a 'docker stop' properly shuts down both Nginx and PostgreSQL.