4 ms·
I use Deis on a single server. It works great. There are a few things you need to be aware of, but the tl;dr is that it works great for us. We'd be using it
by yebyen 9y ago
I use Deis on a single server. It works great.
There are a few things you need to be aware of, but the tl;dr is that it works great for us. We'd be using it more, except that our org hasn't adopted containers in any meaningful way yet, and Deis is large and complicated, and a little too much for them to bite off and swallow all at once. They want to do a pilot on ECS so that we can say we're using more AWS services (yay lock-in, we love vendor lock-in.)
So, those things you need to be aware of:
#1 - In the default mode, Minio is used instead of a real Object Storage backend like S3 or Swift, and Minio is configured to keep all objects in RAM by default. Use S3 instead. This is an option to configure in values.yaml.
#2 - builder really needs to be on an SSD, but if you're not backing your Kube node with SSD, you can at least prevent a lot of builder crashes by making sure there isn't much swap to fill and bog down the disk with swapped pages. This may be counter-intuitive (don't things crash when they run out of RAM? Isn't that why you have swap...) until you realize that Builder has to respond to health checks by default once per second. So if the node that builder runs on is getting even remotely bogged down by swappiness and lots of swappy pages, it will be killed and restarted, which takes some time and is noticeable and annoying.
#3 - The remaining cloud services that Deis can optionally depend on IMHO are take-or-leave, depending on your cloud provider. Deis can do everything in-cluster. I actually use this configuration with Minikube and Deis, and it works great. I let Deis spin up its Postgres database on-cluster and restore from S3 WAL backups each day, it just works.
I'd be using Deis more heavily, except that my app development has a production database attached. (Our infosec department is leary about letting me put backups of sensitive data into S3. So we really have to use RDS for our app, even though Deis is creating a Postgres database that nothing else is stopping you from using with your app. It's for Deis controller operation though.)
#4 - This one may be a dealbreaker if your company is very serious, Deis is now "End-of-Life." This means that Microsoft has committed to provide break fixes for Deis until March only, and by middle of next year, any break fixes will have to come from the community. There is AFAIK nowhere to buy Deis support, although there is a new group that has formed to commit to support Deis into the future, it's not clear what form that support will take, or whether you'll be able to pay money for an SLA, or anything like that. It is open-source.
This may be exactly what you'd prefer, or it may be a deal breaker. I like Open Source, but my group likes support.
I do not work for Deis or any other cloud PaaS provider, although I have evaluated a lot of them including OpenShift (and I consider Deis to be technologically superior in some ways to OpenShift.) Because of my ECS requirement, I'm looking at Convox now. If you have to use ECS, so far I would definitely recommend Convox. If you're like the rest of the world and using K8S, I can't think of any really good reason not to recommend Deis.
- StavrosK 9y agoThat's very helpful, thank you! I was with you up until "Deis is EOL", I only want to use it for my sideprojects, but I still wouldn't want to be out of luck if something breaks on the next Ubuntu update and I can't get a fix anywhere :/ Maybe I should look into OpenShift instead, as that's more active?
- yebyen 9y agoI will tell you this: there is a group of people who are committed to keeping Deis alive, called Team Hephy and the Deis slack is still active. I've used OpenShift and it is certainly more active, but I also have the very strong feeling that Deis is "done" where many parts of OpenShift look like they are still evolving. (And I mean "done" in a good way.) If you are not sure, feel free to drop in and ask any and all questions: https://slack.deis.io/ https://slack.deis.io/ The announcement of EOL came in July, and the announcement that Team Hephy would take over was almost one month to the day later, in August. I have a lot of faith in the Deis codebase and I'm on Team Hephy now. We have yet to put out a fully e2e acceptance test passing and providence-verified signed, versioned release of our own, but we have and know of a number of production users that still use Deis in Production. It definitely does not feel like a ghost town on the Deis slack. Questions get answered. Neither does OpenShift (it is definitely not deserted, and it does not seem to suffer from "abandoned k8s fork" syndrome, they do keep up with the release cadence, because they have to.) I would go with the one that solves your problem better. I'm personally still recommending Deis, as I like the built-in support for Heroku buildpacks that OpenShift lacks. (Convox also has support for this, on ECS.) I'm not aware of any K8S-native Deis competitor (other than Hephy) at least for now. Edit: The really nice thing about working in Kubernetes is that you have the conformance suite[1]. You shouldn't worry about breaking something with the next Ubuntu update, because if Ubuntu update has broken Kubernetes in a way that will cause Deis to fail, then it will not be a Kubernetes-conformant distro anymore (and there is a large list[2] of K8S-conformant distros and platform to choose from, so you should pick a conformant one[3] instead.) So, your question should be whether Deis will continue to work on Kubernetes distributions that are conformant, and with some minimal research, I think you should be able to say that with a high degree of certainty it will, regardless of ongoing vendor support from either side. Then, you can ask whether your K8S distro is likely to remain conformant. (This should be a no-brainer.) Finally, is there anything that can break within Deis internally (not related to how it interacts with Kubernetes) that would mean you'd have to stop using it? For me, the big reveal / final test will be, can we upgrade from Cedar stack to Heroku 16, which is on Team Hephy's planned roadmap for the future. If that goes smoothly, then I'm not sure what else there is to worry about. [1]: https://www.cncf.io/certification/software-conformance/ https://www.cncf.io/certification/software-conformance/ [2]: https://www.cncf.io/certification/software-conformance/#logos https://www.cncf.io/certification/software-conformance/#logo... [3]: https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4EbB_BGCxT_wlxW_xgHVVa23es/edit#gid=0 https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4Eb...