Repository navigation
Build in Dockerfile #283
Description
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.
Reacted by Richard Armstrong, Zoee Silcock, Ainuddin Faizan and Matt Lubner
Activity
mannyhenri commentedon Jun 2, 2018
Will definitely look into this, thanks for sharing.
mattlubner commentedon Jun 2, 2018
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/andnode_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!