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
productiontarget to our Dockerfile and adds the standard Docker scripts to build that target. It also includes ascript/prod_runscript 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-kitandrufus-schedulergems with thewhenevergem, 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_entrypointentrypoint. Populating secrets as part of the main entrypoint allows us to us to run things likekamal app exec bashwithout specifying the--reuseflag to ensure a proper database connection.The
Dockerfilehas 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
whenevergem in the near future.We are installing and configuring msmtp to handle mail requests from cron. The
Dockerfilewas modified to install bothmsmtpandmsmtp-mta(which symlinkssendmailtomsmtp). Also, a~/.msmtprcfile gets created when the application starts so thatmsmtpknow what configuration values to use (SMTP server host, port, from address, etc). We chose to create the~/.msmtprcfile at application start instead of when the Dockerfile is built because that way we can inject the$ENVIRONMENTenvironment variable into the from address.