Hacker News Reader

Comment by orf | Hacker News Reader

I agree with most of the points here, but some stuff is misleading. For example the "you have to rebuild after everything that code change" is ridiculous. Just use "COPY SRC/ /app" In your dockerfile, and in dev mount SRC/ as a volume over /app. There, hot reloading sorted for development.

Don't get me wrong, docker is one of the most frustrating technologies I've used (partly because it shows such promise), but a lot of the problems he describes can be sorted with the most cursory Google.

View on HN

> I agree with most of the points here, but some stuff is misleading. For example the "you have to rebuild after everything that code change" is ridiculous. Just use "COPY SRC/ /app" In your dockerfile, and in dev mount SRC/ as a volume over /app. There, hot reloading sorted for development.

The article _specifically_ refers to production environments, and, by extension, staging servers:

“Good practices dictate that you don’t mount your source code directory in the docker container in production. Which means you also have to rebuild the image on test/staging server every time you make a single line of code change.”

Then it also states in the “logging” section that, contrary to the development environment “On production, since your source code directory isn’t mounted in container […];” so they clearly _are_ mounting the source code in the development containers.

Yes, you have to rebuild your image to deploy a new version. But are you really changing code in production on the fly? This seems dangerous.

Also something that can technically be done with Docker, just it's really not a good idea (and that has nothing to do with Docker).

Oh right, sorry, I thought it was obvious that you have to 'rebuild' the image when a code changes. But if you have a "COPY src/ /app" as the last command in your dockerfile then that's not an expensive operation as all the previous ones are cached.

Unless you change your system packages or add a new line to your requirements.txt, in which case the cache would be invalidated and the build takes longer.

But... it's done by your CI server anyway, so...

Perhaps the article should rephrase it as "it's very complicated to learn how to do it properly, and not obvious when you're doing it wrong".

My experience with Docker is that Google searches often turn up with configurations that other Google searches will say are a bad idea. There don't seem to be any kind of well-documented emergent best practices.

yes, that's pretty much what I meant. Our usage scope has been limited and so has been the time/resources we were willing to invest into researching fixes for things which were obvious for us before.

What do you use to restart the app inside the container when the code changes?

Grandparent is referring to hot reloading, wherein the application itself recognizes changed source files and reloads them on the fly. A common feature of server-side MVC frameworks like Django, Rails, etc.

Because since the source code folder was not mounted on the container, we had to rebuild the image with the updated code and then restart the container. On dev machines, since the source folder is mounted, django runserver's autoreload function works as usual.

I use pm2 with --watch parameter inside the container, the code is mounted, so I can edit outside, but I don't need to restart the app. I do webpack -w locally though to simplify.

Often times I'll just run the container interactively with a shell and start/stop the app manually as if it was running locally while doing development work, almost as if its a super lightweight Vagrant setup.

So, something like docker run -it -v /path/to/source:/app my_image /bin/bash

exactly, I wish he didn't make such a big oversight and do development w/o hot reload!

>> do development w/o hot reload!

We didn't. Please read the relevant sections again carefully.

Reply on news.ycombinator.com