Hacker News Reader

Comment by jsnk | Hacker News Reader

"Mount your code, but don’t forget to restart your services in between changes"

This is the part I find unacceptable for a development environment. Is there a way to have live-reloading of docker instance somehow?

View on HN

If you're running something that doesn't do live code reloading, it won't work without restarting whether or not you're running it in a container. If you're running something that does do live code reloading, it should work just the same inside a container, assuming you have the volumes mounted.

I just want to add that your Docker "containers" are just processes on the host, and don't actually exist outside of the containerized process' lifetime. Your container is not a VM. So restarting a container to pick up code changes is just saying that you're restarting your process to pick up code changes. That's why you'll need to use something like pm2 if you want files watches and hot-loaded. The other comments are great, I just wanted to give some insight into why.

ah, overlapping use of the word 'service' here. I meant the internal server service/process (e.g: uwsgi) if it doesn't watch for changes.

I think restarting an entire container for such small-scale changes is a bit much. Personally, I often resort to using a development server on the active project most of the time, it's a dirty solution with the consequence being that I've negated some of the advantages of my setup - if your server software is fast at restarting, you could throw in some sort of watcher.

This is why I just run all of an app's dependencies in a Docker container and connect the app to the Docker containers. Then I don't have to brew install all this crap.

That's exactly what I do, mainly because on Mac OS the host volume mounts are 2 magnitudes slower than volumes.

We use a few languages in our apps but for the ruby apps we use rerun in our docker-compose files (https://github.com/alexch/rerun) like so:

`rerun --background -- "foreman start"`

It is super simple and works well for us

The code does change inside the docker container when it's mounted as a volume, you just have to watch for it. We (at http://www.duecourse.com, a mostly node + Microservices shop) use nodemon for this

How do you deal with node_ modules and its insistence of being in the same folder as the source for your app?

This has been one of the great challenges for me. Nothing seems to work well with volume mapping.

Yeah, that's a PITA.

We currently just don't mount node_modules at all, and run npm install when we build the image, and have to re-build whenever we change package.json. It sounds bad, but once we've got something working we tend not to need to add new dependencies, it's normally just code changes from there on out.

As an example, here's a docker compose for one service:

         ports:
           - "20003:20003"
         volumes:
           - ./APP/src:/opt/app/src
           - ./APP/test:/opt/app/test
         command: npm run dev

`run dev` is the thing that calls nodemon, which reloads whenever src or test change. Otherwise, everything like node_modules exists inside the image.

Reply on news.ycombinator.com