5 ms·

"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

• enoch_r 10y ago
  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.
• jackweirdy 10y ago
  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 http://www.duecourse.com, a mostly node + Microservices shop) use nodemon for this
  • was_boring 10y ago
    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.
    • jackweirdy 10y ago
      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.
• jamesRaybould 10y ago
  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 https://github.com/alexch/rerun) like so: `rerun --background -- "foreman start"` It is super simple and works well for us
• fapjacks 10y ago
  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.
• BlackjackCF 10y ago
  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.
  • bradgessler 10y ago
    That's exactly what I do, mainly because on Mac OS the host volume mounts are 2 magnitudes slower than volumes.
• avh02 10y ago
  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.