Big disclaimer, I work for SUSE on the team for this product (though I actually work on upstream projects more than the product itself).

SUSE's "Container as a Service Platform"[1] has a one-page install for each node with an admin panel that does auto-provisioning. It also has transactional updates and a few other nice features similar to CoreOS's "Container Linux". In addition, we're working on openSUSE Kubic[2] which will be the community-developed base for CaaSP in the future.

I believe most if not all of the code is available on GitHub[3] under a free software license (because that's how we do things). Not to mention that you could very easily fork openSUSE Kubic, once it's ready.

[1]: https://www.suse.com/communities/blog/introducing-suse-conta... [2]: https://news.opensuse.org/2017/05/29/introducing-kubic-proje... [3]: https://github.com/kubic-project

Given that you work for SUSE and I kinda like you guys, I really hope that it's different from SLES licensing model.

I work at a german govt. institution which uses SLES and we've recently decided to move away from SLES for a simple reason. If you want to use something like immutable infrastructure SLES is painful to use, because you need to do everything through the SMT admin.

You won't even know which packages are available in SLES until you signup for it. Sure you can use openSUSE, but it's not the same packages, it's not the same package versions, and the open repo, while nice, is imho not as comfortable to use as ubuntu packages. IMHO it's not very user friendly.

And yes yast2 is great, but I'm not talking about graphical user interfaces when I say user friendly.

By the way, there are a few more "ContainerOSs" than just CoreOS nowadays.

- There's project atomic [1] which became atomic host [2]

- There's RancherOS, which I find interesting because it seems to have first class zfs support [3]

[1]: http://www.projectatomic.io/docs/kubernetes/

[2]: https://www.redhat.com/en/resources/enterprise-linux-atomic-...

[3]: http://rancher.com/docs/os/v1.0/en/storage/using-zfs/

I'm not involved in sales, so I can't really comment on what the licensing model is like.

> If you want to use something like immutable infrastructure SLES is painful to use, because you need to do everything through the SMT admin.

CaaSP nodes don't really have configurable packages (though I think that's something we're considering adding in the future). Everything is done using Kubernetes specifications, so you won't need to use SUMA to manage your nodes' running containers (though the admin panel is fairly similar when bootstrapping and maintaining a cluster).

> Sure you can use openSUSE, but it's not the same packages, it's not the same package versions, and the open repo, while nice, is imho not as comfortable to use as ubuntu packages.

This is something we've changed quite recently. You can figure out the package versions through Leap (and the SLE sources are actually visible in OBS from memory). There's also a "SUSE PackageHub" which is basically openSUSE backports that don't invalidate your license but are not directly supported (other than the same support we'd give to openSUSE issues). I think this is something I should raise with Richard Brown though, since on paper you should already have this information from the verbatim SLE sources we release that Leap is based on.

> By the way, there are a few more "ContainerOSs" than just CoreOS nowadays.

Yeah, though I expected (and was right) that people who work on those would be more knowledgable than me to comment on them. I work quite a lot with both of those groups on upstream stuff, so I'm well aware that they exist (in fact I've contributed to several Project Atomic projects in order to be able to re-purpose their code and use it with our OCI tooling[1]).

[1]: https://github.com/openSUSE/umoci

Setting up a production bare-metal setup of a distributed system is going to involve a number of steps the first time. We have found there is a large range of existing automation and basic infrastructure in different people's environments.

Generally folks try out our Tectonic sandbox (vagrant based)[1], or Tectonic on AWS/Azure/etc before diving into bare metal to get a sense if the product. This can all be done really quickly because of the consistency.

What sort of data center automation infrastructure do you have in your environment?

[1] https://coreos.com/tectonic/sandbox

I took this route. It took me two days. Not 15 minutes. You need to set up a PXE server (coreos/matchbox) beforehand. Which I needed to get working with existing PXE / DHCP deployment. And I had to do some tweaking on the generated Terraform templates tectonic generated. (my disk names are vd* instead of sd*. I use virualization also for bare metal). So I needed to learn what Terraform was.

But still a much smoother experience than Kubernetes The Hard Way. It is almost one-click.

The 15 minutes is probably true if you take azure or AWS. But deploying something in an existing environment always takes planning and time. However, coreos is more than willing to help. (I simply asked questions on IRC. But they also have an enterprise support plan)

Ubuntu 16.04 and kubeadm gets you from zero to k8s in about a 4 hours or so.

I recently gave up trying to fight the uphill battle of doing things with CoreOS and tectonic in my homelab. Their requirements are fine if you have high end server class hardware to spare (matchbox /requires/ IPMI).

Started to go the NixOS route, but found it more infuriating than trying to setup Tectonic, mostly because their recipe for k8s is super old.

In the end, I gave up trying to use the big tools and fell back to Ubuntu and kubeadm. Started at 8am and ended at around noon with a fully functional 9 node cluster running v1.6 with RBAC and TLS enabled by default.

There are some guys working on a new k8s module for NixOS. https://github.com/NixOS/nixpkgs/pull/25426

