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 _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss