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

Recommendation for Production Redmine install is to use Sidekiq (for Redis) #316

Open
misilot opened this issue Mar 5, 2024 · 5 comments

Comments

@misilot
Copy link

misilot commented Mar 5, 2024

Redmine uses ActiveJob::QueueAdapters::AsyncAdapter as default queue adapter which is not recommended for production environment. Recommended adapter is Sidekiq which uses Redis for persistance. Configuration guide: SidekiqConfiguration.

From: https://www.redmine.org/projects/redmine/wiki/RedmineInstall#Queues-adapter

Can the example docker-compose.yml be updated to include this?

Thanks!

@misilot misilot changed the title Recommendation for Production Redmine install is to use Redis Recommendation for Production Redmine install is to use Sidekiq (for Redis) Mar 5, 2024
@petiepooo
Copy link

I too would like to see this implemented.

Might I suggest documenting an environment variable like REDMINE_QUEUE_REDIS and maybe REDMINE_QUEUE_PORT for setting the hostname and port of a Redis server, and setting the hostname results in docker-entrypoint.sh configuring Sidekiq as Redmine's queue adapter.

@yosifkit
Copy link
Member

Since running sidekiq requires a second process it is not something we'd support running in the same container as redmine's rails server.

We'd be unlikely to add more environment variables for config since the entrypoint script is already complex and fragile. But we are open to documentation improvements and maybe even improvements to the image to allow users to run sidekiq as a second container.

@petiepooo
Copy link

I was reading up more on sidekiq and agree with your point on not running it in the same container. Having the gem be part of the base build could be useful, though, as it would potentially allow running stock images including redis and the sidekiq process in separate containers all as part of a compose stack. Right?

I know people are wanting the ability to schedule tasks and get rid of the non-prod queue warning.. if there was a documented way to do both with the right compose file, that would resolve both asks.

I appreciate the feedback.

@LaurentGoderre
Copy link
Member

You might be able to implement a custom queue like this one:

https://github.com/aws/aws-sdk-rails/blob/main/lib/active_job/queue_adapters/amazon_sqs_adapter.rb

@petiepooo
Copy link

I'm not a good Rails dev, unfortunately. Perhaps someone who is can follow the answer at https://stackoverflow.com/questions/33563161/how-to-put-sidekiq-into-docker-in-a-rails-application better than I. An example compose file containing redmine, redis, sidekiq, and db services, plus a little extra in redmine's image (for docker-entrypoint.sh to setup sidekiq) would be ideal for my use.

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

4 participants