Hacker News new | ask | show | jobs
by tele_ski 1577 days ago
I've been on teams that haven't used docker for dev envs and teams that do in the last 5~ years. The teams that used docker were significantly more productive since each dev env was a replica and forced the team to maintain a common env. The dev env drift without it is huge and causes so many "it works on my machine". I can see a one man show or maybe two not needing a docker dev env but any sizable team IMO it is absolutely required now. You're absolutely right that it is a hoop to jump through, but its a hoop I find very necessary.
3 comments
tsm 1577 days ago
I've worked on Rails, Node, and Clojure teams where Docker was optional and was always glad I avoided it. There has never been something important in my dev environment[1] that couldn't be responsibly managed by rbenv and bundler (or their equivalents for other languages).

[1] The one exception is SQL DBs and redis, but I have always been fine using brew, linuxbrew, or apt for them.

link
taeric 1577 days ago
Oddly, my experience is a mixed bag here. Teams I've been on that went for rigid standardization with docker have largely been much harder to upgrade than those that allow local dev however the dev wants.

This is subtle. There are more bumps along the way. However, the task of upgrading isn't neglected forever. Instead, it usually seems that each new member winds up upgrading some small piece and making sure the code works with a small change in environment.

link
nirvdrum 1577 days ago
How did you handle differences in macOS/Windows and Linux? The last team I was on that tried to do all local development in Docker kept running into breakages. To allow the devs to use whatever editor or IDE they wanted, the source code was stored in the host system and mounted as a Docker volume. While that sounds simple, it's amazing how many times things broke depending on who set it up.

By default, Docker runs everything as root. This isn't a huge problem on macOS or Windows, where Docker runs in a VM and there's some sort of UID mapper mediating things. If a file is generated from a process within Docker (e.g., temporary or log files) and you're running in Linux, now you have files in your local system that you can't edit without "sudo". Fine, don't run the container as root. I'd have expected that to be a best practice, but it doesn't come up in Docker's best practices guide [0]. Adding our own user and switching to that isn't a huge hurdle, although this didn't seem to be an area that we'd have to chart our own path. Unfortunately, some 3rd party images don't run particularly well, if at all, if not run as root.

Once we got that running, we hit our next issue. Although things were working well for one developer, they broke for another because there still existed the same basic problem with Linux users ending up with files owned by UIDs other than their local account. It turns out that not every dev is running with the same UID. Okay, so now we need to map the UID and GID at image build time, but that might break things for people on macOS.

All of our Dockerfiles ended up with something like:

  ARG app_user_uid=61000
  ARG app_user_gid=61000
  ENV APP_USER="app"
  RUN groupadd -g $app_user_gid -o $APP_USER
  RUN useradd --no-log-init --create-home --shell /bin/false --gid $app_user_gid --uid $app_user_uid -o $APP_USER
And needed to be built on Linux with:

  docker-compose build --build-arg app_user_uid=$(id -u) --build-arg app_user_gid=$(id -g) ...
While macOS users used the simpler:

  docker-compose build ...
This all took quite some time to figure out. The person working on it would get things working, think it was all good, push it up, and only find out later that it wouldn't work on another dev's system. CI couldn't catch everything. The point of using Docker was to ensure there weren't inconsistencies against dev environments and that dev matched production. That seems like a fairly common use case, but we couldn't find anything on how to simplify this setup for teams other than mandating every user run the same exact system configuration. I have to believe we were doing something wrong, but we really couldn't find anything on the topic. I'd love to hear how you solved the problem.

[0] -- https://docs.docker.com/develop/dev-best-practices/

link