Assuming you set it to production mode in the documentation, I think it's mostly fine. As far as I know the following features don't work in the docker setup:

• Redis data is not stored outside of docker, restarting loses all data in redis (caches, unread circles for categories, user settings, and more)
• If AWS is not used, uploaded files are not stored outside of docker (restarting may lose any uploaded files)
• Emails cannot be sent from within the docker container
• Docker container does not automatically run with the latest security updates unless recreated (losing data from above)
• The docker image is not as regularly updated, and is currently configured to use a version of ruby and nodejs which are both EOL.
• The docker configuration does not do any kind of scaling, and is not tuned in any way for performance nor has any configuration options clearly specified for someone to do so. The amount of memory given to redis/rails/mysql is not configured. If you anyways intend your production instance to run default redis, mysql, nginx and rails settings (which are up to an extent designed to scale to what is needed) and you have sufficient server capacity, this need not be a dealbreaker.

Depending on who you ask, they will tell you that kubernetes/dockerized services are the only thing that is worthwhile and a must for large scale deployments, or they will tell you that its unnecessary overhead and that you should go with a self-installed setup. The truth is of course that both have their advantages, and you should choose what you think is best for your use case.

Unfortunately, it seems to be somewhat tricky to set QPixel up for people who are not familiar with development in some way (but who are familar with server deployment). It may be worthwhile to fix the issues with the docker image and specify the caveats with that type of installation, rather than say it is not intended for production.

posted about 1 year ago

CC BY-SA 4.0

1y ago

Taeir‭

341 reputation 0 10 34 4