Dockerize civic-server #704
Conversation
adding entrypoint to initialize DB when necessary
…o 13.5 to match app expectations TODO - remove db exposed port
…re generic to support civic_dev.. db as well
Continue dockerize
fix to ensure the server is really listening
change to production config to get it working again
| #run background tasks syncronously | ||
| config.active_job.queue_adapter = :inline | ||
|
|
||
| # Specifies the header that your server uses for sending files. | ||
| # config.action_dispatch.x_sendfile_header = "X-Sendfile" # for apache | ||
| # config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect' # for nginx | ||
|
|
||
| # Force all access to the app over SSL, use Strict-Transport-Security, and use secure cookies. | ||
| config.force_ssl = true | ||
| #config.force_ssl = true |
There was a problem hiding this comment.
this was needed because our deployment is behind reverse proxy
| @@ -36,12 +36,15 @@ | |||
|
|
|||
| # `config.assets.precompile` has moved to config/initializers/assets.rb | |||
|
|
|||
| #run background tasks syncronously | |||
| config.active_job.queue_adapter = :inline | |||
There was a problem hiding this comment.
for some reason, if this is not set, the deployment returns HTTP 500 for any api call...not sure why.
There was a problem hiding this comment.
Maybe @acoffman can comment on this?
There was a problem hiding this comment.
This is likely due to the default production background jobs queue requiring redis in production. Setting it to inline will cause any background tasks (delivering notifications, analytics, generating data dumps, etc) to trigger during the request/response cycle rather than being queued for later processing.
For a smaller installation, that's probably fine, but if you notice performance issues, that could be a culprit.
docker-entrypoint.sh
Outdated
|
|
||
| echo "Migrating civic database" | ||
| # migrate: | ||
| rake db:migrate |
There was a problem hiding this comment.
Since you're initializing the database from scratch here, and not running migrations in the case of an update anyways, you could just run rake db:structure:load here which will load in the schema in its entirety at once rather than stepping through each migration.
There was a problem hiding this comment.
This looks good to me overall. There are a couple things (like an explicit puma configuration) that you might find you need to tweak as you see what the usage looks like in your deployment, but this is a great start. Happy to merge as is, and feel free to follow up with us if you run into any issues with your deployment.
Thanks, @acoffman ! |
|
Awesome! Thanks @ruslan-forostianov and @acoffman ! 👍 |
Please see #701