Open funkyfuture opened 7 years ago
stweil
commented
7 years ago The Docker images were created by @UB-Mannheim, the source Dockerfile is available at https://github.com/UB-Mannheim/kitodo-production/tree/docker. Please post issues and pull requests for improvements also at https://github.com/UB-Mannheim/kitodo-production.
stweil
commented
7 years ago The problem is caused by docker-compose and a configuration file docker-compose.yml which does not connect the database to the Tomcat process running Kitodo.
There remains something which could be improved in Kitodo.Production (unrelated to docker): database failures are always possible (for example because the database server was not restarted after an update of the database software). It would be nice to have a user friendly message for this case.
funkyfuture
commented
7 years ago How is this caused by Docker Compose when the configuration file contains the same options to create the containers as documented in the Usage section?
stweil
commented
7 years ago I'm not an expert for docker-compose, but I see that the services don't get the same names when they are startet from docker-compose as they get by a direct start via docker. Instead of web, I get something like docker_web_1, for example.
funkyfuture
commented
7 years ago Docker Compose is just an orchestration wrapper around Docker.
Beside the fact that a container's name must not affect the behaviour of an application running in that container (this should'n also be the case since the database is addressed by ip), setting names excplicitly yields the same error:
version : '2'
services:
web:
image: kitodo/production
container_name: kitodo-production
ports:
- "8001:8080"
links:
- db:mysql
db:
image: kitodo/database
container_name: kitodo-databasemy suspicion is that this is a race condition as the kitodo-production container doesn't wait to start the application until the database is initialized (as observed in the logs).
such delay is usually coded in the application's entrypoint script which as well should take care of necessary schema initialization and migrations, and thus make the kitodo-database image unnecessary and - if supported by the application - allow the usage of various sql-backends.
this may give you an idea, in particular this routine to wait for a database. here's another example that uses the application's language from the official wordpress image.
stweil
commented
7 years ago Maybe Kitodo.Production fails to work if the database is started after Tomcat. As I already wrote above, the user interface is not robust (no user friendly handling of problems with the database). Maybe other parts of the code could also be improved to handle late availability of the database or short outages of the database connection. My experience shows that such improvements are valuable for a stable production environment.
Working around missing robustness of Kitodo.Production in the Docker file is possible. I'll have a look as soon as time permits, but will of course also accept pull requests for the UB Mannheim docker file. There should also be an updated Docker image with Kitodo.Production 2.0.0.
henning-gerhardt
commented
7 years ago This kind of error is related to docker as I can't reproduce this error on a normal server system setting (real and virtual machine servers).
I stopped my local database instance, started a tomcat instance and deployed the application. Browsing to application URI I got displayed loading screen. After one minute I restarted my database and 2 seconds later I got normal login screen of the application.
Even on a running application and database gone away and come back a few minutes later the application runs fine after database is available again. If any database action is done while database is away then errors displayed to users which could be improved.
stweil
commented
7 years ago Error handling can also be improved for the case of a tomcat service restart when a user was connected. That user should be redirected to the login page at least. Ideally there would also be a message like "lost session, please log in again".
matthias-ronge
commented
7 years ago By default, Tomcat will serialize open sessions during shut-down and restore them on start-up. Best solution to the last point would be to put this back to service. Would you create a separate ticket for that? It’s going away from database driver problem.
funkyfuture
commented
5 years ago fyi, for the current 3.0.0-beta.1, i put together a working setup for a deployment w/ Docker-Compose. it's not production-ready, but we use it to provide evaluation instances. you may use this as a base to provide a software package that is easy to deploy.
we want to evaluate Kitodo and therefore i went with a deployment with Docker and the images provided by https://hub.docker.com/r/kitodo
this
docker-compose.ymlis used to start an instance:when opening the webinterface (after the database has been initialised), it takes about 2 minutes until this stack trace is rendered:
it would be great if the source
Dockerfilewas made available in this repository ino order to make investigation and troubleshooting easily accessible.