Конвейер DevOps, часть 2: пользуемся Fedora Core и mise

для

В этой серии статей Олег Филон, ментор Эйч Навыки, рассказывает, как прийти к крутому CI/CD пайплайну. Сегодня разбираемся, как выбрать ВМ и настроить облака с помощью Fedora Core и инструмента mise.

287 открытий3К показов

Дисклеймер! Перед прочтением настоятельно рекомендуем ознакомиться с первой частью статьи.

Если вы знакомы с FreeBSD, вы уже знаете её достоинства и недостатки по сравнению с Linux. Просуммирую некоторые отличия, важные для выбора облачной ВМ.

FreeBSD не поддерживает контейнеры в привычном понимании — ни docker, ни podman пока не портированы.
FreeBSD использует свою собственную лицензию The FreeBSD Copyright, позволяющую не раскрывать derivative work. Оценить распространённость FreeBSD иногда затруднительно, возможно, часть её кода используется и в Windows(C), и в MacOS(C). Только иногда разработчики сами признают её использование, например, Евгений Гаврилов, руководитель проекта vStack.
Метод разработки FreeBSD ближе к академическому стилю. Есть базовый набор пакетов base, включающий не только ядро, но и достаточно инструментов для сборки остальной системы, именуемой ports. Развитие системы управляется elected Core Team — сейчас в команде 9 человек.
Во FreeBSD давно используется система snapshots/rollback, позволяющая откатить изменения, если что-то сломалось.

Существует дистрибутив Linux, у которого есть некоторые из перечисленных особенностей — это Fedora Core.

Что такое Fedora Core и как с ней работать

Изначально эти идеи возникли в другом дистрибутиве — RedHat CoreOS.

Во-первых, система ориентирована на использование в облаках: в ней предоставляются образы для всех возможных систем виртуализации и форматов дисков. Во-вторых, она разделена на базовую систему, часть из которой монтируется только в режиме чтения (ro:read only), и остальное, доступное через контейнеры.

Обновление системы возможно автоматически, появилась особая утилита rpm-ostree, и можно откатить на предыдущую версию, если что-то не так. Таким образом, CoreOS становится иммутабельной, изменения базовой части системы невозможны в обход коммитов rpm-ostree.

Я как-то провел эксперимент: установил в Yandex Cloud версию FedoraCore 35, выпущенную в конце 2021 года, с включённым по умолчанию сервисом zincati, который автоматически обновляет базовую систему (у него стабильные релизы). Посчитал, сколько коммитов сделано с тех пор: да, как и в git, здесь используется CAS (content-addressable storage), уже привычные нам хэши. ВМ обновилась и рестартанула 8 раз, если я не пропустил какой-либо рестарт:

			grep ^Linux uname*|cut -d" " -f1,3,7-|sed 's/Linux//;s/ x86.*//'
uname35: 5.15.7-200.fc35.x86_64 Dec 8 19:00:47 UTC 2021
uname36: 5.17.5-300.fc36.x86_64 Thu Apr 28 15:51:30 UTC 2022
uname37: 6.1.18-200.fc37.x86_64 Sat Mar 11 16:09:14 UTC 2023
uname38: 6.5.8-200.fc38.x86_64 Fri Oct 20 15:53:48 UTC 2023
uname39.0: 6.6.8-200.fc39.x86_64 Thu Dec 21 04:01:49 UTC 2023
uname39.1: 6.8.4-200.fc39.x86_64 Thu Apr  4 20:45:21 UTC 2024
uname40.0: 6.8.11-300.fc40.x86_64 Mon May 27 14:53:33 UTC 2024
uname40.1: 6.11.3-200.fc40.x86_64 Thu Oct 10 22:31:19 UTC 2024
uname41: 6.12.7-200.fc41.x86_64 Fri Dec 27 17:05:33 UTC 2024

Теперь можно сравнить с этой же системой, установленной из свежего имиджа — как и ожидалось, системы не отличались, хэши коммитов одинаковы. Это то, что имеется ввиду под иммутабельностью ОС. Кроме иммутабельности и смонтированных только по чтению некоторых каталогов, есть и другие меры безопасности. Используется версия Security-Enhanced Linux, никаких логинов по умолчанию, настройки пользователя либо через утилиту cloud-init, либо специальная утилита butane и так называемый ignition file.

У проекта Fedora есть подробнейшая документация — в ней лежит самое авторитетное руководство по установке. Тем не менее у меня возникла пара вопросов:

Во-первых, для преобразования .yaml файла в ignition, который по сути обычный .json файл, используется особый инструмент butane, написанный на языке Go. Судя по размеру образа 130M, он довольно увесистый, но никак не упоминаются другие утилиты для конвертациии .yaml в .json.
Во-вторых, в простейшем случае для первого логина вообще не нужны ни butane, ни .yaml. Вот пример минимального ignition.json файла, который создаётся руками:

			cat ignition.json
{
  "ignition": {
    "version": "3.3.0"
  },
  "passwd": {
    "users": [
      {
        "name": "core",
        "sshAuthorizedKeys": [
          "<ssh-ed25519 your ssh pub key content>"
        ]
      }
    ]
  }
}

