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

61–70 of 208 posts

Re: Docker Compose Isn't Enough

#61

Post by vunderba »

riffraff wrote: post #57
forrestthewoods wrote: post #39

Containers were a mistake. This is all radically more complicated than it needs to be. Running a computer program is not that complicated.

Being able to tell a fellow developer "do docker compose up and you can work" is a lot better than navigating them through the installation of a bunch of tools, each with their own quirks. I'm not convinced anyone below google needs kubernetes, but containers for quickly setting up and running something on my machine are a blessing.

Agreed. Running a modern "computer program" is more than just executing a single binary file.

When you have a open-source application with five or six moving parts (monitors, backend, a database, etc.) being able to deploy it to a VPS with a single docker compose and have them all containers act on an internal dockerized network without conflicting ports, etc. is a GOD SEND.

Re: Docker Compose Isn't Enough

#62

Post by tommica »

lolinder wrote: post #30
wmf wrote: post #9

Earlier quoted context omitted.

It's called content marketing. IMO this article is content marketing done right since it has useful information even if you don't read to the end.

Does it, though? It has a very brief introduction to Docker and Docker Compose, but then it mostly has a lot of FUD that's designed to scare people off of Docker Compose but is not remotely convincing to someone who's actually worked with it. The way they frame that pihole example ("Whew! That’s a lot of stuff!") is just silly. Looking at their website, I think they started out trying to make self-hosting really easy…

Anecdotal, but I learned stuff from this article

Re: Docker Compose Isn't Enough

#63

Post by Loic »

smaudet wrote: post #59
ricw wrote: post #14

So the problem is 1) port mapping and 2) backing up data volumes? There are simple solutions to each 1) you simple have a separate docker-compose file for a different environment, ie docker-compose.dev.yml for your dev server. in this file you simply define the parts that differ from the primary / prod compose file. that way it's a simple command. line variable that initiates a dev vs prod vs any other type. for deta…

I think 2) actually has the most merit. If you have a large number of e.g. temp files a container creates, retaining that file history may not be particularly valuable. Some sort of "hey back this data up, it's important to my function standard would be nice, and not just for container apps. Trying to figure out where your app hid its configuration and save files is a perennial user frustration.

I use the convention that all my containers are getting a /data/ folder where data can be stored and will get an automatic daily backup.

It is easy to set the right storage behind /data/.

Just a convention, nothing more, smoothly working for the past "many" years.

Re: Docker Compose Isn't Enough

#65

Post by denkmoon »

wmf wrote: post #9
oceanparkway wrote: post #4

Definitely burying the lede that Tealok is building an alternative to docker compose. Interesting

It's called content marketing. IMO this article is content marketing done right since it has useful information even if you don't read to the end.

Looks like a grift. Note the copyright on the Tealok page, then have a gander; https://gleipnirinc.com/investors

Re: Docker Compose Isn't Enough

#66

Post by shiroiushi »

forrestthewoods wrote: post #39

Containers were a mistake. This is all radically more complicated than it needs to be. Running a computer program is not that complicated.

Containers are a convenient work-around for the problem where programs have incompatible dependencies, and additionally the problem where security isn't as good as it should be.

For instance, you want to run one program that was written for Python 3.y, but also another program written for Python 3.z. You might be able to just install 3.z and have them both work, but it's not guaranteed. Worse, your OS version only comes with version 3.x and upgrading is painful. With docker containers, you can just containerize each application with its own Python version and have a consistent environment that you can run on lots of different machines (even on different OSes).

They're also a lot more convenient than having to go through the arcane and non-standard installation procedures that a lot of software applications (esp. proprietary ones) have.

Yeah, honestly it kinda sucks that we're adding this layer of inefficiency and bloat to things, but these tools were invented for a reason.

Re: Docker Compose Isn't Enough

#67

Post by skybrian »

ricw wrote: post #14

So the problem is 1) port mapping and 2) backing up data volumes? There are simple solutions to each 1) you simple have a separate docker-compose file for a different environment, ie docker-compose.dev.yml for your dev server. in this file you simply define the parts that differ from the primary / prod compose file. that way it's a simple command. line variable that initiates a dev vs prod vs any other type. for deta…

I guess it’s simple if you already know which S3 service you want to use? For those of us who don’t, it means it’s time to go shopping for one.

Re: Docker Compose Isn't Enough

#68

Post by notpushkin »

I’ve been building a Docker Swarm based server dashboard for a couple years now. It should help with some of problems mentioned in the post: https://lunni.dev/

I like the ideas mentioned though! Docker Compose is pretty good, but something more declarative would definitely be a plus. Would love to see where the project goes (and maybe will borrow some things for the future versions of mine :-)

Re: Docker Compose Isn't Enough

#69

Post by chipdart »

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.

> For many people self-hosting implies a personal server; it's not really "development" but it's not "production" either.

There's Docker swarm mode for that. It supports clustering too.

It's nuts how people look at a developer tool designed to quickly launch a preconfigured set of containers and think it's reasonable to use it to launch production services.

It's even more baffling how anyone looks at a container orchestration tool and complains it doesn't backup the database they just rolled out.

> In that context many people find k8s or other PaaS to be too heavyweight so Docker Compose is pretty popular.

...and proceed to put pressure to shitify it by arguing it should do database backups, something that even Kubernetes stays clear from.

The blogger doesn't even seem to have done any research whatsoever on reverse proxies. If he would have done so, in the very least he would have eventually stumbled upon Traefik which in Docker solves absolutely everything he's complaining about. He would also have researchdd what it means to support TLS and how this is not a container orchestration responsibility.

Quite bluntly, this blog post reads as if it was written by someone who researched nothing on the topic and decided instead to jump to

Re: Docker Compose Isn't Enough

#70

Post by nickfixit »

feisty0630 wrote: post #49
ethagnawl wrote: post #35

Earlier quoted context omitted.

I thought Swarm had been deprecated? I just took a quick look into it and (classic) Swarm was deprecated and ... replaced by Swarm (mode).

Wait until you find out about 'docker-compose' vs 'docker compose'!

Probably before llms figure it out
Post reply on HN