openSUSE MicroOS, a platform for everything from containers, to IoT, and even the desktop

Picture
openSUSE MicroOS &
SLE Micro
A Platform For Everything
from containers, to IoT, and
even desktops
2 FEBURARY 2021

View Slide

Copyright © SUSE 2021
2
Richard
Brown
MicroOS Release Engineer
[email protected]
@sysrich
About Myself
openSUSE contributor since it began
SUSE employee since 2013
Passionate advocate of rolling releases
Former Customer (Systems Manager), QA Engineer, openSUSE Board Member &
openSUSE Chairperson
Currently Linux Distribution Engineer in Future Technology Team focusing on two
rolling distributions
openSUSE MicroOS – Single Purpose Self Administering OS
openSUSE Kubic – MicroOS for Kubernetes & Containers
Photographer in spare time

View Slide

3
What is MicroOS?

View Slide

4
Why is MicroOS?
Computers are no longer only
laptops, desktops, and servers.
People no longer use laptops,
desktops and servers the same way
as they used to.

View Slide

5
IoT: IP WebCams
Do you have an IP Webcam or similar
IoT Device?
Ever updated it?

View Slide

6
IoT: IP WebCams
There are millions of these devices
● 78% of total detected malware
activity is due to IoT botnets (2018)
● Failed updates result in many,
many unhappy customers

View Slide

7
Embedded:
O2 UK Network
Outage 2019
Identified some clear requirements
● Reliable Updates
● Automatic Recovery
● Outage can be very expensive
● Repair can be very time
consuming

View Slide

8
Edge: Trains

View Slide

9
Edge: Trains
aka. 300 Device Rolling Datacentres
Significant local analysis
required:
- State of components
- Control System (signal and
barrier detection)
Status reports regularly sent to
workshops via LTE, GSM-R, UMTS
Big data analysis subsequently
carried out in Public Cloud
Availability: >>99%
Sensors: ~300
Fleet: ~100 Trains, each providing:
- 1-2 billion data points/year;
100-200 billion data points overall
- 0.5 Terabytes of data/year; 50
Terabyte overall

View Slide

10
Datacentres:
Really Big Clusters
Several hundred machines
All with the same OS version
Workload in containers
- Kubernetes
Automatic update
Automatic rollback
Machine with problems? kill and
replace

View Slide

11
Modern Realities
Virtualisation
More Services = More
VMs, not more physical
hardware
Containers
Limits incompatibilities,
isolates service
problems
Cloud
More Hardware is
always just a Credit
Card away
IoT
Single-purpose
devices are
increasingly prolific

View Slide

12
New World Requirements
Scalable
Small, really small, in order to:
- minimise need for updates
- minimise need for configuration
- rollout easily and repeatedly at
scale
Predictable
Run same way on every boot
Is not alterable during operation
System should be customisable
by user before deployment
Reliable
Automated installation of system
updates
Automatic rollback in the event of
issues with system updates
Workloads isolated from Base OS
(eg. Containers as first class
workload)

View Slide

13
Regular Linux is
NOT good enough
Traditional Linux is like a Swiss Army
Knife
Lots of Services & Features
- with increased chances of
incompatibilities between services
- and increased risk of complex
failures

View Slide

14
Users Already
Know This
We build wonderfully complex Linux,
just for users to take it and:
- Deploy Single Purpose
VM/Cloud/IoT instances
- Minimise installed services
- Ignore patching for Rip n’ Replace
- Add more instances over micro-
managing their existing fleets

View Slide

15
Handcrafted isn’t
good enough
Building custom Single Purpose
systems by hand is a lot of work
Still often have issues with
Configuration Management
Still need effort to keep patched
Optimising for RAM/CPU/Disk is HARD

View Slide

16
Nobody is perfect
Even the best designed &
maintained systems have flaws
Those flaws need to be prevented
from getting in the way of what the
system is meant to do
Anything worth doing, is worth being
able to undo

View Slide

17
openSUSE MicroOS
openSUSE MicroOS is both
predictable & immutable. It cannot
be altered during runtime.
MicroOS is reliable with automated
updates and automated recovery
from faulty updates.
MicroOS is small with only what is
needed to run it’s “one job”.
Applications/Services are expected
to be Containerised or Sandboxed.

View Slide

