16 ms·

Docker compose is extremely basic. Even on a single node Kubernetes is more capable than docker compose. Ingresses, Services, Deployments, Cronjobs, Statefulset

Docker compose is extremely basic. Even on a single node Kubernetes is more capable than docker compose. Ingresses, Services, Deployments, Cronjobs, Statefulsets. Awesome operators. Cert-manager. There're so many things I could easily do with Kubernetes that would require countless unmaintainable bash scripts and ad-hoc approaches with docker-compose.

Demiurge 3y ago
Yes, but 50% of the projects the parent poster sees, and 90% of the projects that I see, do not require any of that.
preya2k 3y ago
For me, I really enjoy how basic it is. I’ve never missed any of these things for my simple single-host scenarios.
- vbezhenar 3y ago
  Simple setups will be as simple with Kubernetes. However with Kubernetes your infrastructure will be ready to scale. You need to expose both front-end and back-end services under the same host? No need to tinker with nginx configs, you just create two ingresses and do it in a standardized way. You need to run your service with two replicas and rolling zero-downtime update? Kubernetes has it out of the box. Good luck implementing all the necessary dances with custom docker-compose setup without dropped requests. You want to customize healthcheck? Kubernetes got you covered with all the imaginable scenarios. The only missing block in Kubernetes is support for building containers. This is implemented with docker-compose extremely elegantly and simple. That I admit.
  - mardifoufs 3y ago
    I wonder if there are any plans to add a docker compose like api to kubernetes? I know, kubernetes should not be used for that but there must be a better way than to use docker compose or manually building containers? Don't know a lot about DevOps so I sometimes just build my containers manually with a docker file but it's not ideal for up to date dependencies.
  - justin_oaks 3y ago
    > Simple setups will be as simple with Kubernetes. That is true if you already have Kubernetes. If you don't, then you still need to run and configure the Kubernetes' control plane (e.g. kube-apiserver, etcd, scheduler, etc). Doing that alone may exceed the complexity of a simple setup. I say this as someone who has looked at Kubernetes a lot and wanted to use it, but could never justify it. I have concluded multiple times that docker compose is a better fit for my use case. > However with Kubernetes your infrastructure will be ready to scale. True, but for many purposes you aren't gonna need it. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
    - cholindo 3y ago
      k3s is a super easy way of deploying kubernetes in a linux machine.
      - jadbox 3y ago
        I haven't used k3s, but I will check it out.
    - vbezhenar 3y ago
      kubeadm init is all you need to run and configure everything. It's installed via dep/rpm.
      - gtirloni 3y ago
        I almost spilled my coffee, seriously. I hope you're not putting something like that in production.
        johaugum 3y ago
        Statements like these offer zero value, maybe you could qualify it with some reasoning?
        3y ago
  - constantly 3y ago
    How many lines of unnecessary code have been written to be “ready to scale” and that never happens? This is an anti pattern and I would caution anyone from falling into this mindset where they feel they need Kubernetes even for simple things. I urge people to start simple, focus on features, and deal with complexity when the need actually arises. This Cult of Kubernetes has to go.
    - whoknowswhat11 3y ago
      I'm just using docker alone sometimes w some AWS service set - agreed completely. So simple to iterate, test and deploy. The performance and even reliability of stuff now is impressive. One AMD 7950x3d box on a 5 gig att fiber connection. Price / perf / simplicity is amazing
  - ndriscoll 3y ago
    Most people don't really need things like rolling zero-downtime updates though. If you deploy your service once per week, and it takes 5 seconds to restart, that's still five 9s of availability, which is more than enough for tons of applications. A single Scala+postgres service on my 7 year old quad core machine can handle 10s of thousands of HTTP requests per second, which is plenty of scalability for most applications.
  - gtirloni 3y ago
    > However with Kubernetes your infrastructure will be ready to scale. 90% of the projects won't need scale. You're paying forward for something you won't use most of the time. Speaking as a k8s admin.
    - geerlingguy 3y ago
      Premature optimization is the root of all evil.
  - JeremyNT 3y ago
    > Simple setups will be as simple with Kubernetes. "Simple setups" in Kubernetes will have massive amounts of complexity and overhead, they're just buried in a different abstraction layer. If you have "free" k8s and don't need to touch it operationally? Sure, do everything with it! But somebody is going to have to run that k8s environment. If it's you, and you're not a k8s expert, then you'd better buckle up, because all that hidden complexity is now your problem. In the world where you need to deploy "an app" to "a VM", the simplicity of docker-compose is a sweet spot that any developer can grok without needing an encyclopedic knowledge of how to manage it.
