
First Impressions: Docker for Mac with Kubernetes - alexellisuk
https://blog.alexellis.io/docker-for-mac-with-kubernetes/
======
deforciant
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...](https://webhookrelay.com/blog/2018/01/08/ingress-with-docker-for-
mac/)

~~~
bogomipz
>"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.

~~~
013a
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.

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

~~~
013a
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.

------
otras
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!

~~~
alexellisuk
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.

------
theptip
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!

~~~
deforciant
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.

------
shellbackground
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.

~~~
alexellisuk
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/](https://blog.alexellis.io/serverless-imagemagick/)

------
hinkley
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.

~~~
yebyen
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...](https://blog.alexellis.io/docker-for-mac-with-
kubernetes/#gettingit)

~~~
hinkley
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.

------
alexellisuk
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.

