> I don't think your base image misses the point of Docker. Different people use Docker for different purposes, that is normal and a fundamental goal of Docker.
Far be it from me to tell you how you should run your own project, but it seems to me that if Docker is going to live up to the shipping container metaphor, then it needs to be at least somewhat opinionated. In particular, you've previously explained that Docker is supposed to provide a standard way of separating concerns between development and operations. If this is going to work in practice, then it seems to me that there needs to be agreement on conventions like:
* Logs go to stdout/stderr, not to the container filesystem or even a volume.
* Configuration settings are provided on container startup through environment variables.
* Related to the above, occasional configuration changes are made by starting a new container with new variables, not by editing a config file inside the existing container.
* The container's main process needs to cleanly shut down the main service in response to SIGTERM.
* No SSH in the container, unless the container is providing an SSH-based service, e.g. a gitolite container.
So if I'm right about what the conventions are or should be, then Puhsion's base image is indeed misguided.
Apart from the SSH thing, Baseimage-docker very much complies to those conventions.
- In Baseimage-docker, Runit is configured to have all services log to stdout/stderr. In Passenger-docker, the Nginx error logs are redirected to stdout/stderr. We actively encourage services to log to stdout/stderr.
- Baseimage-docker provides easy mechanisms for allowing multiple processes to access the environment variables that were passed to the container.
- Baseimage-docker's custom init process was designed precisely to allow graceful termination through SIGTERM. It even terminates all processes in the container upon receiving SIGTERM.
Baseimage-docker does not mean that the Docker conventions are thrown out of the door.
Far be it from me to tell you how you should run your own project, but it seems to me that if Docker is going to live up to the shipping container metaphor, then it needs to be at least somewhat opinionated. In particular, you've previously explained that Docker is supposed to provide a standard way of separating concerns between development and operations. If this is going to work in practice, then it seems to me that there needs to be agreement on conventions like:
* Logs go to stdout/stderr, not to the container filesystem or even a volume.
* Configuration settings are provided on container startup through environment variables.
* Related to the above, occasional configuration changes are made by starting a new container with new variables, not by editing a config file inside the existing container.
* The container's main process needs to cleanly shut down the main service in response to SIGTERM.
* No SSH in the container, unless the container is providing an SSH-based service, e.g. a gitolite container.
So if I'm right about what the conventions are or should be, then Puhsion's base image is indeed misguided.