Dockering a nodejs application with external dependencies

Question

We are building Node.js microservices. For some reusable components we have created a utils folder. This folder is outside the actual microservices package. When we run the microservices, we can refer to that code using require(../../utils/logger) and it works like a charm. However when trying to create the docker image for my microservices

project the container gives me an error saying:
Error: Cannot find module '../../Utils/logger

which makes a lot of sense as we are building the docker image inside the microservice project. There are few architectural decisions which needs to be taken here:

1. We move the utils code into each microservice as required.

   • Pro: Microservice remains self sustained completely and no code level dependency on any other package.
   • Cons: Maintenance of cross cutting concerns and the changes would be cumbersome.

2.Create a private npm module and inject dependency into the microservice package.json file. Not sure if that would work.

Any suggestions on this are highly appreciated.

Best, - Vaibhav

Answer 1

Don't use require(../../utils/logger), use npm packages

You should avoid using same files for microservice with symlink or requiring from one folder, because it destroys Loose coupling.

Loose coupling is a design goal that seeks to reduce the inter-dependencies between components of a system with the goal of reducing the risk that changes in one component will require changes in any other component. Loose coupling is a much more generic concept intended to increase the flexibility of a system, make it more maintainable, and makes the entire framework more "stable".

Simply put, you can't have different version of your logger file, but you can have different version of your logger npm package.

Implementation details for using npm modules as reusable components for Node.js microservices:

1. Chose naming convention for packages. My advice is scoped packages. Example: @vaibhav/logger

2. Chose npm registry. There are such options:

   • 2.1. npmjs.com and public packages. It's free, but your packages should have only universal code without any business-valuable details.
   • 2.2 npmjs.com with private packages. It's fast, but not free.
   • 2.3 verdaccio your own npm registry server. It's free simple Node.js solution, which should be install as server in your infrastructure.
   • 2.4 nexus. Universal private registry with npm and docker support.

3. If you use 2.3 or 2.4 solution, then you need to choose ip or link for your server. My advice is use link. Example https://your-registry.com

4. If you use 2.3 or 2.4 solution, the you need to chose install approach in your .npmrc file inside your microservice. There are two options:
   • install all required packages from your registry. The .npmrc file will looks like registry=https://your-registry.com. Your registry should be able to cache public packages.
   • install only your package from your registry, install other packages from public registry. The .npmrc file will looks like @vaibhav:registry=https://mycustomregistry.example.org
5. Define processes for package development, publishing and updating the package version in microservice package-lock.json file. In our projects we define processes in this way:
   • We use GitHub flow for package development. There are only master branch for publishing and feature branches for development. Master branch can be updated only with pull requests from developers or commits from CI server.
   • We use Jenkins as continues integration server for autoupdating version and publish after merging pull request. Jenkins runs npm version command for update version, then publishes new commit to master branch and then publishes to npm registry. Jenkins checks some our rules and use npm version with patch or minor param. Updating major version is breaking change, which we do manualy.
   • We don't have 100% automated process for updating the package version in microservices. We automate only opening pull requests with new package version in package-lock.json file. Developers should check build status and press merge button manually.

Answer 2

Its not part of your question to elaborate how to deal with shared libraries in Microservice-Ecosystems and what to avoid there, but if you like, you should read this up to get you at least a list for pros and cons of "sharing".

Beside that, you can create a library container which only offers this library to be mounted.

version: "2"

services:
  shared:
    image: me/mysharelib
  m1:
    volume_from:
      - shared:ro
  m2:
    volume_from:
      - shared:ro

while your mysharedlib image looks more or less like this

FROM busybox

COPY bin/busyscript.sh /usr/local/bin/busyscript

WORKDIR /your/lib/folder
VOLUME /your/lib/folder

CMD ["busyscript"]

and your busyscript is just a dummy like this

#!/bin/sh
#set -x

pid=0

# SIGTERM-handler
term_handler() {
  if [ $pid -ne 0 ]; then
    kill -SIGTERM "$pid"
    wait "$pid"
  fi
  exit 143; # 128 + 15 -- SIGTERM
}

# setup handlers
# on callback, kill the last background process, which is `tail -f /dev/null` and execute the specified handler
trap 'kill ${!}; term_handler' SIGTERM

echo "Started DW php code"
# wait forever
while true
do
  tail -f /dev/null & wait ${!}
done

As you see, m1/m2 ... m10 mount the library which and it is truly shared across all microservices.

Alternatives: You can for sure use an private NPM packages or simply package the shared lib into the microservice m1..m10 during image build time.

What describe above especially suits you well when you want to replace the shared library in the stack with very little overhead and want to ensure the library is in-sync for all container instancs