deleted 3y ago
[deleted]
c-hendricks 3y ago
> Docker compose is extremely basic Yup thanks for noticing, that's why I use it
deleted 3y ago
[deleted]
MuffinFlavored 3y ago
> Awesome operators https://github.com/operator-framework/awesome-operators https://github.com/operator-framework/awesome-operators archived since 2021 and now https://operatorhub.io/ https://operatorhub.io/ I hadn't heard of this, interesting. Layers and layers of abstractions. What an interesting way to solve things. "It's YAML all the way down"?
- llama052 3y ago
  If you can grasp the layers of abstraction it's a really really fast way to ship operational solutions. Yaml aside it's great for smaller teams and empowers them to do a lot more than they could traditionally do.
  - MuffinFlavored 3y ago
    What are some of the most common use cases you can think of, like the most popular ones? I'm drawing a blank on how I'd use this.
    - llama052 3y ago
      We use a few operators currently. - Prometheus operator Lets us spin up a prometheus monitoring stack on our kubernetes cluster for monitoring metrics and scraping metrics from our services pretty much automatically. - Thanos Operator Spins up prometheus monitoring aggregations across multiple clusters with object storage backends, basically you can store metrics for years and query them with grafana. - Strimzi Operator (Kafka) Orchestrates a kafka cluster for kafka connect or even full blown kafka brokers with zookeeper. - Istio Operator Builds a service mesh on the cluster, offering MTLS and an envoy load balancer with some incredible flexibility - Cert-manager operator Lets us auto-generate certificates for resources via letsencrypt. This one is so nice for internal services and keeps certs valid without any hand holding - Argo CD operator We use this operator to deploy argocd pipelines and ship new services and updates via github actions in a very standardized way, and gives our users a UI to see what's going on. - Actions runner controller Using this actions runner controller we can offload github actions runners to self-hosted runners that automatically scale for pipeline workloads. Another set up and forget system and saves us from buying more github actions minutes. Ultimately we use a ton of operators because it gives us an out of the box framework for tooling we need to deploy without reinventing the wheel. Of course some operators aren't worth using and it's definitely worth checking them out to see if they worth your time. A lot of them are really open to updates and changes also so you can help evolve them as you grow into other cases. I will say, it's very important to understand what you are abstracting with these, you can absolutely blindly deploy services with operators and have it blow up in your face if you aren't sure what's going on behind the scenes or lack distributed service knowledge in production.

Demiurge 3y ago

Yes, but 50% of the projects the parent poster sees, and 90% of the projects that I see, do not require any of that.

preya2k 3y ago

For me, I really enjoy how basic it is. I’ve never missed any of these things for my simple single-host scenarios.

vbezhenar 3y ago
Simple setups will be as simple with Kubernetes. However with Kubernetes your infrastructure will be ready to scale. You need to expose both front-end and back-end services under the same host? No need to tinker with nginx configs, you just create two ingresses and do it in a standardized way. You need to run your service with two replicas and rolling zero-downtime update? Kubernetes has it out of the box. Good luck implementing all the necessary dances with custom docker-compose setup without dropped requests. You want to customize healthcheck? Kubernetes got you covered with all the imaginable scenarios. The only missing block in Kubernetes is support for building containers. This is implemented with docker-compose extremely elegantly and simple. That I admit.
- mardifoufs 3y ago
  I wonder if there are any plans to add a docker compose like api to kubernetes? I know, kubernetes should not be used for that but there must be a better way than to use docker compose or manually building containers? Don't know a lot about DevOps so I sometimes just build my containers manually with a docker file but it's not ideal for up to date dependencies.
- justin_oaks 3y ago
  > Simple setups will be as simple with Kubernetes. That is true if you already have Kubernetes. If you don't, then you still need to run and configure the Kubernetes' control plane (e.g. kube-apiserver, etcd, scheduler, etc). Doing that alone may exceed the complexity of a simple setup. I say this as someone who has looked at Kubernetes a lot and wanted to use it, but could never justify it. I have concluded multiple times that docker compose is a better fit for my use case. > However with Kubernetes your infrastructure will be ready to scale. True, but for many purposes you aren't gonna need it. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
  - cholindo 3y ago
    k3s is a super easy way of deploying kubernetes in a linux machine.
    - jadbox 3y ago
      I haven't used k3s, but I will check it out.
  - vbezhenar 3y ago
    kubeadm init is all you need to run and configure everything. It's installed via dep/rpm.
    - gtirloni 3y ago
      I almost spilled my coffee, seriously. I hope you're not putting something like that in production.
      - johaugum 3y ago
        Statements like these offer zero value, maybe you could qualify it with some reasoning?
        3y ago
- constantly 3y ago
  How many lines of unnecessary code have been written to be “ready to scale” and that never happens? This is an anti pattern and I would caution anyone from falling into this mindset where they feel they need Kubernetes even for simple things. I urge people to start simple, focus on features, and deal with complexity when the need actually arises. This Cult of Kubernetes has to go.
  - whoknowswhat11 3y ago
    I'm just using docker alone sometimes w some AWS service set - agreed completely. So simple to iterate, test and deploy. The performance and even reliability of stuff now is impressive. One AMD 7950x3d box on a 5 gig att fiber connection. Price / perf / simplicity is amazing
- ndriscoll 3y ago
  Most people don't really need things like rolling zero-downtime updates though. If you deploy your service once per week, and it takes 5 seconds to restart, that's still five 9s of availability, which is more than enough for tons of applications. A single Scala+postgres service on my 7 year old quad core machine can handle 10s of thousands of HTTP requests per second, which is plenty of scalability for most applications.
- gtirloni 3y ago
  > However with Kubernetes your infrastructure will be ready to scale. 90% of the projects won't need scale. You're paying forward for something you won't use most of the time. Speaking as a k8s admin.
  - geerlingguy 3y ago
    Premature optimization is the root of all evil.
- JeremyNT 3y ago
  > Simple setups will be as simple with Kubernetes. "Simple setups" in Kubernetes will have massive amounts of complexity and overhead, they're just buried in a different abstraction layer. If you have "free" k8s and don't need to touch it operationally? Sure, do everything with it! But somebody is going to have to run that k8s environment. If it's you, and you're not a k8s expert, then you'd better buckle up, because all that hidden complexity is now your problem. In the world where you need to deploy "an app" to "a VM", the simplicity of docker-compose is a sweet spot that any developer can grok without needing an encyclopedic knowledge of how to manage it.

deleted 3y ago

[deleted]

c-hendricks 3y ago

> Docker compose is extremely basic Yup thanks for noticing, that's why I use it

deleted 3y ago

[deleted]

MuffinFlavored 3y ago

> Awesome operators https://github.com/operator-framework/awesome-operators https://github.com/operator-framework/awesome-operators archived since 2021 and now https://operatorhub.io/ https://operatorhub.io/ I hadn't heard of this, interesting. Layers and layers of abstractions. What an interesting way to solve things. "It's YAML all the way down"?

llama052 3y ago
If you can grasp the layers of abstraction it's a really really fast way to ship operational solutions. Yaml aside it's great for smaller teams and empowers them to do a lot more than they could traditionally do.
- MuffinFlavored 3y ago
  What are some of the most common use cases you can think of, like the most popular ones? I'm drawing a blank on how I'd use this.
  - llama052 3y ago
    We use a few operators currently. - Prometheus operator Lets us spin up a prometheus monitoring stack on our kubernetes cluster for monitoring metrics and scraping metrics from our services pretty much automatically. - Thanos Operator Spins up prometheus monitoring aggregations across multiple clusters with object storage backends, basically you can store metrics for years and query them with grafana. - Strimzi Operator (Kafka) Orchestrates a kafka cluster for kafka connect or even full blown kafka brokers with zookeeper. - Istio Operator Builds a service mesh on the cluster, offering MTLS and an envoy load balancer with some incredible flexibility - Cert-manager operator Lets us auto-generate certificates for resources via letsencrypt. This one is so nice for internal services and keeps certs valid without any hand holding - Argo CD operator We use this operator to deploy argocd pipelines and ship new services and updates via github actions in a very standardized way, and gives our users a UI to see what's going on. - Actions runner controller Using this actions runner controller we can offload github actions runners to self-hosted runners that automatically scale for pipeline workloads. Another set up and forget system and saves us from buying more github actions minutes. Ultimately we use a ton of operators because it gives us an out of the box framework for tooling we need to deploy without reinventing the wheel. Of course some operators aren't worth using and it's definitely worth checking them out to see if they worth your time. A lot of them are really open to updates and changes also so you can help evolve them as you grow into other cases. I will say, it's very important to understand what you are abstracting with these, you can absolutely blindly deploy services with operators and have it blow up in your face if you aren't sure what's going on behind the scenes or lack distributed service knowledge in production.