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

161–169 of 169 posts

Re: Docker for Mac with Kubernetes

#161

Post by tmzt »

amazingman wrote: post #147
driton wrote: post #82

Earlier quoted context omitted.

Have you ever tried docker-compose? While the two solutions are obviously with different goals in mind, one being to fully run the kubernetes setup locally, and the other one to run a few docker containers who talk to one another, if it's for the purpose of running a simple-ish dev environment, in my experience, docker-compose is much faster and simpler than minikube.

docker-compose trades a better initial UX for far less flexibility and, funnily enough, higher practical complexity in the long run. It's great if you want to get from zero to MVP with as little thinking about what your infrastructure needs will be as possible. It's pretty awful, however, when you want to truly productionalize what you've done and you find out that in order to do so you'll have to use the newest Comp…

If you want a single file configuration on k8s, take a look at kedge.org

It's basically an extended version of native k8s yaml with some smart defaults and grouping resources similar to compose.

Re: Docker for Mac with Kubernetes

#162

Post by amazingman »

tmzt wrote: post #161
amazingman wrote: post #147

Earlier quoted context omitted.

docker-compose trades a better initial UX for far less flexibility and, funnily enough, higher practical complexity in the long run. It's great if you want to get from zero to MVP with as little thinking about what your infrastructure needs will be as possible. It's pretty awful, however, when you want to truly productionalize what you've done and you find out that in order to do so you'll have to use the newest Comp…

If you want a single file configuration on k8s, take a look at kedge.org It's basically an extended version of native k8s yaml with some smart defaults and grouping resources similar to compose.

One could also just use one file with multiple YAML objects delimited by “\n—-\n”. The Kedge stuff looks moderately interesting, and I definitely would have found it useful a year ago. Now, though, I seem to have developed a begrudging admiration for the “native” YAML format. Maybe it’s Stockholm Syndrome, but once I finally began to understand Kubernetes I began to find the verbose YAML format to be a benefit rather than a barrier.

Re: Docker for Mac with Kubernetes

#163

Post by sandGorgon »

StavrosK wrote: post #160
sandGorgon wrote: post #159

Earlier quoted context omitted.

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

the docker stack deploy command does automatic diffing of which services have changed. So your deploys are automatically optimized. This is generally the philosophy of Swarm vs kubernetes - everything is built in. You can argue this is less powerful, but in general it works brilliantly. In so far as separating out the different "applications", you simply put them on a separate overlay network (encrypted if you want).

Also, if you are dead-set on making them entirely separate, every separate "application" is a separate "Stack". So you can stack deploy them separately.

If I had to do what you just told me - single nginx proxying to two different "applications" - i would do this. 1. stack 1 - application 1 + network 1 2. stack 2 - application 2 + network 1 3. stack 3 - nginx + network 1

now you can deploy any of them independently. You can make this even more sophisticated by having each stack on a different overlay network (encrypted as well). And nginx bridging between them.

Not sure why you are facing problem with the official tutorial - btw, a manager is a worker ;) I have a fairly large dev swarms on a single node.

Re: Docker for Mac with Kubernetes

#164

Post by xorcist »

amazingman wrote: post #158
xorcist wrote: post #151

Earlier quoted context omitted.

> 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 a…

The statement was that containerized workloads are less dependent on configuration management. That could easily be interpreted as if configuration management gets less important when you containerize, which is an idea that seems to spread easily on its own, while I have found the complete opposite to be true. That's why number one guideline is to get a grip on your infrastructure and configuration before you move to containers. Otherwise you will end up with a mess worse than before.

Re: Docker for Mac with Kubernetes

#165

Post by Bgd1 »

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.

You use one of the Docker plugins: https://docs.docker.com/docker-for-aws/persistent-data-volum... https://github.com/thecodeteam/rexray

Re: Docker for Mac with Kubernetes

#166

Post by Bgd1 »

linkmotif wrote: post #120
Axsuul wrote: post #109

Earlier quoted context omitted.

Yet with a Docker Swarm setup, you could get away with probably 10 dollars/month. K8s likely taking more resources than your app containers is why k8s may not be the best option for single node deployments. I've personally tried both orchestration options and much prefer Swarm to smaller deployments. Sure k8s could prepare you better for the future if your app takes off to the moon but that's just premature optimizat…

This might all very well be true, but Swarm doesn’t let you connect cloud disks directly to your containers, to my knowledge. Also I challenge the $10 because what cloud instances plus ancillary services add up to $10? I’m talking 2 CPUs and 7.5gb RAM.

It does. Check out Docker volume plugins like: https://docs.docker.com/docker-for-aws/persistent-data-volum... https://github.com/thecodeteam/rexray

Re: Docker for Mac with Kubernetes

#167

Post by xchaotic »

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…

you still have to go from bare metal in someone else's DC to having you software running on top of it, who's going to do all that config work? You're spending resources either way.

Re: Docker for Mac with Kubernetes

#168

Post by kuschku »

xchaotic wrote: post #167
kuschku wrote: post #142

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

you still have to go from bare metal in someone else's DC to having you software running on top of it, who's going to do all that config work? You're spending resources either way.

As I said before, thanks to container linux, that's 3 lines in a json config.

I've deployed a handful of servers automatically myself this way, and I'm still a student.

Saving about an order of magnitude in terms of costs, gaining flexibility, and the only additional work is so low that it costs a compsci student half an hour once (aka ~10€ in wages) — there's no reason not to do it.

Re: Docker for Mac with Kubernetes

#169

Post by faisyl »

StavrosK wrote: post #160
sandGorgon wrote: post #159

Earlier quoted context omitted.

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

Swarm is nice as-is but is, but really shines with support like docker-swarm-proxy. Please check out http://proxy.dockerflow.com/. It allows for automatic service discovery as well as routing/termination etc. It also runs as a stack on swarm itself. Supports custom TLS termination as well as SNI routing.
Post reply on HN