Closed aghster closed 5 years ago
Thanks for the update :) I had also added the jpeg-dev to the Dockerfile and while I was debugging what was wrong with mongo a healthcheck for that
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:27017"]
interval: 10s
timeout: 2s
retries: 10
in the docker compose. Dont think that this is required, just to let you know.
Hey there,
quite a bunch of stuff. I will try to answer in detail to share my thoughts. Thank you so much for your valuable contributions again, @aghster!
I moved the docker files into their own folder (docker/)
Thanks.
patzilla is installed not from source, but from pypi
This is important as the patzilla distribution package already contains a compiled release of the frontend patzilla-ui, otherwise the user would have to build the frontend using webpack on her workstation. As this would require more steps to perform and maybe additional quirks to resolve, it would not deliver properly on the wash & go experience we are trying to achieve here.
Sidenote: Saying that, there might be another type of Docker container in the future which will give you a complete development sandbox setup. While I recognize Alpine Linux is popular amongst Docker people by optimizing for resource efficiency and image size, I am also looking into the direction of a regular Debian-based Docker container here. As the production system is running on Debian Linux, this would deliver an environment which is closer to each other.
I fixed a missing dependency (jpeg-dev, apparently required by pillow) and added some optional libraries [...] that I considered possibly useful.
Thanks. The missing jpeg-dev
package exactly was the reason of the issue I was running into when trying #5.
patzilla.ini
I added a default patzilla.ini configuration file that is now no longer copied into the container, but linked into the container from outside the container. This allows to modify patzilla.ini without the need to rebuild the entire image afterwards.
volumes: - ./patzilla.ini:/patzilla.ini:ro
Way to go. Thanks again!
Instead, only the container (or even just pserve within the container) must be restarted.
pserve
also accepts the --reload
argument, which will reload the process after the configuration (and in fact any source file) was changed. Usually, while configuration does not change very often when operating an instance of PatZilla, I wanted to mention it here nevertheless.
Furthermore, by providing a default configuration file, executing "docker-compose up -d" should now build a patzilla image and run a container thereof out-of-the-box. (Previously, one had to provide a patzilla.ini file by oneself, which might not have been evident.)
This. Thanks! ;]
Of course, docker/patzilla.ini should still be reviewed and customized (in particular, by adding one's own api keys) before running the patzilla container
Sad but true. To improve the situation, we could start by extending the patzilla make-config
command to accept additional variables to be interpolated into the configuration as template variables. You might recognize the formatting of the values to be customized like {ops_api_consumer_key}
and {ops_api_consumer_secret}
already fits the variable notation syntax of the native new style Python string formatting. Then, the user would just issue another single one-shot command between the docker-compose build process and launching the machinery, like
docker exec-foo /usr/bin/patzilla make-config --ops_api_consumer_key=foo --ops_api_consumer_secret=bar > patzilla.ini
But (judging by a quick test run) the default patzilla.ini now already provides sufficient configuration for patzilla to at least start up.
This is excellent!
With kind regards, Andreas.
Hi,
I have reviewed the old docker files and tried to improve them a bit, particularly so that they now hopefully work out-of-the-box.
The main modifications are:
I hope, this makes it easier to quickly set up a running patzilla docker container.