Скопируем этот файл в каталог /tmp, он нужен один раз для первого входа, не содержит секретов, к нему нужно будет указать полный путь. Как и ранее, скачиваем свежий образ для libvirt/qemu: выбираем нужную архитектуру и формат диска, проверяем контрольные суммы и цифровые подписи. Команды для создания ВМ будут немного отличаться от уже опробованных из прошлой статьи — сначала сделаем для нашего ignition.json опцию, которую понимает virt-install:

			export IGN=(--qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=/tmp/ignition.json")
echo $IGN
--qemu-commandline=-fw_cfg name=opt/com.coreos/config,file=/tmp/ignition.json

Затем распаковываем образ в стандартный каталог и создаём ВМ:

			xz -cdv fedora-coreos-41.20250215.3.0-qemu.x86_64.qcow2.xz > /var/lib/libvirt/images/fc41stab.qcow2
virt-install --import --memory 4096 --vcpus 1 -w bridge=br0 \
 --os-variant="fedora-coreos-stable" --graphics=none \
 -n fc41stab "${IGN[@]}" --disk /var/lib/libvirt/images/fc41stab.qcow2

Созданная заранее переменная шелл использована как "${IGN[@]}". virt-install выдаст интереснейший лог процесса инсталяции, а в самом конце — перед приглашением — покажет IP-адрес вновь созданной ВМ. Переходим в другую консоль и проверяем наш ssh-ключ: ssh -v core@192.168.100.2 в моём случае. После успешного логина выполняем первоочерёдные проверки и настройки:

			$ id
uid=1000(core) gid=1000(core) groups=1000(core),4(adm),10(wheel),16(sudo),190(systemd-journal) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
$ sudo -l
Matching Defaults entries for core on fc41stab:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR
    LS_COLORS", env_keep+="MAIL QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT
    LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET
    XAUTHORITY", secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/var/lib/snapd/snap/bin

User core may run the following commands on fc41stab:
    (ALL) ALL
    (ALL) NOPASSWD: ALL
$ sudo hostnamectl hostname fc41stab
$ sudo passwd core

Теперь ВМ можно остановить и сделать финальные настройки нашего персонального облака для этой ВМ. Добавим MAC- и статический IP-адреса в dnsmasq.conf и зададим имя новой ВМ в сети (пример есть в прошлой статье). Откроем в virt-manager окно overview, затем откроем вкладку XML и в самом конце удалим конфиг для qemu — целиком вот этот фрагмент:

			<qemu:commandline>
  <qemu:arg value="-fw_cfg"/>
  <qemu:arg value="name=opt/com.coreos/config,file=/tmp/ignition.json"/>
</qemu:commandline>

Далее кнопка Apply. Возможно, virt-manager попросит сначала установить Edit → Preferences → General → Enable XML editing. То же самое можно сделать из командной строки: sudo virsh edit fc41stab. Ignition-файл нужен только для установки, далее эту ВМ можно донастраивать, клонировать, копировать её образ куда угодно, в том числе в большие облака.

А мы продолжим знакомство с этой необычной системой, как её рекламирует проект Федора:

Fedora CoreOS — это автоматически обновляемая, минимальная, монолитная, ориентированная на контейнеры операционная система, разработанная для кластеров, работоспособная автономно, оптимизированная для Kubernetes.

Проверим, что dnsmasq обновился, и начнём по порядку.

			$ host fc41stab
fc41stab.local has address 192.168.100.118
fc41stab.local mail is handled by 1 fc41stab.local.
$ ssh -v fc41stab

Далее выполняем команды внутри ВМ. Основное, к чему придётся привыкнуть, — что часть каталогов смонтированы readonly, запись в них в обход утилиты rpm-ostree невозможна даже судоерам:

			core@fc41stab:~$ mount|grep ro,|grep ^/dev
/dev/vda4 on /sysroot type xfs (ro,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/vda3 on /boot type ext4 (ro,nosuid,nodev,relatime,seclabel)
core@fc41stab:~$ mount|grep rw,|grep ^/dev
/dev/vda4 on /etc type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/vda4 on /sysroot/ostree/deploy/fedora-coreos/var type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)
/dev/vda4 on /var type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota)

Я специально грепнул только реальные устройства, потому что кроме них смонтированы ещё 19 виртуальных — пока углубляться не будем. Как видно, в режиме rw смонтированы /etc и /var. Даже стандартый home — это линк /home → var/home.

