Hacker News Reader

Comment by snapetom | Hacker News Reader

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.

View on HN

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.

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/6997

@bdcravens mentioned this as a solution in another comment:

http://docker-sync.io/

Thanks! I came across that project in the past, bookmarked it, and then completely forgot it even existed. Trying it out tonight :)

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.

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

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.

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

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.

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.

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.

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.

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.

A star fruit is also known as a carambola.

Reply on news.ycombinator.com