4 ms·

> let me emphasize this: absolutely nobody should be running anything in production using a docker-compose file. This might be a stupid question: what is wrong

> let me emphasize this: absolutely nobody should be running anything in production using a docker-compose file. This might be a stupid question: what is wrong about deploying with Compose? What are the "proper" ways of doing things?

doctoboggan 3y ago
Nothing is wrong with deploying with docker-compose. Many people will push you toward k8s but if compose does the job there is absolutely no reason to introduce the complexity of k8s. Compose will get you far. (farther than many people think).
spdustin 3y ago
FTA: """ What you're meant to do is, of course, run it on Kubernetes, which is largely the same (it's containers all the way down) except it's configured differently, you can now think about scaling out (on several nodes), you have actual health/liveness checks and policies for rolling out new versions, restarting, etc. It's k8s! We all love to hate it, but at least the industry has sorta standardized around it, so that makes commiserating easier. And because penpot is made up of three services (backend, exporter, frontend — not counting postgres and redis), although you could technically deploy all three of them separately, the idiomatic and era-appropriate thing to do at the time of this writing is to use a helm chart, which lets you deploy several resources at once. """
gaganyaan 3y ago
It's fine if you've got a low-volume service or one where downtime isn't a huge deal. If you ever find yourself needing e.g. autoscaling due to load or you start measuring how many 9's of uptime you get, then you'd want to look elsewhere.
redox99 3y ago
There's nothing wrong. What's actually wrong is always using k8s even when it's overkill.
evilduck 3y ago
Compose is fine for what it is, it’s served my personal VPS for years perfectly and I’ve hosted internal tools for teams with it for stuff that would never need to scale beyond that instance and never needed to be public. Personal projects and even small companies can likely get away with it just fine. But if you’re dealing with any larger organization they probably don’t want to deal with you spinning up a random unprovisioned server running docker and compose services and will require stuff like Ansible scripts or similar to manage it. Once you start trying to manage docker-compose with extra tooling you might as well bite the bullet and learn k8s and get more out of your time and learning investment.

doctoboggan 3y ago

Nothing is wrong with deploying with docker-compose. Many people will push you toward k8s but if compose does the job there is absolutely no reason to introduce the complexity of k8s. Compose will get you far. (farther than many people think).

spdustin 3y ago

FTA: """ What you're meant to do is, of course, run it on Kubernetes, which is largely the same (it's containers all the way down) except it's configured differently, you can now think about scaling out (on several nodes), you have actual health/liveness checks and policies for rolling out new versions, restarting, etc. It's k8s! We all love to hate it, but at least the industry has sorta standardized around it, so that makes commiserating easier. And because penpot is made up of three services (backend, exporter, frontend — not counting postgres and redis), although you could technically deploy all three of them separately, the idiomatic and era-appropriate thing to do at the time of this writing is to use a helm chart, which lets you deploy several resources at once. """

gaganyaan 3y ago

It's fine if you've got a low-volume service or one where downtime isn't a huge deal. If you ever find yourself needing e.g. autoscaling due to load or you start measuring how many 9's of uptime you get, then you'd want to look elsewhere.

redox99 3y ago

There's nothing wrong. What's actually wrong is always using k8s even when it's overkill.

evilduck 3y ago

Compose is fine for what it is, it’s served my personal VPS for years perfectly and I’ve hosted internal tools for teams with it for stuff that would never need to scale beyond that instance and never needed to be public. Personal projects and even small companies can likely get away with it just fine. But if you’re dealing with any larger organization they probably don’t want to deal with you spinning up a random unprovisioned server running docker and compose services and will require stuff like Ansible scripts or similar to manage it. Once you start trying to manage docker-compose with extra tooling you might as well bite the bullet and learn k8s and get more out of your time and learning investment.