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

151–160 of 169 posts

Re: Docker for Mac with Kubernetes

#151

Post by xorcist »

amazingman wrote: post #148
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…

If you design your infrastructure and choose your tooling well, then containerized (not "dockerized") software is far less dependent upon configuration management; indeed, using Chef/Puppet/etc can be completely unnecessary for the containerized workload . To be clear, however, there is absolutely still a need for the now-traditional configuration management layer at the level of the hosts running your containerized…

> indeed, using Chef/Puppet/etc can be completely unnecessary for the containerized workload

This is more than naive. As long as your software needs any kind of configuration, there is a need for configuration management. There will be access tokens, certificates, backend configuration, partner integration of various kinds, and monitoring and backup configuration and you will want guarantees that these are consistent for your various testing and staging environments. You will want to track and bisect changes. You can either roll your own framework for this or use Ansible/Puppet.

Whether you distribute your software pieces with tar balls, linux packages or docker images or completely orthogonal to how you tie these pieces to a working whole. And the need for configuration management absolutely increases when moving towards containerized solutions, not by the change in software packaging format but by the organizational changes most go through where more people are empowered to deploy more software which can only increase integration across your environment.

I see organizations that have ignored this because they believe this magic container dust will alleviate the need of keeping a tight grip over what they run, and find themselves with this logic spread over their whole toolchain instead. That's when they need help cleaning up the mess.

Re: Docker for Mac with Kubernetes

#152

Post by breeny592 »

kuschku wrote: post #142
pacala wrote: post #133

Earlier quoted context omitted.

Exactly. Hardware rental is one way to tackle provisioning. You're still left with all the other tasks required to bootstrap your own datacenter. As you build up the roll-your-own solution, you end up in the same place: hire IT headcount. If you are a small startup looking to validate market fit, your best bet is Cloud + Kubernetes. If you are an established business with millions of daily customers and serious IT he…

> Exactly. Hardware rental is one way to tackle provisioning. You're still left with all the other tasks required to bootstrap your own datacenter. As you build up the roll-your-own solution, you end up in the same place: hire IT headcount. For a startup, building a datacenter isn’t required in the beginning. I meant, literally renting existing hardware, in an existing datacenter. This is just a single step from rent…

I think pacala's point still stands - if you rent hardware, there is still a larger effort involved around running scalable services (DR, auto-scaling/load balancing, deployments etc). If you rent hardware, you likely will need a larger dedicated % of resources dedicated to maintaining that, over OOTB service providers.

Edit: got user names wrong

Re: Docker for Mac with Kubernetes

#153

Post by moondev »

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…

I agree for the most part, but kubernetes orchestrates docker (for now). It's also much easier to install than full blown k8s

Re: Docker for Mac with Kubernetes

#154

Post by ecnahc515 »

jsjohnst wrote: post #62
kuschku wrote: post #58

Earlier quoted context omitted.

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

> Using PXE (or, rather, iPXE) is the recommended deploy mode for container linux Really? Is that a new thing? I don’t remember that last time I was reading the docs, but maybe I missed it (that it’s the “preferred” method rather than being just “an option”). Seems rather odd to limit your audience like that in the age of “cloud everything” as I think it’s generally more rare that folks fully control their layer 2, b…

Network booting combined with good out of band management controls allows fully automated provisioning of nodes in a baremetal setup, so I don’t see how this is a negative? The alternative is a live cd/usb or attaching a disk with something already preinstalled.

If you’re on prem with VMware or openstack there’s better options which you can use, but that’s not exactly baremetal. in those environments CoreOS recommends using different provisioning options more suited for those providers.

Re: Docker for Mac with Kubernetes

#155

Post by mholt »

nemothekid wrote: post #110
dominotw wrote: post #92

Earlier quoted context omitted.

>I have used DC/OS, Mesos, and Marathon extensively Would you use DC/OS-marathon (vs k8s) now if you were to make that decision now. I've heard that mesos stack is good for machine learning/big data stacks but how does marathon compare for deploying webapps.

I've run 2 Mesos stacks in production and have experience setting up a k8s stack (on prem). First off in my experience k8s ops is way more complex that the DC/OS stack. I recently setup a new DC/OS deployment (80% of the cluster resources was Spark, which works natively with Mesos and I'd rather run the ancillary services on Marathon, then spend another 80% of my time on k8s). If I didn't have the Spark requirement I…

From me, an eternal thank-you for upgrading Caddy's proxy middleware!

Re: Docker for Mac with Kubernetes

#156

Post by jlawer »

linkmotif wrote: post #118
tokenizerrr wrote: post #99

Earlier quoted context omitted.

You're running on GKE. Of course that's easy, they're handling all the difficult parts for you! It's still not that difficult running it on your own servers, but there are many more pain points. Please get some experience with that, then re-evaluate whether Docker or Kubernetes is easier for small deployments.

Right, I agree. But with your easier Swarm setup, how do you then attach cloud disks directly to your docker container, like a PersistentVolume affords? That one feature makes basically anything worth it, IMO. Most apps are stateful.

NFS mounts, provisioned via the same configuration management platform the hardware is provisioned by (Saltstack in my case)

