Docker Compose best practices for dev and prod

Re:Docker Compose best practices for dev and prod by JadoJodo on Tuesday August 16, 2022 @01:53PM (#32486329)

One of the things we've really struggled with is sharing dev compose files between Windows and macOS. We were unable to make bind mounts work correctly with Windows, due to performance issues (this used to be documented in the Docker docs, but I can't seem to locate it now). This resulted in us falling back to VSCode's remote container tooling.

Has anyone else had this issue with Windows? The last time I looked into the issue was about 8 months ago, so it's possible the issues have been addressed since then.

[ Parent | on HN ]

Re:Docker Compose best practices for dev and prod by nickjj on Tuesday August 16, 2022 @02:03PM (#32486474)

> We were unable to make bind mounts work correctly with Windows, due to performance issues (this used to be documented in the Docker docs, but I can't seem to locate it now)

Docker Desktop volume performance on Windows is great if you're using WSL 2 as long as your source code is in the WSL 2 file system. It also works great with WSL 1. I've been using it for a long time for full time dev.

In fact, volume performance on Windows tends to be near native Linux speeds. It's macOS where volume speeds are really slow (even on a new M1 using Virtiofs). Some of our test suites run in 30 seconds on Windows but 3 minutes on macOS.

But the Docker Compose config is the same in both. If you want, I currently maintain example apps for Flask, Rails, Django, Node and Phoenix at https://github.com/nickjj?tab=repositories&q=docker-*-exampl..., I use some of these exact example apps at work and for contract work. The same files are used on Windows, macOS and Linux.

The only time issues arise is when developers on macOS forget that macOS' file system is case insensitive where as Linux is not. Docker volumes take on properties of their host so this sometimes ends up being a "but it works on my machine!" issue specific to macOS. CI running in Linux always catches this tho.

[ Parent | on HN ]

Re:Docker Compose best practices for dev and prod by KronisLV on Tuesday August 16, 2022 @04:39PM (#32488597)

> Docker Desktop volume performance on Windows is great if you're using WSL 2 as long as your source code is in the WSL 2 file system. It also works great with WSL 1. I've been using it for a long time for full time dev.

My experience actually was the exact opposite. This one project had horrible IO performance on Windows, when running a bunch of PHP containers, with the WSL2 integration in Docker Desktop set to enabled.

It was bad to the point of the app taking half a minute to just load a CRUD page with some tables, whereas after switching to Hyper-V back end for running Docker, things sped up to where the page load was around 3 seconds.

I have no idea why that was, but after switching to something other than WSL2, things did indeed improve by an order of magnitude.

[ Parent | on HN ]

Re:Docker Compose best practices for dev and prod by kyriakos on Wednesday August 17, 2022 @01:14PM (#32499060)

I have had great performance with Windows 10, docker desktop and wsl2. Code in wsl2 partition. Used to use an ec2 host for it but this setup performs better and the code sync step is eliminated.

[ Parent | on HN ]

Re:Docker Compose best practices for dev and prod by freenatec on Tuesday August 16, 2022 @10:53PM (#32491756)

If you’re using WSL 2, but your project files are in windows-land and vscode is reading them via the mnt path (like /mnt/c/code/myproject), then you’re going to have show-stopping performance problems.

[ Parent | on HN ]

Re:Docker Compose best practices for dev and prod by tmpz22 on Tuesday August 16, 2022 @02:00PM (#32486438)

You're trying to create a uniform developer experience across two platforms that are wildly different.

If you find yourself spending a ton of time on a one-size-fits-all-disappoints-everybody solution, maybe its time to build two effective solutions instead.

[ Parent | on HN ]

Re:Docker Compose best practices for dev and prod by bluedino on Tuesday August 16, 2022 @02:15PM (#32486620)

That's kind of the point if containers, isn't it?

[ Parent | on HN ]

Re:Docker Compose best practices for dev and prod by DrBenCarson on Tuesday August 16, 2022 @02:56PM (#32487175)

No definitely not. In fact to this day containers only run on Linux. Your Mac or PC just runs a Linux VM in order to be able to run any containers.

Containers are not meant to make anything OS-agnostic. Containers are just a way of running Linux

[ Parent | on HN ]

Re:Docker Compose best practices for dev and prod by jiggawatts on Tuesday August 16, 2022 @09:05PM (#32491049)

Not quite true: Windows containers run natively on Windows. As of Windows 11, even Server 2022 containers can run using process isolation.

Something hilarious to me is that "multi-arch" images are a thing, and can result in the same dockerfile building a Windows image on a Windows PC, and a Linux image on a Linux PC!

[ Parent | on HN ]

Re:Docker Compose best practices for dev and prod by sneak on Wednesday August 17, 2022 @02:00AM (#32492832)

This is a red herring and this feature only exists as a Microsoft platform strategy. I don’t know of anyone real using Windows executable docker containers on Windows hosts.

dockerd for windows isn’t even free software, last I looked.

[ Parent | on HN ]

Re:Docker Compose best practices for dev and prod by tmpz22 on Tuesday August 16, 2022 @02:20PM (#32486672)

Oh god no, Linux containers were not intended to be the solution for cross compatibility issues between Windows and MacOS

[ Parent | on HN ]