Build in Dockerfile

[shankie-codes]

Is there any reason why that we don't do the build in the Dockerfile so that it gets built on docker-compose build rather than docker-compose up? By being in up, it effectively takes down your server every time you do a code push as there's a considerable wait for it to do the build inside the container. It also means that simple container restarts incur a build, even when you might not have pushed code.

In my project, I have changed the Dockerfile to:

FROM node:7
MAINTAINER jaga santagostino <kandros5591@gmail.com>

RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

COPY package.json /usr/src/app
RUN npm install
COPY . /usr/src/app

ENV NODE_ENV production

# Build it
RUN npm run clean && npm run build && npm run build:server

EXPOSE 8000
CMD ["npm", "run", "start:prod"]

and added an additional volume map to docker-compose.yml to prevent volume-mapping the host's (blank) dist directory over top of what we've just built in the last step.

Regardez:

  volumes:
   - .:/usr/src/app/
   - /usr/src/app/node_modules
   - /usr/src/app/dist

Any reason for this? If not, I can do a PR as I think it's a much nicer workflow.

[mannyhenri]

Will definitely look into this, thanks for sharing.

[mattlubner]

Agreed, this is a common pattern these days and we'll definitely be moving towards it as we make our way through the v3 milestones.

Do be aware though, using persistent Docker volumes to exclude subdirectories from the host's (project's) working directory will have the side effects of slowing the container's startup (after each image rebuild) and resulting in (potentially many) orphaned persistent volumes (of previous versions of dist/ and node_modules/).

I'd recommend the (admittedly more tedious) alternative of explicitly volume-mapping each individual project file and directory. If anyone has a better way, please share!