Flynn is the best option for #1. It's a full cli written for humans with a web dashboard. It can mount anything that run under Linux, docker files or simple web apps (through Heroku build packs).

In regards to #2, this is a bit tricky, the way it works is that you point a domain to it and the apps are given a subdomain and load balanced.

OpenShift uses Kubernetes, which allows that degree of precision. I'm not familiar with its GUI though.

I believe DCOS has a really nice interface.

The interface of DCOS really is excellent, the default project for kubernetes doesn't even come close, especially the 1.9 release of DCOS polished everything up. It does have its quirks though. Which does force you to use the json editor sometimes.

But the openshift UI is also very nice, I've been using it through the CDK with minishift and it's an excellent interface for kubernetes/openshift.

Even the OpenShift UI forces you to drop into a yaml editor every now and then. Kubernetes is too powerful to really represent in any UI without a ton of work - which is really the central decision when adopting Kube. Do you want the power available if you need it? Or do you want something simpler that might constrain a future choice?

Of note, there's a structured web editor for any API resource in Kube, OpenShift, or extension being prototyped now that I'm hoping helps bridge that gap.

Also, check out the latest nightlies or 3.6.0-alpha.2 for a bunch of massive improvements to the overview - I think it's easily the biggest enhancement over the last few years.

There are some nice features of the UI in OpenShift that I'm missing in the kube dashboard, such as the terminal.

Also the ability to split up access to workspaces in OpenShift could be useful, though I don't know if that's accomplished with actual API objects or whether it would map onto kube.

I love this JSON Editor https://jsonformatter.org/json-editor

#2 would probably be a combination of "stateful sets" and "label selectors" in kubernetes.

Generally, though, you're fighting the high level idea of these tools by trying to tie to specific hardware.

I guess it should've occurred to me to ask why notamy wants that. HA? Hardware-specific differences maybe? Those are the uses I know of.

It's an issue of hardware differences + some of the software not being designed to be clustered Kubernetes/etc.-style (and it's not mine so I can't just rewrite it).

OK, that makes sense. But why use a platform that abstracts physical layout when you already have a physical layout in mind?

This isn't really something that I have experience with, hence asking; my issue is mainly not really knowing the tools available, therefore I'm looking in the wrong place.

Gotcha! I hope I was helpful.

Normally in these circumstances I'd recommend BOSH but, off the top of my head, I don't know what kind of affinity can be defined. So it might be another rabbit hole.

> Generally, though, you're fighting the high level idea of these tools by trying to tie to specific hardware.

I figured as much, but I'm trying to avoid inventing my own solution if one already exists.

However, you can run Flynn in single machine mode, which guarantees your hardware will be set, and you get the best of both worlds (CLI + GUI + Specific Hardware)