За автоматические обновления отвечает сервис zincati. Если его отключить, обновления можно запускать вручную: rpm-ostree --bypass-driver upgrade. После рестарта проверяем новое состояние системы:

			core@fc41stab:~$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Tue 2025-03-18 12:22:26 UTC)
Deployments:
● fedora:fedora/x86_64/coreos/stable
                  Version: 41.20250302.3.2 (2025-03-17T22:11:15Z)
                   Commit: aa4d65c700789b34bb953c2ee8250c6643802ed57ab1f4f5dd61e821b2be8709
             GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1

  fedora:fedora/x86_64/coreos/stable
                  Version: 41.20250215.3.0 (2025-03-04T19:05:12Z)
                   Commit: d0742b8c6b45095a6e4f856d787a65f4d2702316856d78227f0b68f8f85511b5
             GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1

rpm-ostree rollback позволяет откатить обновления к предыдущему комиту. Другие полезные команды:

rpm-ostree db diff — список обновлённых пакетов между комитами
rpm-ostree db list — список и версии пакетов в комитах

А как же устанавливать пакеты привычным dnf? Это своевременный вопрос. Посмотрим сначала что уже стоит:

			core@fc41stab:~/temp$ rpm-ostree db list aa4d65> rpm-ostree.db.list.250317
core@fc41stab:~/temp$ head -1 rpm-ostree.db.list.250317
ostree commit: aa4d65 (aa4d65c700789b34bb953c2ee8250c6643802ed57ab1f4f5dd61e821b2be8709)
core@fc41stab:~/temp$ wc -l rpm-ostree.db.list.250317
440 rpm-ostree.db.list.250317

Это напоминает FreeBSD base, но важно, что набор включает podman, docker, git — для остального есть утилита toolbox. Она делает доступными все пакеты федоры, упакованные в контейнер. Заглянем в toolbox:

			core@fc41stab:~/temp/tbox$ toolbox
Error: missing command

create    Create a new Toolbx container
enter     Enter an existing Toolbx container
list      List all existing Toolbx containers and images

Run 'toolbox --help' for usage.
core@fc41stab:~/temp/tbox$ toolbox create tbox
Image required to create Toolbx container.
Download registry.fedoraproject.org/fedora-toolbox:41 (384.2MB)? [y/N]: y
Created container: tbox
Enter with: toolbox enter tbox
core@fc41stab:~/temp/tbox$ podman images
REPOSITORY                                 TAG         IMAGE ID      CREATED      SIZE
registry.fedoraproject.org/fedora-toolbox  41          2288b69816a7  7 hours ago  2.29 GB
core@fc41stab:~/temp/tbox$ toolbox enter tbox
⬢ [core@toolbx tbox]$

Мы оказались внутри контейнера — об этом говорит изменившееся приглашение $PS1. Если снова посмотреть mount, увидим ещё больше хитро подмонтированных каталогов — этакий оверлей из базовой и контейнерной ФС. Но зато работает dnf, поэтому можно устанавливать любые пакеты. Добавим привычные, без них неуютно в новой системе:

			⬢ [core@toolbx tbox]$ sudo dnf update
Updating and loading repositories:
 Fedora 41 openh264 (From Cisco) - x86_64                                                            100% |   7.2 KiB/s |   4.8 KiB |  00m01s
 Fedora 41 - x86_64                                                                                  100% |  16.8 MiB/s |  35.2 MiB |  00m02s
 Fedora 41 - x86_64 - Updates                                                                        100% |   5.2 MiB/s |  11.7 MiB |  00m02s
Repositories loaded.
Nothing to do.
⬢ [core@toolbx tbox]$ sudo dnf install tmux btop

Как видим, пакеты доступны, но желательно иметь их вне контейнера. Нет проблем: скопируем их в свой ~/bin каталог, он одинаков и внутри, и снаружи контейнера:

			⬢ [core@toolbx tbox]$ type tmux
tmux is /usr/bin/tmux
⬢ [core@toolbx tbox]$ mkdir ~/bin
⬢ [core@toolbx tbox]$ cp /usr/bin/tmux ~/bin
⬢ [core@toolbx tbox]$ type btop
btop is /usr/bin/btop
⬢ [core@toolbx tbox]$ cp /usr/bin/btop ~/bin

Выйдем из контейнера и проверим:

			⬢ [core@toolbx tbox]$ 
