Slide 1

Slide 1 text

Ignaz Forster Research Engineer [email protected] Transactional Updates deep dive

Slide 2

Slide 2 text

2 Tumbleweed Leap 15 Availability read-only root FS read-write root FS Tumbleweed Leap 15 openSUSE Kubic SUSE CaaS Platform

Slide 3

Slide 3 text

3 TOC ● What is it and how does it work? ● How do I use it? ● What’s new? ● A deeper look ● How do I create packages? ● What are the alternatives? ● What’s next?

Slide 4

Slide 4 text

What is it and how does it work?

Slide 5

Slide 5 text

5 What is a Transactional Update? An update that ● is atomic – Either fully applied, or not applied 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 condition

Slide 6

Slide 6 text

6 Updates with snapper current / Backup / (pre) 1. 2. Backup / (post) 3. Active system 1. Create “pre” snapshot 2. Update the current system 3. Create “post” snapshot Update is modifying the currently active file system Restarts services immediately

Slide 7

Slide 7 text

7 Updates with snapper A Transactional Update is an update that ● is atomic – Either fully applied, or not applied 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 condition

Slide 8

Slide 8 text

8 Updates with transactional-update ● Using zypper & snapper in the background ● Also creates two snapshots – Pre: Backup of the current system – Post: Working snapshot ● Will not touch the currently running system ● Sets “Post” snapshot as new default btrfs root file system ● Changes applied on reboot

Slide 9

Slide 9 text

9 Updates with transactional-update current / Backup / (pre) 1. new / (post) 2. 3. 1. Snapshot of current system 2. Create new target snapshot 3. Update system and set as default for next boot Current root file system is not modified Active system

Slide 10

Slide 10 text

How do I use it?

Slide 11

Slide 11 text

11 Cheat Sheet List repositories zypper lr -d zypper lr -d Refresh repositories zypper ref zypper ref Update installed packages transactional-update up transactional-update up Perform a distribution update transactional-update dup transactional-update dup Install package(s) transactional-update pkg in transactional-update pkg in Update package(s) transactional-update pkg up transactional-update pkg up Remove package(s) transactional-update pkg rm transactional-update pkg rm List snapshots snapper list snapper list Mark snapshots for removal by snapper transactional-update cleanup transactional-update cleanup View default subvolume btrfs subvolume get-default / btrfs subvolume get-default / Open shell transactional-update shell transactional-update shell Request reboot transactional-update reboot transactional-update reboot System rollback transactional-update rollback [number] transactional-update rollback [number]

Slide 12

Slide 12 text

12 Live Demo

Slide 13

Slide 13 text

13 Pitfalls ● Snapshots will be branched from the current system → multiple Snapshots without rebooting will not contain the previous snapshot’s changes! ● When using transactional-update on a read-write system → don’t forget to reboot your system before making any changes to the root file system!

Slide 14

Slide 14 text

What’s new?

Slide 15

Slide 15 text

15 Unified /var ⇒ /var

Slide 16

Slide 16 text

16 RPM database relocation /var/lib/rpm → /usr/lib/sysimage/rpm (synchronized with Fedora)

Slide 17

Slide 17 text

17 Improved /etc handling Overlay /etc now part of snapshot → RPM packages can modify the real configuration → “pre” snapshot used for storing the system configuration

Slide 18

Slide 18 text

A deeper look

Slide 19

Slide 19 text

19 /var handling ● /var is a special directory as it contains variable data – Has to have read-write permissions ● Cannot be rolled back – A rollback would usually delete production data (e.g. your new orders in your database or your Docker images) ● Typically stored on a separate subvolume or partition ● /var will not be mounted into the update snapshot (but we have some special handling for plain files and directories)

Slide 20

Slide 20 text

20 /etc handling ● On read-only systems /etc has to be writeable – Mounted as an overlay file system – Overlay stored in /var ● On snapshot creation /etc contents will be synced into root file system – Snapshot contains configuration at that time ● On reboot into new snapshot delete overlay contents ● Only files modified after snapshot creation will remain

Slide 21

Slide 21 text

21 Other subvolumes ● /opt, /var/log and /boot/grub2 will be bind mounted into the update snapshot ● Everything else, including/srv, won’t!

Slide 22

Slide 22 text

22 What else? ● transactional-update is the only way to update a read-only system ● Configuration via /etc/transactional-update.conf ● Snapper will clean up old snapshots ● If an operation wasn’t successful the snapshots will be deleted

Slide 23

Slide 23 text

23 health-checker ● Add your own checker scripts to check for system consistency ● Automatic rollback if checks fail

Slide 24

Slide 24 text

24 rebootmgr ● transactional-update.timer triggers daily update including reboot ● rebootmgr manages reboot (e.g. in maintenance windows or synchronized via etcd)

Slide 25

Slide 25 text

How do I create packages?

Slide 26

Slide 26 text

26 Packaging requirements ● No special requirements, just follow the packaging guidelines and FHS ● Important: Don’t modify /var contents using RPM scripts! ➔ If you have to do so (e.g. database initialization or migration) write a systemd startup script (see Migration / Updates for reference) ● /var contents will be created on boot (not during installation)

Slide 27

Slide 27 text

27 Summary ● Only works with BTRFS root file systems ● Just use any RPM package ● General purpose tool: Especially useful for servers and clusters, but may also find its use on desktops ● Fast snapshot switching ● Sane /etc and /var handling

Slide 28

Slide 28 text

What’s next?

Slide 29

Slide 29 text

29 Next development targets ● Inclusion into SUSE Linux Enterprise Server ● IMA / EVM support for system verification / integrity ● Fix RPM packages with scripts modifying /var and /srv ● Zypper integration

Slide 30

Slide 30 text

30 Related talks ● For a Kubic system in action (including containers) see pgonin’s talk Your first steps with openSUSE Kubic tomorrow (13:00, 105) ● For a more general / high-level product overview review yesterday’s talk Atomic Bonds: openSUSE Kubic & SUSE CaaSP by Richard Brown ● Older talks: – Thorsten Kukuk: Transactional Updates with btrfs at FOSDEM 2017 or openSUSE Conference 2017 ● Blog posts: – Transactional Updates in openSUSE Leap 15 – Official Kubic Website

Slide 31

Slide 31 text

Join Us at kubic.opensuse.org

Slide 32

Slide 32 text

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/