This PR adds the production target to our Dockerfile and adds the standard Docker scripts to build that target. It also includes a script/prod_run script that can be used to start a staging or production container locally. This was needed to test the changes to our production Dockerfile, so we include it in this PR.
The default command for the production container is bin/peoplesoft_course_class_data. This mostly works, but I cannot figure out how to get DaemonKit to log properly to STDOUT. I am seeing errors when I stop the container: log writing failed. can't be called from trap context. I suspect this issue has something to do with DaemonKit being a very old dependency and unmaintained. That said, my intention is to replace the existing daemon-kit and rufus-scheduler gems with the whenever gem, so I think we can just ignore this issue for the time being.
Some notable items:
Secrets are populated as part of the script/_prod_entrypoint entrypoint. Populating secrets as part of the main entrypoint allows us to us to run things like kamal app exec bash without specifying the --reuse flag to ensure a proper database connection.
The Dockerfile has been modified to work for both development and production environments. It tags the various stages of the Docker multi-stage build so that they can leveraged using the Docker target option.
Cron was added to the Dockerfile because we will be integrating the whenever gem in the near future.
We are installing and configuring msmtp to handle mail requests from cron. The Dockerfile was modified to install both msmtp and msmtp-mta (which symlinks sendmail to msmtp). Also, a ~/.msmtprc file gets created when the application starts so that msmtp know what configuration values to use (SMTP server host, port, from address, etc). We chose to create the ~/.msmtprc file at application start instead of when the Dockerfile is built because that way we can inject the $ENVIRONMENT environment variable into the from address.
This PR adds the
production
target to our Dockerfile and adds the standard Docker scripts to build that target. It also includes ascript/prod_run
script that can be used to start a staging or production container locally. This was needed to test the changes to our production Dockerfile, so we include it in this PR.The default command for the production container is
bin/peoplesoft_course_class_data
. This mostly works, but I cannot figure out how to get DaemonKit to log properly to STDOUT. I am seeing errors when I stop the container:log writing failed. can't be called from trap context
. I suspect this issue has something to do with DaemonKit being a very old dependency and unmaintained. That said, my intention is to replace the existingdaemon-kit
andrufus-scheduler
gems with thewhenever
gem, so I think we can just ignore this issue for the time being.Some notable items:
Secrets are populated as part of the
script/_prod_entrypoint
entrypoint. Populating secrets as part of the main entrypoint allows us to us to run things likekamal app exec bash
without specifying the--reuse
flag to ensure a proper database connection.The
Dockerfile
has been modified to work for both development and production environments. It tags the various stages of the Docker multi-stage build so that they can leveraged using the Docker target option.Cron was added to the Dockerfile because we will be integrating the
whenever
gem in the near future.We are installing and configuring msmtp to handle mail requests from cron. The
Dockerfile
was modified to install bothmsmtp
andmsmtp-mta
(which symlinkssendmail
tomsmtp
). Also, a~/.msmtprc
file gets created when the application starts so thatmsmtp
know what configuration values to use (SMTP server host, port, from address, etc). We chose to create the~/.msmtprc
file at application start instead of when the Dockerfile is built because that way we can inject the$ENVIRONMENT
environment variable into the from address.