feat(docker): wrote dev and prod Dockerfiles #195
Conversation
|
hey @lowercasename @wlonk this is still a WIP, i wanna see if i can get the MongoDB portion done and figure out how the app currently consumes MongoDB connection params (looks like they're in a config file now?) |
|
|
||
| docker/ | ||
| scripts/ | ||
|
|
| tap "homebrew/core" | ||
| tap "homebrew/services" | ||
| brew "mongodb-community" | ||
| cask "docker" |
There was a problem hiding this comment.
Does this need to be in here? Seems OS X dev specific; I'm not strongly opposed to it, but I would love to talk it through a bit.
There was a problem hiding this comment.
it's absolutely OS X specific; i had meant it as a convenience for developers on Macs
There was a problem hiding this comment.
Docker is absolutely not my strong suit - what's the usual way to handle OS-specific convenience packages? Is it good practice to have them? Can there be a check made to see what the host OS is?
| @@ -0,0 +1,24 @@ | |||
| FROM node:14 | |||
There was a problem hiding this comment.
Hah, a delight! All my work Docker images have to fuse Node and Python base images together (we have Good Reasons Actually for serving our static assets from our backend).
There was a problem hiding this comment.
ugggggg that reminds me, would we consider separating static assets into a webpack bundle and pushing them to S3/CloudFront? probably not something we need to do at current scale
There was a problem hiding this comment.
Yeah, that's a Future Problem.
There was a problem hiding this comment.
Definitely a Future Problem, but a solution I'm not opposed to. I think it'll be waiting for the transition away from the model/controller handling so much of the view functionality.
|
the first milestone i'm aiming for is " |
|
Using local yarn as a taskrunner for Docker is interesting! A lot of my motivation for using Docker is to avoid having to run yarn locally, since we have to juggle so many versions. But I think what you're describing is reasonable for this use-case! |
|
yup, i figure that since any developer will have a Node environment locally, using yarn as the generic taskrunner makes sense. |
|
You'd be surprised how many people I know seem militantly opposed to yarn just because it's not npm, mind you. I think yarn here is a good shout. |
|
@lowercasename I suspect that's just conservatism; in my experience, yarn is "npm but better on literally every metric" 🤷 I may also be neophilic! |
|
@hakamadare You said this is a WIP; is there anything I can do to help move it forward from that status to a mergeable proposal? |
```sh
$ docker build \
-t sweet:dev \
-f docker/Dockerfile.dev \
.
$ docker run \
--rm \
-it \
sweet:dev
```
still to do:
* write docker-compose files to provide mongodb
* get mongo connection params from environment
* automatically populate sweetbot user?
* untangle dependencies and devDependencies (prod Dockerfile is broken)
hakamadare
force-pushed
the
hakamadare/docker-compose
branch
from
de9df4d to
a117b5c
Compare
also some rework of configuration to use env vars rather than entire files. still need to fix some references to `config/auth.js`.
$ docker build \ -t sweet:dev \ -f docker/Dockerfile.dev \ . $ docker run \ --rm \ -it \ sweet:devstill to do: