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

Docker Compose Isn't Enough

blog.tealok.tech

Post reply on HN
Print view View original

181–190 of 208 posts

Re: Docker Compose Isn't Enough

#181

Post by soneil »

eliribble wrote: post #130
dizhn wrote: post #116

Earlier quoted context omitted.

(Not parent) The quickest way I could do it is if I just used my existing wireguard setup to directly access the docker container IP. In that case it's just one compose up away even without mapping/exposing ports.

Thanks, interesting. Sounds like your container has some kind of side-car that makes it directly addressable over Wireguard without needing to address the host IP. Does that mean you'd need to modify the docker-compose in some way before `docker-compose up`? How do you know which port Paperless is using for HTTP? When you want to load up Paperless in a web browser, are you typing in a service name, or the container I…

It took me a moment to put this together too, so to be clearer - the wireguard endpoint is in docker, so you're adding the docker bridge to your vpn. So DNS is handled by docker, just as containers can already address each other by name - you're on the container network with them.

Re: Docker Compose Isn't Enough

#182

Post by nunez »

I'm having this problem now with our home automation stack. Compose is super easy to start with but scales poorly and makes things like "I want to access this service at https://foo.bar instead of http://somehost:61234, no HTTPS because the app doesn't support it natively and I don't have time to roll nginx."

Kubernetes makes this so easy once you get past the YAML and abstractions, so I'll probably FINALLY move this stack over to it. Long overdue.

And this is coming from someone who for the longest time recommended that developers new to containers start with compose before considering Kubernetes!

Re: Docker Compose Isn't Enough

#183

Post by chipdart »

papichulo2023 wrote: post #156
chipdart wrote: post #148

Earlier quoted context omitted.

> Most people dont need rolling release, 24/7 availability, auto scaling, etc.. That's perfectly fine. That's not the reason why you are better off running your apps in Kubernetes though. You are better off running your apps in Kubernetes because it handles everything you ever need to effortlessly run containerized apps. You don't even need to install tooling or deployment tools or anything at all. You can have a sin…

> You don't need to bother with anything else. Hey that is not true, at least last time I tried I spent considerable time trying to integrate a bare metal load balancer from a 9 stars github repo plugin because apparently exposing the port is not recommended. Also having the master and the node in the same server can be problematic because by design it shouldnt be like. One last point, the runtime ram and cpu overhea…

> Hey that is not true, at least last time I tried I spent considerable time trying to integrate a bare metal load balancer from a 9 stars github repo plugin because apparently exposing the port is not recommended.

You sound like you tried to put together an ad-hoc ingress controller without knowing what an ingress controller is and why abusing NodePort is a mistake in the context of a cluster.

You can check this out to go through the basics.

https://kubernetes.io/docs/concepts/services-networking/ingr...

> Also having the master and the node in the same server can be problematic because by design it shouldnt be like.

You should look at the problem to see if an approach makes sense. If you're using vanilla Kubernetes on a one-box deployment then you're abusing a large-scale high-scalable cluster management system by shoving it into a single box. It can work, but most of the resources will be wasted on managing your cluster of one node.

There are plenty of Kubernetes distributions that are designed to handle well small clusters, and even one-box systems. Minikube, microk8s, and even k3s come to mind. I'm partial towards microk8s because installing it is just a matter of installing a single package from the distro's official repository.

Re: Docker Compose Isn't Enough

#185

Post by ChocolateGod »

stryan wrote: post #176
orf wrote: post #174

Earlier quoted context omitted.

What’s the advantage of configuring, testing and maintaining all of that instead of a 10 line Kubernetes manifest that does more?

Not having to install and manage Kubernetes? Unless you're paying someone else to run it for you (in which case this entire conversation is sort of moot as that's way out of scope for comparison) that stuff is all still running somewhere and you have to configure it. e.g. even in small-scale setups like k3s you have to set up shared storage or kube-vip yourself for true high availability. It's not some magic bullet f…

You can always use something like Docker Swarm or Nomad which achieves the same end result as Kubernetes (clustered container applications) without the complexity of having to manage Kubernetes.

Re: Docker Compose Isn't Enough

#186

Post by anonzzzies »

orf wrote: post #172
anonzzzies wrote: post #154

Earlier quoted context omitted.

