Docker Configuration Changes

[rydente]

From #118:

Goal:

• Nothing needed by new dev other than git clone then docker-compose up.

Compose configuration:

• Update to compose 3.1 format to support secrets and swarm stacks in prod. (Update Docker to v3.3 #143)
• [ ] Implement secrets in compose (compose file 3.1 format). Looks like we're going Heroku which won't use compose files in prod.
• Remove .env to reduce developer complexity and prevent env var bleeding into unnecessary containers (e.g, node keys in db container). Move those vars to compose file.
• default docker-compose.yml is designed for local dev ease-of-use. Any other overrides can be added in other files for CI or Prod.

Dockerfile/Docker Hub:

• always pin versions in Dockerfile when possible (node stable)
• store node image in code4hr org and keep it up to date with latest node stable (it rebuilds when upstream node repo changes)

Tooling:

• file watcher that's fast at restarting node when needed locally
• remove proxy from being used for local dev. It's only needed for prod and some limited proxy testing by ops on occasion.

(Pulled the following from the Node.js Good Defaults README):

Local Development Features:

• Dev as close to prod as you can. docker-compose builds a local development image that is just like production image except for the below dev-only features needed in image. Goal is to have dev env be as close to test and prod as possible while still giving all the nice tools to make you a happy dev.
• Prevent needing node/npm on host. Installs node_modules outside app root in container so local development won't run into a problem of bind-mounting over it with local source code. This means it will run npm install once on container build and you don't need to run npm on host or on each docker run. It will re-run on build if you change package.json.
• One line startup. Uses docker-compose up for single-line build and run of local development server.
• Edit locally while code runs in container. docker-compose uses proper bind-mounts of host source code into container so you can edit locally while running code in Linux container.
• Use nodemon in container. docker-compose uses nodemon for development for auto-restarting node in container when you change files on host.
• Enable debug from host to container. opens the legacy debug port 5858 and new inspect port 9229 for using host-based debugging like chrome tools or VS Code. Nodemon enables --inspect by default in docker-compose, but you can change to --debug for < 6.3 debugging.
• Provides VSCode debug config. for Visual Studio Code fans, .vscode has a config for both --debug and --inspect node options.
• Small image and quick re-builds. COPY in package.json and run npm install && npm cache clean before COPY in your source code. This saves big on build time and keep container lean.

Production-minded Features:

• Use Docker build-in healthchecks. uses Dockerfile HEALTHCHECK with /healthz route to help Docker know if your container is running properly (example always returns 200, but you get the idea).
• Proper NODE_ENV use. Defaults to NODE_ENV=production in Dockerfile and overrides to development in docker-compose for local dev.
• Don't add dev dependencies into production image. Proper NODE_ENV use means dev dependencies won't be installed in container by default. Using docker-compose will build with them by default.
• Enables proper SIGTERM/SIGINT for graceful exit. Defaults to node index.js rather then npm for allowing graceful shutdown of node. npm doesn't pass SIGTERM/SIGINT properly (you can't ctrl-c when running docker run in foreground). To get node index.js to graceful exit, extra signal-catching code is needed. The Dockerfile and index.js document the options and links to known issues.

[rydente]

Hey @BretFisher, what did you mean by proxy in the second Tooling subtask?

Also, re: secrets, since the PostgreSQL image uses environment variables, we'd likely still have a .env file, so would it make sense to use 6 files (5 Node.js secrets and 1 .env file) instead of the single .env file, even with environment variable bleeding?

I would assume we'd want to switch out the secrets between enviroments (development and production), so we wouldn't want to keep those in version control, right? We'd have them in a .gitignore? How would we have a one-step deployment (docker-compose up only) then? We'd have to have something to have those secrets/files generated, right?

[BretFisher]

For proxy task, since nginx is just performing page caching and ssl reverse proxy, it doesn't add value to local development and may prove tricky with "cache busting" type issues. So we can have the default docker-compose.yml just be two services and an additional "override" compose file that adds proxy for prod :)

[BretFisher]

I've started a branch and PR at #147 for this and started checking off some of the tasks, but how to we seed the db? I assume it's why my node container just exits on start.

[rydente]

I think Trails handles the seeding, but need @wbprice to confirm.

@BretFisher: thank you so much for this.

[wbprice]

@ryayak1460 fixture data is being created by Trails where it doesn't already exist during a bootstrap step.

[BretFisher]

So when I run the develop branch trails will seed db. That never happens in this branch. All that's needed is node index.js right?

[BretFisher]

Yea, even if just on host w/o docker if I just run node index.js this is the output, then it exits. Would be good to improve error handling on node startup so if something is missing (environment var, psql accessible, etc.) it'll properly error before exit.

➜  🐳  okcandidate-platform git:(142-docker-improve) node index.js
Warning: Accessing PropTypes via the main React package is deprecated, and will be removed in  React v16.0. Use the latest available v15.* prop-types package from npm instead. For info on usage, compatibility, migration and more, see https://fb.me/prop-types-docs
(node:17347) [DEP0022] DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead.
➜  🐳  okcandidate-platform git:(142-docker-improve)