5 ms·

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

by orf 10y ago

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.

blowski 10y ago
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.
- swap32 10y ago
  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.
gtirloni 10y ago
What do you use to restart the app inside the container when the code changes?
- alfonsodev 10y ago
  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.
- majewsky 10y ago
  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.
- swap32 10y ago
  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.
- vel0city 10y ago
  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
mmarx 10y ago
> 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.
- cpuguy83 10y ago
  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).
- orf 10y ago
  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...
eggie5 10y ago
exactly, I wish he didn't make such a big oversight and do development w/o hot reload!
- swap32 10y ago
  >> do development w/o hot reload! We didn't. Please read the relevant sections again carefully.

by orf 10y ago

blowski 10y ago

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.

swap32 10y ago
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.

gtirloni 10y ago

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

alfonsodev 10y ago
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.
majewsky 10y ago
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.
swap32 10y ago
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.
vel0city 10y ago
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

mmarx 10y ago

> 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.

cpuguy83 10y ago
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).
orf 10y ago
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...

eggie5 10y ago

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

swap32 10y ago
>> do development w/o hot reload! We didn't. Please read the relevant sections again carefully.