6 ms·

I have to scratch my head every time I see a blog post about creating a dev environment that doesn't use volumes like this. IMO, this is the way to go and what

I have to scratch my head every time I see a blog post about creating a dev environment that doesn't use volumes like this. IMO, this is the way to go and what Docker was meant to be as a dev environment. Maybe it's because I'm never confident in the changes I make, but my style is to write a few lines at a time, save, re-run or refresh. I can't imagine having to do a docker build every code change. If you do the later, it's just nominally better than developing on a remote server, which brings its own challenges.

roofwellhams 5y ago
Did you try typescript? Now I can write for hours without trying out the app. And when I try... It just works
- redleather 5y ago
  This is such a weird comment.. nothing about the OC suggests they were talking about front end dev; not to mention that writing for hours before actually running it is a pretty terrible way to code. Typescript is also not a workaround for volume binding, which can accommodate any stack.
  - dehrmann 5y ago
    > nothing about the OC suggests they were talking about front end dev >> I'm never confident in the changes I make, but my style is to write a few lines at a time, save, re-run or refresh. This is a pretty typical frontend development pattern, especially seeing "refresh."
    - dividedbyzero 5y ago
      I read that as "re-run or refresh, as applicable", i.e. re-run a Go app or refresh a Node.js webapp. Besides, it absolutely can be a big issue with non-frontend development, so the point still stands.
      - snapetom 5y ago
        Yes, that is why I specifically mentioned "re-run." About 75% of my work is actually API and backend data engineering work (Python Go, Node in that order). I do "save and re-run" less in that type of work, but definitely not enough to make frequent docker builds a hassle.
  - pgwhalen 5y ago
    As another commenter mentioned, "refresh" tipped them off as a front end dev. As a backend dev working in statically typed languages, I will sometimes code for hours without running, and I wouldn't say anything about it is terrible. I haven't worked with Typescript, but it wouldn't surprise me if it enabled a similar development process. I wouldn't necessarily infrequent running as a technique worth emulating, but in certain situations it works pretty well.
    - snapetom 5y ago
      The majority of my work is actually in Python and Go on the backend. I do save/re-run less than when I'm doing front end, but docker builds are still a hassle. Flask will automatically reload on file changes, taking advantage of a docker volume. With Go, I'm doing go runs in development anyway up until deployment with go build. Maybe I'm doing things wrong, but docker volumes are essential in how I like to dev.
    - lanstin 5y ago
      Even there it is beneficial to run sooner. E.g, for servers as soon as the listen is up and dispatching, run it and see that the handler runs. Often times the only times my error handling code runs is during this initial code writing time. (For certain annoying to test for types of error). Fast iterations around a known good baseline.
- archsurface 5y ago
  A star fruit is also known as a carambola.
globular-toast 5y ago
Honestly I'm quite blown away to know there are people who weren't doing it this way. I think it's due to a fundamental misunderstanding of what docker is for and that is caused by using a solution without knowing the problem.
krono 5y ago
How awesome would it be if we could exclude specific dirs or files from bind mounts. Think of cache directories, log files, and, of course, node_modules. The common workaround to this, is to create an empty volume and map whatever you don't want mounted to it. You'll end up with an empty directory in your host system, but its contents are available from within the container. It has many problems though, mostly permission and ownership related, but it somehow makes Docker for Mac even slower and crash even more often than usual. Example minimal docker-compose.yaml file for a custom "devcontainer" we use in VSCode that showcases the workaround: version: '3.8' services: project: image: devcontainer:dev container_name: devcontainer build: context: . dockerfile: Dockerfile args: ALPINE_VERSION: '3.13' NODE_VERSION: '14.16.1' ports: - 3000:3000 volumes: - ..:/project - node_modules:/project/node_modules:cached volumes: node_modules: This feature gets asked for quite often. Here are two issues on GitHub I was quickly able to find: https://github.com/docker/compose/issues/6470 https://github.com/docker/compose/issues/6470 https://github.com/docker/compose/issues/6997 https://github.com/docker/compose/issues/6997
- sm4rk0 5y ago
  @bdcravens mentioned this as a solution in another comment: http://docker-sync.io/ http://docker-sync.io/
  - krono 5y ago
    Thanks! I came across that project in the past, bookmarked it, and then completely forgot it even existed. Trying it out tonight :)
qbasic_forever 5y ago
Using host volumes can have big performance problems on OSX and Windows. Node or frontend development with huge node_modules folders in particular can run into problems like flakey file change notifications or just general slowness accessing files. Linux users aren't immune from trouble either. Host volume permissions are a big source of pain--if your mounted files don't have the same UID/GUID as the user baked into the dockerfile then you'll hose access to the files on your local machine. Most simple dockerfiles run as root (especially dockerfiles created by windows or mac developers who never deal with this problem) and all the created files inside them show up as root owned on your localhost. You have to take special care to craft your dockerfile to not run as a root user, launch with explicit user UID/GUID that matches your host machine, and use a tool like fixuid as an entrypoint to fix up mismatches. A good workaround though is to use docker's internal volumes instead of host mounts. This fixes all the Linux permission issues (the internal volumes live in their own root/docker managed location), and fixes the slowness on other platforms (no VM folder mount slowdown). But you give up the freedom of seeing your files locally and need to go all in with something like VS code remote containers, or running your IDE directly in the container.

