[tomgruner]

Docker is a container for running processes, or a process. Containers should be disposable and transient. I have begun to think of it in terms similar to OOP. Images are your Classes. Containers are your class Instances. When you are done with an instance, you discard it and make a new instance. So don't go shoving all kinds of crap into the instance like crons and sshd that don't belong there. Most devs don't expect to have their code be free of memory leaks when it comes to interpreted languages. And docker containers don't need to worry about child processes being stopped - they should just be disposed of and you make a new container from your image. Keeping containers around would be like trying to pickle a python class instance perpetually that has references to who knows what... Just make a new instance when you need it. And just make a new container when you need one. I use named containers and a Makefile that stops and deletes existing containers with the same name before starting a new one.

[FooBarWidget]

To me, that does not make any sense. Your program executable is already like a Class. A normal process is already like instances of your classes. If all you want is OOP, then why are you using Docker? Your Unix system has been doing that for 30+ years!

[tomgruner]

The benefits of me that docker brings is the ability to share containers with my team and to deploy those same containers to the server. The reason that I started thinking of it in terms of programming, like OOP, was to help me get my head around how to correctly use docker on a server. As I start to understand docker, finding the correct place for configuration, data, crons, debugging, and execution are all important and the closest paradigm that I can easily apply to it is OOP, even though it is not a perfect match. OOP can also help visualize how one image can inherit from another image and override both methods and configuration of that image so that instances will behave in a different manner.