Home » DevOps » Replacing Docker Desktop with hyperkit + minikube

About Arnon Rotem Gal Oz

Arnon Rotem Gal Oz

Replacing Docker Desktop with hyperkit + minikube

MacOS is a Unix but it isn’t a Linux so, unfortunately, if/when we need to use linux-y things like docker we need to install a VM just like in the Windows world. That’s of course also true for docker.

Like most people I’ve been using Docker Desktop for a lot of years to get my fix for container. It works pretty well, good even for almost everything. I don’t remember exactly when, Docker desktop added support for running Kubernetes. That looks good on paper and technically it works but not without a price… (at least on my Mac) it also comes with fans a-blazing and the soundtrack of a 747 taking off. Luckily, most of the time I have access to remote Kubernetes servers so I rarely used the option but whenever I did (re)try it, I quickly tuned it back off.

Installing Kubernetes

Last month, I changed jobs and joined Kaltura – so I went through the whole new computer setup thingy (you know, the important stuff, like setting up a development font, themes for all editors etc :) ), I also decided to see if I can get Kubernetes running without paying the noise-tax – and it seems that its doable with couple of simple steps:

brew install hyperkit
brew install minikube
minikube start

if you like you can also define the resources for the minikube image before you start it up

minikube config set cpu <whatever>
minikube config set memory <whatever>

tada working Kubernetes without all the fan-fare (pardon the pun). Here’s an image of Lens with my local cluster running 25+ containers (though you’d have to take my word that the machine is quiet :) )

Getting Docker to run

At this point you can kubectl deploy anything that is already existing – but what do you do if you want to deploy an image created locally? well, that’s not complicated either you need to build the image on the docker minikube is using :

eval $(minikube docker-env)

you can then docker build -t <whatever> . (or any other docker command for that matter) as usual.

It works so well I added the eval command to my .zshrc file and just stopped using docker desktop altogether.

Docker Desktop license change

Coda : A day or so ago, I saw that Docker is trying to monetize Docker Desktop and require a subscription license for businesses, so not only this seems to be working better (for me anyway) using hypekit+minikube can also be a good solution for devs who don’t want/can’t get their orgs to pay for a subscription so another plus here.

if you uninstall docker desktop you will need to install the docker CLI which is still using an apache 2.0 license:

brew install docker

What about Podman?

The Docker Desktop license change made this post rather popular. As I wrote above it seems that the Docker CLI is still Apache 2.0 (at the time of writing :) ), and so there’s no need to drop it, if licensing is the reason for change.

That said, there’s also a complete alternative to Docker CLI called Podman. installing it on MacOS is the predictable

brew install podman

Podman, like the docker CLI needs a linux VM to work with if run on a mac. As it happens minikube also has podman installed on its VM which you can utilize via
eval $(minikube podman-env) – unfortunately, minikube has podman v.2.2.1 and the version installed by brew is the latest (v.3.3.1) and they are not compatible.

If you also need Kubernetes, like I do, I’d stay with the Docker CLI. if, however you just need to build containers – you can migrate to Podman easily – by running

podman machine init # one time to download and setup a VM
podman machine start

Podman seem to be compatible with the Docker CLI (though it adds a few specific commands like machine and system) so you can build/pull etc. like before.

One note about building images with Podman: I tried building one of my existing Dockerfiles with Podman and got the following error: “Error: error creating build container: short-name resolution enforced but cannot prompt without a TTY“. The reason is that while Docker assumes images come from docker hub by default, You need to specify them with Podman , so changing FROM apache/airflow:2.1.2 to FROM docker.io/apache/airflow:2.1.2 solved the problem

Published on Java Code Geeks with permission by Arnon Rotem Gal Oz, partner at our JCG program. See the original article here: Replacing Docker Desktop with hyperkit + minikube

Opinions expressed by Java Code Geeks contributors are their own.

(0 rating, 0 votes)
You need to be a registered member to rate this.
3 Comments Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newest Most Voted
Inline Feedbacks
View all comments
1 month ago

Nice to read but this only works for Intel Macs. What about M1?

1 month ago

Have you tried skaffold for building? It works really well with minikube. Can reload your pod/deployment, forward ports, and you can tell the build if certain files (like static html) can just be copied in instead of reloading the whole container.

I’ve got skaffold deploying a maven/jib build to skaffold and the build/redeploy is heaps faster than docker-maven-plugin.

1 month ago

I’m pretty sure kaltura can afford to pay for a docker subscription for it’s developers.

This is like me posting how people can use obs and YouTube to avoid paying for the product that employs you.

Bottom line: lets all support the products we use!