How I saved my MacOS Docker development experience
Introduction
I am sure that most of you have experienced a very lack luster and very frustrating experience with docker on MacOS. If not then please let me know how you have survived so long. And this is not to bash MacOS, I love the overall MacOS developer experience and environment, but and its a big BUT when it comes to docker it falls so flat its scary.
Granted you can use docker on a Macbook, however this is painfully slow and if its not slow I am sure its because you are doing very one dimensional things and probably only using already build docker images from docker hub. And if you are then its very usable and you shouldn’t be having to many performance issues.
The issue
I have really struggled with docker on my Macbook when it comes to building new images or using cli tools that build and mount images like AWS Sam or AWS CoPilot or when I need to build a production image to host in a ECS container.
I have the Macbook Pro M1 Pro chip 16GB model for reference, so its not a sluggish machine at all. I do understand the reasons behind docker being slow on MacOs and Windows it boils done to a few things but mainly docker runs in a VM on those operating systems and not natively as it does on Linux.
Most of the pain can be solved by building these in a CI/CD pipeline. Here are a couple of problems with that being the only answer:
- This pertains mainly to the local development process and experience not deployment
- I need to test my container locally and build a production build in certain instances
- Testing locally using AWS Sam and Copilot require building locally as well
- CI/CD costs money to host and to run builds and deployments
The last straw was trying to build a production image for a NextJS application we are developing, on a Friday as well (I know its a Friday anything to do with production environments is living dangerously).
There was nothing out of the ordinary with the dockerfile or anything special I was doing but still building this image took a staggering 33 minutes…. 33 minutes i had to do several times because I was testing why there was only a production bug and not in development and its was a stupid reason at the end of the day, but this stupid reason cost me 2+ hours because of the time it took to actually build the image.
This is not the only thing that takes long, AWS SAM serverless api builds take like 10+ minutes for a very simple API, and don’t get me started on testing these api’s locally using sam local start-api
AWS Copilot is not that bad but can still take some time.
But you get my point this is just a terrible experience and engineers we hate waiting for our machines to catch up. It hurts productivity and can be down right hair pulling especially if you need to do do these builds or run containers to solve some bugs and it requires repetitive building of your containers.
The solution
The solution to this is quite easy if you use containers on a daily basis don’t use MacOS. But what if you love MacOS? Maybe you are too deep into its ecosystem like I am?
Well there is one solution and this might not solve it for everyone but it did for me in a big way! I am a big advocate for having a HomeLab. Running docker on Linux is definitely the way to go if you need the performance like I do.
And I did try the experimental features of docker desktop as well before going down this route.
Your Homelab doesn’t need to be local it could be in the cloud, there are a few options like Github Codespaces, AWS has something simliar, or maybe try Oracle’s free tier that is super generous I think you can get 4 cores and 24GB Ram which is perfect!
However my primary HomeLab is a 10 year old i7 32GB Ram and a 1TB ssd, just a regular desktop grade spec and no server grade components.
With my HomeLab I am doing things a little different its not just installed with Linux and although this would be perfectly fine. I have a Layer 1 hypervisor installed call Proxmox (Its free and it’s awesome)
My HomeLab does a whole bunch of things for me and I will more then likely write an article about it and all that it does in the future because it really is an amazing tool for an engineer to have.
During the final 33 min (It still erks me to say that!) build I quickly logged into my Proxmox dashboard and created an Ubuntu 20.4 instance.
I assigned it 4 cores and 16GB Ram with a 100GB hard drive space, this was going to be my remote code server.
I set it up and made sure to install the OpenSSH client this is very important!
Once it was all installed and I could SSH into the machine. I installed VSCode remote Development Extension
Once installed you will be able to connect to your VM’s instance via SSH straight through VSCode
And then everything is pretty much the same as if you were on your local machine! Its pretty great and best of all that pesky MacOS Docker issue is now a thing of the past! My 33 min (yuck!) build time got reduced to 4min and that was including pulling down a fresh node16-alpine image! Thats a massive improvement! Oh and here’s the kicker, I did this entire setup in less time then my 33 min final build locally took in fact I started the process as it was building.
Like I mentioned this solution won’t be for everyone, however its working amazingly for me so far! Let me know if you have any tips around docker for MacOS, I know that this is the most performant solution that I have tried.