logout
core@fc41stab:~/temp/tbox$ ldd ~/bin/*
/var/home/core/bin/btop:
        linux-vdso.so.1 (0x00007f45e8231000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f45e7fc3000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f45e7edd000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f45e7eae000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f45e7cbb000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f45e8233000)
/var/home/core/bin/tmux:
        linux-vdso.so.1 (0x00007ff7f2acb000)
        libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007ff7f28c8000)
        libutempter.so.0 => /lib64/libutempter.so.0 (0x00007ff7f28c3000)
        libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007ff7f2895000)
        libevent_core-2.1.so.7 => /lib64/libevent_core-2.1.so.7 (0x00007ff7f285d000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ff7f2777000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007ff7f2764000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ff7f256f000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007ff7f2562000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff7f2533000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff7f2acd000)

А теперь серьезно: настраиваем Fedora Core сервер для команды разрабов

Для начала настроим полноценный dev env: репозиторий кода, образы контейнеров, инструменты для сборки и сервер приложений.

Обычно в команде есть один админ или несколько. Уже созданный пользователь core — это админ, у него есть права sudo, плюс ему доступен контейнер tbox. В нашей Федоре каталог с секретами устроен особым образом:

			core@fc41stab:~$ tree ~/.ssh/
/var/home/core/.ssh/
└── authorized_keys.d
    └── ophil

2 directories, 1 file

Первоначально обычный файл authorized_keys назывался ignition и располагался в каталоге ~/.ssh/authorized_keys.d, что подразумевает, что можно ещё добавить ключей, назвав их никами других админов. Так же можно поступить с разрабами — настроить для всех один dev env.

Создадим нового пользователя без прав sudo:

			sudo adduser dev;
sudo usermod -aG docker dev
sudo passwd dev
sudo cp -a ~/.ssh/ ~dev/
sudo chown -R dev:dev ~dev/.ssh

Как мы уже знаем, мелкие утилиты можно просто скопировать из тулбокса в ~/bin или /usr/local/bin. Для языков программирования и прочих инструментов есть замечательная программа mise. Сейчас мы её установим для dev и немного познакомимся. Свой ключ я уже добавил в ~dev/.ssh/authorized_keys.d/, так что логинимся и настраиваем инструменты для команды разрабов.

			ssh -v dev@fc41stab
dev@fc41stab:~$ id
uid=1001(dev) gid=1001(dev) groups=1001(dev),983(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
dev@fc41stab:~$ curl https://mise.run | sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9557  100  9557    0     0  26211      0 --:--:-- --:--:-- --:--:-- 26255
mise: installing mise...
######################################################################## 100.0%
mise: installed successfully to /var/home/dev/.local/bin/mise
mise: run the following to activate mise in your shell:
echo "eval \"\$(/var/home/dev/.local/bin/mise activate bash)\"" >> ~/.bashrc

mise: run `mise doctor` to verify this is setup correctly
dev@fc41stab:~$ echo "eval \"\$(/var/home/dev/.local/bin/mise activate bash)\"" >> ~/.bashrc
dev@fc41stab:~$ . ~/.bashrc

mise позволяет устанавливать и использовать различные версии языков программирования, инструментов и библиотек. Другие менеджеры версий, например, aqua, asdf, ubi — собрали репозитории таких инструментов, и mise их использует в качестве бэкендов. Огласим весь список:

			dev@fc41stab:~/src$ mise registry > mise.registry
dev@fc41stab:~/src$ wc -l mise.registry 
883 mise.registry
dev@fc41stab:~/src$ mise ls-remote python|tail
3.12.6
3.12.7
3.12.8
3.12.9
3.13.0
3.13-dev
3.13.1
3.13.2
3.14.0a6
3.14-dev
dev@fc41stab:~/src$ mise -v use -g python@3.12
dev@fc41stab:~/src$ mise ls
Tool    Version  Source                      Requested 
python  3.12.9   ~/.config/mise/config.toml  3.12

Да, список великоват: сохранил в файл — 883 штук, и он постоянно растёт. Это только названия пакетов, поиск версий, а команда mise ls-remote python выдала 911 вариантов для python.

Зато теперь можно настраивать пайплайны для наших разработчиков. А в следующей статье разберемся, как работать с пайплайнами и хуками в git.

287 открытий3К показов

Также рекомендуем

Разработчик написал 25 тыс строк кода... на экране смартфона

Разработчик создал плагин для Neovim, написав 25 000 строк кода на смартфоне с помощью Termux. Проект уже собрал 2K звёзд на GitHub, демонстрируя, что даже в ограниченных условиях можно достичь успеха

Жизнь после теста Тюринга: языковым моделям пора делать ошибки и учиться на своём опыте

Учёные DeepMind предлагают заменить тест Тьюринга на «эпоху опыта» — ИИ должен действовать, ошибаться и учиться на своём прошлом

Все программирование, которое должен знать Project Manager

Рассказываем, кто такие project-менеджеры и должны ли они уметь программировать и читать код.

🔥 Самый популярный Linux-дистрибутив Ubuntu отметил 20-летие

Самый популярный Linux-дистрибутив празднует 20-летие. За два десятилетия Ubuntu изменила экосистему свободного ПО, став стандартом для миллионов пользователей и ключевым игроком в развитии облачных технологий