Optimized Dockerfile for production

[synhershko]

This PR brings a Dockerfile for creating an optimized container suitable for production, also speeds up the build by proper layering.

How Has This Been Tested?

By running it internally

Types of changes

• [] Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• [] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• [] My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• [] I have added tests to cover my changes.
• All new and existing tests passed.

[epugh]

Thanks @synhershko for this. I want to make sure I understand what is going on! So, by using the FROM command, you first load in the Node code via yarn install, then you do a second FROM, you install node and yarn, but don't do yarn install. Whereas, with the ./bin/setup_docker, we actually call the yarn install separately in that script....

It seems like what we should be publishing to Docker hub is an image based on the Dockerfile.prod, not the current Dockerfile.dev the way I have documented in the wiki at https://github.com/o19s/quepid/wiki/How-to-release-Quepid, specifically at Step 4....

Do you mind providing some steps on how to use this?

[epugh]

Also, not quite sure why PhantomJS has been flaky on your PR's.. I created https://github.com/o19s/quepid/tree/pr/33 and tweaked the .circleci/config.yml and things started working again. Odd...

Also, do you think any of the changes you've made should be in Dockerfile.dev???

[synhershko]

This PR uses Docker's multi-stage build (see https://docs.docker.com/develop/develop-images/multistage-build/), this helps keeps the container from bloating and also helps with CI and layer caching. Specifically, this was done based on the observation that yarn install can be done on container build pretty much like bundle install and no need to call it on first run (as opposed to DB setup tasks). In our deployment, we skip yarn install when we deploy because it's already done in the build stage.

It seems like what we should be publishing to Docker hub is an image based on the Dockerfile.prod, not the current Dockerfile.dev the way I have documented in the wiki at https://github.com/o19s/quepid/wiki/How-to-release-Quepid, specifically at Step 4....

Correct. Just run docker build -t quepid/quepid -f Dockerfile.prod . rest is pretty much the same.

Re PhantomJS - I believe it's only used for testing, I didn't see any usage of it anywhere else. No need for that in a prod container IMO, especially since it's a deprecated and dead project now.

Re Dockerfile.dev - that'd really depend on your dev cycles, I don't have opinion on that :) internally we use same Dockerfile.prod but mount the code from the local folder.

[epugh]

Thanks for the insight on phantomjs, yes we only use it for testing, and I didn't realize it was no longer used. Though changing the circle docker image to circleci/ruby:2.5-node-browsers-legacy now makes that clear!

I am testing out the .prod build. Can you share the remainder of your deployment steps? Do you deploy Quepid locally with a docker-compose set up? Or do you use an existing mysql and just run this image?

[epugh]

https://github.com/o19s/quepid/wiki/Installation-Guide is the partially completed page!

[epugh]

I built off of the .prod and the .dev and saw only a small size difference. Any other ideas on potentially shrinking the prod version?

REPOSITORY                                                    TAG                 IMAGE ID            CREATED             SIZE
quepid/quepid-dev                                             latest              c1f26269543d        34 seconds ago      2.1GB
quepid/quepid-prod                                            latest              05e3df91c410        7 minutes ago       2.33GB

[synhershko]

Can you share the remainder of your deployment steps? Do you deploy Quepid locally with a docker-compose set up? Or do you use an existing mysql and just run this image?

docker-compose with local sql for local work, and deploying onto kubernetes. Both I believe are out of scope for this repo, as long as the container image is working and all env vars are properly documented.

Re image sizes - it's most likely because of the framework install and all the required packages. I wouldn't spend time on this, but likely if you use alpine linux and install ruby and all the necessary requirements you can shave off another 1g from the image.

[epugh]

@synhershko thank you for all the help. I’ve finally put together some “Production” install directions for Quepid: PR #36 is the work, and the associated directions are here: https://github.com/o19s/quepid/wiki/Installation-Guide. I've run through it manually twice now. Let know if you see any issues, and I'd like to merge and release 6.0.3 with the docker-compose deploy based upgrade process soon.

[epugh]

@synhershko thank you for all your help, and getting this job done. I'd love your eyes on https://github.com/o19s/quepid/wiki/Installation-Guide and the related https://github.com/o19s/quepid/wiki/How-to-release-Quepid.

I've just merged #36 which grew off this one, so closing this one now. Thank you!