[Discuss] node.js and npm on Debian?

[Rich Braun]

Dan Ritter expresses doubts about containers:
> And transfers those headaches to your security and ops teams.

My earlier message wasn't about deployment, where security and operations are
concerned, but about setting up a Docker dev environment on a laptop or
desktop where one might once have used the VirtualBox tool.

As an example, he suggests:
> [Suppose] There's a new RCE vulnerability against node-sprintf
> version 1.1.0. Where is it running? Is it safe to keep running
> your containers until the weekend, or do you need to replace
> some today?

Well OK let's go through this thought experiment: at home I have five
computers. Two of them are running ancient copies of OpenSuSE, each of which
has an assortment of VirtualBox-based VMs running Windows and various other
distros of Linux. Three of them are running latest/greatest Ubuntu 16.04.3
LTS, with latest/greatest Docker 17.12.0-ce; with few exceptions (due to
hardware-attached devices), the 3-node swarm is kept identical by use of
Ansible playbooks. There are about three dozen different services that I run
on the Docker systems, and only a handful of lingering antiquated things that
I haven't yet migrated off the SuSE boxes.

Which of these setups is easier for me, i.e. a staff of 0.05 of one full-time
equivalent, to keep running?

Continuing with:
> You've got a display inconsistency in floating point
> representation. Which of your deployed containers has it? What
> libraries were they using? If it's a one-line fix, can you
> insert the patched library on every container or do you need to
> rebuild every container?

What I do is build each service with the minimum possible set of dependencies.
Most are built by me (the list is growing at:
github.com/instantlinux/docker-tools) to ensure fewest dependencies but I use
other people's stock containers if they adhere to my minimalist philosophy and
are kept current.

The base image that I start with is Alpine 3.7 for most containers. So if
there's a flawed library in those, I just grep my Dockerfiles for "alpine:3.7"
and rebuild those. If there's a flawed dependency that sits above the distro,
then I might have more digging to do--but in general my dependencies are
explicitly identified and I can track them down more quickly.

Once I identify what needs relaunching, I fire off rebuilds (in my case,
they're built simultaneously by Jenkins locally and by Docker's free
automated-build service; at work the equivalents are Jenkins and CodeShip) and
then run a makefile to relaunch the needed containers.

Can I do the same with my old OpenSuSE boxes, or the VMs sitting on top of
them? Ugh, it's really hard to update any of that stuff. It's all manual.

> Your QA team tested version 10.4.2, but node:latest is pulling
> in 10.4.2a since some point after your got it tested but before
> you deployed. Does your deployment process guarantee the version
> number that you tested is the version you deployed?

Yes, all my own deployments (look at my github repo's Dockerfiles) make the
best effort to version-pin every dependency that matters. But for the
try-out-npm query that triggered my posting, I was going for the shortest and
simplest command. So I'll amend my recommendation:

 docker run -d --name nodejs node:8.9.4-stretch sleep 7d

> All of those problems are solved by configuration management and
> deployment systems, and containers at best obfuscate them.

We disagree, fundamentally I think. Few other mechanisms I've tried provide
the ability to audit & track deployments that containerization does. If you
click the links to the microbadger site from the README files in my github
repo, you can see exactly what's in the containers that I publish. The same
cannot be said of the contents of the VMs or even the base installations of
the OpenSuSE boxes that I last reinstalled circa 2012, even with the tools
that I've tried on those (puppet, chef, ansible).

But we digress. This thread was: what's the easiest way to get npm running on
a debian box? You can develop a Node.JS app within docker and then deploy it
with something other than docker. If Kent were asking how to deploy it, there
are many ways to accomplish that these days, only a couple of which involve
containers (though I suspect that 5 years from now, containers will be the
primary mechanism underlying most deployment tools).

-rich