18
SLE Micro
SLE Micro is both predictable &
immutable. It cannot be altered
during runtime.
SLE Micro is reliable with automated
updates and automated recovery
from faulty updates.
SLE Micro is small with only what is
needed to run it’s “one job”.
Applications/Services are expected
to be Containerised.

View Slide

19
MicroOS Architecture
openSUSE MicroOS is a rolling release
based on openSUSE Tumbleweed.
MicroOS is wholly built, developed,
and tested as part of the
Tumbleweed release process.
Any test failure detected before the
release of either Tumbleweed &
MicroOS can prevent the release of
both distributions.
SLE Micro is a regular release based
on SUSE Linux Enterprise.

View Slide

20
Pretty Small (and
Shrinking)
619MB Bare Metal Install
165 MB kernel-default
152 MB kernel-firmware
68 MB grub2
382MB VM Image
68 MB grub2
35 MB kernel-default-base
10 MB systemd
288 RPMs, 210 Source Packages

View Slide

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

View Slide

22
Transactional
Updates
Any change to a system should be
applied reliably, reproducibly, and
reversibly.
Transactional Updates are:
- Atomic
- Either fully applied, or not at all
- Applied without impacting
the running system

View Slide

23
Transactional Update User View
ro
ro ro ro
curr.
root

View Slide

24
Transactional Update Phase 1
ro
ro ro ro
1
curr.
root
ro
ro-Clone

View Slide

25
ro
ro ro ro
1
curr.
root
rw
ro-Clone
2
Change rw

View Slide

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

View Slide

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

View Slide

28
Transactional Update Activation
ro
ro ro ro
1
curr.
root
New
root
ro-Clone
2
Change rw
3
zypper up
Change ro
5
“Rollback”
4

View Slide

29
Transactional Update After Reboot
ro
ro ro ro
curr.
root
ro

View Slide

30
Transactional Update Without Reboot
ro
ro ro ro
curr.
root ro ro
New
root

View Slide

31
Powered by btrfs
Unique
Very space efficient – each
snapshot only contains diffs
Config files in /etc are part of the
snapshot and rollback
Brings many benefits of image-
style upgrades without their
limitations
Flexible
No new package format
necessary (eg. rpm-ostree)
No size limitation for partitions/OS
Easily enhanceable
Reliable
Able to use boot config from
previous working snapshots
Smaller threat surface for boot-
blocking issues

View Slide

32
Rollback
In the event of a failure/unwanted
behavioural change
Immutable: Nothing has changed on
disk
Rollback is done by booting an old
snapshot
This can be done as often as wanted

View Slide

33
Health Check
Checks for errors during boot phase
Error with new snapshot? Rollback to
last known working snapshot
Error with already successful booted
snapshot? Try reboot, else shutdown
services, inform admin
Needs access to harddisk

View Slide

34
Secure Updates
Updates downloaded with https
Packages signed
Repositories signed
Intruder cannot exchange good, new
packages with old, insecure ones
Verify Packages
System not updated if (dependency)
conflicts occur
Snapshots get immediately deleted if
error occur during update

View Slide

35
Hardware
Requirements
ARM (aarch64):
EFI, either firmware or uboot
X86_64:
UEFI
Legacy BIOS
Memory (Virtualised):
512MB + Workload
Storage:
/ (root) – 5GB
/var - 5GB

View Slide

36
Deployment Options
DVD/NET ISO w.
YaST
Customisable,
streamlined,
installer
VM/Vagrant/Cloud/Pi
Images
Preconfigured, ready
to use disk images
Yomi
Installing directly
using Saltstack
Combustion/Ignition
For use to configure
images/systems on
first boot

View Slide

37
Ignition
https://github.com/coreos/ignition
Partial replacement of cloud-init
Features:
Partitioning disks
Formatting partitions
Writing files, enable systemd services
Configure users
Runs out of initramfs during first boot
Does not touch sub-systems not
mentioned in user supplied config

View Slide

38
Combustion
Combustion can do everything
Ignition can plus:
Create additional files
Install Packages
Setup Devices
Repartition existing Hard Drives
Runs as a dracut module, executing
scripts from external storage labelled
“combustion” or “ignition”
https://en.opensuse.org/
Portal:MicroOS/Combustion

View Slide

39
Toolbox
MicroOS’ read-only root filesystem
raises some challenges:
- Reboot needed to install additional
tools
- Situation after reboot is different
then before
Toolbox:
- Launches small, privileged
container
- Root filesystem available below
/media/root
- zypper to install the necessary tools
- Persistent between usages

