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