Live data from Hacker News

Writing Dockerfiles for Node.js Web Apps

blog.hasura.io

21–30 of 37 posts

Re: Writing Dockerfiles for Node.js Web Apps

#21

When does it make sense to run Node on docker vs Heroku dynos or something similar? Is it just a cost thing at a certain number? Are these significantly specialized containers? The types mentioned in the doc seem like basic web apps. I've used Docker for things like complicated java dev environments. But it seems over-applied for basic web apps.

> But it seems over-applied for basic web apps.

Generally your app will be composed of multiple services (like Java, Node.js, some database etc) and there are benefits to run them as microservices (isolation, easy to develop, easy to scale) and hence Docker makes sense in those use cases. Though the app seems basic and overkill to use Docker, the architecture enforces this and adds the above mentioned benefits.

Re: Writing Dockerfiles for Node.js Web Apps

#23
post #15

Earlier quoted context omitted.

Does Kubernetes support graceful reload of containers, with 0 downtime? I'd be very interested if so.

Yes, it does. Kubernetes can perform rolling updates [1]. One scenario is that when you rollout a new version, the old container will only be killed when new one is up and running. If there are many replicas running, Kubernetes will replace them with new versions one by one. And all of this behaviour is highly configurable. [1] https://kubernetes.io/docs/tutorials/kubernetes-basics/updat...

Thanks! I think for our scenario it's a bit overkill as we're only running one container and pm2 seems a better fit for that.

It would be interesting to know how this works under the hood though, is this just built on top of docker swarm load balancing?

Re: Writing Dockerfiles for Node.js Web Apps

#24
post #22

> root@id:/app# nodemon src/server.js Why is this needed when "CMD [ "nodemon", "server.js" ]" already exists?

CMD will work in detached mode. i.e - "docker run -d". In an interactive mode i.e - "docker run -ti", you can land up with shell access of the container, where you can run commands / perform other tasks as required. In this case, we are running nodemon.

Re: Writing Dockerfiles for Node.js Web Apps

#25

I completely get the purpose and benefit of Docker. More and more though I'm becoming convinced that for many settings and problems Docker actually creates more problems and meaningless ritual because Docker rapidly is becoming the standard way of deploying software with hardly anyone asking about the reasons anymore. Docker recreates many of the benefits the Java platform has had from the start (in addition to some…

I like Docker because it makes it more explicit what dependencies my software has. Most Dockerfiles start with an apt-get update, but I prefer specifying the exact versions of the packages to install. This way I notice changes before they break my stuff.

Re: Writing Dockerfiles for Node.js Web Apps

#26

I completely get the purpose and benefit of Docker. More and more though I'm becoming convinced that for many settings and problems Docker actually creates more problems and meaningless ritual because Docker rapidly is becoming the standard way of deploying software with hardly anyone asking about the reasons anymore. Docker recreates many of the benefits the Java platform has had from the start (in addition to some…

Isn't the selling point more about the dev perspective?

The problem is more about your dev machine being different from your deployment machine.

Not your deployment machines are all different.

Re: Writing Dockerfiles for Node.js Web Apps

#27
post #23

Earlier quoted context omitted.

Yes, it does. Kubernetes can perform rolling updates [1]. One scenario is that when you rollout a new version, the old container will only be killed when new one is up and running. If there are many replicas running, Kubernetes will replace them with new versions one by one. And all of this behaviour is highly configurable. [1] https://kubernetes.io/docs/tutorials/kubernetes-basics/updat...

Thanks! I think for our scenario it's a bit overkill as we're only running one container and pm2 seems a better fit for that. It would be interesting to know how this works under the hood though, is this just built on top of docker swarm load balancing?

Kubernetes will definitely be an overkill if you run only one container. But, if your application follows microservice architecture and have multiple containers, Kubernetes is the best solution to run them.

Kubernetes architecture is entirely different from that of Docker Swarm.

A Kubernetes Service object [1] can load balance traffic to various Kubernetes Pods (think containers) [2] as defined by it's " pod selectors". It can choose to direct traffic only to running containers.

[1] https://kubernetes.io/docs/concepts/services-networking/serv... [2] https://kubernetes.io/docs/concepts/workloads/pods/pod/

Re: Writing Dockerfiles for Node.js Web Apps

#28
post #4

> Using an appropriate base image (carbon for dev, alpine for production). Isn't using the same container everywhere the actual selling point for containers?

Depends on the use-case. For development, you would need to install some system dependencies, access to bash for debugging etc and hence the full blown base image. In production, you want the image sizes to be minimal and hence alpine base image. Also reduces the attack vector.

But why are you doing minute-to-minute development within a container? What's so hard about installing the official Node package for your development system's distribution? When the developer is finished working on a feature, then and only then build a production Docker image from the codebase that now implements that feature, maybe run a few smoke tests, and push to CI. Building special containers for development purposes is sheer madness.

Re: Writing Dockerfiles for Node.js Web Apps

#30

I completely get the purpose and benefit of Docker. More and more though I'm becoming convinced that for many settings and problems Docker actually creates more problems and meaningless ritual because Docker rapidly is becoming the standard way of deploying software with hardly anyone asking about the reasons anymore. Docker recreates many of the benefits the Java platform has had from the start (in addition to some…

> So, with Docker we now indiscriminately add an additional layer of complexity on top of existing applications regardless of the actual problems this might solve.

I agree that it adds an extra layer of complexity but it also provides a lot of things out of the box (like isolation, separation of concerns, platform agnostic deployments, reproducability and lot more) which makes the life of a developer so easy. If he wants to deploy his application, instead of SSHing into the server, installing the dependency, managing the lifecycle of his application. He just needs to dockerize his application and rest assured that it will run irrespective of the platform on which it is put to run as long as it has docker running.

I think what it boils down to is what you expect a tool to do and if it really solves some hard hitting problems you have with your development life and took away your nightmares then it is totally fine to invest in it and chill.

Post reply on HN