View Slide

40
My openSUSE MicroOS Life

View Slide

41
MicroOS Desktop
openSUSE MicroOS Desktop is
MicroOS where the ”one job” is
running as a Desktop.
MicroOS Desktop provides only a
minimal base system with a Desktop
Environment and Basic Configuration
Tools ONLY.
All Applications, Browsers, etc are
provided by FlatPaks from FlatHub.

View Slide

42
Who is the MicroOS
Desktop for?
It is not for everyone. Your Tumbleweed & Leap Desktops are
Safe :)
It should be perfect for lazy developers, who no longer want
to mess around with their desktop and just ”get stuff done”,
especially if they develop around containers.
It should also appeal to the same audience now more used
to an iOS, Chromebook or Android-like experience where the
OS is static, automated & reliable and the Apps are the
main thing the user cares about.

View Slide

43
MicroOS Desktop Goals
MicroOS Desktop should be reliable, predictable &
immutable, just like regular MicroOS.
MicroOS Desktop should be less customisable than regular
openSUSE Tumbleweed/Leap.
MicroOS Desktop should be small, but not at the expense of
functionality. Printing, Gaming, Media Production and much
more should all work.
MicroOS Desktop should just work “out of the box”.

View Slide

44
MicroOS Desktop Status
MicroOS Desktop should be reliable,
predictable & immutable, just like regular
MicroOS.
MicroOS Desktop should be less customisable
than regular openSUSE Tumbleweed/Leap.
MicroOS Desktop should be small, but not at
the expense of functionality. Printing, Gaming,
MultiMedia are all valid use cases.
MicroOS Desktop should just work “out of the
box”.

View Slide

45

View Slide

46
Not a Container
OS
openSUSE MicroOS/SLE Micro is not designed to be used
as the Base OS inside containers
Tumbleweed and SLE are already our Container OSs
registry.opensuse.org/tumbleweed – 90.4MB
registry.opensuse.org/busybox – 9.4MB
registry.suse.com/suse/sle15 - 117MB

View Slide

Insert Image
Talking about
containers...

View Slide

48
openSUSE Kubic
openSUSE Kubic is now a MicroOS
Derivative, focused specifically on
Containers and Kubernetes.
Like MicroOS, it is wholly built,
developed, and tested as part of the
Tumbleweed release process.

View Slide

49
Kubernetes is special
Lots of Moving Parts
Containers,
Kubernetes, Container
Runtime, and base
Operating System all
need to be updated
regularly
Containers at Scale
Kubernetes is
designed to run
100s-1000s of
containers at once
Large Clusters
Kubernetes clusters
can span dozens or
hundreds of
physical machines
or VMs

View Slide

50
Kubic – openSUSE’s Kubernetes OS
Inheriting all the usual benefits of
openSUSE MicroOS, with optimisations
for Containers and Kubernetes,
including
– Fully Integrated kubeadm
– CRI-O Container Runtime
– Kured for automating reboots across
the cluster
– Kubic-Control – alternative cluster
bootstrapping tool

View Slide

51
Kubic + Rancher = Kubic NG?
If MicroOS in Kubic has the single purpose of running
Kubernetes with a containerised control plane, why not
have Rancher control the patch level of the cluster
nodes?
● Removal of transactional-update & podman from
Kubic base image
● btrfs send/receive of centrally curated root
subvolume image
● Updates delivered via containers then deployed
transactionally on nodes
● btrfs checksum verification of node rootfs compared
to curated root subvolume image

View Slide

52
Join the Fun
[email protected]
- Mailing list
#kubic on irc.freenode.net
- IRC
openSUSE:Factory & devel:kubic on
build.opensuse.org
- Build Service

View Slide

Picture
Thank you For more information, contact SUSE at:
+1 800 796 3700 (U.S./Canada)
+49 (0)911-740 53-0 (Worldwide)
Maxfeldstrasse 5
90409 Nuremberg
www.suse.com
© 2020 SUSE LLC. All Rights Reserved. SUSE and
the SUSE logo are registered trademarks of
SUSE LLC in the United States and other
countries. All third-party trademarks are the
property of their respective owners.

View Slide

openSUSE MicroOS, a platform for everything from containers, to IoT, and even the desktop

openSUSE MicroOS, a platform for everything from containers, to IoT, and even the desktop

Richard Brown

More Decks by Richard Brown

Other Decks in Programming

Featured

Transcript