We run large, auto scaling clusters with compose and a small orchestration thing we have been using since the 90s (written in perl) (before compose we had our own compose-like with chroot). No issues. For decades.

Cool - everyone knows it’s possible to hack together something, or anything else. But Is it a good idea to spend time and resources starting to do that now if you haven’t been doing it with a sketchy Perl script since the 90s? Not really.

You do you. I think k8s is overly complicated stuff that almost no companies (outside google/meta/etc) need and some peopple here peddle for some reason. That's fine. We like making profit instead of waste time with the latest nonsense.

I don't think it's a good idea to spend time and resources learning complexity you never need. You are probably going to say that's not true as your cloud hoster has this all set up, but yeah, that's where the making profits comes in. We save millions/year on not cloud hosting. And managing your own k8s cluster apparently is quite hard (at least that's what even the fanboiz here say).

Starting today, I would use Go probably instead of Perl, but I would do the same. It's much simpler than kubernetes. But sure; for our goals; we like simplicity and don't need resumes to drive.

Re: Docker Compose Isn't Enough

#187

Post by hamandcheese »

chefandy wrote: post #96
hamandcheese wrote: post #81

Earlier quoted context omitted.

> to solve their problems without having to write executable code. Some people would rather write 1000 lines of yaml than 100 lines of python, and I really don't understand why.

It brings a new layer of complexity, which means more surface area for bugs and vulnerabilities. It’s often easier for developers to write a script using standardized tooling than dig into deep configuration docs for a complex application you’re not familiar with, but that’s where the benefits stop. Configuring built-in functionality makes sense for the same reason using an existing framework/os/etc authentication sy…

This is a hilarious take given the overwhelming number of outages that are caused by "bad config".

If you can't code, then yeah, I bet config is easier. But as a person who codes every day, I much prefer something that I can interact with, test, debug, type check, and lint _before_ I push to prod (or push anywhere, for that matter).

Re: Docker Compose Isn't Enough

#188

Post by dizhn »

eliribble wrote: post #130
dizhn wrote: post #116

Earlier quoted context omitted.

(Not parent) The quickest way I could do it is if I just used my existing wireguard setup to directly access the docker container IP. In that case it's just one compose up away even without mapping/exposing ports.

Thanks, interesting. Sounds like your container has some kind of side-car that makes it directly addressable over Wireguard without needing to address the host IP. Does that mean you'd need to modify the docker-compose in some way before `docker-compose up`? How do you know which port Paperless is using for HTTP? When you want to load up Paperless in a web browser, are you typing in a service name, or the container I…

I can already directly access the docker network because it's in the allowedips setting of wireguard. But for convenience, yes, when I do get a docker-compose.yml file I change 127.0.0.1 IPs to that of the wireguard interface IP. (I can leave 0.0.0.0 IPs as is because this host does not have a public IP) This way I am exposing the ports, but I am exposing them in a way that they are not world-accessible but still accessible to me conveniently.

For services open to the public internet I just add a subdomain + a reverse proxy entry into an existing caddy instance and point to the docker IP.

Re: Docker Compose Isn't Enough

#189

Post by dizhn »

soneil wrote: post #181
eliribble wrote: post #130

Earlier quoted context omitted.

Thanks, interesting. Sounds like your container has some kind of side-car that makes it directly addressable over Wireguard without needing to address the host IP. Does that mean you'd need to modify the docker-compose in some way before `docker-compose up`? How do you know which port Paperless is using for HTTP? When you want to load up Paperless in a web browser, are you typing in a service name, or the container I…

It took me a moment to put this together too, so to be clearer - the wireguard endpoint is in docker, so you're adding the docker bridge to your vpn. So DNS is handled by docker, just as containers can already address each other by name - you're on the container network with them.

I don't actually do this. I either access the services by IP or add a private IP to dns. (I think this is not widely supported but cloudflare does support it.)

Your explanation is interesting though. Would that actually work?

Re: Docker Compose Isn't Enough

#190

Post by leosarev »

I also think that both docker-compose & k8s & helm are wrong layer of abstraction. I see a lot of people building a opinionated way to run containers and way for them to communicate with another, to request a DB or a redis.

I like to name some such attempts: - .NET Aspire - Avito Plato (home grown PaaS of ¨russian Amazon") - infrastructure layer of our ZIIoT (MES platform on top of k8s)

Post reply on HN