Настройка хранилища

Fedora CoreOS поставляется с простой схемой хранилища по умолчанию: корневой раздел является последним и расширяется, занимая весь объём диска. Помимо загрузочного раздела, все данные хранятся на корневом разделе. Дополнительные сведения см. в разделе о разметке диска.

Ниже приведены примеры различных способов настройки этой схемы.

Fedora CoreOS требует, чтобы корневая файловая система была не менее 8 ГиБ. По практическим причинам образы дисков для некоторых платформ поставляются с меньшей корневой файловой системой, которая по умолчанию автоматически расширяется, заполняя всё доступное пространство на диске. Если вы добавляете дополнительные разделы после корневой файловой системы, вы должны обязательно явно изменить размер корневого раздела, как показано ниже, чтобы он составлял не менее 8 ГиБ.

В настоящее время, если корневая файловая система меньше 8 ГиБ, при входе выдаётся предупреждение. Начиная с июня 2021 года, если корневая файловая система меньше 8 ГиБ и за ней следует другой раздел, Fedora CoreOS откажется загружаться. Дополнительные сведения см. в этой ошибке.

Ссылки на блочные устройства из Ignition

Многие из приведённых ниже примеров ссылаются на блочное устройство, такое как /dev/vda. Имя доступных блочных устройств зависит от базовой инфраструктуры (физическое оборудование или облако) и часто от конкретного типа экземпляра. Например, в AWS у некоторых типов экземпляров есть NVMe-диски (/dev/nvme*), другие используют /dev/xvda*.

Если ваша конфигурация дисков проста и использует тот же диск, с которого загружалась ОС, то ссылку /dev/disk/by-id/coreos-boot-disk можно использовать для удобного обращения к этому устройству. Эта ссылка доступна только во время провизионинга, чтобы было легко ссылаться на тот же диск, с которого загружалась ОС.

Если вам нужен доступ к другим дискам, вы можете загрузить одну машину с конфигурацией Ignition, обеспечивающей только доступ по SSH, а затем просмотреть блочные устройства, например, с помощью команды lsblk.

Для физического оборудования рекомендуется ссылаться на устройства через ссылки /dev/disk/by-id/ или /dev/disk/by-path.

Настройка отдельных монтирований /var

Вот пример конфигурации Butane для настройки /var на отдельном разделе на том же основном диске:

Добавление раздела /var на основной диск

variant: fcos
version: 1.7.0
storage:
  disks:
  - # The link to the block device the OS was booted from.
    device: /dev/disk/by-id/coreos-boot-disk
    # We do not want to wipe the partition table since this is the primary
    # device.
    wipe_table: false
    partitions:
    - number: 4
      label: root
      # Allocate at least 8 GiB to the rootfs. See NOTE above about this.
      size_mib: 8192
      resize: true
    - size_mib: 0
      # We assign a descriptive label to the partition. This is important
      # for referring to it in a device-agnostic way in other parts of the
      # configuration.
      label: var
  filesystems:
    - path: /var
      device: /dev/disk/by-partlabel/var
      # We can select the filesystem we'd like.
      format: ext4
      # Ask Butane to generate a mount unit for us so that this filesystem
      # gets mounted in the real root.
      with_mount_unit: true

Вы, конечно, можете смонтировать только часть /var в отдельный раздел. Например, чтобы смонтировать /var/lib/containers:

Добавление раздела /var/lib/containers на основной диск

variant: fcos
version: 1.7.0
storage:
  disks:
  - device: /dev/disk/by-id/coreos-boot-disk
    wipe_table: false
    partitions:
    - number: 4
      label: root
      # Allocate at least 8 GiB to the rootfs. See NOTE above about this.
      size_mib: 8192
      resize: true
    - size_mib: 0
      label: containers
  filesystems:
    - path: /var/lib/containers
      device: /dev/disk/by-partlabel/containers
      format: xfs
      with_mount_unit: true

В качестве альтернативы вы также можете смонтировать хранилище с отдельного диска. Например, здесь мы монтируем /var/log из раздела на /dev/vdb:

Добавление /var/log со вторичного диска

variant: fcos
version: 1.7.0
storage:
  disks:
  - device: /dev/vdb
    wipe_table: false
    partitions:
    - size_mib: 0
      start_mib: 0
      number: 1
      label: log
  filesystems:
    - path: /var/log
      device: /dev/disk/by-partlabel/log
      format: xfs
      with_mount_unit: true

Определение диска с несколькими разделами

В этом примере мы очищаем диск и создаём два новых раздела.

