Lessons from Building Node Apps in Docker
jdlm.info
jdlm.info
In fact, I'm going to make a very heretical suggestion and say, don't even start writing app code until you know exactly how your whole SDLC, deployment workflow, architecture, etc will work in production. Figure out all that crap right at the start. You'll have a lot of extra considerations you didn't think of before, like container and app security scanning, artifact repository, source of truth for deployment versions, quality gates, different pipelines for dev and prod, orchestration system, deployment strategy, release process, secrets management, backup, access control, network requirements, service accounts, monitoring, etc.
The reason to map all that out up front is to "shift left". If you do these things one at a time, you lose more time later as you slowly implement each piece, refactoring as you go. Whereas if you know everything you're going to have to do, you have much better estimates of work. It's like doing sprint grooming but much farther ahead. Figure out potential problems sooner and it saves your butt down the road. (You can still change everything as you go, but your estimates will be wayyyy closer to reality, and you'll need less rework)
A weird comparison would be trying to build wooden furniture without planning out how you were gonna build it. You can get it done, but you have no idea if it'll take a weekend or two months. Plan it out and you can get more done in one shot, and the quality even improves. This is also the principle behind mise en place.
And even if you are planning to write desktop only software or an app for mobile, think in advance how do you want to package and release it, sign the code, provide help, branding customisation, etc.
Agile is an anti-pattern of SDLC as the lie "improve as you go" doesn't apply to release planning
Say you did your code architecture, and you've been writing code for 3 months. The security architect comes by and takes a look at your work, and announces that your design is inherently flawed; you need to fix some token-passing thing that's tied deeply into your app to support some system they have to audit company apps. You end up doing rework for a sprint or 2 to fix it. This in particular may not apply to you, but there are hundreds of examples like this.
https://github.com/insightfulsystems/alpine-node
...and use those as the base for most of my stuff in order to have a bit more control over what goes in the images:
Not trying to be flippant here - I am genuinely still trying to get my head around docker’s popularity, it’s just so awkward in so many cases...
But it has its uses. For instance, putting all your services in a private network and only expose port 80 and 443. Images gives your reproducibility even when your build system is not. The image validated is the one deployed. Disencentive hand editing in prod ...
Basically nothing you can not do you yourself. It just simplify (and potentially accelerate) some deployment processes.
Treating Docker containers as artifacts--as Configurable, Better Tarballs--by itself is a significant improvement for much of the non-JVM world, and even does have some benefits for the JVM world as well.
Trying to do local dev in it is silly, IMO, but there's real value to shipping Docker containers to wherever you want to actually run the thing.
No you cannot, at least not for stuff that ships nodejs extensions to be compiled (e.g. by node-gyp). So for example if you're working on OS X and then run stuff in the Docker container you may hit errors. Additionally, if you are running e.g. on Ubuntu 18.04 and compile there and then run npm in a docker container on Ubuntu 16.04, you may hit library mismatches.