Docker and NodeJS
Created: 2019-01-21 09:08:39 -0800 Modified: 2019-01-21 09:09:08 -0800
IntroductionSection titled Introduction
pnpm, follow these instructions.
HiDeoo wrote a quick guide for me on this here.
- Since I’m using a monorepo (Lerna), I wanted to avoid copying over hundreds of MB of files to the Docker daemon (which takes forever). The .dockerignore file is supposed to be used for that, but there are some issues (e.g. you can’t do something like “!packages/*/package.json”). So HiDeoo ignores * by default and then only includes the files (via ”!”) that are needed for the build.
- When it comes to using private modules, you have to have your npmrc set up correctly. Unfortunately, “npm adduser” accepts credentials via prompts, not via command-line arguments, so it’s easier to copy a complete .npmrc onto the machine. The way that I did this locally:
- Create .npmrc_for_docker in the root directory that I pass to the “docker build” command. It’s not named “.npmrc” so that it doesn’t get picked up by normal NPM commands automatically and because it needs to be git-ignored. This file should contain any NPMRC configuration like “save-exact=true” and registry/auth information.
- Add .npmrc_for_docker to .gitignore.
- Add “!.npmrc_for_docker” to .dockerignore so that it’s not ignored.
- Modify the Dockerfile to copy .npmrc_for_docker as .npmrc:
- If ever running this from CI, you could omit this step and have CI output the .npmrc from an environment variable since CI should be the thing that has secrets in it, not your repository.
I ran into a huge problem with all of this:
Your lockfile needs to be updated, but yarn was run with
To clarify: “—frozen-lockfile” will install using yarn.lock, but if any updates need to be made, it will error out (as this would indicate that something would be different in the resulting build).
I tried everything that I could think of to fix this:
- I updated the Yarn version inside the container from 1.9.X to 1.12.X. This seemed to have no impact other than adding in integrity hashes, which apparently aren’t necessary (HiDeoo: And they added integrity as a migration path with unsafe-disable-integrity-migration so this shouldn’t error anw except if the integrity is invalid).
- I tried to make sure that my npmrc on the host (Linux) was the same as in the container.
- I wiped out almost everything in Docker in case it was a layer-caching issue.
- Meanwhile, this did work for HiDeoo, so I know there wasn’t a problem with only ever installing the Overseer’s package.json file.
In the end, I never figured out what was causing this issue. This means that the builds in production could be slightly different from the builds in development, which could lead to issues that would be incredibly difficult to track down.
NodeJS gotchasSection titled NodeJS gotchas
Using Yarn or NPM to start your applicationSection titled Using Yarn or NPM to start your application
Suppose you have this in your Dockerfile:
Then, suppose you have this in your package.json
If you start your container and then run htop in the container, you’ll see something like this
I don’t know if there’s any real CPU impact of doing this, but as you can see, Node sticks around in order for Yarn to work in the first place, so you’ll always be using a few tens of MB of RAM.
Debugging with Visual Studio CodeSection titled Debugging with Visual Studio Code
When exposing ports, expose 9229-9231, e.g.:
Add a launch configuration inside VSC: