Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

An overview and discussion regarding the openSUSE Project's latest rolling-release distribution, MicroOS. The session will detail how concerns regarding the stability of rolling releases are addressed by narrowing the scope of OS, and using technologies like (Atomic) Transactional Updates and automated health checking to guarantee the system keeps working. The session will cover how MicroOS is developed, and the broad range of suitable use cases, from Container server workloads, to Raspberry Pi's and Desktops including real-world examples from the community.

Richard Brown

February 06, 2021
Tweet

More Decks by Richard Brown

Other Decks in Programming

Transcript

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

    View Slide

  2. 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. Copyright © SUSE 2021
    3
    What is MicroOS?

    View Slide

  4. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    5
    IoT: IP WebCams
    Do you have an IP Webcam or similar
    IoT Device?
    Ever updated it?

    View Slide

  6. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    8
    Edge: Trains

    View Slide

  9. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    21
    “I NEVER want to touch a running system”
    - Every SysAdmin, ever

    View Slide

  22. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    23
    Transactional Update User View
    ro
    ro ro ro
    curr.
    root

    View Slide

  24. Copyright © SUSE 2021
    24
    Transactional Update Phase 1
    ro
    ro ro ro
    1
    curr.
    root
    ro
    ro-Clone

    View Slide

  25. Copyright © SUSE 2021
    25
    Transactional Update Phase 2
    ro
    ro ro ro
    1
    curr.
    root
    rw
    ro-Clone
    2
    Change rw

    View Slide

  26. Copyright © SUSE 2021
    26
    Transactional Update Phase 3
    ro
    ro ro ro
    1
    curr.
    root
    rw
    ro-Clone
    2
    Change rw
    3
    zypper up

    View Slide

  27. Copyright © SUSE 2021
    27
    Transactional Update Phase 4
    ro
    ro ro ro
    1
    curr.
    root
    ro
    ro-Clone
    2
    Change rw
    3
    zypper up
    Change ro 4

    View Slide

  28. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    29
    Transactional Update After Reboot
    ro
    ro ro ro
    curr.
    root
    ro

    View Slide

  30. Copyright © SUSE 2021
    30
    Transactional Update Without Reboot
    ro
    ro ro ro
    curr.
    root ro ro
    New
    root

    View Slide

  31. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    40
    My openSUSE MicroOS Life

    View Slide

  41. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    45

    View Slide

  46. Copyright © SUSE 2021
    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

  47. Insert Image
    Copyright © SUSE 2021
    Talking about
    containers...

    View Slide

  48. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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. Copyright © SUSE 2021
    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

  53. 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