When dockerizing a web+sidekiq app, should the sidekiq process be in a separate container or should the container just run `bundle exec foreman start` to start both the web and sidekiq processes?
#sidekiq #docker

@postmodern For production we use separate containers to allow worker and web processes to scale separately.

@postmodern typically the app will have a single image, but you’ll start multiple instances so you can scale web and worker processes separately.

@postmodern separate container

@postmodern I would be curious if the Ruby Cloud Native buildpack + a Procfile and the pack CLI just works ™️ for you.

https://github.com/heroku/buildpacks-ruby#use-herokuruby-cnb-locally-with-pack

It doesn’t support running container data stores but will give you an image you can reuse for your app.

@solnic @postmodern +1 to separate container for a #SideKiq worker(s)

@esparta @solnic should I get fancy and make separate Dockerfiles for each container with a common base Dockerfile they inherit from?

@postmodern for dev, I have been putting sidekiq in the same container as the rails app via Procfile. Can’t speak to prod but 2 jobs ago they used same Docker image for rails and sidekiq and set a different entry point when starting the container

@davetron5000 my desire is for this app to be ran locally to provide a local single-user web interface, and I do want to appeal to people who prefer to run everything under Docker. I also suspect someone will eventually want to deploy it to their cloud.

@postmodern then I’d say all in one container would probably be simplest. You could even call it Procfile.local to reinforce its not for production workloads but fine for local work

@postmodern @esparta nah docker-compose.yml is your friend

@postmodern Make a single image that can be run either way - this way you can change the CMD to runforeman` for ease in hosting, or run web/sidekiq in different containers if you need the scale/flexibility.