I think "1 container = 1 process" is a common misconception. There should be a separation of concerns, but there's no reason to go to extremes where it doesn't make sense.
When docker first arrived, people were confused about how to use it. I remember seeing lots of people putting an ssh daemon in their containers!?! I like the s6-overlay approach, it's pragmatic.
I haven't been using containers as much lately, but I wonder if s6-overlay's approach could be used to justify including a database into the container with an application. Is that a good idea?
> I haven't been using containers as much lately, but I wonder if s6-overlay's approach could be used to justify including a database into the container with an application. Is that a good idea?
The answer is as always: it depends. My rule of thumb here would be: would it ever make sense to configure the application to use a different (or even just remote) database? If so, then the database should have a separate container (when using a local db). This applies most of the time.
Similarly, if the database itself is an integral part of the application which it doesn't make sense to swap out or have remote... then by all means just include it and tell the user to mount their data volume to /data or whatever. Example: A single-system file indexer.
> would it ever make sense to configure the application to use a different (or even just remote) database?
Emh, don’t we always end up like this? As in, the database stays up while restarting the app; The DB is restarted when upgrading versions; and when we start 10 front-end nodes while keeping one DB only. All if this because they have different lifecycles: DB data is permanent, webserver data is ephemeral.
>would it ever make sense to configure the application to use a different (or even just remote) database? If so, then the database should have a separate container (when using a local db).
This can probably be further simplified to "does it run over ports? then probably yes". E.g. you'd separate your application and database, but not your database and its filesystem.
I'm not sure I fully understand, but with my assumptions in hand:
That's bit of an implementation detail, I think.
If my app is the most amazing file system indexer using PostgreSQL behind the scenes, I don't think the "port" distinction is relevant... oh, wait. You're thinking of ports as in INET vs. plain sockets?
That took me a long time to get. A very technical way to put it, but thank you.
S6-overlay people lay it out pretty neat https://github.com/just-containers/s6-overlay#the-docker-way