roofwellhams 5y ago

Did you try typescript? Now I can write for hours without trying out the app. And when I try... It just works

redleather 5y ago
This is such a weird comment.. nothing about the OC suggests they were talking about front end dev; not to mention that writing for hours before actually running it is a pretty terrible way to code. Typescript is also not a workaround for volume binding, which can accommodate any stack.
- dehrmann 5y ago
  > nothing about the OC suggests they were talking about front end dev >> I'm never confident in the changes I make, but my style is to write a few lines at a time, save, re-run or refresh. This is a pretty typical frontend development pattern, especially seeing "refresh."
  - dividedbyzero 5y ago
    I read that as "re-run or refresh, as applicable", i.e. re-run a Go app or refresh a Node.js webapp. Besides, it absolutely can be a big issue with non-frontend development, so the point still stands.
    - snapetom 5y ago
      Yes, that is why I specifically mentioned "re-run." About 75% of my work is actually API and backend data engineering work (Python Go, Node in that order). I do "save and re-run" less in that type of work, but definitely not enough to make frequent docker builds a hassle.
- pgwhalen 5y ago
  As another commenter mentioned, "refresh" tipped them off as a front end dev. As a backend dev working in statically typed languages, I will sometimes code for hours without running, and I wouldn't say anything about it is terrible. I haven't worked with Typescript, but it wouldn't surprise me if it enabled a similar development process. I wouldn't necessarily infrequent running as a technique worth emulating, but in certain situations it works pretty well.
  - snapetom 5y ago
    The majority of my work is actually in Python and Go on the backend. I do save/re-run less than when I'm doing front end, but docker builds are still a hassle. Flask will automatically reload on file changes, taking advantage of a docker volume. With Go, I'm doing go runs in development anyway up until deployment with go build. Maybe I'm doing things wrong, but docker volumes are essential in how I like to dev.
  - lanstin 5y ago
    Even there it is beneficial to run sooner. E.g, for servers as soon as the listen is up and dispatching, run it and see that the handler runs. Often times the only times my error handling code runs is during this initial code writing time. (For certain annoying to test for types of error). Fast iterations around a known good baseline.
archsurface 5y ago
A star fruit is also known as a carambola.

globular-toast 5y ago

Honestly I'm quite blown away to know there are people who weren't doing it this way. I think it's due to a fundamental misunderstanding of what docker is for and that is caused by using a solution without knowing the problem.

krono 5y ago

How awesome would it be if we could exclude specific dirs or files from bind mounts. Think of cache directories, log files, and, of course, node_modules. The common workaround to this, is to create an empty volume and map whatever you don't want mounted to it. You'll end up with an empty directory in your host system, but its contents are available from within the container. It has many problems though, mostly permission and ownership related, but it somehow makes Docker for Mac even slower and crash even more often than usual. Example minimal docker-compose.yaml file for a custom "devcontainer" we use in VSCode that showcases the workaround: version: '3.8' services: project: image: devcontainer:dev container_name: devcontainer build: context: . dockerfile: Dockerfile args: ALPINE_VERSION: '3.13' NODE_VERSION: '14.16.1' ports: - 3000:3000 volumes: - ..:/project - node_modules:/project/node_modules:cached volumes: node_modules: This feature gets asked for quite often. Here are two issues on GitHub I was quickly able to find: https://github.com/docker/compose/issues/6470 https://github.com/docker/compose/issues/6470 https://github.com/docker/compose/issues/6997 https://github.com/docker/compose/issues/6997

sm4rk0 5y ago
@bdcravens mentioned this as a solution in another comment: http://docker-sync.io/ http://docker-sync.io/
- krono 5y ago
  Thanks! I came across that project in the past, bookmarked it, and then completely forgot it even existed. Trying it out tonight :)

qbasic_forever 5y ago

Using host volumes can have big performance problems on OSX and Windows. Node or frontend development with huge node_modules folders in particular can run into problems like flakey file change notifications or just general slowness accessing files. Linux users aren't immune from trouble either. Host volume permissions are a big source of pain--if your mounted files don't have the same UID/GUID as the user baked into the dockerfile then you'll hose access to the files on your local machine. Most simple dockerfiles run as root (especially dockerfiles created by windows or mac developers who never deal with this problem) and all the created files inside them show up as root owned on your localhost. You have to take special care to craft your dockerfile to not run as a root user, launch with explicit user UID/GUID that matches your host machine, and use a tool like fixuid as an entrypoint to fix up mismatches. A good workaround though is to use docker's internal volumes instead of host mounts. This fixes all the Linux permission issues (the internal volumes live in their own root/docker managed location), and fixes the slowness on other platforms (no VM folder mount slowdown). But you give up the freedom of seeing your files locally and need to go all in with something like VS code remote containers, or running your IDE directly in the container.