Remote docker for MacBooks

Mon 10 May 2021

Remote Docker has been described by the people over at Docker itself. I’ve been working on a MacBook and have pretty powerful hardware at my disposal. I decided to test this out and the results surprised me greatly. In this article we go from start to finish. The process that I’ve went through to run the benchmarks for a remote docker solution to try and solve the drastic performance impact most Intel based MacBooks have when running complex projects.

Let’s start and kickoff to the why. My colleague had the same problem with his MacBook. He ran the same projects as we did. On our Dell XPS the projects had reloads in about 1 ~ 2 seconds. On his MacBook a refresh could take up to about 10 ~ 20 seconds. That situation was not workable and it was annoyingly slow. This will definitely save you a lot of time.

Let’s also be sensible. The MacBook also runs very hot when computing and doing IO through docker. This is also without good reasons as opposed to the XPS running the same projects in 60 / 70 degrees. My temps on the MacBook quickly rise to 90 / 95 degrees celcius. I believe the CPU’s in my particular model will throttle at 95. In any case, 95 degrees is not a very comfortable temperature to keep your CPU running at. In this new setup your MacBook can focus on running development tooling and not be hard pressed with keeping docker up.

I've also seen that memory usage is a considerable amount more than on my Linux machine. You can get this insight with docker stats.

These reasons are good enough for me to do some research into this. Also, docker-sync and docker-bg-sync are not the same as they both work the angle of working within the contraint of running from within Hyperkit. Difference between the two that one does work in the background while the other does the work upfront.

There are a few approaches that I will dive into with the benchmark I've made specifically for this:

  • Running the benchmark native on the MacBook
  • Setting up a share on the MacBook, running it from the remote
  • Setting up a share on the remote machine, running code native from remote

Running the benchmark native

I focused on making a good benchmark first. This would test the performance in all three cases and proves the methodology. The benchmark initially did not have the files benchmark. I've written these specifically with the MacBook in mind because of the performance penalty when doing any file IO within docker.

From what I understand without delving deeper into this is that Hyperkit, the chosen solution for Docker for Mac, has a pretty big performance penalty by making their own mounts and trying to keep up with the host each time a file is touched.

That said, the results of the benchmark in regard to the other benchmarks speak for themselves. These figures are relative to each other and results may vary from model to model.

Running of MacBook Share

Now, this was interesting looking back at it. The penalty wasn't as high as expected and this seems like the best middle ground to be honest. It will give you the best flexibility with security in mind.

Setting up the share was rather easy. I used the build in sharing system and turned on Samba sharing under advanced. Then it was simply logging in on the remote and run it from there. It took me literally a couple minutes to set this up.

In a company setting you need to comply to ISO standards. Rights and security wise this would be the easiest approach on remotely using docker. It will give you a performance penalty of sorts but already many times faster than running it native.

Running native on remote

The remote host is my main PC. Running Manjaro. I'm aiming to run LXC containers. The remote host will need Docker and Samba to run the projects. I won't be going into details as the respective getting started guides are very easy and most people will know how to get setup with both.

Installing Samba added the current user to sambashare group. That group will allow users to share folders. To add a specific password for that user you can run smbpasswd -a {user}.

Now we need a share. You can see examples and make a new share in the following configuration file /etc/samba/smb.conf. Make sure to add the user that you want to authenticate with to your configuration.

By default the firewall should be good to go to allow the host to broadcast whatever is exposed on the machine to the network. Be sure to open relevant ports for your projects if the machine is behind or running a stricter firewall.

After that we pull the code into the share and work off that.

Benchmark results

Let's talk results! I've ran the benchmark 3 times for good measure. Here is what my findings are. The numbers are the benchmark runtime in seconds.

I'll also have to add to this that my main PC is running a 3800x. This means a better single core clock speed. The benchmark performed a little faster on the remote machine because of this. I will add some reports later for comparison between the platform for delta's so that we can compare better.

Native on MB Share on MB Share on Remote
Run #1 248.829 58.112 37.414
Run #2 238.615 56.994 38.114
Run #3 248.123 60.223 37.347
Average 243.722 57.553 37.764

It is really interesting to me that the share on the MacBook will get you pretty good results as opposed to running it native. Running it off a share created on the MacBook will also make things a lot more managable from a company standpoint.