3 ms·

> my iterative dev setup often isn’t that similar to my ‘under docker’ setup This seems like a strange complaint to me, because it's one of the best things abo

> my iterative dev setup often isn’t that similar to my ‘under docker’ setup This seems like a strange complaint to me, because it's one of the best things about iterating with docker. Make a change, do a build (super quick because of fs layers) then run it. If it works, ship it! Not only that, but now I can do the same thing in Windows. It's a wonderful time to develop linux applications.

lobster_johnson 10y ago
I don't know about the OP, but a lot of people rely on hot code reloading to see live changes, be it a Node.js app or a React UI. The Docker build workflow is way too slow for that. When I work on React apps, I expect the UI to seamlessly reload every time I save a file. You can accomplish this perfectly well with Docker, of course, though you have to use volumes and so on. Docker for Mac's mounting support has inotify/fsevents on both sides, though the volumes are not fast. (Fast enough for a React app, but enough for a Postgres database.)
vidarh 10y ago
Exactly. First thing I do when setting up a new project now is to set up a Dockerfile for the container I will build things in. For scripting languages etc. it's also easy enough to just mount your working directory anyway, so the Docker container provides the environment but you don't need to rebuild the container for every change. E.g. for my Ruby web projects I'll often have things like this in a Makefile: rundev: docker run -t -i --rm -v ${PWD}:/usr/src/app -p 8080:80 ${IMAGE} bundle exec shotgun ${SHOTGUN_OPTS} With a Dockerfile that might be as simple as this: FROM ruby:2.3.1-onbuild EXPOSE 80 CMD bundle exec puma --port 80 Gives me a predictable environment where I "only" rebuild the Docker container when I add/remove dependencies, and when I run it in development, shotgun will hot-reload the Ruby code from the mounted host directory. Saves me from polluting my hosts with whatever version of code I need for different projects. At this point there's very little code I'm willing to run outside of containers, not for security reasons but because they prevent my laptop from getting full of cruft. I couldn't imagine going back to developing outside of containers.

lobster_johnson 10y ago

I don't know about the OP, but a lot of people rely on hot code reloading to see live changes, be it a Node.js app or a React UI. The Docker build workflow is way too slow for that. When I work on React apps, I expect the UI to seamlessly reload every time I save a file. You can accomplish this perfectly well with Docker, of course, though you have to use volumes and so on. Docker for Mac's mounting support has inotify/fsevents on both sides, though the volumes are not fast. (Fast enough for a React app, but enough for a Postgres database.)

vidarh 10y ago

Exactly. First thing I do when setting up a new project now is to set up a Dockerfile for the container I will build things in. For scripting languages etc. it's also easy enough to just mount your working directory anyway, so the Docker container provides the environment but you don't need to rebuild the container for every change. E.g. for my Ruby web projects I'll often have things like this in a Makefile: rundev: docker run -t -i --rm -v ${PWD}:/usr/src/app -p 8080:80 ${IMAGE} bundle exec shotgun ${SHOTGUN_OPTS} With a Dockerfile that might be as simple as this: FROM ruby:2.3.1-onbuild EXPOSE 80 CMD bundle exec puma --port 80 Gives me a predictable environment where I "only" rebuild the Docker container when I add/remove dependencies, and when I run it in development, shotgun will hot-reload the Ruby code from the mounted host directory. Saves me from polluting my hosts with whatever version of code I need for different projects. At this point there's very little code I'm willing to run outside of containers, not for security reasons but because they prevent my laptop from getting full of cruft. I couldn't imagine going back to developing outside of containers.