[macinjosh]

I understand the desire here to get more performance out of macOS for web development. The problem is that even if you have the right stack installed writing and executing code in macOS is not the same as doing it in the same OS and stack that the code is deployed on. You will still run into situation where it “works on my machine” but fails when deployed.

A common set of issues has to do with the file system.

[JeffMarmalade]

My personal experience is that while it's an enticing concept — the idea that local development using Docker will reflect production issues — it just doesn't pan out. I quickly realised that trying to accurately replicate my production environments locally was not going to be a happening thing, and ended up migrating my development stack to docker-based environments such as https://lando.dev and https://laradock.io which make no pretence of being a reflection of production.

Further, if you have an m1 Mac your Docker environment will be running ARM versions of linux which almost certainly is not what you are running in production, so it starts becoming pretty clear that Docker on Mac is !== Docker in Production.

However, I do agree, there are issues you might find in production that you won't find when running your app in Indigo. I would argue that's what staging is for. Just create a literal clone of your production docker stack either on your Mac or a spare Pi and run your tests there before pushing to production.

I think there's a growing realisation that Docker is harming developer productivity. It certainly was for me.

Re file system issues, you're absolutely right; this colossal thread <https://github.com/docker/roadmap/issues/7> was in fact a motivating factor for me; the underlying file system issues seem pretty insurmountable. Fundamentally, Docker on Linux is awesome, and Docker on Mac (and Windows) just isn't, purely for this one reason.

[macinjosh]

> I quickly realised that trying to accurately replicate my production environments locally was not going to be a happening thing

Your production environment should be easily reproducible via some sort of infrastructure as code system, or it could be built in containers/docker itself. In that case you absolutely can replicate your production environment locally incredibly closely. Usually the main differences are around scale and performance. I see this as good though as it is much easier to stumble upon performance issues on a local dev machine than it is on a blazing fast prod instance.

> I would argue that's what staging is for. Just create a literal clone of your production docker stack either on your Mac or a spare Pi and run your tests there before pushing to production.

Staging is for sharing and reviewing your work with other stakeholders before deploying to production. I prefer to not have asinine platform related bugs to show up when I am demoing my work around the company or with clients. Also in my experience staging is not a spare pi (which is also ARM!) or a local docker instance.

> Further, if you have an m1 Mac your Docker environment will be running ARM versions of linux which almost certainly is not what you are running in production, so it starts becoming pretty clear that Docker on Mac is !== Docker in Production.

It is still the same OS and is miles ahead of just simply being POSIX compliant. I would be interested in specific differences and issues you've seen in ARM linux vs. x86 linux, especially when it comes to the layers PHP operates within.

> Re file system issues, you're absolutely right; this colossal thread

Have you tried the VirtioFS experimental feature in docker desktop? With it enabled I can write hundreds of GB per day from docker to my macOS file system with no sweat.

In any case, I was referring to differences between executing code on a macOS file system vs. a linux file system that matches production. macOS handles permissions and case sensitivity differently which can cause problems, especially for junior devs.

Anyway, good luck with this endeavor. I am sure many will find it sufficient!

[IndigoStack]

Hope you don't mind me continuing the conversation, I like having my thinking challenged/stretched :)

> I quickly realised that trying to accurately replicate my production environments locally was not going to be a happening thing

Sorry I wasn't clear; my production environments are docker and as such yes, trivial to get running locally. My experience was that this was far less useful than expected. The moment I started turning on things like Xdebug and implementing mechanisms to deal with non-production .envs etc etc it became less and less useful for me. I'm guessing there are workarounds for all these kinds of issues (or you wouldn't be a proponent), but I do suspect that if you're developing locally in a 95+% clone of a production docker environment, you are one of very few who have managed it and enjoyed it enough to keep doing it. Which is to say you're a legend :D

> staging

Perhaps I used poor terminology; call it "Test". And the Pi was a poor example also, sorry! I don't run Pi's, and my personal dev circumstances are fairly atypical. However, I do feel it's solid advice to suggest that people:

a) run whatever development environment is most productive for you on a daily basis locally, so long as it closely replicates the production environment at the level your job requires. So as a front-end / back-end developer that means the same PHP/MySQL/Nginx versions etc.

b) run a clone of your production environment on a separate machine (local VM / local tiny PC / second VPS, whatever) for testing

> specific differences and issues you've seen in ARM linux vs. x86 linux

Absolutely none (as you probably guessed); I've never run an ARM server, nor had any issues between native binaries on x86 or M1 and their identical counterparts in production. As you suggested, the issues I typically face (and many like me, I expect) are at a different abstraction level from this; most boiled down to a) service configuration differences eg PHP extensions or b) file system issues (eg permissions & case sensitivity).

Re VirtioFS no, when I still used D4M I ran docker-sync with various strategies. It kinda worked. I then ran VS Code's Remote Containers. It kinda sorta worked. Both were annoying on an almost-daily basis.

[glacials]

> I think there's a growing realisation that Docker is harming developer productivity.

It depends a lot on specifics, but as a trend I tend to agree. However, there's value in making the development environment consistent among engineers. I wonder if there's a middle ground for version-pinning things like PostgreSQL and Ruby that's not as extreme as containerization.

[lukeholder]

I work on a PHP project that is installed an any number of environments - so exactly duplicating production is impossible. Of course we have a CI/Test system that tests various combinations of PHP version and DB engines, but we can't replicate every possible production environment. Using Docker to match production is therefore moot in our case.

All the PHP development frameworks these days have moved to Docker or VMs but nothing beats native. Indigo looks promising.

[JeffMarmalade]

Interesting! I hope Indigo may be really helpful for you. If I'm understanding your use-case correctly, you could create a stack with both MySQL versions, and another stack containing a site per PHP version, all pointing at the same codebase in your filesystem, but each configured to use a different PHP. Then you can run them all simultaneously if you want, with each in their own browser window eg project-72.test, project-73.test, project-74.test, project-80.test etc (one per PHP).

[nicoburns]

In theory yes. In practice I haven’t seen any of these issues in years. And the last time I did see issues was due to case-insensitive file system which is easily fixed by running local code on a case-sensitive partition.

And many of us have a staging environment for QA anyway, so if the odd issue did sneak through, it wouldn’t be a major problem as it wouldn’t make it to production.