Proposal :: Avoide Docker Pitfalls

[blaggacao]

Help avoid docker pitfalls by posting interesting resources to comon docker ceavats in order to improve the base image quality.

I'll do a start:
PID1 and Zombie Processes
Syslogging
cron vs systemd - actually scheduling should be shifted out of the main app-container and performed by ephemeral worker-containers against the persitence layer see aso problems of systemd within docker
SIGTEM handling at the example of a postgresql container for gracefull shutdown.. I doubt odoo does atomic operations...

[sle-odoo]

Hi Blaggacao,
Thanks for your interest.

PID1 and Zombie Processes:
This kind of issue occurs when we don't wait our child processes (roughly) and that's not something we do. Process oriented code is using the subprocess library, specifically the call or communicate methods, which are waiting. So i'll say it is unlikely that you end up having zombie processes if you are only using our addons.
However, Odoo has its own reapping layer when you run it in worker mode (by using the workers key on /etc/odoo/openerp-server.conf). It is always advised to turn on the worker mode, this way you'll be able to set limits, etc.

Syslogging:
Do you want to send the logs to a containerized syslog server? If it's the case, i don't think it's something complicated: i suppose you could configure the Odoo logging and link it to the containerized syslog to achieve that. It's just a matter of configuration.

Cron vs systemd:
Please elaborate, i'm not sure i see the point. If you want to start an Odoo instance that will only run the crons, it's also a matter of configuration and not Docker related.

Shutdown of the postgres container/process:
If it is about the Odoo reaction against an "abrupt" Postgresql quit, it is not docker related.

Regards

[blaggacao]

Hi Simon
thanks for your detailed reply, I aimed at making this a collection of useful resources for the odoo-docker-community.

Disclaimer: I might not always used the correct terms, as I'm relatively new to most of the glossary. Give me hints, please and try to be fault tolerant.

@ PID1 : iirc this aplies when only a docker process running, in distributed environments, one might want additionally an agent running (eg. consul agent) together with the docker or a templating service (eg consul-template) or just ntp. In the default deployment I think you would always have some very tiny helper daemons that are tied to the docker (while other tied to the node as well). Its intersting to know that odoo manages it's own stuff (thanks for the pointers), but one layer beyond, we hit this problem again.

@ Syslog: I'm just thinking loud about possibilities to solve this kind of problem. A containerized syslog per node is certainly an appealing solution. We just have to be aware that some logs (eg. kernels) could be silently swallowed else. Of course odoo logging would be tied there to, however iirc systemd (as by know dominant design) comes with an integrated jurnalling solution. I would have to dig further into it to make statements about the journald architecture and implementation.

@ Cron vs systemd: As systemd is gaining ground, and provides timer for services. I wonder if odoo is dependend on an external timing tool (eg. cron daemon) or if this is entirely managed by the cron worker. On an ideal container environemnt, I would run regular commands on ephemeral containers (docker run --rm) out of the same codebase (contanier image) that are not exposed in any way on the network and run against the same persistence layer (files, db and eventually sessions), the question is: who triggers those ephemeral containers? on the host node it could be systemd without problem and would be probaly the tool of choice do to its dominant design characteristics, it also plays well with fleet and others... [1]

@ SIGTERM: It was just an example to illustrate dockers SIG behaviours... The question is of course, how does odoo (or better PID1) react to the signal send by docker stop and if the reaction is appropriate.

[1] this touches the question where all kind of preforking should be done. I argue in line with 12 factor apps, that the containerized app itself should scale over the process model. like this the time trigger becomes responsibility of the distributed scheduler. (As well as managing worker container according to load). I'd love to hear your opinion if you see benefits in a containerized setup to make happen multiprocessing on the application layer. (iirc we can specify the cpu sets used by a docker run to make this a selsible option)

Addendum to [1]:
I really am trying hard to figure out what an wsgi server would add in this setup. I understand that wsgi can provide a better (optimized and generic) server to the app and interface with the reverse proxy for load balancing. As far as I understand wsgi reduces the odoo stack to what I probably want it to be: app source code, that can be run and provide functionality as a service to an interface (iirc it's socket in case of using wsgi server, right?) - Can you comment?

[sle-odoo]

Hi,
So my comments, not ordered:

• The code we use for our cron and for our reactions to signals is in openerp/service.
• I'm not against adding a reap layer if there is a concrete usecase. You're pointing out consul-agent but at first sight the wise decision would be to derive from the docker consul-agent image.
• About the syslog option, maybe we should have documentation or blog post or something with some nice things do do with this Docker image. I'll keep that in mind.

So i'm sorry but i'll have to close this ticket. I know it's not the first of yours, sorry about that, but i would like to keep this place clean to quickly react to real issues*. Once again, this bugtracker is not the right place for this kind of discussion/questions, try one of our mailing list.

It looks like you're interested in Odoo deployment, you should have a look at our deploying documentation if not already done and maybe propose some pull requests to complete it?

Regards

*Like when wkhtmltopdf changed its download url, we learnt it here (sure, we now have automated test to avoid this kind of stuff).

[blaggacao]

the problem is: the mailing list is neither, or less. Because of the high background noise. We lack of a real solution to keep discussion focused and effective. I'm sory for ranting, but this is not satisfying...
-> discourse tool

Other than that I agree with you.

We'll keep contributing to the deplying doc in mind.. this seems like a good thing to do.