2022-06-16
2282
#docker#node
Geshan Manandhar
32033
Jun 16, 2022 ⋅ 8 min read

Node.js and Docker: Improve DX with Docker Compose

Geshan Manandhar Geshan is a seasoned software engineer with more than a decade of software engineering experience. He has a keen interest in REST architecture, microservices, and cloud computing. He also blogs at geshan.com.np.

Recent posts:

Automate Repetitive Tasks With The Pinion Code Generator

Automate repetitive tasks with the Pinion code generator

Discover how the Pinion code generator automates repetitive tasks and boosts productivity compared to tools like Yeoman, Plop, and Hygen.

Joseph Mawa
May 21, 2024 ⋅ 7 min read
Exploring Hurl An Alternative To Postman

Exploring Hurl, a command line alternative to Postman

Hurl is an excellent Postman alternative that improves the DX of working with APIs through the command line.

Nwani Victory
May 20, 2024 ⋅ 8 min read
How To Integrate WunderGraph With Your Frontend Application

How to integrate WunderGraph with your frontend application

Unify and simplify APIs using WunderGraph to integrate REST, GraphQL, and databases in a single endpoint.

Boemo Mmopelwa
May 17, 2024 ⋅ 5 min read
Understanding The Latest Webkit Features In Safari 17.4

Understanding the latest Webkit features in Safari 17.4

The Safari 17.4 update brought in many modern features and bug fixes. Explore the major development-specific updates you should be aware of.

Rahul Chhodde
May 16, 2024 ⋅ 10 min read
View all posts

13 Replies to "Node.js and Docker: Improve DX with Docker Compose"

  1. Nice article, thanks! One question: in the development stage of the Docker file, you copy the sources to /src in the image. But in the compose file with the dev target, you mount the current directory (.) to that same location as a volume. Are both really necessary? Isn’t it enough to do the volume mount, for the dev stage?

  2. Thanks for the good article!
    What’s the difference between `CMD [“nodemon”, “bin/www”]` for dev target inside Dockerfile and `command: npm run start:dev` inside docker-compose.yml? Will it override the one from dockerfile? And what’s the reason to specify both then?

  3. @Tom thanks for the comment. They are essentially the same thing. There are 2 advantages of doing it, first one is when the files are changed they are synced inside the container too without the need to build it. Another one is if some NPM dependencies are installed on the host machine (not the container) they will also be synced into the container. I hope this clarifies your query!

  4. Seems like a reasonable, detailed post. There’s one main thing that is missing that caused me to skip most of the content – *why* do I want to move to a dockerized dev environment? What are the benefits from your perspective? How has it improved, or what has it enabled in your development workflow? What are the drawbacks?

  5. Hey @Dale, great question. Below are the benefits from my point of view:

    1. Let’s say there is Node 16 out, in a new branch you could test you node app changing literally 1 line. Build and docker-compose up you can see the changes.
    2. You don’t even need to install node locally on your machine if you want.
    3. You may use a mac/windows but the app is deployed on a Linux server, if you use docker the same(ish) container goes to prod so the binaries and other things will work as expected

    Some more reasons: https://geshan.com.np/blog/2018/10/why-use-docker-3-reasons-from-a-development-perspective/

    It has improved a lot in the past years. It helps have a better streamlined workflow as you ship not only the code but essentially the whole stack with each deployment.

    Drawbacks — I don’t see much for the good things it provides but the need to build and the time it takes to build the container might be one. On mac the file sync becomes a bit slow at times and yes it adds a bit more complexity to do things like doing line by line debugging which is one time setup. But, these should be tradeoff one should take for the portability and flexibility docker on dev provides. Thats my point of view, thanks!

  6. Great article, thanks!
    Just one question: what about the restart policy in production, in case of crash? Since you use nodemon only for development, how do you restart the app in production? Do you suggest using something like nodemon or pm2 in production or relying on the container restart policy?

  7. @Francessco, thanks for the comment.

    About restart of container on prod, there are two ways to deal with it IMO. First one let the container orchestrator like Kubernetes handle it. If a pod is down which is less than desired K8s will spin up a new one. Or you can even try something like PM2 – https://pm2.keymetrics.io/docs/usage/quick-start/ to get the job done. Analyze both and use the one that fits your need and use case. For a general node app I would go for Kubernetes to take care of it.

  8. Do we still need a dockerignore if we explicitly copy required directories and exclude nodemodules and .git file

  9. Depends on what you want to do, if there is a docker ignore you don’t need to remember to do it. Lets say if you want to exclude your env files or logs from getting into docker it would be easier to add them to docker ignore than excluded them in the docker file. Hope it helps!

  10. Whats your perfered way of updating the image when new node dependencies are installed locally?

  11. Thanks for this great resource, it will help us a lot.
    I see in docker-composer you are setting NODE_ENV=development, but it was already done in build phase declared Dockerfile. Is there any reason to not use the one from Dockerfile or vice versa ?

Leave a Reply