search

hapipal / boilerplate

A friendly, proven starting place for your next hapi plugin or deployment
https://hapipal.com
183 stars 27 forks source link

Docker flavor #78

Closed timcosta closed 4 years ago

timcosta commented 5 years ago

Docker based flavor. Generally strategy is noted in both docker.md and server/Dockerfile.

This flavor makes some changes to how env variables are handled for docker best-practices.

timcosta commented 5 years ago 
➜  npm run docker:test:ci

> hapipal-boilerplate@2.3.0 docker:test:ci /Users/timcosta/src/hpal-boilerplate
> docker-compose up test

Recreating hpal-boilerplate_test_1 ... done
Attaching to hpal-boilerplate_test_1
test_1      |
test_1      | > hapipal-boilerplate@2.3.0 lint /app
test_1      | > eslint .
test_1      |
test_1      |
test_1      | > hapipal-boilerplate@2.3.0 test /app
test_1      | > lab -a @hapi/code -L
test_1      |
test_1      |
test_1      |
test_1      |   .
test_1      |
test_1      | 1 tests complete
test_1      | Test duration: 70 ms
test_1      | Assertions count: 1 (verbosity: 1.00)
test_1      | No global variable leaks detected
test_1      | Linting results: No issues
test_1      |
hpal-boilerplate_test_1 exited with code 0
YoannMa commented 5 years ago

Why not keep the .env file, omitting it with .dockerignore and just use docker-compose env_file option ?

IIRC, dotenv does not care if the file exists or not at runtime.

timcosta commented 5 years ago

So, this is one of the decisions I made that I struggled with a decent amount.

In my experience, most local env vars are consistent across users machines, and can be checked into git, which makes them suitable to be put in the docker-compose.yml file.

A .env file in generally only needed when you have true secrets in use locally that users need to fetch from a password manager of some sort, and cannot be checked into git. This IMO is less common, and due to the fact that docker-compose does break if you tell it there's an env file that doesnt exist, I chose to exclude it. That feels like functionality that someone can add later on if they desire.

Either way, I dont think including the dotenv package leads to Docker best practices, because that means you are reading secrets from a file, which may need to be built into your images, which is insecure. Omitting this package and encouraging the use of docker fundamentals is a choice I made to make building insecure apps just a little bit harder.

Definitely open to more discussion, either here or in slack though. It's not something I feel super strongly about either way honestly.

timcosta commented 5 years ago

Conversation around .env and secrets was had in slack, here: https://hapihour.slack.com/archives/CA4J8PBGR/p1565904779105200

Added additional docs, currently no open issues.

wswoodruff commented 4 years ago

Hey @timcosta! Thanks for working on this — do we have enough things figured out to move forward on this PR or are there any things we still need to make decisions on / anything blocking?