5 ms·

First Impressions: Docker for Mac with Kubernetes

98 points by alexellisuk 9y ago

alexellisuk 9y ago
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.
- Annatar 9y ago
  I read the article and I’m still no wiser than I was before I read it: why exactly does this matter when we have SmartOS?
  - twblalock 9y ago
    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.
    - Annatar 9y ago
      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?
      - cube2222 9y ago
        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.
        Annatar 9y ago
        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.
        dominotw 9y ago
        This seems like such a tangent to topic at hand. This article is not even about kuberenetes or docker itself.
        Annatar 9y ago
        Then what is the article about? Or was it to serve as propaganda for Docker and Kubernetes... again?
shellbackground 9y ago
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 9y ago
  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/
deforciant 9y ago
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-for-mac/ https://webhookrelay.com/blog/2018/01/08/ingress-with-docker...
- bogomipz 9y ago
  >"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 9y ago
    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 9y ago
      Well, just give em a personal namespace with 4-8000millicpu
      - 013a 9y ago
        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 9y ago
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 9y ago
  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 9y ago
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 9y ago
  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.
hinkley 9y ago
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 9y ago
  That is true, and it's also mentioned in the article, under heading "Getting It" https://blog.alexellis.io/docker-for-mac-with-kubernetes/#gettingit https://blog.alexellis.io/docker-for-mac-with-kubernetes/#ge...
  - hinkley 9y ago
    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.

98 points by alexellisuk 9y ago

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.

Annatar 9y ago
I read the article and I’m still no wiser than I was before I read it: why exactly does this matter when we have SmartOS?
- twblalock 9y ago
  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.
  - Annatar 9y ago
    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?
    - cube2222 9y ago
      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.
      - Annatar 9y ago
        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.
        dominotw 9y ago
        This seems like such a tangent to topic at hand. This article is not even about kuberenetes or docker itself.
        Annatar 9y ago
        Then what is the article about? Or was it to serve as propaganda for Docker and Kubernetes... again?

shellbackground 9y ago

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 9y ago
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/

deforciant 9y ago

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-for-mac/ https://webhookrelay.com/blog/2018/01/08/ingress-with-docker...

bogomipz 9y ago
>"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 9y ago
  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 9y ago
    Well, just give em a personal namespace with 4-8000millicpu
    - 013a 9y ago
      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 9y ago

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 9y ago
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 9y ago

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 9y ago
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.

hinkley 9y ago

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 9y ago
That is true, and it's also mentioned in the article, under heading "Getting It" https://blog.alexellis.io/docker-for-mac-with-kubernetes/#gettingit https://blog.alexellis.io/docker-for-mac-with-kubernetes/#ge...
- hinkley 9y ago
  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.