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?
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.
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.
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.
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.
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.
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.
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.
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.
25 comments
[ 4.0 ms ] story [ 77.7 ms ] threadYou'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.
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?
Why is docker for Windows/Mac better? It integrates better, handles directory sharing. Also, it doesn't seem like smartos supports kubernetes.
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/
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...
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.
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.
Kube also still has some oddities when working with namespaces, especially when using third party tools.
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.
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!
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.
When they say "is now shipping" they don't mean the stable channel, they mean edge.
https://blog.alexellis.io/docker-for-mac-with-kubernetes/#ge...
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.