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

141–150 of 208 posts

Re: Docker Compose Isn't Enough

#141

Post by eliribble »

WifiAdapter wrote: post #17

After reading it I don't get what the author is trying to tell me. Docker compose works just fine for what it's made. I can have multiple different docker containers (deployed with compose) all with the same port and just use Traefik to route the requests, without having to change the default ports or even use ipv6. What am I missing?

Interesting, I wasn't aware that Traefik could do this without significant modification to the docker-compose configuration provided by the application developer. I also thought that Traefik required some sort of higher-level container orchestration like Docker Swarm or Kubernetes.

I'll have to look in to that.

Re: Docker Compose Isn't Enough

#142

Post by number6 »

eliribble wrote: post #93
number6 wrote: post #85

Earlier quoted context omitted.

Sounds more like a skill issue. I am quite glad with traeffik and docker-compose. But I don't have that high loads or interactions on my servers

How many steps is it for you to add a new service to your system? Say you wanted to try out Paperless NGX, what would you need to do?

Add the labels to the docker-compose file and then run it.

I regularly try out new services or tools with docker-compose

Re: Docker Compose Isn't Enough

#143

Post by trvdex »

number6 wrote: post #142
eliribble wrote: post #93

Earlier quoted context omitted.

How many steps is it for you to add a new service to your system? Say you wanted to try out Paperless NGX, what would you need to do?

Add the labels to the docker-compose file and then run it. I regularly try out new services or tools with docker-compose

[dead]

Re: Docker Compose Isn't Enough

#144

Post by eliribble »

raphinou wrote: post #139

I am particularly happy with docker swarm with traefik as described here: https://dockerswarm.rocks/traefik/ Incredibly easy to setup and manage for usual small scale deployments. I use it as one node swarms, and I have setup - backups - automatic https certificates setup and renewal - automatic upgrades to new images - easy setup of persistence of data on the server I'm very surprised it is not more popular, with qu…

Looks like https://dockerswarm.rocks says that the site is deprecated.

https://dockerswarm.rocks/swarm-or-kubernetes/ says "it's not sensible to build a new product using Docker Swarm Mode"

Re: Docker Compose Isn't Enough

#145

Post by kentonv »

eliribble wrote: post #105
lolinder wrote: post #34

Earlier quoted context omitted.

It's more than just a runtime for running containers, from the main landing page it looks like they're really specifically targeting self-hosting for the barely-technical [0]. In that context this article makes some degree of sense: their target audience will probably be legitimately overwhelmed by that pihole example and wouldn't know how to write a Python script to save their life. If they can pull it off more powe…

I'm actually a fan of Sandstorm, and think it got a lot of things right. I'd love to be able to talk to Kenton Varda about why he thinks adoption on it was weak. Personally I think that it put a bit too much burden on application developers since it required them to develop applications specifically for sandstorm . > I'm skeptical that what the non-technical self-hoster needs is a TOML DSL that abstracts away ports I…

> I'd love to be able to talk to Kenton Varda about why he thinks adoption on it was weak.

Oh hai.

Honestly I'm not sure I'm a reliable source for why we failed. It's tempting to convince myself of convenient excuses.

But I really don't think the problem was with the idea. We actually had a lot of user excitement around the product. I think we screwed up the business strategy. We were too eager to generate revenue too early on, and that led us to focus efforts in the wrong areas, away from the things that would have been best for long-term growth. And we were totally clueless about enterprise sales, but didn't realize how clueless we were until it was too late (a classic blunder). Investors really don't like it when you say you're going to try for revenue and then you don't, so we were pretty much dead at that point.

Re: Docker Compose Isn't Enough

#146

Post by chipdart »

hifromwork wrote: post #101
chipdart wrote: post #72

Earlier quoted context omitted.

> I'd say its 100% production ready. That's fine. Some people also manually launch containers individually with Docker as their production system. They'd be wasting their time and making their lives needlessly harder, though. They already have tools that do all the legwork for them. Why not do the research and opt to force a square peg into a round hole? Research Docker swarm mode, reverse proxies like Traefik, and L…

>They'd be wasting their time and making their lives needlessly harder, though. Using Kubernetes where it's not needed is just that - wasting your time and making your life harder. Before you say that I just need to research more: I know Docker swarm mode, I run my personal server on Kubernetes using Traefik and Let's Encrypt, I professionally work with Kubernetes (both as an admin and working on Kubernetes security,…

> Using Kubernetes where it's not needed is just that - wasting your time and making your life harder.

I think this is a very ignorant and misguided take.

Kubernetes is a container orchestration system, just like Docker swarm mode or even Docker compose. If you need to deploy sets of containerized apps into your own VMs, you can pick up any Kubernetes implementation. You don't even need Helm or anything. Plain old kustomize scripts will do. Some aren't even longer than a docker-compose.yml.

More to the point, Kubernetes is an interface. One that you can use in local deployment and in major cloud providers.

You should really check your notes because your comments contrast with the realities of actually running a service.

> Before you say that I just need to research more: (...)

