Docker Mac Brew



In this guide, I will show you how to set up local DNS to work with Kubernetes in Docker Desktop for Mac. We’re going to send *.localhost domain traffic to your local Kubernetes cluster with the help of dnsmasq and some clever IP routing.

Brew tap browsh-org/homebrew-browsh brew install browsh browsh. A Docker image is available that bundles an up to date version of Firefox, so that.

  1. $ brew install docker $ docker -version Docker version 18.09.5, build e8ff056 Note that brew install docker and brew cask install docker is different. Some of the instructions about docker.
  2. $ brew tap caskroom/cask # Tap the Caskroom/Cask repository from Github using HTTPS. $ brew search docker # Searches all known Casks for a partial or exact match. $ brew cask info docker # Displays information about the given Cask $ brew cask install docker # Install the given cask. $ brew cleanup # Remove any older versions from the cellar.
  3. Give feedback and get help. To get help from the community, review current user topics, join or start a discussion, log on to our Docker Desktop for Mac forum. To report bugs or problems, log on to Docker Desktop for Mac issues on GitHub, where you can review community reported issues, and file new ones.See Logs and Troubleshooting for more details. For information about providing feedback on.

Docker Toolbox Mac Brew

Configuring the Host Mac

Prerequisites

Docker ce for mac brew
  • Install Homebrew
  • Install Docker Desktop for Mac
  • Enable Kubernetes in Docker Desktop’s Preferences.

Make a Loopback Alias

Make 172.173.174.175 into a loopback alias that points at your Mac.

You can turn this into a plist so that the configuration survives reboots. Make a file /Library/LaunchDaemons/localhost.docker.kubernetes.loopback.plist containing the following:

Mac

Configure dnsmasq

Mac

Install it via Brew.

Append the following line to dnsmasq.conf, which will tell dnsmasq to load additional *.conf configuration files from the dnsmasq.d directory.

Create a new file /usr/local/etc/dnsmasq.d/localhost.conf that directs *.localhost domains to 172.173.174.175 like this:

Restart the service.

Resolver

Make a new file /etc/resolver/localhost to tell your Mac to use its dnsmasq service to resolve *.localhost domains:

Configuring the Virtual Machine (VM)

iptables

Use iptables to tell the VM to forward 172.173.174.175 to 192.168.65.2 (its address for your Mac). The following command uses a minimal Docker image with nsenter(1) to punch through to the containing VM and run iptables there.

Docker Mac Brew

How Does it Work?

  • The VM sends 172.173.174.175 traffic to your Mac.
  • Your Mac sends 172.173.174.175 traffic to itself.
  • Both use dnsmasq to resolve *.localhost domains.
  • dnsmasq always answers with 172.173.174.175 for *.localhost domains.
  • Therefore *.localhost domains, resolved from either your Mac or the VM, always indicate an IP address that routes traffic back to your Mac.

What’s the Deal With the IP Address?

A typical guide for using dnsmasq for local development would tell you to set *.localhost to resolve to 127.0.0.1. That works for your Mac.

Create Docker Machine

The problem with doing that is when your VM resolves foo.localhost to 127.0.0.1. On your VM, 127.0.0.1 is the VM itself. We don’t want foo.localhost to go to the VM. We want it to go to the host Mac and let the host Mac handle the routing from there.

So we have foo.localhost resolve to 172.173.174.175, an arbitrary IP address from the private network block. And we separately configure both the host Mac and the VM to loop that traffic back to the host Mac.

Testing It Out

Make sure kubectl is pointed at the docker-desktop cluster:

Install the nginx ingress controller like so:

Navigate to http://anything.localhost in your browser. If everything is working properly, you will see a generic 404 Not Found page.

Did it work for you? Let us know on Twitter!

From 0 to K8s in Hours, Not Months

Don’t waste time and resources on DevOps. Our team of Certified Kubernetes Admins manage and maintain Kubernetes clusters using AWS to host applications for ourselves and our partners.

You might also be interested in these articles:

More Posts by Joel Wietelmann: