Docker-Compose Example 01

Docker-compose example with Node JS

As a base image, I am using node image that runs under Alpine Linux, a lightweight Linux distribution. I want to expose two ports. EXPOSE is not publishing any ports, it is just a form of a documentation. It is possible to specify ports with Docker Compose later. Port 3000 is the port we use to run our web server, and 9229 is a default port for Node.js Inspector. After we coping package.json and package-lock.json we install dependencies. Coping the rest of files happens later to maximize benefits of docker caching intermediate containers.
1
FROM node:10.15.0-alpine
2
EXPOSE 3000 9229
3
WORKDIR /home/app
4
COPY package.json /home/app/
5
COPY package-lock.json /home/app/
6
RUN npm ci
7
COPY . /home/app
8
RUN npm run build
9
CMD ./scripts/start.sh
Copied!
The executable for the container could be an npm start script, but I prefer to use a shell script instead. It makes it easier to implement more complex steps which might require executing a different command to start the application in a development or production mode. Moreover, it allows for running additional scripts like migrations for your database.
1
#!/bin/sh
2
if [ "$NODE_ENV" == "production" ] ; then
3
npm run start
4
else
5
npm run dev
6
fi
Copied!

Docker Compose

I am splitting my Docker Compose configuration into two files. One is a bare minimum to run the application in production or on the continuous integration server. Namely, no volumes mounting and .env files. The second one is a development-specific configuration.
1
# docker-compose.yml
2
version: "3"
3
services:
4
app:
5
build: .
6
depends_on:
7
- postgres
8
ports:
9
- "3000:3000"
10
- "9229:9229"
11
postgres:
12
image: postgres:11.2-alpine
13
environment:
14
POSTGRES_PASSWORD: postgres
Copied!
During development, I am interested in sharing code between the container and the host file system, but this should not apply to node_modules. Some packages (e.g., argon2) require additional components that need a compilation step. Package compiled on your machine and copied to the container is unlikely to work. That is why you would like to mount extra volume just for node modules.
The other addition to the development configuration of docker compose is using the .env file. It is a convenient way to manage environment variables on your local machine. That said, you should not keep it in the repository. In production, use environment variables instead.
For more information on how to configure Postgres container go to Docker Hub.
1
# docker-compose.override.yml
2
version: "3"
3
services:
4
app:
5
env_file: .env
6
volumes:
7
- .:/home/app/
8
- /home/app/node_modules
Copied!
Docker Compose reads the override file by default unless said otherwise. If you are using Docker Compose on CI then explicitly specify all configuration files that apply.
1
docker-compose -f docker-compose.yml -f docker-compose.ci.yml up
Copied!

Npm Scripts and Node Inspector

Npm scripts are specific to your project, but for the reference, those are mine.
1
{
2
...
3
"scripts": {
4
"dev": "concurrently -k \"npm run build:watch\" \"npm run start:dev\"",
5
"start": "node dist/index.js",
6
"start:dev": "nodemon --inspect=0.0.0.0:9229 dist/index.js",
7
"build": "tsc",
8
"build:watch": "tsc -w"
9
}
10
}
Copied!
I do not call npm scripts directly from the command line. They are a convenient place to encapsulate complexity and simplify start.sh (and later the other scripts).
The important takeaway is that inspector should be bound to host 0.0.0.0 which is a public IP of the container instead of the default localhost. Otherwise, you are not able to access it from your local machine.

.dockerignore

There is a bunch of stuff you can list here and which are not needed to run the application in the container. Instead of trying to list all of them, I distinguish three.
1
.git
2
node_modules
3
dist
Copied!
Ignore node_modules for reasons I have already explained when covering volumes. dist is just the output directory of our build pipeline. You might not have its counterpart in your project when you write in JavaScript/CommonJS and do not need a build step. These are all simple things, but you would better not miss them.

Last modified 2yr ago