I also had a look at Docker for Mac. It's now my default k8s dev environment, I must admit that even if their high CPU usage issue it's still a lot more CPU friendly than minikube.

What's great for development is that you can also build images on Mac and run them inside k8s environment, no need to change daemons. Which was sometimes a bit annoying with Minikube and I usually found myself just pushing them to the dockerhub and then pulling to minikube :) However, not sure why the dashboard is not enabled by default, it's quite handy.

If you are interested in ingress controllers and demoing your apps directly from your mac, have a look at my recent blog post: https://webhookrelay.com/blog/2018/01/08/ingress-with-docker...

At this point minikube is so far behind on docker versions that the docker documentation is a source of frustration. I’m working on dockerizing a largish node project and so I have to keep clearing out old containers to make space, and the cleanup commands aren’t there.

Also about once a week I’ll build and tag a docker image successfully and it’s just gone. Docker images doesn’t show it and you can’t run it. Restart minikube and run a ten minute build again. Super.

I’m supposed to be documenting this stuff for people who don’t use docker. Right. Off to upgrade docker for Mac instead.

>"It's now my default k8s dev environment, ..."

Could I ask you what are you developing that you need a whole local K8 dev environment? What I mean is as opposed to just using docker compose or docker container themselves. Are you specifically developing K8 features? Thanks.

If you're developing a service architecture that runs in kube on production, you want to emulate that as close as possible locally.

I'm more of the opinion that devs should just have access to a kube "cluster" (maybe just one machine) in the cloud, possibly one per dev. Make a change to the service, build it, and deploy it. Give easy tools to re-image your cluster whenever you want. Primarily because you want your "local" environment to match production as closely as possible.

Well, just give em a personal namespace with 4-8000millicpu

Yeah that can work as well. In general, though, I prefer absolutely strict isolation between environments. In our deployments, this goes all the way to having separate GCP Projects for each environment. This has as much to do with kubernetes as it does with all the other cloud resources in each environment that we don't want commingling inside the same GCP project.

Kube also still has some oddities when working with namespaces, especially when using third party tools.

I have two projects that talk directly with k8s, it's keel (CI tool for kube) https://github.com/keel-hq/keel and ingress controller for webhookrelay.com so I need a working cluster locally. However, other services are also tested on local minikube as it's easier to make sure they are interacting as intended when running in K8s :)

Thanks, that makes perfect sense. I guess that's what I expected but wanted to see if there was another use case. Keel looking interesting. I will take a look. Thanks.

Unrelated, but my first and last is also Alex Ellis, and you're the reason I had to register alexanderellis in place of alexellis on github. Funny to see in the wild!

Nice to meet you Alex! If only we could find the guy who registered "alexellis" on Twitter and toss a coin for that account too. I had to go with alexellisuk.

I hadn't put two and two together and realized that minikube would use a different Docker daemon from docker-for-mac -- that makes this built-in k8s feature a lot more useful than I'd originally thought.

If I need to run a pod with some containers that are in a GCR registry, I can just `gcloud docker pull` them and then run them, rather than having to jump through hoops to configure minikube with registry secrets. That's nice!

Yep, for local development it's the same, a lot easier to just rebuild and run. Haven't thought about `gcloud docker pull`, thanks!

I guess this is also quite important with any other registry such as jfrog, quay, etc. And it's good that credentials are safer (I hope so) in the osx keychain rather than Minikube.

What looks particularly funny that it's OpenFaaS examples, such as in this post: figlet service. Several years ago it was simple binary, which you could invoke in console to produce fancy-stylized string. Now, same functionality require running figlet function-as-a-service inside Docker container inside Kubernetes cluster. I understand, that's merely an example, but nevertheless.

Kubernetes is optional - Docker Swarm (which some people prefer for its simplicity is also available) - basically yes binaries get wrapped in containers now for build/ship/run.

You're right though it is just an example - one of many in the function store. OpenFaaS can run any binary as a function - that means that we can strip back all the complexity needed to utilise ImageMagick for instance as a function by making it a function that works over stdin/stdout. Normally that would have involved a Node.js runtime and native compilation packages.

Here's the example: https://blog.alexellis.io/serverless-imagemagick/

I just upgraded Docker for Mac and there's nothing about Kubernetes in the UI.

When they say "is now shipping" they don't mean the stable channel, they mean edge.

That is true, and it's also mentioned in the article, under heading "Getting It"

https://blog.alexellis.io/docker-for-mac-with-kubernetes/#ge...

It’s the word Shipped in the title that’s getting me. The edge program is essentially a beta. And now we’re redefining “shipped” to mean “available in eval builds”.

I suppose it’s been 20 years since we ruined the word Beta. I am not surprised that it’s happening again, but I am a bit disappointed.

Docker for Mac now ships with Kubernetes built-in. Let's explore why this matters, a history of developer tooling for running Docker on Mac/Windows and my first impressions as I kick the tyres with the Kubernetes integration.

Because far, far, far more people use Macs than use SmartOS, and even people who run SmartOS in prod use Macs to write and test their software.

You're not being serious, and you're not arguing in good faith. You aren't wiser from reading the article because you don't want to be. You'd rather crap on other peoples' achievements and push an agenda than approach this with an open mind. Looking at your profile and your comment history makes this abundantly clear.

SmartOS runs under any hypervisor, including ones on macOS.

The argument that “far more people use Macs” is therefore completely beside the point.

I myself use macOS too.

The premise of the article is “let’s explore why this matters” but from pure capabilities standpoint, my question remains unanswered: why does it matter if there is SmartOS which doesn’t need any of this?

If I understand correctly, you just want to run a container OS on a hypervisor.

Why is docker for Windows/Mac better? It integrates better, handles directory sharing. Also, it doesn't seem like smartos supports kubernetes.

It doesn’t suppport it because it works differently so it doesn’t need it. The complexity of needing Docker and Kubernetes falls away, although Docker is supported.

This seems like such a tangent to topic at hand. This article is not even about kuberenetes or docker itself.

Then what is the article about? Or was it to serve as propaganda for Docker and Kubernetes... again?