Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker for Mac with Kubernetes

docs.docker.com

Post reply on HN
Print view View original

51–60 of 169 posts

Re: Docker for Mac with Kubernetes

#51

Post by [deleted] »

fapjacks wrote: post #47
alexellisuk wrote: post #38

I normally used minikube for openfaas development - I appreciate the efforts of the project, it's an invalueable tool. The DfM integration works very well for local development and I've got some screenshots below: https://twitter.com/alexellisuk/status/949595379326210048 Make sure you do a context-switch for kubectl too. I see some people talking about Swarm vs Kubernetes. Swarm has always maintained a less modular a…

I find that Swarm is the only thing that fits my use case of just shipping. There's so much complexity and overhead with kubernetes and often I just want something that works so I can ship it. You just can't beat Swarm for building an insta-cluster that works well and quickly gets you where you want to be. I'm sure kubernetes is great if you have forty datacenters around the globe, but I don't, and neither does anybo…

[deleted]

Re: Docker for Mac with Kubernetes

#52

Post by kuschku »

xorcist wrote: post #32
sz4kerto wrote: post #13

Earlier quoted context omitted.

No, it didn't. Yes, k8s has 'won' in large-scale deployments, but if you're working at a small shop, then just imitating what Google does with millions of servers is dumb. Do what works at your scale -- and Swarm is extremely easy to manage. Many people ask why would someone use an orchestrator on a small cluster (dozens of hosts). Why not? Swarm is very easy to manage and maintain, using Puppet or Ansible is not les…

> Swarm is very easy to manage and maintain, using Puppet or Ansible is not less complicated The idea that dockerized software somehow is less dependent on configuration management seems to be a popular and completely misguided one. The two trends are completely separate, but I would argue from experience that unless you have absolutely nailed the configuration and integration of all your moving parts, don't even loo…

Thanks to CoreOS containerLinux, you don’t really need Puppet or Ansible. You specify your Ignition config, and just drop it as a tiny partition on the servers, and drop the OS onto a separate, adjecent partition, and then have local storage even separately. Commonly you use PXE to avoid having these locally.

Then everything you do on top of that is handled by the container scheduler, and your containers.

Re: Docker for Mac with Kubernetes

#53

Post by linkmotif »

pacavaca wrote: post #12
sandGorgon wrote: post #7

Earlier quoted context omitted.

Your docker compose yml is trivially reusable for Swarm. We run it in production and is spectacular . The complexity overhead of kubernetes may be premature when you don't have massive requirements

That's the thing, we use k8s in production and I just used docker-compose for testing in my device environment for the sake of simplicity. Though over time it became not so simple to maintain two parallel config as the system grown up.

Helm makes this easy. It’s great, just use the templating features and not the package management stuff.

Re: Docker for Mac with Kubernetes

#54

Post by jsjohnst »

sz4kerto wrote: post #13
pacavaca wrote: post #2

Wow! Did Docker give up swarm? I thought there was a time when Docker didn't like the existence of k8s all that much. Anyways, I envision this being very useful for development, may even replace my docker-compose based test setup.

No, it didn't. Yes, k8s has 'won' in large-scale deployments, but if you're working at a small shop, then just imitating what Google does with millions of servers is dumb. Do what works at your scale -- and Swarm is extremely easy to manage. Many people ask why would someone use an orchestrator on a small cluster (dozens of hosts). Why not? Swarm is very easy to manage and maintain, using Puppet or Ansible is not les…

> people ask why would someone use an orchestrator on a small cluster (dozens of hosts)

I’d love to know who these mythical folks are?

1) dozens of hosts (heck, hosts >1) is exactly why you need orchestration

2) while there are huge deployments across the globe, I wouldn’t consider “dozens of hosts” small by no means. That’s actually probably above average.

3) k8s is actually easier to maintain than you allude. I see these comments about Swarm over k8s generally from folks who never even tried it (or did so years ago), is that the case here?

Re: Docker for Mac with Kubernetes

#55

Post by linkmotif »

So confused by all the posts from people who say they run Swarm because kubernetes is too complicated or is only for huge deployments.

I’ve had all sort of difficulties installing Docker. By hand it’s not trivial to get a secure install. Docker machine is great except it’s often broken. The Docker machine dev team is a tired, understaffed bunch that’s always playing a sisyphean whack-a-mole against dozens of cloud providers and very needy posters on Github, myself included.

