docker: common/dev/debug/prod configurations

[tiborsimko]

Currently, we advertise how to develop Invenio 2.x via Docker in our documentation, using DEV configuration. However, when somebody goes that way, he/she would find that running test suite reports many failures due to HTTP redirection associated with debugging mode. This may be a rather surprising default...

I'd rather propose to strive at the defaults whether the following would hold true:

$ git checkout maint-2.0
$ docker-compose build
$ docker-compose up
$ docker exec -i -t invenio_web_1 python setup.py test

[...]

Ran 977 tests in 701.359s

OK (skipped=6)

(This is the case for Invenio 1.x Docker configurations, for our Flask-* and other projects...)

We could achieve this by reconsidering DEV -> DEBUG -> PROD modes, choosing a conservative default, and extending our configurations progressively for various use case scenarios. For example:

• COMMON profile: create common Docker Compose configuration as docker-compose-common.yml that will be used as a base for everything;
• DEV profile [default]: create docker-compose.yml that will extend COMMON to make Invenio runnable in a DEV friendly mode, without extra debugging and stuff, but mirroring what Travis/Jenkins do; useful for regular CI/kwalitee purposes;
• DEBUG profile: if wanted, create another docker-compose-debug.yml that would extend COMMON/DEV with human-related DEBUG capabilities, with Flask-DebugToolbar/Werkzeug and friends on; either create new profile if needed or just pass appropriate environment variables to the DEV profile to achieve the same;
• PROD profile: create yet another docker-compose-production.yml that will extend COMMON in a way that will be useful for composing production Invenio environments with overlays. (TBD)

WDYT? CC @crepererum @jirikuncar

[lnielsen]

Could be useful to have a full prod setup (haproxy, 2 web nodes, cache, mq, db master, db slave, task node).

[jirikuncar]

Can we just improve our testing suite that checks during setUp that current_app.debug is False and if it's not it warns user and set current_app.debug = False.

[tiborsimko]

@jirikuncar This would indeed take care of separate DEV/DEBUG profiles, so that only one configuration is sufficient. And if we switch defaults to DEV mode, leaving PROD mode aside, then this should do, I think.

[crepererum]

For the link that Tibor mentioned in the issue description: extend does not work with link, see:

• extends – Inherit services from other services docker/compose#1088
• extending containers with links docker/compose#1495

For prod:

• do we really want a full-setup here, because this would involve that we need to extend the mysql and redis base images as well to insure a proper security setup. otherwise, all deployed instances will have the same DB credentials :(
• we might want to use another tool than docker-compose which works better on multi-machine setups, like http://kubernetes.io/ Did anyone test swarm?

For DEBUG=True + tests, this is somehow:

• tune our test system to handle this
• VS
• deactivating the redirection debugger of Flask (my vote goes here)

More votes:

• Dev. setup should run with DEBUG=True, because it is essential when working with new code. I cannot imagine to work without it and check the server logs for every exception.
• I also vote that the dev. setup is quite similar to the production setup, because so devs. can test what happens in that case, which is:
  • no write access to most parts of the file system
  • encrypted connections in most places
  • very limited connections to other hosts
  • verified broker messages ( celery: message signing #3201 )
• at the same time, I do not see any problems making the prod. setup more full-blown. Even on one machine, 8+ containers wouldn't be a problem.

[tiborsimko]

extend does not work with link

Oops!

we might want to use another tool than docker-compose which works better on multi-machine setups, like http://kubernetes.io/ Did anyone test swarm?

Yes, I also see compose configurations as primarily targeted to single-machine systems and developer-friendly or demo-friendly use cases. For real scalable production, with haproxy and whatnot, Swarm may come handy. It plays nicely with CERN OpenStack, @jirikuncar tested it. But when I looked last time at Swarm, only Ubuntu was supported. Hopefully the support for CC7 is either already there or not too far away...

For DEBUG=True + tests, this is somehow: tune our test system to handle this VS deactivating the redirection debugger of Flask (my vote goes here)

Both options would address the issue at hand. FWIW I also like the latter option better; it may be useful to have a possibility to run tests both in debug and non-debug modes. It does not seem to be a very common need to debug redirections, this could be an opt-in switch via DEBUG_TB_INTERCEPT_REDIRECTS and friends.

[jirikuncar]

Dev. setup should run with DEBUG=True

Can we then change default of DEBUG_TB_INTERCEPT_REDIRECTS to False?

[tiborsimko]

@crepererum Please make any changes for maint-2.0, so that we can have the same Docker setup for all our v2.x branches. Developer-oriented changes of this kind can go to past maintenance branches.