Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] All-In-One Docker Image #54

Open
DerLeole opened this issue Feb 15, 2023 · 1 comment
Open

[Feature Request] All-In-One Docker Image #54

DerLeole opened this issue Feb 15, 2023 · 1 comment

Comments

@DerLeole
Copy link

As the main purpose of docker containers is the quick, easy, and scalable deployment of software, having to manage multiple of them for a single app can be tedious when one plans to host multiple wger instances.

Additionally I suspect some of the problems that arise in the docker in regards to data persistence, volumes, and binding local directories can be traced back to permissions errors between the different containers. A singular container allows for tighter controls of these and properly setup with environment variables like "GID" and "UID" would allow for rootless operation, which is an important feature to have.

Finally it would allow for the cleanup of environment variables, as some might not be needed anymore and simplify the nginx setup.

I know this is a tall order and probably a good bit of work, but it would make for much easier deployment, more consistency, and likely fix some errors reported here along the way.

@rolandgeider
Copy link
Member

Hi!

I actually used containers because, specially on windows, the permission problems were a real pain and the volumes are a nice solution to this that works without having to map any user ids and so on. Tha being said, it's probably just a matter of trying a couple of possible setups etc and shouldn't be impossible to fix.

As for putting everything in one container, while it would be still possible to cram everything in there right now, the more services we need the more difficult this becomes. E.g. we're planning on adding a celery task queue for background tasks in the near future. Separating these services on their own image is also a best practice in the docker world (and is the reason why tools like docker compose exist). In the end, it's still the easiest way to deploy a complex application with lots of moving parts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants