4 ms·

docker compose was one of the most spectacular and developer friendly deployment tool i have used. unfortunately the ecosystem is on kubernetes. you want to in

docker compose was one of the most spectacular and developer friendly deployment tool i have used. unfortunately the ecosystem is on kubernetes. you want to integrate with spot instance bidding on AWS...u need kubernetes. you want monitoring tools...u need kubernetes, etc the Compose spec is now open and standardised - https://www.compose-spec.io/ https://www.compose-spec.io/ a kubernetes distro that can be managed entirely using compose files will be a massively impactful project. Not like Kompose which converts Compose files to k8s yml files....but entirely on Compose files. I really hope someone does a startup here.

frenchman99 4y ago
What do you mean with monitoring tools? You could deploy Prometheus/Grafana or an ELK stack on Compose so I'm not sure I understand what you mean
- sandGorgon 4y ago
  im talking about managed tools... not self hosted ones. e.g. datadog, etc https://www.datadoghq.com/blog/monitoring-kubernetes-with-datadog/ https://www.datadoghq.com/blog/monitoring-kubernetes-with-da... that said, Grafana's own hosted solution "Grafana Cloud" gives Kubernetes operators...but not for anything else. https://grafana.com/docs/grafana-cloud/kubernetes-monitoring/prometheus/prometheus_operator/ https://grafana.com/docs/grafana-cloud/kubernetes-monitoring... the entire ecosystem is supporting k8s. there's not much choice here.
