Container structure simplification and volume management

[YannickB]

Hello all,

Many people spoke to me about the structure data/files/exec of the container, which may not be state of the art of today.

Indeed, Docker introduced some time ago an extensive management for volumes, which can now be independently managed. Before we needed to create what we called "data containers" (here data and files) to ensure we don't lose the volume each time we update the container executing the binary (here exec). I agree we don't need data/files/exec anymore, this confuse people and make the use of external images quite difficult.

For example, for a Odoo10 + Postgres service, I suggest the following structure : Odoo 10 + Postgres

• Postgres
• Odoo 10 -- Odoo 10 SSH (child of Odoo 10 to allow access to customers, container optionnal, the odoo binary is in Odoo10)

This structure means we can deploy child container under a container effectively deployed on the node. This was impossible before, I expect some heavy change in core to make it possible.

Then, I'll start working on simplifying the template, so we only need one container. At the same time, the volume management will be improved so they can be independently managed in clouder, making sure we don't risk losing data.

I am migrating my own infrastructure on the master branch. I want to do this before the migration, then this shall be done in the next days.

cc @lasley @samuellefever

[samuellefever]

Nice !

Envoyé de mon iPhone

Le 15 mars 2017 à 15:17, Yannick Buron [email protected] a écrit :

Hello all,

Many people spoke to me about the structure data/files/exec of the container, which may not be state of the art of today.

Indeed, Docker introduced some time ago an extensive management for volumes, which can now be independently managed. Before we needed to create what we called "data containers" (here data and files) to ensure we don't lose the volume each time we update the container executing the binary (here exec). I agree we don't need data/files/exec anymore, this confuse people and make the use of external images quite difficult.

For example, for a Odoo10 + Postgres service, I suggest the following structure : Odoo 10 + Postgres

Postgres Odoo 10 -- Odoo 10 SSH (child of Odoo 10 to allow access to customers, container optionnal, the odoo binary is in Odoo10) This structure means we can deploy child container under a container effectively deployed on the node. This was impossible before, I expect some heavy change in core to make it possible.

Then, I'll start working on simplifying the template, so we only need one container. At the same time, the volume management will be improved so they can be independently managed in clouder, making sure we don't risk losing data.

I am migrating my own infrastructure on the master branch. I want to this before the migration, then this shall be done in the next days.

cc @lasley @samuellefever

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[lasley]

@YannickB - I don't personally plan on providing SSH access to my customers, but I think we could abstract out the SSH container a bit. What if we add an option for "allow ssh" when deploying a base, or during one click deploy? We could then just use a centralized SSH image for the container.

[lasley]

cc @tedsalmon

[YannickB]

@lasley I mentionned SSH only for example, as said this is completely optional and by default no ssh container will be deployed, but you'll have a button in your Odoo service to deploy it.

Another use case Postfix (with postfix binary) -- Spamassasin (linked to postfix) -- Rsyslog (with shared volume with postfix, so this container can manage the postfix syslog) -- Cron etc... Remember Docker recommand having only one process per container, so rsyslog/cron/other process shall be in side container with volumes shared with the main one.

Or Postgresql -- Phppgadmin (to give web access to customer to his database)

What I suggest is mainly to have one main container with the main process, with the possibilities to manage container children for side purpose.

[lasley]

Ohhhhh cool yeah this is going to be awesome, thanks for the elaboration 👍