variant: fcos
version: 1.7.0
storage:
  disks:
    -
      # Mandatory. We use the World-Wide Number ID of the drive to ensure
      # uniqueness.
      device: /dev/disk/by-id/wwn-0x50014e2eb507fcdf
      # This ensures that the partition table is re-created, along with all
      # the partitions.
      wipe_table: true
      partitions:
        # The first partition (slot number 1) is 32 GiB and starts at the
        # beginning of the device. Its type_guid identifies it as a Linux
        # swap partition.
        - label: part1
          number: 1
          size_mib: 32768
          start_mib: 0
          type_guid: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
        # The second partition (implicit slot number 2) will be placed after
        # partition 1 and will occupy the rest of the available space.
        # Since type_guid is not specified, it will be a Linux native
        # partition.
        - label: part2

Перенастройка корневой файловой системы

Можно перенастроить саму корневую файловую систему. Вы можете использовать путь /dev/disk/by-label/root для ссылки на исходный корневой раздел. Вы должны убедиться, что новая файловая система также имеет метку root.

Для работы повторного провизионинга корня требуется не менее 4 ГиБ оперативной памяти.

Вот пример перехода с xfs на ext4 с повторным использованием того же раздела на основном диске:

Изменение корневой файловой системы на ext4

variant: fcos
version: 1.7.0
storage:
  filesystems:
    - device: /dev/disk/by-partlabel/root
      wipe_filesystem: true
      format: ext4
      label: root

Как и в предыдущем разделе, вы также можете полностью переместить корневую файловую систему. Здесь мы перемещаем корень на устройство RAID0:

Перемещение корневой файловой системы на RAID0

variant: fcos
version: 1.7.0
storage:
  raid:
    - name: myroot
      level: raid0
      devices:
        - /dev/disk/by-id/virtio-disk1
        - /dev/disk/by-id/virtio-disk2
  filesystems:
    - device: /dev/md/myroot
      format: xfs
      wipe_filesystem: true
      label: root

Вам не нужны ключи path или with_mount_unit; FCOS знает, что корневой раздел особый, и сам разберётся, как его найти и смонтировать.

Если вы хотите продублировать загрузочный диск на нескольких накопителях для устойчивости к отказу диска, вам нужно зеркалировать все разделы по умолчанию (root, boot, раздел EFI System и код загрузчика). Для этого существует специальный синтаксис конфигурации Butane:

Зеркалирование загрузочного диска на два накопителя

variant: fcos
version: 1.7.0
boot_device:
  # Change to match target architecture (aarch64, ppc64le, etc.)
  layout: x86_64
  mirror:
    devices:
      - /dev/sda
      - /dev/sdb

Определение файловой системы

В этом примере демонстрируется процесс создания файловой системы путём определения и маркировки разделов, объединения их в массив RAID и форматирования этого массива как ext4.

Определение файловой системы на устройстве хранения RAID

variant: fcos
version: 1.7.0
storage:
  disks:
  # This defines two partitions, each on its own disk. The disks are
  # identified by their WWN.
  - device: /dev/disk/by-id/wwn-0x50014ee261e524e4
    wipe_table: true
    partitions:
    -
      # Each partition gets a human-readable label.
      label: "raid.1.1"
      # Each partition is placed at the beginning of the disk and is 64 GiB
      # long.
      number: 1
      size_mib: 65536
      start_mib: 0
  - device: /dev/disk/by-id/wwn-0x50014ee0b8442cd3
    wipe_table: true
    partitions:
    - label: "raid.1.2"
      number: 1
      size_mib: 65536
      start_mib: 0
  # We use the previously defined partitions as devices in a RAID1 md array.
  raid:
    - name: publicdata
      level: raid1
      devices:
      - /dev/disk/by-partlabel/raid.1.1
      - /dev/disk/by-partlabel/raid.1.2
  # The resulting md array is used to create an EXT4 filesystem.
  filesystems:
    - path: /var/publicdata
      device: /dev/md/publicdata
      format: ext4
      label: PUB
      with_mount_unit: true

Зашифрованное хранилище (LUKS)

Вот пример настройки устройства LUKS в /var/lib/data.

variant: fcos
version: 1.7.0
storage:
  luks:
    - name: data
      device: /dev/vdb
  filesystems:
    - path: /var/lib/data
      device: /dev/mapper/data
      format: xfs
      label: DATA
      with_mount_unit: true

Корневую файловую систему также можно переместить на LUKS. В этом случае устройство LUKS должно быть привязано с помощью Clevis. Доступны два основных типа привязки: TPM2 и Tang (или их комбинация с использованием разделения секрета Шамира).

