Portal:MicroOS/Design

Installed Packages

The openSUSE MicroOS installation media contains all packages, which are

necessary to boot the system.
necessary to run containers.
necessary to configure and run the "Container as a Service" stack.

The package list is similar to the SUSE Linux Enterprise Server minimal system.

There is no guarantee for a stable ABI: packages will be introduced if needed and removed if no longer needed. This is not considered to be a disadvantage, as the customer workload runs in a container. On the contrary the advantage is that only the minimal set of software necessary to do the requested job is installed.

Additional RPM packages for hardware enablement, logging, monitoring and similar tasks are available on the installation media. The online repository is identical to the openSUSE Tumbleweed repository.

Job scheduler

openSUSE MicroOS is using systemd timers (see man systemd.timer) for job execution. Compared to cron the systemd timers provide better control and debug options and avoid problems with cronjobs and systemd session management. cron is not installed by default, so regular cronjobs will not be executed.

Init system

openSUSE MicroOS is using systemd as its init system. Support for legacy SysV init scripts (which includes LSB compatible init scripts) is not included by default, SysV init scripts should be converted to systemd services instead.

Filesystem

The only available and supported filesystem for the root filesystem is btrfs. Other filesystems like ext4 and xfs are available and supported for data partitions. The root filesystem is read-only, some subvolumes are available to store data, like /var, /home and /root. To store modified configuration files, overlayfs is used for /etc. The work directory for /etc/ is /var/lib/overlay/<snapshot_number>/etc.

Filesystem Layout

Subvolumes

  /@/<subvolumes>            - Default subvolumes (see the list of default subvolumes on the BTRFS support page)
  -> /root                   - root user home directory
  -> /boot/writable          - store for early boot services (GRUB, Ignition)
  -> /var                    - Variable data, not part of a snapshot
  -> /.snapshots/1/snapshot  - Initial installation of Base OS
  -> /.snapshots/2/snapshot  - Base OS after first update
  -> /.snapshots/3/snapshot  - Base OS after second update
  -> /.snapshots/X/snasphot  - Base OS after (X-1) updates

With the exception of the .snapshots subvolumes, the non-default subvolumes listed above are added by default in openSUSE MicroOS in order to ensure it's possible to write to those locations when the rest of the root filesystem is read-only.

Important Folders

   /var

to store variable data should be an own btrfs partition. This is since snapshots and rollback have qgroups enabled on the root filesystem, which would be a massive performance bottleneck especially for containers.

   /var/lib/overlayfs

is used to provide the overlay store mounted for /etc. For writing changes each btrfs snapshot has one corresponding overlay; the overlays are transparent, i.e. changes in older snapshots will also be visible to newer snapshots. The directory doesn't have to be on a separate partition.

Configuration

The system is pre-configured as far as possible during installation - usually no additional configuration is needed by the system administrator. For configuration openSUSE MicroOS is using cloud-init for OpenStack Cloud and else ignition to adjust the system during the boot phase. Primary configuration items are network and ssh keys to allow the admin to login to the machine.

Note that by default a root password will only be set if the installation is done with YaST2. Otherwise a local login is not possible, so either an account needs to be configured or ssh keys have to be installed.

Ignition

Most of our pre-built MicroOS system images use Ignition for configuration on first boot.

Check out our Ignition Quick Start page on how to get started.

Cloud-init

Our pre-build images for OpenStack are using Cloud-init for configuration on first boot. It is a flexible and popular framework for customizing cloud instances.

There is some documentation how to setup cloud-init for MicroOS.

Health Check

Several checks for errors are done during boot phase. If an error was detected, the following rules will be used:

Error with new snapshot:
- Rollback to last known working snapshot if one exists
Error with already successfully booted snapshot
- Try rebooting the system
- If the error persist shut down services, inform the system administrator

Security and Immutability

Apparmor
- Fully supported
SELinux
- Fully supported for base image and Container Host system role

Installing and Updating Packages

A MicroOS installation can be updated and new RPM packages can be installed using the transactional-update or the pkcon application. See more information on Portal:MicroOS/Zypper (and Kubic:Update and Reboot#Update and Reboot of openSUSE_Kubic and openSUSE MicroOS).