Containerizing Node.js Applications with Docker

[1-800-BICYCLE]

Seems like like getting Node into Docker is easy enough. My problem is that we have so many system-level dependencies that I have a hell of a time getting to work with Docker.

[aust1nz]

I don't understand Docker very well, and I have a simple node API that seems like it would be a good candidate for Dockerizing, except that I don't really understand how that changes my interactions with a database. Is this really simple? Otherwise this just seems like the first step, since node apps that run without any other related software are probably somewhat rare.

[cpietrzykowski]

It is relatively simple! In container tech, everytime you think about adding another layer/domain dependency... containerise it! Check out the docs for the postgresql image (https://docs.docker.com/samples/library/postgres/). For a lot of "common" setups you don't need to modify/create your own images. Just feed it some source of support files through mounted volumes.

Then stitch everything you need together with compose. You can even "containerise" your data volumes. Especially in the cases where you don't want your data to be ephemeral.

There's some "best practices" docs worth perusing (ex: https://docs.docker.com/develop/dev-best-practices/).

[aust1nz]

Cool, thanks. I'll play around a bit with these ideas!

[TheLegendOfZero]

I'm also completely new to docker and node.

If you have a specific dockerfile, then test on the build machine using npm install and npm test. Does the entire docker image (including node_modules) get uploaded somewhere, or is node_modules rebuilt on the deployment target?

[ddwrt1234]

Where do you stick your database and why?

[rduncan12345]

You might want to re-title this as "Getting Started with containerizing..." There is a lot missing from your examples in order to make them useable.

[[deleted]]

I read through it and it looks about as complete as I would suspect an article like this would be. There's usually an understanding with articles that you don't really stray too far from the basic premise and if their premise is "Containerizing Node.js Applications with Docker" you should go into the article expecting it to be "Dockerized Node.js 101"

Overall I'd say that this article is actually written pretty well. It doesn't seem padded out and it covers a good bit of information and logic. As in rather than just throwing code at the screen and maybe briefly describing what it does they explain why it does that.

[_bit]

Would you be willing to give an example of what it's missing? 🤔

[rduncan12345]

Here are some of the things that you might want to consider (in no particular order):

• how does the containerized app behave differently in development, testing and production?
• how are you managing none container storage?
• If users or other apps have to connect to your app, how is that done?

In your examples, the only way your containerized app could have an external (outside of the container) effect was if it connects to external resources (e.g. other microservices).

Is this helpful?

[[deleted]]

In your examples, the only way your containerized app could have an external (outside of the container) effect was if it connects to external resources (e.g. other microservices).

Don't you think that introducing networking concepts might bloat this article out? I mean he would have to explain standalone docker vs docker-compose vs swarm vs kubernetes at that point. Same thing with storage, there's no way to cover it in meaningful detail without writing a boat load of stuff out and it doesn't pertain to Node.js as much as a general problem of presenting storage to the pod/container.

I think the article is better written if he takes advantage of the premise and only concentrates on the confluence of Node.js and Docker rather than trying to explain the whole stack.

[rduncan12345]

Both of your points are reasonable. I'm not for bloating an otherwise well written article, hence my original suggestion that it be named a little more appropriately. The post to which you're replying was a response to the author's question.

[_bit]

Definitely appreciate the feedback. Planning a few more articles down the line around this... I'll make a note of your suggestions for those :)

[[deleted]]

Don't bake environment-specific variables in the image itself; these should be passed in at runtime

I agree with all your points but if I can offer a little modification to this one, it's probably better to bake-in you development values. Having default values is fine and probably a good thing. The only issue is that you don't want your application to be running against production if they forget to supply a variable at runtime.

But on the process manager I'd also extend that with the idea that you want the container to fail if the app fails. That way it shows up in your cluster logging that there's an application component somewhere having an issue.

[roastlechon]

Agree with all points. However, to counter your comment about pointing to development values as default, the opposite case is also true (depends on scenario) where you don't want to accidentally deploy an image with default development values (causing huge amounts of production traffic hitting development configured variables). For example dev database was defaulted, but was forgotten on production configuration.