I'm using Dokku to serve a bunch of sites and love it, it has made deployments a breeze. I did run into some Docker problems (used too much CPU and couldn't connect to its socket, etc), but I don't think it was Dokku's fault, but Docker's.

I want to see if I can use Kubernetes as a Dokku replacement (hopefully a more stable one), but I don't think Kubernetes has all the niceties Dokku has (automatic reverse proxying, Let's Encrypt support, etc).

You might look at Red Hat's OpenShift, which builds on top of Kubernetes. Or Deis, which has adopted buildpacks.

Cloud Foundry has buildpacks too, but it's usually seen as a heavyweight solution -- the light footprint variant is 6 VMs, the standard variant is 20-something.

Disclosure: I work for Pivotal, we contribute a lot to Cloud Foundry. Red Hat is a competitor.

SUSE's Cloud Application Platform is already available to selected customers. It is based Cloud Foundry running on top of Kubernetes, all with a very slick UI. No VMs.

https://www.suse.com/products/cloud-application-platform/ https://www.suse.com/communities/blog/take-look-suse-cloud-a...

I tried it recently with an internal app, and the experience was very similar to Heroku. cf push and my app was running.

Disclosure: I work for SUSE, we contribute to Cloud Foundry and the containers ecosystem. Pivotal is a competitor.

I am actually super pleased that SUSE have picked up where HPE left off. I am hopeful it will avoid too many distro-level monoculturisms.

The link to the UI blog post has turned up in our private chat channels :)

btw, here is an article about the management UI:

https://www.suse.com/communities/blog/introducing-stratos-ui...

Ah, I've heard about Deis, I'll check that one out, thanks. My main concern is the fact that Kubernetes recommends running more than one server, which is a luxury my personal projects cannot afford. Does anyone know how well it runs on a single server?

It is possible to run Kubernetes on a single machine combining master and worker nodes but there are few instructions for it. Really only makes sense for single bare metal machine. For production, better to run separate VMs. The hosted Kubernetes, GKE and Azure, can run clusters without paying for master nodes and can have pretty small nodes.

There's minikube, but so far as I'm aware, it's not really meant for production use; it exists mostly for local development.

My own company has Pivotal Web Services[0], which gives a Heroku-like experience using Cloud Foundry. Pricing is per-megabyte[1], plus services. I expect we'll introduce a container service before long, because we like to dogfood our stuff with real production workloads.

[0] http://run.pivotal.io/

[1] http://run.pivotal.io/pricing/

Yeah, minikube is just for trying K8s out. PWS looks interesting, but, as with other managed/cloud offerings, it's much more expensive than a dedicated server (50ish EUR/mo for a 64 GB RAM i7).

For my side-projects, where I am cost-sensitive, I think the best solution would be a dedicated server with something like Dokku. It would just be nice if the "something" could be an industry standard.

I think it's hard to split the difference. If there was a service using RackHD to spit out cheap bare metal it'd be more doable to run on top of that, I think.

It's easy enough to set that up (though it's not the recommended use case) using kubeadm.

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.

That'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?

I 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/

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/

[2]: https://www.cncf.io/certification/software-conformance/#logo...

[3]: https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4Eb...

I used to work on buildpacks -- can I suggest getting in touch with the Cloud Foundry Buildpacks team? They also do a lot of work around the Ubuntu base image (cflinuxfs2) and there's been work towards cflinuxfs3.

They also used to use soft-forked Heroku buildpack code. Almost all of the Cloud Foundry buildpacks have now been rewritten on top of a single shared library. The strength of Heroku's code was that each buildpack has a maintainer familiar with the relevant ecosystem. The weakness was that they were all different. Often forked from a previous one and then tinkered into submission.

That's really cool and good to know. I will keep that in mind! Thanks

Thank you, the fact that there's a team that will take over puts my mind at ease somewhat. I'll give Deis a shot, thanks again!

For the Kubernetes + Dokku replacement, GitLab's Auto DevOps https://docs.gitlab.com/ce/topics/autodevops/ can do a lot of stuff. It's included in CE, thus it's free.

That's a layer over Kubernetes and Prometheus, no? It looks good, but it assumes I've already installed the former.

In the next few months, GitLab supports GKE Cluster Integration. https://docs.gitlab.com/ce/user/project/clusters/index.html

You can set up your Kubernetes, Helm, Tiller, Runner, Prometheus by one click.

Gitlab now bundles Prometheus, but you would need to install Kubernetes.

Kubernetes can have automatic reverse proxying and let's encrypt via an Ingress controller. I don't doubt Dokku has some nice plugins that Kubernetes doesn't though, especially for developers.

Ah, thanks, I'll try that. Dokku does have nice plugins, but they tend to be things I can write Dockerfiles for. The other big thing Dokku does is that it builds the image on the server, so it doesn't need a Docker registry, you just push the code directly to Dokku and the image gets built and deployed.

I haven't used kubernetes yet, but https://traefik.io/ was a great reverse proxy in combination with docker swarm. I imagine it works great with kubernetes, too.

Putting a few labels on the containers you want to expose with your reverse proxy is all you need to do. Traefik continuously monitors docker to react to changes. Traefik handles load balancing and automatic certificate generation with ACME, too

That looks great, thank you. I'll try it with my K8s install.

Shameless self plug: we are also building an alternative[1] that enables you to run tons of services on a single node (and to call them easily from front end projects - with the help of autogenerated type safe clients).

[1] https://github.com/1backend/1backend

I used to love dokku until I had 7-minute deployment times for an average application in production. Has that been fixed? Was around 0.6.0 I think.

Can you give more info on that 7-minute deployment time?

Dokku is basically a wrapper around Herokuish which is just a docker image with Heroku buildpacks pre-installed on them to build an image of your app to be dployed to docker instance...

Source: Am a maintainer of Dokku.

Mine takes 30 seconds for a sizable rails app

It's awesome. Even lets liberal arts majors set up servers and R, Python, etc. apps with easy ;-)