Kubernetes on the other hand is trivial with GKE. It’s great for single node deployments. I run a single node on GKE and it’s awesome, easy, and very cheap. You can even run preemptible instances. The myth that kubernetes is complicated is largely perpetuated by the same kind of people who say React is complicated: the people who’ve not tried it.

And like React, once you try kubernetes you never go back. Kubernetes is actually the orchestration equivalent of React. You declare what should be true, and Kubernetes takes care of the rest.

And the features it provides are useful for any-sized application! If you try kubernetes you quickly discover persistent volumes and statefulsets, which take away most of the complexities out of stateful applications (ie most applications). You also discover ingress resources and controllers, which make trivial so many things that are difficult with Swarm, like TLS termination. Swam doesn’t have such features, which any non-trivial app (say, Django, wordpress, etc) benefits from tremendously.

Re: Docker for Mac with Kubernetes

#56

Post by bradmwalker »

sz4kerto wrote: post #13
pacavaca wrote: post #2

Wow! Did Docker give up swarm? I thought there was a time when Docker didn't like the existence of k8s all that much. Anyways, I envision this being very useful for development, may even replace my docker-compose based test setup.

No, it didn't. Yes, k8s has 'won' in large-scale deployments, but if you're working at a small shop, then just imitating what Google does with millions of servers is dumb. Do what works at your scale -- and Swarm is extremely easy to manage. Many people ask why would someone use an orchestrator on a small cluster (dozens of hosts). Why not? Swarm is very easy to manage and maintain, using Puppet or Ansible is not les…

The future of Docker, Inc. is being an Oracle acquisition.

Re: Docker for Mac with Kubernetes

#57

Post by jsjohnst »

kuschku wrote: post #52
xorcist wrote: post #32

Earlier quoted context omitted.

> Swarm is very easy to manage and maintain, using Puppet or Ansible is not less complicated The idea that dockerized software somehow is less dependent on configuration management seems to be a popular and completely misguided one. The two trends are completely separate, but I would argue from experience that unless you have absolutely nailed the configuration and integration of all your moving parts, don't even loo…

Thanks to CoreOS containerLinux, you don’t really need Puppet or Ansible. You specify your Ignition config, and just drop it as a tiny partition on the servers, and drop the OS onto a separate, adjecent partition, and then have local storage even separately. Commonly you use PXE to avoid having these locally. Then everything you do on top of that is handled by the container scheduler, and your containers.

> Commonly you use PXE to avoid having these locally.

I’ve not seen PXE used anywhere that the DC wasn’t O&O (or essentially close to it). As that’s the exception to the rule these days, isn’t your premise a bit cavalier?

I’ve used PXE a lot in my past [0] to great benefit (well, more specifically iPXE through chainloading), so I’m not detracting from it, just saying it’s applicability is limited for most folks.

[0] I wrote “Genesis” for Tumblr which handled initial machine provisioning from first power-on after racking to being ready for deploys.

Re: Docker for Mac with Kubernetes

#58

Post by kuschku »

jsjohnst wrote: post #57
kuschku wrote: post #52

Earlier quoted context omitted.

Thanks to CoreOS containerLinux, you don’t really need Puppet or Ansible. You specify your Ignition config, and just drop it as a tiny partition on the servers, and drop the OS onto a separate, adjecent partition, and then have local storage even separately. Commonly you use PXE to avoid having these locally. Then everything you do on top of that is handled by the container scheduler, and your containers.

> Commonly you use PXE to avoid having these locally. I’ve not seen PXE used anywhere that the DC wasn’t O&O (or essentially close to it). As that’s the exception to the rule these days, isn’t your premise a bit cavalier? I’ve used PXE a lot in my past [0] to great benefit (well, more specifically iPXE through chainloading), so I’m not detracting from it, just saying it’s applicability is limited for most folks. [0]…

Using PXE (or, rather, iPXE) is the recommended deploy mode for container linux, that's why I mentioned it.

Re: Docker for Mac with Kubernetes

#60

Post by dominotw »

linkmotif wrote: post #55

So confused by all the posts from people who say they run Swarm because kubernetes is too complicated or is only for huge deployments. I’ve had all sort of difficulties installing Docker. By hand it’s not trivial to get a secure install. Docker machine is great except it’s often broken. The Docker machine dev team is a tired, understaffed bunch that’s always playing a sisyphean whack-a-mole against dozens of cloud pr…

GKE=Google cloud?

I don't understand ur comment, yea using something in preinstalled in the cloud is easier than installing something on your own.

Post reply on HN