All your appeals to authority are falsified by your claims.

I, on the other hand, actually use Kubernetes both professionally and in personal projects, as well as Docker swarm mode, and can tell you I'm no uncertain terms that none of your points have any traction in reality.

> I still claim that there are production usecases that are better served by docker-compose.

I'm sorry, but your comments simply sound deeply uninformed and misguided.

I mean, it makes absolutely no sense to comment on using docker compose in production when Docker swarm mode is far more capable and Docker swarm mode stacks already share most of the schema with docker compose. You literally have virtually nothing to do to adapt a docker-compose script to launch a stack.

Unbelievable.

Re: Docker Compose Isn't Enough

#147

Post by therealfiona »

raphinou wrote: post #139

I am particularly happy with docker swarm with traefik as described here: https://dockerswarm.rocks/traefik/ Incredibly easy to setup and manage for usual small scale deployments. I use it as one node swarms, and I have setup - backups - automatic https certificates setup and renewal - automatic upgrades to new images - easy setup of persistence of data on the server I'm very surprised it is not more popular, with qu…

I love Swarm and don't see the appeal of K8s when something as simple as Swarm exists. I do however run K8s in prod for work and would never run Swarm in prod due to Docker seeming to have its days numbered. Idk where that leaves us aside from ECS. But I also have no need to run something any more robust than ECS in AWS for my workload.

We are moving our EKS workload over to ECS over the next year. I expect needing to down size my team because of it.

One thing K8s is not is cheap. That shit takes a well oiled team or a couple of hot shots so do right. We probably did a lot of what makes it expensive to ourselves by not switching to managed add-ons sooner and never evolving the apps that run in the cluster. I've only been lead for about 5 months now, but I'm finally able to start making significant progress on the necessary evolution that I've been trying to make happen for 2 years before my promotion. The enterprise is a big ship. Takes time to turn. Thanks for reading what turned into a rambling vent session.

Re: Docker Compose Isn't Enough

#148

Post by chipdart »

papichulo2023 wrote: post #117
chipdart wrote: post #72

Earlier quoted context omitted.

> I'd say its 100% production ready. That's fine. Some people also manually launch containers individually with Docker as their production system. They'd be wasting their time and making their lives needlessly harder, though. They already have tools that do all the legwork for them. Why not do the research and opt to force a square peg into a round hole? Research Docker swarm mode, reverse proxies like Traefik, and L…

Most people dont need rolling release, 24/7 availability, auto scaling, etc.. on their home server, so managing k8s just add way more complexity. My main reason to not use is because I would need to host a artifact service somewhere else which is PITA. Some k8s runtime support local building but is not as easy as compose in my experience.

> 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 single kustomize script that defines your services and deployments, have in place an ingress and Let's Encrypt, and you're done. You don't need to bother with anything else. Just run kubectl apply and go grab a coffee.

Is this something no one would ever need?

Re: Docker Compose Isn't Enough

#149

Post by sebazzz »

wmf wrote: post #10
Izkata wrote: post #8

I've always understood docker-compose to be a development or personal tool, not for production. Is that not usually the case? Also aside, "docker compose" (V2) is different from "docker-compose" (V1) [0], it was rewritten and integrated into docker as a plugin. It should still be able to handle most old compose files, but there were some changes. [0] https://docs.docker.com/compose/releases/migrate/

For many people self-hosting implies a personal server; it's not really "development" but it's not "production" either. In that context many people find k8s or other PaaS to be too heavyweight so Docker Compose is pretty popular. For more production-oriented self-hosting there are various newer tools like Kamal but it will take a while for them to catch up.

On my personal home server I abuse Docker Compose so I don't have to use a huge command line to spin up/spin down containers but I can just say "docker compose up -d" and be done with it.

Re: Docker Compose Isn't Enough

#150

Post by eliribble »

kentonv wrote: post #145
eliribble wrote: post #105

Earlier quoted context omitted.

I'm actually a fan of Sandstorm, and think it got a lot of things right. I'd love to be able to talk to Kenton Varda about why he thinks adoption on it was weak. Personally I think that it put a bit too much burden on application developers since it required them to develop applications specifically for sandstorm . > I'm skeptical that what the non-technical self-hoster needs is a TOML DSL that abstracts away ports I…

> I'd love to be able to talk to Kenton Varda about why he thinks adoption on it was weak. Oh hai. Honestly I'm not sure I'm a reliable source for why we failed. It's tempting to convince myself of convenient excuses. But I really don't think the problem was with the idea. We actually had a lot of user excitement around the product. I think we screwed up the business strategy. We were too eager to generate revenue to…

Oh, hey, holy shit! You're one of my heroes. I've read through your internal discussions on protobuf within Google, you did amazing work there, and held your own against a difficult political environment.

It sounds like you have no criticism of the technical approach, then, but rather just the business mechanics? That's eye-opening, given how much has changed in self-hosted deployment since Sandstorm started. If you started something similar today, ignoring business needs, would you build something technically similar?

Post reply on HN