I'm probably late to the game, but I have just discovered Docker's new (well..) feature, the multi-stage builds. At first, it came handy for building Go binaries, starting with a golang
base image, compiling the project and then continuing with a scratch
image to actually run the binary. Here's how it helped me build the containers for the Discover project. Superb!
But then I started thinking about other cases and suddenly it struct me! Frontend baby! In this article I will go through building a Dockerfile
suitable for holding a Gatsby project. This Dockerfile
will be able to serve a development environment with the help of docker-compose
, but also creating a final image from nginx
ready to go up on your kubernetes cluster (or wherever really).
So, let's get on.
The process
In a frontend project there are usually two distinct processes. The development and the build. Development will spin up a local server, probably with webpack
, some file-watching daemon, etc. The build process will build everything up producing the final artifacts that will go on your server. create-react-app
anyone?
The base in each of these processes is the same. Install Node, fetch npm packages, and so on.
Gatsby in particular, has two commands, gatsby develop
and gatsby build
.
The Dockerfile
Let's start with the base image. Here's a very common Dockerfile
for building a Gatsby project.
FROM node:10 as node
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm ci
COPY . .
EXPOSE 8000
CMD ["gatsby", "build"]
Pretty basic.
Now let's add a docker-compose.yaml
file to help us with local development. You may have one of these already probably serving a local API, so embedding it into your workflow will be easy peasy.
version: "3.4"
services:
website:
container_name: gatsby_website
build:
context: ./
dockerfile: Dockerfile
ports:
- 8000:8000
command: ./node_modules/.bin/gatsby develop -H 0.0.0.0
volumes:
- /usr/src/app/node_modules
- .:/usr/src/app
environment:
- NODE_ENV=development
Notice how we are overriding the command so instead of running gatsby build
inside the container, the gatsby develop
process will kick in instead. Try it by running running docker-compose up
. The local service should start and you will be able to make any changes and watch them go live.
The deployment
But now, we would like to actually build our website and put it inside an nginx
container. That container will then be deployed in a kuberentes
cluster. Let's do some modifications to our files above:
FROM node:10 as node
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm ci
COPY . .
CMD ["gatsby", "build"]
+ FROM nginx as server
+
+ EXPOSE 80
+
+ COPY --from=node /usr/src/app/public /usr/share/nginx/html
version: "3.4"
services:
website:
container_name: gatsby_website
build:
context: ./
dockerfile: Dockerfile
+ target: node
ports:
- 8000:8000
command: ./node_modules/.bin/gatsby develop -H 0.0.0.0
volumes:
- /usr/src/app/node_modules
- .:/usr/src/app
environment:
- NODE_ENV=development
So now I've added a second stage to our Dockerfile
that starts from nginx
and also copies all the artifacts from the previous stage. docker-compose
has also been accommodated to stop at the first stage so it will never reach the second one.
Let's build the image now with Docker
:
> docker build -t gatsby-image .
That's it! Now our Dockerfile
will produce an nginx
container with our final website deployed in. docker-compose
will continue to work as. Brilliant!
Conclusion
And there you go. A single Dockerfile
to use for both development and production in conjunction with docker-compose
. Life just became simpler.
I'm sure more use cases can come out of that. I would love to hear how are you using it! Hit me in the comments below.
Top comments (0)