jeremy_k 4y ago
When you say 'a kubernetes distro that can be managed entirely using compose files will be a massively impactful project. Not like Kompose which converts Compose files to k8s yml files....' Do you mean from the your perspective, you set up your docker-compose and this startup ends up deploying pods into Kubernetes based on your compose file? Basically cutting out the middleman of you having to deal with Kubernetes yaml files?
- sandGorgon 4y ago
  yes. basically. and this is a path that multiple people are trying to solve. e.g. AWS CDK8s, https://tanka.dev/ https://tanka.dev/, etc Compose would be awesome.
  - jeremy_k 4y ago
    Disclaimer: I work for the company which wrote the blog post. We basically do this at ReleaseHub, however there is a level of indirection we introduced. We basically have our own version of Kompose which generates our own YAML file, which we call an Application Template[1]. The Application Template then gets parsed into Kubernetes YAML and deployed, however as an end user, you never have you deal with the Kubernetes YAML. The main piece missing is that we set everything up to parse the docker-compose file once and then expect people to interact with our YAML. However, having seen the level of interest about compose in this thread I'm wondering if maybe there is a feature to be built where we remove the need for interacting with our YAML, an end user can push changes to their compose and through GitOps we update everything and deploy new changes to Kubernetes. The compose spec has come a long way since we started (we were attending the spec meetings back in 2020 to see how the project was going to kick off) and is in an even better place to support this direct Compose -> Kubernetes idea. If you're curious, feel free to reach out jeremy@releasehub.com. [1] - https://docs.releasehub.com/reference-documentation/application-settings/application-template/schema-definition https://docs.releasehub.com/reference-documentation/applicat...
    - sandGorgon 4y ago
      here's the thing - people have a degree of discomfort with "your own YAML". I'm not trying to flame, but genuinely tell you what the evolution of FUD has been. At this point, you are sitting in a landscape which has already argued around Borg vs Kubernetes and consequently YAML vs Jsonnet vs Cue (e.g. https://github.com/cue-lang/cue/discussions/669 https://github.com/cue-lang/cue/discussions/669). We have original Borg and k8s architects who have spilled lot of ink on this. It is going to be super hard to digest another custom markup. This is really your battleground. People will ask - why not the standrdised Compose specification or standardised jsonnet/cue. In this context, Compose is kind of loved by all (though not the technically superior choice here) the good news is - ur asking the same question probably and thats a good direction. You also have the steps to build up on (k3s, k11s, k9s - yes they are all different things and very cool). Best wishes if you go down this path.
khuey 4y ago
Perhaps I'm missing something but you can throw containers at Fargate Spot on AWS and it works just fine.
- sandGorgon 4y ago
  sure. and it works great. Docker Compose is also unnecessary for that. I'm talking to the demographic of users who want to run Compose/K8s/Rancher by themselves. For most people, i dont recommend it - you should use Fargate.
kalev 4y ago
This is something i’ve been thinking about for a long time and your comment made me think about it again. I’ve seen many companies developing using docker-compose but deploying their software in a different way (on bare metal, kubernetes or nomad). Why hasn’t anyone build this yet? I’m afraid I’m missing something so starting on this my own is risky.

frenchman99 4y ago

What do you mean with monitoring tools? You could deploy Prometheus/Grafana or an ELK stack on Compose so I'm not sure I understand what you mean

sandGorgon 4y ago
im talking about managed tools... not self hosted ones. e.g. datadog, etc https://www.datadoghq.com/blog/monitoring-kubernetes-with-datadog/ https://www.datadoghq.com/blog/monitoring-kubernetes-with-da... that said, Grafana's own hosted solution "Grafana Cloud" gives Kubernetes operators...but not for anything else. https://grafana.com/docs/grafana-cloud/kubernetes-monitoring/prometheus/prometheus_operator/ https://grafana.com/docs/grafana-cloud/kubernetes-monitoring... the entire ecosystem is supporting k8s. there's not much choice here.

jeremy_k 4y ago

When you say 'a kubernetes distro that can be managed entirely using compose files will be a massively impactful project. Not like Kompose which converts Compose files to k8s yml files....' Do you mean from the your perspective, you set up your docker-compose and this startup ends up deploying pods into Kubernetes based on your compose file? Basically cutting out the middleman of you having to deal with Kubernetes yaml files?

sandGorgon 4y ago
yes. basically. and this is a path that multiple people are trying to solve. e.g. AWS CDK8s, https://tanka.dev/ https://tanka.dev/, etc Compose would be awesome.
- jeremy_k 4y ago
  Disclaimer: I work for the company which wrote the blog post. We basically do this at ReleaseHub, however there is a level of indirection we introduced. We basically have our own version of Kompose which generates our own YAML file, which we call an Application Template[1]. The Application Template then gets parsed into Kubernetes YAML and deployed, however as an end user, you never have you deal with the Kubernetes YAML. The main piece missing is that we set everything up to parse the docker-compose file once and then expect people to interact with our YAML. However, having seen the level of interest about compose in this thread I'm wondering if maybe there is a feature to be built where we remove the need for interacting with our YAML, an end user can push changes to their compose and through GitOps we update everything and deploy new changes to Kubernetes. The compose spec has come a long way since we started (we were attending the spec meetings back in 2020 to see how the project was going to kick off) and is in an even better place to support this direct Compose -> Kubernetes idea. If you're curious, feel free to reach out jeremy@releasehub.com. [1] - https://docs.releasehub.com/reference-documentation/application-settings/application-template/schema-definition https://docs.releasehub.com/reference-documentation/applicat...
  - sandGorgon 4y ago
    here's the thing - people have a degree of discomfort with "your own YAML". I'm not trying to flame, but genuinely tell you what the evolution of FUD has been. At this point, you are sitting in a landscape which has already argued around Borg vs Kubernetes and consequently YAML vs Jsonnet vs Cue (e.g. https://github.com/cue-lang/cue/discussions/669 https://github.com/cue-lang/cue/discussions/669). We have original Borg and k8s architects who have spilled lot of ink on this. It is going to be super hard to digest another custom markup. This is really your battleground. People will ask - why not the standrdised Compose specification or standardised jsonnet/cue. In this context, Compose is kind of loved by all (though not the technically superior choice here) the good news is - ur asking the same question probably and thats a good direction. You also have the steps to build up on (k3s, k11s, k9s - yes they are all different things and very cool). Best wishes if you go down this path.

khuey 4y ago

Perhaps I'm missing something but you can throw containers at Fargate Spot on AWS and it works just fine.

sandGorgon 4y ago
sure. and it works great. Docker Compose is also unnecessary for that. I'm talking to the demographic of users who want to run Compose/K8s/Rancher by themselves. For most people, i dont recommend it - you should use Fargate.

kalev 4y ago

This is something i’ve been thinking about for a long time and your comment made me think about it again. I’ve seen many companies developing using docker-compose but deploying their software in a different way (on bare metal, kubernetes or nomad). Why hasn’t anyone build this yet? I’m afraid I’m missing something so starting on this my own is risky.