Transactional Updates - deep dive

With the release of Leap 15 the new system role called "Transactional Server" was introduced, so this is the perfect opportunity to have a look at the concept behind it and how to work with such a system in practice.

In this talk we will have a look at transactional-updates from different angles:
* The basic concepts behind transactional-update
* How to use the Transactional Server or Kubic (Users & Administrators)
* Packaging for transactional systems (Packagers)
* Recent developments in the transactional-update world

Transcript

1. Ignaz Forster Research Engineer iforster@suse.de Transactional Updates deep dive
2. 2 Tumbleweed Leap 15 Availability read-only root FS read-write root FS Tumbleweed Leap 15 openSUSE Kubic SUSE CaaS Platform
3. 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?
4. What is it and how does it work?
5. 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
6. 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
7. 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
8. 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
9. 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
10. How do I use it?
11. 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 <name> transactional-update pkg in <name> Update package(s) transactional-update pkg up <name> transactional-update pkg up <name> Remove package(s) transactional-update pkg rm <name> transactional-update pkg rm <name> 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]
12. 12 Live Demo
13. 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!
14. What’s new?
15. 15 Unified /var ⇒ /var
16. 16 RPM database relocation /var/lib/rpm → /usr/lib/sysimage/rpm (synchronized with Fedora)
17. 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
18. A deeper look
19. 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)
20. 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
21. 21 Other subvolumes • /opt, /var/log and /boot/grub2 will be bind mounted into the update snapshot • Everything else, including/srv, won’t!
22. 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
23. 23 health-checker • Add your own checker scripts to check for system consistency • Automatic rollback if checks fail
24. 24 rebootmgr • transactional-update.timer triggers daily update including reboot • rebootmgr manages reboot (e.g. in maintenance windows or synchronized via etcd)
25. How do I create packages?
26. 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)
27. 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
28. What’s next?
29. 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
30. 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
31. Join Us at kubic.opensuse.org
32. 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 rbrown@opensuse.org Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/