Привязка TPM2 просто привязывает шифрование к используемой физической машине. Обязательно разберитесь в её модели угроз, прежде чем выбирать между привязкой TPM2 и Tang. Дополнительные сведения см. в этом разделе документации по привязке Clevis TPM2.

Для работы повторного провизионинга корня требуется не менее 4 ГиБ оперативной памяти.

Существует упрощённый синтаксис конфигурации Butane для настройки шифрования и привязки корневой файловой системы. Вот пример его использования для создания зашифрованной корневой файловой системы с привязкой TPM2:

Шифрование корневой файловой системы с помощью привязки Clevis TPM2

variant: fcos
version: 1.7.0
boot_device:
  luks:
    tpm2: true

Это эквивалентно следующей развёрнутой конфигурации:

Шифрование корневой файловой системы с помощью привязки Clevis TPM2 без использования boot_device

variant: fcos
version: 1.7.0
storage:
  luks:
    - name: root
      label: luks-root
      device: /dev/disk/by-partlabel/root
      clevis:
        tpm2: true
      wipe_volume: true
  filesystems:
    - device: /dev/mapper/root
      format: xfs
      wipe_filesystem: true
      label: root

Развёрнутая конфигурация не включает ключи path или with_mount_unit; FCOS знает, что корневой раздел особый, и сам разберётся, как его найти и смонтировать.

Следующий пример привязывает шифрование корневой файловой системы к PCR 7, что соответствует компоненту загрузки UEFI, используемому для отслеживания сертификата Secure Boot из памяти. Поэтому обновления прошивки UEFI и сертификатов не должны влиять на значение, хранящееся в PCR 7.

Привязка для PCR 8 (компонента загрузки UEFI, используемого для отслеживания команд и командной строки ядра) не поддерживается, так как командная строка ядра изменяется при каждом обновлении ОС.

Шифрование корневой файловой системы с помощью привязки Clevis TPM2, привязанной к PCR 7

variant: fcos
version: 1.7.0
storage:
  luks:
    - name: root
      label: luks-root
      device: /dev/disk/by-partlabel/root
      clevis:
        custom:
          needs_network: false
          pin: tpm2
          config: '{"pcr_bank":"sha1","pcr_ids":"7"}'
      wipe_volume: true
  filesystems:
    - device: /dev/mapper/root
      format: xfs
      wipe_filesystem: true
      label: root

Более подробную документацию по полям config можно найти на страницах руководства clevis: man clevis-encrypt-tpm2

Следующую команду clevis можно использовать для подтверждения того, что шифрование корневой файловой системы привязано к PCR 7.

$ sudo clevis luks list -d /dev/disk/by-partlabel/root
1: tpm2 '{"hash":"sha256","key":"ecc","pcr_bank":"sha1","pcr_ids":"7"}'

Вот пример упрощённого синтаксиса конфигурации с Tang:

Шифрование корневой файловой системы с помощью привязки Clevis Tang

variant: fcos
version: 1.7.0
boot_device:
  luks:
    tang:
      - url: http://192.168.122.1:80
        thumbprint: bV8aajlyN6sYqQ41lGqD4zlhe0E

Система будет обращаться к серверу Tang при загрузке.

Дополнительную информацию о настройке сервера Tang см. в документации upstream.

Вы можете настроить как привязку Tang, так и привязку TPM2 (включая несколько серверов Tang для избыточности). По умолчанию для разблокировки корневой файловой системы требуется только устройство TPM2 или один сервер Tang. Это можно изменить с помощью ключа threshold:

Шифрование корневой файловой системы с помощью привязок как TPM2, так и Tang

variant: fcos
version: 1.7.0
boot_device:
  luks:
    tang:
      - url: http://192.168.122.1:80
        thumbprint: bV8aajlyN6sYqQ41lGqD4zlhe0E
    tpm2: true
    # this will allow rootfs unlocking only if both TPM2 and Tang pins are
    # accessible and valid
    threshold: 2

Задание размера корневого раздела

Если вы используете Ignition для перенастройки или перемещения корневого раздела, этот раздел не расширяется автоматически при первой загрузке (см. связанное обсуждение в этой задаче). В случае перемещения корневого раздела на новый диск (или несколько дисков) вам следует задать желаемый размер раздела с помощью поля size_mib. Если перенастройка корневой файловой системы выполняется на месте, как в примере с LUKS выше, вы можете изменить размер существующего раздела с помощью поля resize:

Изменение размера корневого раздела до максимального