Try https://www.ubuntu.com/kubernetes. The video there shows an automated deployment of Kubernetes to AWS. For bare metal, choose the "MAAS" option (MAAS is Ubuntu's solution to bare metal deployments by API and replaces AWS in the stack for bare metal).

Disclosure: I work for Canonical.

Edit: I realise this isn't exactly "like" CoreOS. But I think it's useful to post about the traditional alternative for comparison :)

docker swarm. it really is as simple as installing the docker daemon on a cluster of machines and issuing a command to link them together.

I have to agree. Swarm is probably the easiest thing to get going besides the Docker engine itself. Honestly I felt like I might have been missing some step or component when I set up a swarm, because it was just really easy. Then I could start swarm services by making some slight modifications to my pre-existing Docker Compose files. It is very very easy.

And also runs very stable. It's not perfect, but I've certainly run into fewer bugs than when I was trying to get Kubernetes set up.

Agree, for quick and easy docker clusters swarm is hard to beat. Although it’s not quite the same as kubernetes or tectonic (swarm needs too many diy things to make it truly useable in more complex setups, with load balancers and what not).

I'm working on an approachable (i.e. easy to setup and manage) container orchestrator at http://quilt.io that may be worth checking out. It's still very early beta quality software, and some features are missing (notably bare-metal isn't there yet, but it's on the roadmap). That said, it's designed to solve precisely this problem -- ops shouldn't be this hard.

Cool! Bare-metal would be the killer feature for me to adopt this for my usecases.

you should consider a rename: https://en.wikipedia.org/wiki/Quilt_%28software%29

Already in progress =)

Not sure about true "bare metal" but try https://github.com/kubernetes/kops for 0-to-kubernetes on AWS, including provisioning instances, storage, etc.

Full Disclosure: I'm a Red Hat Consultant for OpenShift.

There's lots of Container platforms these days. Docker Swarm, Rancher, OpenShift (and it's upstream project, OpenShift Origin), still others. IMO, the leading edge ones are based on Kubernetes [00]. I'm (obviously) most familiar with OpenShift so I'll speak to that and I'll answer questions honestly if you have them for me.

From field experience, once you have your hardware or VMs ready [0][1][2][3], it takes 10 minutes to stand up a one node cluster or about 30 minutes for an HA cluster with 9 nodes (3 masters, 3 infrastructure nodes, 3 application nodes). We have blogs written by Eric Schabell [4] that show you how install a basic system with a script in minutes. We also have minishift [5] (downstream of minikube [6]) which is another great way to try OpenShift on Linux, MacOS, or Windows with Vagrant and VirtualBox. Paying customers can download CDK [7] on RHEL, MacOS or Windows. You can also try it at OpenShift Online [8] (hosted OpenShift as a Service) or OpenShift.io [9] (IDE and DevOps tools integrated with OpenShift Online).

I hope the above doesn't sound too much like an advertisement but we offer several FOSS ways to try it and I linked to upstreams where applicable.

[00] https://kubernetes.io/

[0] https://docs.openshift.org/3.6/install_config/install/prereq...

[1] https://docs.openshift.org/3.6/install_config/install/host_p...

[2] https://docs.openshift.org/3.6/getting_started/administrator...

[3] https://docs.openshift.org/3.6/install_config/install/advanc...

[4] http://www.schabell.org/2017/08/cloud-happiness-how-to-insta...

[5] https://github.com/minishift/minishift

[6] https://kubernetes.io/docs/tasks/tools/install-minikube/

[7] https://developers.redhat.com/products/cdk/download/

[8] https://www.openshift.com/features/index.html

[9] https://openshift.io/

Disclosure, i work at containership.

We have a SaaS based product that can stand up a Kubernetes cluster for you, and it really does only take 10-15 minutes from signup to being live. https://containership.io

I've done the bootkube setup by hand, it's pretty quick but lacks any documentation. On the list to document/blog on when time permits.

Joyent Triton.

They specifically referred to bare-metal deployments (presumably local). While you could deploy SmartOS locally and run Triton yourself, I have a feeling that running a control plane like Triton is a bit overkill for a self-hosted deployment. Not to mention it likely takes several days too.

There is "CoaL", or "Cloud on a Laptop" from Joyent just to get the feet wet with Triton:

http://blog.shalman.org/running-sdc-coal-on-smartos/

this video demonstrates that it doesn't take days and the description even says it is just as suitable for bare metal as it is for VMware:

https://www.youtube.com/watch?v=apZ-G5LwYiY

Just setup and use Rancher http://rancher.com/ you'll have something setup and usable in 10-15 minutes. Then your cluster can just grow as your needs grow.

I wish there was more from a-z about rancher, like say for instance, setup rancher in a local environment, without immediately connecting it to aws, using maybe like a linode host or something or a proxmox and getting it off the ground. I found ranger was complex, but it seems pretty darn powerful to me, like the proxmox of docker orchestration.

Take a look at this video series

https://www.codemy.net/channels/docker-for-developers