Re: Docker for Mac with Kubernetes

#157

Post by bonesss »

pacala wrote: post #101
drdaeman wrote: post #77

Earlier quoted context omitted.

> Kubernetes on the other hand is trivial with GKE How do I install GKE on my servers? ;) > By hand it’s not trivial to get a secure install. The default install (basically, adding a repo and apt-get install docker-ce on Debian and derivatives - trivial to automate with Ansible) is reasonably secure if you view Docker as a tool for packaging and task scheduling with some nice extras and don't buy the marketed isolati…

> How do I install GKE on my servers? ;) Great question! All major Cloud providers offer managed Kubernetes services: https://cloud.google.com/kubernetes-engine https://azure.microsoft.com/en-us/services/container-service https://aws.amazon.com/eks https://www.ibm.com/cloud/container-service The choice is Cloud + Kubernetes vs. roll everything on your own hardware. Running your own hardware is a major IT effort. Kube…

> Running your own hardware is a major IT effort. Kubernetes is just a part of that effort.

For Enterprise nerds VMWare has also just launched a Kubernetes service, so the #1 Enterprise VM supplier just added k8s on-prem for everyone who is in a hybrid cloud situation.

Re: Docker for Mac with Kubernetes

#158

Post by amazingman »

xorcist wrote: post #151
amazingman wrote: post #148

Earlier quoted context omitted.

If you design your infrastructure and choose your tooling well, then containerized (not "dockerized") software is far less dependent upon configuration management; indeed, using Chef/Puppet/etc can be completely unnecessary for the containerized workload . To be clear, however, there is absolutely still a need for the now-traditional configuration management layer at the level of the hosts running your containerized…

> indeed, using Chef/Puppet/etc can be completely unnecessary for the containerized workload This is more than naive. As long as your software needs any kind of configuration, there is a need for configuration management. There will be access tokens, certificates, backend configuration, partner integration of various kinds, and monitoring and backup configuration and you will want guarantees that these are consistent…

I never said anything about magic container dust, nor did I say anything about having less of a grip over our operations. I was attempting to make a point about how your workloads themselves (applications/jobs) can be free of a direct need for Chef/Puppet/etc, which can dramatically simplify your configuration management layer. I never intended to claim that somehow magically our pods need no configuration bits at all, and honestly I’m not sure where you got that idea.

Re: Docker for Mac with Kubernetes

#159

Post by sandGorgon »

StavrosK wrote: post #145
sandGorgon wrote: post #140

Earlier quoted context omitted.

No - you don't need it to be swarm aware at all. All you need to do is create a docker service out if traefik/nginx/haproxy/whatever and bind the ports of the service to type "ingress". From then on, all traffic is internal - and you deal with it normally from one docker service to another.

Ah, okay, so pretty agnostic. Sounds like this is geared towards single project deployments, though (ie it wouldn't be suited in a multitenant scenario), but that's good to know. I've been looking for a Dokku replacement for running my side-projects on with easy scalability (by provisioning another server), but I haven't found anything that's suitable for running multiple apps together in a heroku-like way but still…

but that is what swarm is - swarm is fully production ready to scale to tons of servers and works brilliantly on a single server as well. Not sure why you think swarm wouldnt fit the bill ?

Re: Docker for Mac with Kubernetes

#160

Post by StavrosK »

sandGorgon wrote: post #159
StavrosK wrote: post #145

Earlier quoted context omitted.

Ah, okay, so pretty agnostic. Sounds like this is geared towards single project deployments, though (ie it wouldn't be suited in a multitenant scenario), but that's good to know. I've been looking for a Dokku replacement for running my side-projects on with easy scalability (by provisioning another server), but I haven't found anything that's suitable for running multiple apps together in a heroku-like way but still…

but that is what swarm is - swarm is fully production ready to scale to tons of servers and works brilliantly on a single server as well. Not sure why you think swarm wouldnt fit the bill ?

From what I saw, it's not very easy to have a deployment with multiple applications on the swarm, is that wrong?

For example, I have ten applications, and each requires a database, a redis instance, a celery instance and two web workers. Dokku lets me deploy these independently of each other, but uses the same nginx instance and proxies them transparently.

As I understand it, Swarm has no notion of multiple projects. Each swarm is running a single deployment, where all containers are equal, is that correct?

Basically, Dokku is a self-hosted Heroku, which is what I need (I want to be able to easily create a project that I can run semi-independently of the others on the same server). My understanding is that, to do that with Swarm, I'd have to have a single termination container that would connect to every app, but apps wouldn't be any more segregated than that. Maybe I'm complicating things, though. Have you used Swarm for such a use case?

I tried the official tutorial, but couldn't get it to work, as the instructions appeared outdated and didn't work for single-host deployments, and were geared more towards Windows and Mac than Linux. Would you happen to have a good "getting started" document? All my apps are already using docker-compose.

EDIT: Also, a machine that's a manager doesn't want to join the swarm as a worker as well, that's why I'm saying that it doesn't appear good for single-server deployments:

> Error response from daemon: This node is already part of a swarm. Use "docker swarm leave" to leave this swarm and join another one.

Post reply on HN