variant: fcos
version: 1.7.0
storage:
  disks:
    - device: /dev/disk/by-id/coreos-boot-disk
      partitions:
        - label: root
          number: 4
          # 0 means to use all available space
          size_mib: 0
          resize: true
  luks:
    - name: root
      device: /dev/disk/by-partlabel/root
      clevis:
        tpm2: true
      wipe_volume: true
  filesystems:
    - device: /dev/mapper/root
      format: xfs
      wipe_filesystem: true
      label: root

Добавление swap

В этом примере создаётся раздел подкачки, занимающий весь диск sdb, создаётся область подкачки на нём и создаётся unit подкачки systemd, чтобы область подкачки была включена при загрузке.

Настройка раздела подкачки на втором диске

variant: fcos
version: 1.7.0
storage:
  disks:
    - device: /dev/sdb
      wipe_table: true
      partitions:
        - number: 1
          label: swap
  filesystems:
    - device: /dev/disk/by-partlabel/swap
      format: swap
      wipe_filesystem: true
      with_mount_unit: true

Добавление сетевого хранилища

Системы Fedora CoreOS можно настроить для монтирования сетевых файловых систем, таких как NFS и CIFS. Лучше всего это делать с помощью Ignition, создавая unit-ы systemd. Файловые системы можно монтировать при загрузке, создав стандартный mount unit. В качестве альтернативы файловую систему можно монтировать, когда пользователи обращаются к точке монтирования, создав дополнительный automount unit. Ниже приведены примеры каждого из них для файловой системы NFS.

Настройка монтирований NFS

Создание unit-а systemd для монтирования файловой системы NFS при загрузке.

Файл .mount должен быть назван на основе пути (например, /var/mnt/data = var-mnt-data.mount)

variant: fcos
version: 1.3.0
systemd:
  units:
    - name: var-mnt-data.mount
      enabled: true
      contents: |
        [Unit]
        Description=Mount data directory

        [Mount]
        What=example.org:/data
        Where=/var/mnt/data
        Type=nfs4

        [Install]
        WantedBy=multi-user.target

Создание unit-а systemd для монтирования файловой системы NFS, когда пользователи обращаются к точке монтирования (automount)

variant: fcos
version: 1.3.0
systemd:
  units:
    - name: var-mnt-data.mount
      contents: |
        [Unit]
        Description=Mount data directory

        [Mount]
        What=example.org:/data
        Where=/var/mnt/data
        Type=nfs4

    - name: var-mnt-data.automount
      enabled: true
      contents: |
        [Unit]
        Description=Automount data directory

        [Automount]
        TimeoutIdleSec=20min
        Where=/var/mnt/data

        [Install]
        WantedBy=multi-user.target

Включён только unit .automount. Он активирует unit .mount по требованию, когда происходит обращение к точке монтирования.

Расширенные примеры

В этом примере настраивается зеркалированный загрузочный диск с корневой файловой системой, зашифрованной с помощью TPM2, переопределяются размеры автоматически созданных реплик корневого раздела и добавляется зашифрованный зеркалированный раздел /var, занимающий оставшуюся часть дисков.

Зашифрованный зеркалированный загрузочный диск с отдельным /var

variant: fcos
version: 1.7.0
boot_device:
  # Change to match target architecture (aarch64, ppc64le, etc.)
  layout: x86_64
  luks:
    tpm2: true
  mirror:
    devices:
      - /dev/sda
      - /dev/sdb
storage:
  disks:
    - device: /dev/sda
      partitions:
        # Override size of root partition on first disk, via the label
        # generated for boot_device.mirror
        - label: root-1
          size_mib: 10240
        # Add a new partition filling the remainder of the disk
        - label: var-1
    - device: /dev/sdb
      partitions:
        # Similarly for second disk
        - label: root-2
          size_mib: 10240
        - label: var-2
  raid:
    - name: md-var
      level: raid1
      devices:
        - /dev/disk/by-partlabel/var-1
        - /dev/disk/by-partlabel/var-2
  luks:
    - name: var
      device: /dev/md/md-var
      # No key material is specified, so a random key will be generated
      # and stored in the root filesystem
  filesystems:
    - device: /dev/mapper/var
      path: /var
      label: var
      format: xfs
      wipe_filesystem: true
      with_mount_unit: true

Разметка диска

Все системы Fedora CoreOS начинают с одного и того же образа диска, который немного различается между архитектурами в зависимости от того, что требуется для загрузки. При первой загрузке корневая файловая система расширяется, заполняя оставшуюся часть диска. Образ диска можно настроить с помощью конфигураций Butane, чтобы переразметить диск и создать/переформатировать файловые системы. Установка на физическое оборудование не отличается; установщик лишь копирует необработанный образ на целевой диск и внедряет указанную конфигурацию в /boot для использования при первой загрузке.

