Richard Brown openSUSE Chairman [email protected] Kubic Project openSUSE’s Container Starship, going where no distribution has gone before 

Topics ● What is the Kubic Project? ● The Problem with Traditional Distributions ● Transactional Updates In Detail ● MicroOS – *SUSE enters the Atomic-Era ● Cool Things you can do with MicroOS Today ● Just the Beginning – Kubic as a Container Service Platform 

Kubic Project ● Founded in May 2017 ● Sub-Project of the openSUSE Project ● Focused on Container Technologies incl: – MicroOS, Tumbleweed-based Cluster Host OS – Velum, Kubernetes Cluster Bootstrapper & MicroOS Cluster Dashboard ● Upstream of SUSE Container as a Service Platform (CaaSP) 

Why? ● Application delivery is changing – Containers – Flatpak/snaps/AppImage 

Why? ● Micro-Services are fun – Why bother with complex installations when someone else's solution is a docker pull away? – VMs are comparably resource and management heavy – Lots of positive momentum behind containers, but tools are lacking 

Why? ● Containers are disruptive – Diferent requirements from the OS – Faster delivery expectations – Portability increases support demands – Containerized clusters want to run at scale 

Why? ● Setting up a container host should be easy – No point saving time with containers just to waste it administering a machine – Containers should take care of themselves, why can’t the host system? 

The Problem with Traditional Distributions 

“I NEVER want to touch a running system” - Every SysAdmin, ever 

Upgrading a Running System Is DANGEROUS ● Services are running ● Users are doing things ● Sofware changes things (sometimes on purpose!) ● Not all packages are packaged properly (sorry) 

Reality does not make things easy Rolling Releases bring larger challenges ● Intrusive Updates (SysV init → systemd) ● Major version updates of complex stacks (GNOME, KDE) ● What should I do if the update breaks my system? 

Reality does not make things easy Critical Mission Systems are even worse ● Update should not interrupt services Service interruption more expensive than regular reboots ● Updates need to be fully applied perfectly, or no changes made System state should never be undefined/questionable RPM post-installation scripting can lead to an undefined state 

Traditional Snapshots – An Imperfect Solution curr. root ro ro ro ro 

Traditional Snapshots – An Imperfect Solution curr. root ro ro ro ro ro ro-Clone 1 

Traditional Snapshots – An Imperfect Solution curr. root ro ro ro ro ro ro-Clone 1 zypper up 2 

Transactional Updates 

What is a Transactional Update? An Update that: ● Is Atomic – Either fully applied, or not at all – Update does not influence the running system ● Can be rolled back – A failed or incompatible update can be quickly discarded to restore the previous system conditions 

Other Solutions ● Several Diferent Partitions – Waste of Disk Space ● Special package formats (rpm-ostree, snap, etc) – Need to learn something new – Can’t re-use existing packages → And you need to redesign systems, tools & company policies 

All you need ● btrfs root filesystem with snapshots/rollback enabled ● snapper ● zypper (or package manager of your choice) ● btrfsprogs 

Traditional Snapshots curr. root ro ro ro ro 

Transactional Updates ro ro ro ro curr. root 

ro Transactional Updates ro ro ro ro curr. root 1 ro-Clone 

Transactional Updates ro ro ro ro curr. root rw 1 ro-Clone 2 Change rw 

Transactional Updates ro ro ro ro curr. root rw 1 ro-Clone 2 Change rw 3 zypper up 

Transactional Updates ro ro ro ro curr. root ro 1 ro-Clone 2 Change rw 3 zypper up Change ro 4 

Transactional Updates ro ro ro ro curr. root New root 1 ro-Clone 2 Change rw 3 zypper up Change ro 5 “Rollforward” btrfs subvol set-default 4 

Transactional Updates – Afer Reboot ro ro ro ro curr. root ro 

Transactional Updates – without Reboot ro ro ro ro curr. root ro ro New root 

How to do transactional updates ● transactional-update [up|dup|patch] ● transactional-update pkg [install|remove|update] $PKG1..$PKGN – Install anything you’d like ● BONUS: transactional-update shell 

Transactional Updates – Rollback ro ro ro ro curr. root New root 1 Rollback btrfs subvol set-default 

Advantages ● btrfs: – Snapshots with CoW are space eficient – Deduplication possible – btrfs send/receive – update with golden images ● rpm: – Existing packages can be used – No need to learn new tools, policies remain valid 

Advantages, cont. ● Normal boot time ● Very quick rollback 

Disadvantages ● Currently limited to btrfs only ● Special requirements of RPMs – Care needs to be made that files are in the right place – User data & configuration should be converted on use, not during package install ● Reboot needed to activate changes 

Dealing with Configuration Files ● rootfs snapshots always contain package-provided files for /etc ● overlayfs used to transparently store/overlay user-provided files for /etc 

MicroOS 

openSUSE MicroOS ● openSUSE Tumbleweed-derivative utilising transactional- updates & read-only rootfs ● Docker installed and enabled by default (for now) ● Download/Install from https://sofware.opensuse.org/distributions/tumbleweed 

Diferences from Tumbleweed ● Update using transactional-update dup ● Install/Remove packages using transactional-update pkg install|remove 

MicroOS Today 

MicroOS Example Use Cases ● Containers – docker – runc – lxc – cri-o 

MicroOS Example Use Cases 

MicroOS Example Use Cases ● Rolling Server – Use the latest of everything with no risk – Web (esp. NodeJS, Ruby, etc) – Virtualisation host – Media Server 

MicroOS on Raspberry Pi3 

Kubic Desktop 

Kubic Desktop https://rootco.de/2017-11-16-hackweek-2017-conclusion/ 

Kubic Container Service Platform 

Why? ● Setting up a container host should be easy – No point saving time with containers just to waste it administering a machine – Containers should take care of themselves, why can’t the host system? 

What’s Next? ● Setting up a container cluster should be easy – No point saving time with containers just to waste it administering a cluster of machines – Containers should take care of themselves, why can’t the cluster? – Cluster admins should be able to seemlessly bootstrap, monitor and upgrade whole clusters at once 

Kubic Container Service Architecture Cluster Nodes (etcd + Kubernetes Master) Log Server Administration Node 

Current Status ● “Unconfigured Cluster Node” - fully supported system-role in Kubic ● Can be used to setup a Kubernetes Cluster Manually ● https://kubernetes.io/docs/getting-started-guides/scratch/ #bootstrapping-the-cluster 

Current Status ● Velum & related “Container-as-a-Service Platform” containers are not working yet ● Contributions welcome ● https://github.com/kubic-project/container-images ● Alternatives being investigated – OpenShif – kubeadm 

Join Us at www.opensuse.org 

License This slide deck is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license. It can be shared and adapted for any purpose (even commercially) as long as Attribution is given and any derivative work is distributed under the same license. Details can be found at https://creativecommons.org/licenses/by-sa/4.0/ General Disclaimer This document is not to be construed as a promise by any participating organisation to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. openSUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for openSUSE products remains at the sole discretion of openSUSE. Further, openSUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All openSUSE marks referenced in this presentation are trademarks or registered trademarks of SUSE LLC, in the United States and other countries. All third-party trademarks are the property of their respective owners. Credits Template Richard Brown [email protected] Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/