compose-on-kubernetes
kubevela
Our great sponsors
compose-on-kubernetes | kubevela | |
---|---|---|
2 | 27 | |
1,413 | 6,062 | |
- | 2.4% | |
1.2 | 9.0 | |
about 3 years ago | 3 days ago | |
Go | Go | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
compose-on-kubernetes
-
why was Compose on Kubernetes discontinued ! what to use instead !
enjoy the title says, https://github.com/docker/compose-on-kubernetes is no longer maintained, with no explanation why and no recommendations on what to use instead. i've briefly looked at Kompose as an alternative, but i don't like how it's a converter. i'd prefer the source of truth to exist inside a single, simpleYAML file, like a docker-compose file. what would you recommend?
-
Best Practices Around Creating Production Ready Web Apps with Docker Compose
https://github.com/docker/compose-on-kubernetes looks dead now, maybe for misguided political reasons while they remain in denial that swarm might compete? But it's too bad, there's no reason some k8s api/operator thing can't make this frictionless.
Still, someone already mentioned docker-desktop having some tricks for deploying straight to aws and [there is definitely a way to do this with ecs](https://aws.amazon.com/blogs/containers/deploy-applications-...). There's also tools like kompose which translate configs automatically and are suitable for use in a pipeline, so the only thing you need is a compose file in version control.
So yes, you can still basically use compose in production, even on a non-swarm cluster, and it's fine. A lot of people that push back against this are perhaps just invested in their own mad kubectl'ing and endless wrangling with esoteric templates and want to push all this on their teammates. From what I've seen, that's often to the detriment of local development experience and budgeting, because if even your dev environment always requires EKS, that gets expensive. (Using external/managed databases is always a good idea, but beside the main point here I think. You can do that or not with or without docker-compose or helm packages or whatever, and you can even do that for otherwise totally local development on a shared db cluster if you design things for multi-tenant)
At this point I'll face facts that the simple myth here (docker-compose is merely a toy) is winning out over the reality (docker-compose is partly a tool but isn't a platform, and it's just a format/description language). But consider.. pure k8s, k8s-helm, ECS cloudformation, k8s-terraforming over EKS, and docker-compose all have pretty stable schemas that require almost all the same data and any one of them could pretty reasonably be considered as a lingua-franca that you could build the other specs from (even programmatically).
From this point of view there's an argument that for lots of simple yet serious projects, docker-compose should win by default because it is at the bottom of the complexity ladder. It's almost exactly the minimal usable subset of the abstract description language we're working with, and one that's easy to onboard with and requires the least dependencies to actually run. For example: even without kompose it's trivial to automate pulling data out of the canonical docker-compose yaml and injecting that into terraform as part of CD pipeline for your containers on EKS; then you keep options for local-developer experience open and you're maintaining a central source of truth for common config so that your config/platform is not diverging more than it has to.
I'm an architect who works closely with ops, and in many ways not a huge fan of docker-compose. But I like self-service and you-ship-it-you-run it kinds of things that are essential for scaling orgs. So for simple stuff I'd rather just use compose as the main single-source-of-truth than answer endless bootstrappy questions about k8s or ECS if I'm working with others who don't have my depth of knowledge. (Obviously compose has been popular for a reason, which is that kubernetes really is still too complicated for a lot of people and use-cases.) Don't like these ready-made options for compose-on-ECS, or compose-to-k8s via kompose? Ok, just give me your working docker-compose and I'll find a way to deploy it to any other new weird platform, and if I need some pull-values/place-values/render-template song and dance with one more weird DSL for one more weird target deployment platform, then so be it. I've often found the alternative here is a lot of junior devs deciding that deployment/dev-bootstrap is just too confusing, their team doesn't help them and pushes them to an external cloud-engineering team who doesn't want to explain this again because there's docs and 10 examples that went unfollowed, so then junior devs just code without testing it all until they have to when QA is broken. Sometimes the whole org is junior devs in the sense that they have zero existing familiarity with docker, much less kubernetes! Keep things as simple as possible, no simpler.
Seen this argument a million times, and no doubt platform choices are important but even pivoting on platforms is surprisingly easy these days. When you consider that compose is not itself a platform but just basically a subset of a wider description language, this all starts to seem a bit like a json vs yaml debate. If you need comments and anchors, then you want yaml. If you need serious packaging/dependencies of a bunch of related microservices, and a bunch of nontrivial JIT value lookup/rendering, then you want helm. But beyond org/situation specific considerations like this, the difference doesn't matter much. My main take-away lately is that leadership needs to actually decide/enforce where the org will stand on topics like "local development workflows"; it's crazy to have a team divided where half is saying "we develop on laptops with docker-compose" and half is saying "we expect to deploy to EKS in the dev environment". In that circumstance you just double your footprint of junk to support and because everyone wants to be perfectly pleased, everyone is annoyed.
kubevela
- Is there any Django app deployment tool for VPS-based environments with UI?
- What's the status of Open Application Model?
-
Using compose files as a universal infrastructure interface, even for Kubernetes
Finally, I think the OAM model offers one possible future. Take a look at projects like KubeVela and Crossplane. These allow you to compose your own custom abstraction layer. The developer creates a simple CRD called "Application" and this is translated into ths k8s or even off-cluster resources. Problem right now is the complexity is transferred onto guys configuring the platform..... I want to see more "out of the box" implementations.
- Helm or Kustomize for my situation?
- KubeVela, the extensible engine for IDP and platform engineering
-
Opinionated application platform on top of Kubernetes?
Gotcha, thanks! We already run ArgoCD but having devs write raw manifests feels so low-level when it’s usually the same combo of configmaps, ingresses, services, deployments… Maybe this is more in the direction of what I’m looking for? 🤔 https://kubevela.io
-
Finding better motivations for software work (Other than pride)
Note: On that topic, I'm keeping a close eye on the Open Application Model and the kubevela projects. I think it’ll help write a representation of an application and its components that we can validate the structure of our code against, and generate documentation from it. Not a complete solution to the problem, but it'll help with certain parts of architecture documentation
- Kubevela - The modern application platform.
-
Clusterpedia —— Cluster API Searching Has Never Been Easier
Also, kubevela is getting ready to connect to clusterpedia https://github.com/kubevela/kubevela/issues/4237,
-
Acorn
https://kubevela.io/ is an alternative that has been around longer, exposes CUE naturally, and builds on open standards for app packs. I'd recommend this open-source product.
What are some alternatives?
harbormaster
crossplane - The Cloud Native Control Plane
argo-cd - Declarative Continuous Deployment for Kubernetes
kustomize - Customization of kubernetes YAML configurations
rancher - Complete container management platform
Dokku - A docker-powered PaaS that helps you build and manage the lifecycle of applications
porter - Kubernetes powered PaaS that runs in your own cloud.
kpt - Automate Kubernetes Configuration Editing
spinnaker - Spinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.
terraform-controller - A Kubernetes Terraform Controller, managing Cloud resources through Kubernetes
kapp - kapp is a simple deployment tool focused on the concept of "Kubernetes application" — a set of resources with the same label
devtron - Tool integration platform for Kubernetes