См. Перенастройка корневой файловой системы для примеров поддерживаемых изменений корневого раздела.

Таблицы разделов

Использование номеров разделов для ссылки на конкретные разделы не рекомендуется; вместо этого следует использовать метки или UUID. Fedora CoreOS резервирует метки boot, boot-<number>, root, root-<number>, BIOS-BOOT, bios-<number>, EFI-SYSTEM и esp-<number>, а также имена устройств RAID md-boot и md-root. Создание разделов, файловых систем или устройств RAID с этими метками не поддерживается.

Таблица разделов x86_64

Образ диска x86_64 имеет формат GPT с защитным MBR. Он поддерживает загрузку как через BIOS, так и через UEFI (включая Secure Boot).

Разметка таблицы разделов со временем менялась. Текущая разметка:

Table 1. Таблица разделов для x86_64
Номер	Метка	Описание	Тип раздела
1	BIOS-BOOT	Содержит образ BIOS GRUB	raw data
2	EFI-SYSTEM	Содержит образ EFI GRUB и шим Secure Boot	FAT32
3	boot	Содержит конфигурацию GRUB, образы ядра/initramfs	ext4
4	root	Содержит корневую файловую систему	xfs

Раздел EFI-SYSTEM можно удалить или переформатировать при загрузке через BIOS. Аналогично, раздел BIOS-BOOT можно удалить или переформатировать при загрузке через EFI.

Смонтированные файловые системы

Fedora CoreOS использует OSTree — систему для управления несколькими загружаемыми деревьями операционной системы, совместно использующими хранилище. Каждая версия операционной системы является частью файловой системы /. Все развёртывания совместно используют один и тот же /var, который может находиться в той же файловой системе или монтироваться отдельно.

Здесь показаны точки монтирования по умолчанию для системы Fedora CoreOS, установленной на диск /dev/vda:

Точки монтирования по умолчанию на x86_64

$ findmnt --real # Some details are elided
TARGET        SOURCE                                                   FSTYPE  OPTIONS
/             /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash]     xfs     rw
|-/sysroot    /dev/vda4                                                xfs     ro
|-/etc        /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash/etc] xfs     rw
|-/usr        /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash/usr] xfs     ro
|-/var        /dev/vda4[/ostree/deploy/fedora-coreos/deploy/var]       xfs     rw
`-/boot       /dev/vda3                                                ext4    ro

Ранее раздел EFI System монтировался в /boot/efi, но теперь это не так. В системах, настроенных с зеркалированием загрузочного устройства, на каждом составляющем диске есть независимые разделы EFI.

Неизменяемый `/`, доступный только для чтения `/usr`

Поскольку OSTree используется для управления всеми файлами, принадлежащими операционной системе, точки монтирования / и /usr не доступны для записи. Любые изменения операционной системы следует вносить через rpm-ostree.

Аналогично, точка монтирования /boot не доступна для записи, а раздел EFI System по умолчанию не монтируется. Этими файловыми системами управляют rpm-ostree и bootupd, и администратор не должен изменять их напрямую.

Добавление каталогов верхнего уровня (т.е. /foo) в настоящее время не поддерживается и запрещено атрибутом неизменяемости.

Настоящий / (то есть корень файловой системы в разделе root) смонтирован только для чтения в /sysroot, и к нему нельзя обращаться или изменять его напрямую.

Конфигурация в `/etc` и состояние в `/var`

Единственные поддерживаемые места для записи — это /etc и /var. /etc должен содержать только конфигурационные файлы, и не предполагается, что он будет хранить данные. Все данные должны храниться в /var и не будут затронуты обновлениями системы. Традиционные места, которые могут хранить состояние (например, /home или /srv), являются символическими ссылками на каталоги в /var (например, /var/home или /var/srv).

Выбор версии и загрузка

Для каждой версии Fedora CoreOS, в настоящее время доступной в системе, создаётся пункт меню GRUB. Этот пункт меню ссылается на развёртывание ostree, которое состоит из ядра Linux, initramfs и хеша, связанного с коммитом ostree (передаётся через аргумент ядра ostree=). Во время загрузки ostree считывает этот аргумент ядра, чтобы определить, какое развёртывание использовать в качестве корневой файловой системы. Каждое обновление или изменение системы (установка пакетов, добавление аргументов ядра) создаёт новое развёртывание. Это позволяет выполнить откат к предыдущему развёртыванию, если обновление вызывает проблемы.

Want to help? Learn how to contribute to Fedora Docs ›