Docker-Compose Example 01
Last updated
Last updated
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.
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.
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.
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.
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.
Npm scripts are specific to your project, but for the reference, those are mine.
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.
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.
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.