Fedora coreos что это

Установите/запустите Fedora CoreOS (FCOS) на KVM/OpenStack |

Fedora CoreOS (FCOS) – это минимальная операционная система, предназначенная для безопасного выполнения контейнерных рабочих нагрузок в любом масштабе. Строительными блоками этой операционной системы являются великолепные CoreOS и Fedora Atomic. Он имеет функцию автоматического обновления и является неизменяемым, чтобы обеспечить стабильность и надежность ОС. ОС автоматически обновляется с использованием последних улучшений ОС, исправлений ошибок и обновлений безопасности с помощью rpm-ostree.

В отличие от других операционных систем Linux, Fedora CoreOS (FCOS) не имеет конфигурации во время установки. Каждая система FCOS начинается с общего образа диска. Для каждого механизма развертывания (облачная виртуальная машина, локальная виртуальная машина, «голое железо») конфигурация может быть предоставлена при первой загрузке. FCOS считывает и применяет файл конфигурации с помощью Ignition.

При установке Fedora CoreOS на «голое железо» или в качестве виртуальной машины с файлом ISO Ignition внедрит конфигурацию во время установки. Но для развертываний, выполняемых в облачной среде, Ignition соберет конфигурацию через облачный механизм пользовательских данных.

Запустите/установите Fedora CoreOS (FCOS) на KVM/OpenStack.

В этом руководстве мы увидим, как можно запустить Fedora CoreOS (FCOS) в среде виртуализации OpenStack и KVM. Ниже приведен стандартный процесс подготовки неизменяемой инфраструктуры Fedora CoreOS на OpenStack/KVM.

Вы начинаете с написания конфигурации Fedora CoreOS (FCC). Это файл YAML, который определяет желаемую конфигурацию машины.
Затем вы воспользуетесь транспилятором конфигурации Fedora CoreOS для проверки вашего FCC и преобразования его в конфигурацию Ignition.
Последний шаг — запуск компьютера с Fedora CoreOS и передача сгенерированной конфигурации Ignition. после того, как машина успешно загрузилась, можно начать подготовку.

Шаг 1. Загрузите последний образ QCOW2.

Существует два способа загрузки образов FCOS для OpenStack и KVM.

Вариант 1) Использование coreos-installer

coreos-installer — это программа, помогающая установить Fedora CoreOS (FCOS) и Red Hat Enterprise Linux CoreOS (RHCOS). Этот инструмент можно использовать для загрузки последних образов для FCOS.

Установите coreos-installer в Fedora:

### Fedora Workstation / Server ### sudo dnf -y install coreos-installer ### Fedora COreOS ### rpm-ostree install coreos-installer

Проверьте параметры загрузки команды:

$ coreos-installer download --help coreos-installer-download 0.11.0 Download a CoreOS image USAGE: coreos-installer download [OPTIONS] OPTIONS: -s, --stream Fedora CoreOS stream [default: stable] -a, --architecture Target CPU architecture [default: x86_64] -p, --platform Fedora CoreOS platform name [default: metal] -f, --format Image format [default: raw.xz] -u, --image-url Manually specify the image URL -C, --directory Destination directory [default: .] -d, --decompress Decompress image and don't save signature --insecure Skip signature verification --stream-base-url Base URL for Fedora CoreOS stream metadata --fetch-retries Fetch retries, or "infinite" [default: 0] -h, --help Prints help information

Список образов Fedora CoreOS, доступных для загрузки:

$ coreos-installer list-stream Architecture Platform Format aarch64 aws vmdk.xz aarch64 metal 4k.raw.xz aarch64 metal iso aarch64 metal pxe aarch64 metal raw.xz aarch64 openstack qcow2.xz aarch64 qemu qcow2.xz x86_64 aliyun qcow2.xz x86_64 aws vmdk.xz x86_64 azure vhd.xz x86_64 azurestack vhd.xz x86_64 digitalocean qcow2.gz x86_64 exoscale qcow2.xz x86_64 gcp tar.gz x86_64 ibmcloud qcow2.xz x86_64 metal 4k.raw.xz x86_64 metal iso x86_64 metal pxe x86_64 metal raw.xz x86_64 nutanix qcow2.xz x86_64 openstack qcow2.xz x86_64 qemu qcow2.xz x86_64 virtualbox ova x86_64 vmware ova x86_64 vultr raw.xz

Загрузить изображение для OpenStack:

coreos-installer download --stream stable --platform openstack --decompress --format qcow2.xz

Вывод выполнения команды:

Downloading Fedora CoreOS stable x86_64 openstack image (qcow2.xz) and signature > Read disk 662.0 MiB/662.0 MiB (100%) gpg: Signature made Wed 27 Apr 2022 02:29:28 AM EAT gpg: using RSA key 787EA6AE1147EEE56C40B30CDB4639719867C58F gpg: Good signature from "Fedora (35) <[email >" [ultimate] ./fedora-coreos-35.20220410.3.1-openstack.x86_64.qcow2

Убедитесь, что созданный файл находится в вашем текущем рабочем каталоге:

$ ls fedora-coreos-*-openstack.x86_64.qcow2 fedora-coreos-35.20220410.3.1-openstack.x86_64.qcow2

Для Openstack вам необходимо загрузить образ Fedora CoreOS в сервис OpenStack Glance:

openstack image create "fcos" \ --file fedora-coreos-35.20220410.3.1-openstack.x86_64.qcow2 \ --disk-format qcow2 --container-format bare \ --public

Подтвердите, что изображение загружено:

$ openstack image list +--------------------------------------+-----------------+--------+ | ID | Name | Status | +--------------------------------------+-----------------+--------+ | 6576c788-19e1-4de4-bf63-a769763cd00d | fcos | active | +--------------------------------------+-----------------+--------+

Цему/KVM:

coreos-installer download --stream stable --platform qemu --decompress --format qcow2.xz

Пример вывода команды:

Downloading Fedora CoreOS stable x86_64 qemu image (qcow2.xz) and signature > Read disk 657.6 MiB/657.6 MiB (100%) gpg: Signature made Wed 27 Apr 2022 02:23:48 AM EAT gpg: using RSA key 787EA6AE1147EEE56C40B30CDB4639719867C58F gpg: Good signature from "Fedora (35) <[email >" [ultimate] ./fedora-coreos-35.20220410.3.1-qemu.x86_64.qcow2

Вариант 2) Загрузка образов FCOS вручную

Скопируйте URL-адрес последней версии изображения со страницы загрузки FCOS для вашей платформы.

OpenStack:

wget -O fedora-coreos-openstack.qcow2.xz unxz fedora-coreos-openstack.qcow2.xz

QEMU/KVM:

wget -O fedora-coreos-qemu.qcow2.xz unxz fedora-coreos-qemu.qcow2.xz

Для Openstack вам необходимо загрузить образ Fedora CoreOS в сервис OpenStack Glance:

openstack image create "fcos" \ --file fedora-coreos-openstack.qcow2 \ --disk-format qcow2 --container-format bare \ --public

Подтвердите, что изображение загружено:

$ openstack image list +--------------------------------------+-----------------+--------+ | ID | Name | Status | +--------------------------------------+-----------------+--------+ | 6576c788-19e1-4de4-bf63-a769763cd00d | fcos | active | +--------------------------------------+-----------------+--------+

Шаг 2. Создайте конфигурацию Fedora CoreOS (FCC)

FCC — это файл YAML, имеющий желаемую конфигурацию машины. FCC поддерживают все функции Ignition, а также предоставляют дополнительный синтаксис («sugar»), который упрощает указание типичных изменений конфигурации.

Это мой базовый файл конфигурации YAML для добавления ключа SSH к пользователю core по умолчанию.

$ vim fcos.fcc variant: fcos version: 1.0.0 passwd: users: - name: core ssh_authorized_keys: - ssh-rsa

core — имя пользователя FCOS.
— это содержимое вашего открытого ключа.

Полную информацию о FCC и ее спецификациях можно найти на странице подготовки и настройки FCOS.

Шаг 3. Преобразование конфигурации FCC в конфигурацию зажигания.

Теперь мы будем использовать транспилятор конфигураций Fedora CoreOS для проверки нашего FCC и преобразования его в конфигурацию Ignition.

### Podman ### podman pull quay.io/coreos/fcct podman run -i --rm quay.io/coreos/fcct --pretty --strict fcos.ign ### Docker ### docker pull quay.io/coreos/fcct docker run -i --rm quay.io/coreos/fcct --pretty --strict fcos.ign

Замените fcos.fcc именем файла FCC и fcos.ign именем создаваемого файла зажигания.

Вы можете вручную проверить файл конфигурации зажигания с помощью:

### Podman ### podman run --rm -i quay.io/coreos/ignition-validate - < fcos.ign ### Docker ### docker run --rm -i quay.io/coreos/ignition-validate - < fcos.ign

Шаг 4. Запустите компьютер с Fedora CoreOS.

Как только у вас будет готов файл зажигания, вы можете создать компьютер с Fedora CoreOS, передав созданную конфигурацию Ignition.

В OpenStack

OpenStack CLI: настройка и использование OpenStack CLI

openstack server create \ --image fcos \ --key-name \ --flavor m1.small \ --security-group \ --network private \ --user-data fcos.ign \ fcos

с именем вашего SSH-ключа, загруженного в OpenStack.
с идентификатором вашей группы безопасности, загруженным в OpenStack.

Немедленный вывод при запуске сборки

+-------------------------------------+---------------------------------------------+ | Field | Value | +-------------------------------------+---------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | ru6YiFeRLWn5 | | config_drive | | | created | 2020-01-24T19:27:11Z | | flavor | m1.small (1) | | hostId | | | id | 6402494f-a2b1-4b6d-b462-7bc54d38d53b | | image | fcos (6576c788-19e1-4de4-bf63-a769763cd00d) | | key_name | jmutai | | name | fcos | | progress | 0 | | project_id | 06bcc3c56ab1489282b65681e782d7f6 | | properties | | | security_groups | name='7fffea2a-b756-473a-a13a-219dd0f1913a' | | status | BUILD | | updated | 2020-01-24T19:27:11Z | | user_id | 336acbb7421f47f8be4891eabf0c9cc8 | | volumes_attached | | +-------------------------------------+---------------------------------------------+

Проверьте статус виртуальной машины:

$ openstack server list --name fcos +--------------------------------------+------+--------+---------------------+-------+----------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+------+--------+---------------------+-------+----------+ | 6402494f-a2b1-4b6d-b462-7bc54d38d53b | fcos | ACTIVE | private=10.10.1.126 | fcos | m1.small | +--------------------------------------+------+--------+---------------------+-------+----------+

Давайте посмотрим, сможем ли мы пропинговать виртуальную машину:

$ ping -c 3 10.10.1.126 PING 10.10.1.126 (10.10.1.126) 56(84) bytes of data. 64 bytes from 10.10.1.126: icmp_seq=1 ttl=64 time=0.320 ms 64 bytes from 10.10.1.126: icmp_seq=2 ttl=64 time=0.297 ms 64 bytes from 10.10.1.126: icmp_seq=3 ttl=64 time=0.373 ms --- 10.10.1.126 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.297/0.330/0.373/0.031 ms

Можем ли мы подключиться к экземпляру по SSH?

$ ssh [email Warning: Permanently added '10.10.1.126' (ECDSA) to the list of known hosts. Enter passphrase for key '/home/centos/.ssh/id_rsa': Fedora CoreOS 31.20200113.3.1 Tracker: https://github.com/coreos/fedora-coreos-tracker

Проверьте версию ОС:

$ cat /etc/os-release NAME=Fedora VERSION="35.20220410.3.1 (CoreOS)" ID=fedora VERSION_ID=35 VERSION_CODENAME="" . $ uname -a

На KVM/QEMU

Скопируйте загруженный образ в каталог установки виртуальных машин, например:

sudo cp fedora-coreos-qemu.qcow2 /var/lib/libvirt/images/fedora-coreos-qemu.qcow2

С помощью virt-install:

sudo virt-install -n fcos --vcpus 2 -r 2048 \ --os-variant=fedora31 --import \ --network bridge=virbr0 \ --disk=/var/lib/libvirt/images/fedora-coreos-qemu.qcow2,format=qcow2,bus=virtio \ --noautoconsole \ --qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=/path/to/fcos.ign"

Или используя переменные:

IGNITION_CONFIG="/path/to/example.ign" IMAGE="/path/to/image.qcow2" VM_NAME="fcos" VCPUS="2" RAM_MB="2048" DISK_GB="10" sudo virt-install --connect="qemu:///system" \ --name="$" \ --vcpus="$" \ --memory="$" \ --os-variant="fedora-coreos-$STREAM" \ --import \ --graphics=none \ --disk="size=$,backing_store=$" \ --qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=$"

Установка пакетов программного обеспечения в Fedora CoreOS

Существует ограничение на количество пакетов, которые вы можете установить в Fedora CoreOS. Основной способ обновления Fedora CoreOS и установки приложений — rpm-ostree.

rpm-ostree работает путем изменения вашей установки FCOS, расширяя пакеты, из которых состоит Silverblue. При наслоении пакета создается новое «развертывание» или корень загрузочной файловой системы, и после наслоения пакета необходимо перезагрузить систему. Это сохраняет откат и транзакционную модель.

Сначала сгенерируйте метаданные репозитория rpm:

$ sudo rpm-ostree refresh-md Enabled rpm-md repositories: updates fedora Updating metadata for 'updates'. done rpm-md repo 'updates'; generated: 2020-01-24T14:56:09Z Updating metadata for 'fedora'. done rpm-md repo 'fedora'; generated: 2019-10-23T22:52:47Z Importing rpm-md. done

Пакет можно установить на Silverblue, используя:

$ sudo rpm-ostree install Example: $ sudo rpm-ostree install vim Checking out tree f480038. done Enabled rpm-md repositories: updates fedora rpm-md repo 'updates' (cached); generated: 2020-01-24T14:56:09Z rpm-md repo 'fedora' (cached); generated: 2019-10-23T22:52:47Z Importing rpm-md. done Resolving dependencies. done Will download: 13 packages (20.0 MB) Downloading from 'fedora'. done Downloading from 'updates'. done Importing packages. done Checking out packages. done Running pre scripts. done Running post scripts. done Running posttrans scripts. done Writing rpmdb. done Writing OSTree commit. done Staging deployment. done .

После установки пакетов требуется перезагрузка:

sudo systemctl reboot

Установка на голый металл

Если вы заинтересованы в установке FCOS на «голое железо» с загрузкой ISO или PXE, следуйте инструкциям по установке «голого железа», чтобы записать Fedora CoreOS на диск. Зажигание подается во время установки.

Оставайтесь на связи: у нас будет больше руководств по Fedora CoreOS. А пока посмотрите другие руководства:

Управляйте пакетами в Fedora Silverblue с помощью Toolbox, rpm-ostree и Flatpak
Как запустить Docker-контейнеры с помощью Podman и Libpod
Настройте реестр контейнеров Docker с помощью Podman и Let’s Encrypt SSL
Установите Minikube Kubernetes на CentOS 8/CentOS 7 с KVM

ОС для контейнеров Fedora CoreOS продолжит развитие Fedora Atomic и Container Linux

На этой неделе состоялся анонс первой предварительной версии Fedora CoreOS — специальной редакции Linux-дистрибутива Fedora, предназначенной для запуска приложений в контейнерах. По факту новая система продолжила развитие двух других проектов: Fedora Atomic Host и CoreOS Container Linux.

Наработки компании CoreOS, появившейся в 2013 году и ставшей хорошо известной в среде DevOps-инженеров и других любителей Linux-контейнеров, перешли к Red Hat в результате поглощения, что случилось полтора года назад. В то же самое время у американского Linux-вендора уже не один год формировалось своё видение нового ~~дивного~~ контейнерного мира — и происходило это, в частности, в рамках Project Atomic (о результатах его деятельности мы писали, например, здесь).

Появление Fedora CoreOS подтвердило намерения Red Hat объединить лучшее из собственных и приобретённых наработок в виде одного дистрибутива, призванного стать стандартом для развёртывания и запуска приложений в контейнерах. Как сообщается в анонсе проекта, он «сочетает инструменты provisioning'а, модель автоматических обновлений и философию Container Linux [от CoreOS] и технологию пакетирования, поддержку [стандарта] OCI, а также безопасность от SELinux из Atomic Host».

Среди основных фич Fedora CoreOS на данный момент называются:

следование принципам неизменной инфраструктуры(immutable infrastructure) в виде базового образа ОС (generic OS image) и последующего использования Ignition для provisioning'а: конфигурация системы описывается в YAML-документе FCC (Fedora CoreOS Config) и передаётся в FCCT(Fedora CoreOS Config Transpiler) для валидации и преобразования в конфиг для Ignition; после запуска машины изменение её конфигурации возможно только путём модификации FCC-файла и повторного provisioning'а;
автоматические обновления: новые релизы ОС автоматически скачиваются и устанавливаются, выкатываясь постепенно во времени и не требуя вмешательства пользователей; сами релизы при этом распространяются в нескольких «потоках» (release streams): testing, stable, next, — каждый из которых получает обновления безопасности и исправление критических багов;
встроенный сервис телеметрииfedora-coreos-pinger, периодически собирающий информацию о машине (версию ОС, облачную платформу, тип сущности) — без каких-либо уникальных идентификаторов — и передающий её на серверы проекта Fedora (авторы обещают инструкцию, как отключить этот сервис).

Fedora CoreOS предназначен для использования в production, но это не относится к текущей предварительной версии. Ожидается, что систему объявят стабильной через полгода. Её предшественник в лице Fedora Atomic Host будет поддерживаться до конца жизни Fedora 29 (т.е. по конец ноября), и всем его пользователям рекомендуется мигрировать на Fedora CoreOS.

Образы для загрузки доступны здесь, а быстрая инструкция по запуску — здесь.

P.S.

Читайте также в нашем блоге:

«Представлен Talos — современный Linux-дистрибутив для Kubernetes»;
«Red Hat заменяет Docker на Podman»;
«Прошлое, настоящее и будущее Docker и других исполняемых сред контейнеров в Kubernetes»;
«Linux-дистрибутив from scratch для сборки Docker-образов — наш опыт с dappdeps».

CoreOS — Linux для минималистичных кластеров. Коротко

CoreOS — это операционная система на базе Linux для построения легко и гибко масштабируемых кластеров. CoreOS — минималистичный дистрибутив. Установочный ISO образ объемом всего в 136Мб, а в памяти на конечной машине после установки и запуска она займет всего 114Мб. CoreOS основан на ChromeOS, который в свою очередь базируется на Gentoo.

Фактически, CoreOS можно условно можно разделить на следующие части:

Systemd — управляет локальными службами на машинах кластера
Docker — обеспечивает изоляцию служб, но его использование, в принципе, не обязательно
Etcd — распределенно хранит конфигурацию кластера
Fleet — обеспечивает распределенное управление службами («надстройка» над systemd)

CoreOS умеет запускать службы systemd на нужных машинах кластера, следить за их состоянием, хранить их конфигурацию.

Systemd

В CoreOS используется обычный systemd, который сейчас можно встретить во многих дистрибутивах Linux. Это система локального управления Linux-службами.

Docker

О Docker уже не раз писали на Хабре. Если коротко и по-простому — Docker берет ядро хостовой операционной системы Linux, монтирует к нему указанный вами образ файловой системы и позволяет работать внутри этого образа как будто вы находитесь в виртуализованном окружении.

Обратите внимание, что Docker не использует виртуализацию. Для изоляции процессов используются cgroups и namespaces, что позволяет избавиться от довольно серьезного оверхеда, который дают такие инструменты как KVM. Конечно, Docker можно использовать и на Mac и на Windows, но в этом случае хостовая операционная система должна будет работать внутри VirtualBox или любой другой системы виртуализации, поскольку Docker для работы необходимо ядро Linux (см. Boot2Docker)

Etcd

Etcd — распределенное Key-Value хранилище, которое запускается на каждой машине кластера CoreOS и обеспечивает общий доступ практически ко всем данным в масштабе всего кластера. Внутри etcd хранятся настройки служб, их текущие состояние, конфигурация самого кластера и т.д. Etcd позволяет хранить данные иерархически (хранилище древовидно), подписываться на изменения ключей или целых директорий, задавать для ключей и директорий ключей значения TTL (фактически, «экспирить» их), атомарно изменять или удалять ключи, упорядоченно хранить их (что позволяет реализовывать своеобразные очереди). Поскольку конфигурация сервисов, запущенных в масштабе кластера, хранится в etcd, узнать о запуске и остановке того или иного сервиса можно просто подписавшись на изменения соответствующих ключей в хранилище.

Etcd поддерживает REST HTTP интерфейс, поэтому для работы с ним достаточно curl. Из командной строки в CoreOS управляется с помощью утилиты etcdctl.

Fleet

Fleet — это «надстройка» над systemd, которая переносит управление службами с локальной машины на уровень кластера. Fleet хранит конфигурацию служб в виде юнитов systemd (в etcd), автоматически доставляет ее на локальные машины, запускает, перезапускает (при необходимости), останавливает службы на машинах кластера. Fleet умеет планировать запуск служб исходя из загруженности конкретных машин кластера. Ему можно сказать, что конкретную службу нужно запускать только на определенных машинах и т.д.

CoreOS — это очень просто

Для того, чтобы запустить службу hello в кластере CoreOS, нужно всего-навсего сделать следующее:

1. Зайти на любой из серверов кластера по SSH (они все равноправны)
2. Создать текстовый файл с описанием службы. Например, hello.service:

[Unit] Description=My Service After=docker.service [Service] TimeoutStartSec=0 ExecStartPre=-/usr/bin/docker kill hello ExecStartPre=-/usr/bin/docker rm hello ExecStartPre=/usr/bin/docker pull busybox ExecStart=/usr/bin/docker run --name hello busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done" ExecStop=/usr/bin/docker stop hello

3. Выполнить следующие команды:

fleetctl submit hello.service fleetctl load hello.service fleetctl start hello.service

4. Все! Получив последнюю команду, fleet, поскольку мы не дали ему никаких инструкций на этот счет, опеределит наименее загруженную машину кластера, возьмет наш юнит-файл, передаст его на выбранную машину, поместит туда, где systemd хранит свои службы и попросит systemd его запустить. А после запуска будет мониторить состояние. Если машина, на которой исполнялась служба, неожиданно «упадет», fleet перезапустит нашу службу на другой машине.

Рассмотрим наш пример поподробнее.

Файл конфигурации службы:

[Unit] # Текстовое описание службы Description=My Service # Служба запускается только после старта службы docker.service After=docker.service [Service] # Ждать старта службы бесконечное количество времени # Полезно в том случае, если docker не обнаружит образа локально и начнет его скачивать TimeoutStartSec=0 # Перед запуском службы последовательно выполнить указанные команды. # Минус перед именем файла указывает на то, что код возврата команды можно проигнорировать. ExecStartPre=-/usr/bin/docker kill hello ExecStartPre=-/usr/bin/docker rm hello # А тут код возврата игнорировать не нужно и если docker вернет ненулевой результат # fleet поймет, что службу запустить не удалось и сообщит об этом ExecStartPre=/usr/bin/docker pull busybox # Это команда запуска службы. Мы просто выполняем бесконечный цикл Bash. ExecStart=/usr/bin/docker run --name hello busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done" # Это команда остановки службы ExecStop=/usr/bin/docker stop hello

Команды, которые необходимо выполнить:

# Читаем файл конфигурации службы с диска и помещаем его в хранилище для дальнейшей работы fleetctl submit hello.service # Определяем, на какой машине запустить службу и помещаем файл конфигурации в хранилище локального systemd на этой машине fleetctl load hello.service # Запускаем службу fleetctl start hello.service

Посмотреть состояние служб можно командой fleetctl list-unit-files (короткая сводка по всем службам) либо fleetctl status hello.service (подробная информация о службе).

Установка CoreOS

CoreOS можно установить различными способами. Но если вы решили поэкспериментировать, рекомендую установку через Vagrant.

1. Установите Git, VirtualBox, затем Vagrant последних версий.
1а. Либо выполните в какой-нибудь папке git clone github.com/coreos/coreos-vagrant.git && cd coreos-vagrant
1б. Либо, если Git вам скачивать не захотелось, распакуйте куда-нибудь вот это.

2. Зайдите в папку, переименуйте там файл user-data.sample в user-data, config.rb.sample в config.rb. Зайдите на discovery.etcd.io/new, скопируйте в буфер появившийся URL, раскомментируйте строчку с инструкцией discovery в user-data и замените там URL.

3. Зайдите в папку и выполните там vagrant up
4. Дождитесь скачивания базового образа.
5. Выполните vagrant ssh.

Ограничения, слабые стороны и неожиданности CoreOS

CoreOS не обеспечивает ничего, кроме того, что обеспечивает 🙂 Иными словами, «из коробки», она не умеет ничего, кроме того, что мы обсудили. И, если вы собираетесь строить кластеры на базе CoreOS, вы столкнетесь как минимум со следующими проблемами:

Пакетный менеджер и обновления

В CoreOS отсутствует пакетный менеджер. И какая-либо система сборки или установки дополнительного ПО тоже (если не считать wget и curl 🙂 ). В качестве альтернативы могу предложить использовать интегрированный toolbox контейнер Docker. Для его активации просто выполните /usr/bin/toolbox из командной строки. Будет запущен привилегированный контейнер с Fedora, где есть доступ к yum.

Обновления CoreOS выполняются для ОС целиком с помощью системы активных/пассивных разделов. Фактически, системных разделов в CoreOS два. Активен в каждый момент только один из них. Обновление всей ОС устанавливается на второй, после чего выполняется перезагрузка и смена активного раздела. Операционная система обновляется только целиком. Соответственно, достаточно легко можно выполнить откат к предыдущей версии ОС. Если вы, как и я ;), уже захотели заиметь пакетный менеджер в CoreOS из коробки, прочтите Developer Documentation.

Обнаружение служб

«Фишка» CoreOS в том, что она легко переносит службы между машинами кластера, самостоятельно останавливая и запуская их. Грубо говоря, это значит, что ваш веб-сервер, изначально запущенный на машине X, через пять минут может легко оказаться на машине Y, у которой совсем другой IP адрес во внутренней сети. Конечно, с помощью специальных инструкций для Fleet вы можете легко «приковать» сервис к конкретной машине, но… тогда зачем вам вообще CoreOS? 🙂 Это создает проблему разрешения IP адресов для ваших служб. В принципе, достаточно легко запросить etcd и узнать, на какой машине сейчас выполняется служба. Но совсем автоматически этого не произойдет. Service Discovery вопрос достаточно серьезный и для его решения предлагается огромное количество ПО, из которого мне наиболее импонирует SkyDNS. Использовать SkyDNS можно с помощью sidekick-юнитов.

Персистентность контейнеров и данные как таковые

Если вы заметили, CoreOS фактически строится вокруг stateless docker-контейнеров, которые легко перенести на другую машину и там запустить. Действительно, довольно-таки легко контейнеризировать скажем, nginx и php-fpm. Файлы конфигурации для них тоже можно распространять в виде контейнера. Даже исходный код вашего приложения можно распространять в виде data-volume (это docker-контейнер, который содержит только данные) и подключать к различным службам. А что прикажете делать с базами данных?

Выходов несколько. Во-первых, сервисы вроде Flocker, которые мигрируют контейнеры с данными вслед за контейнерами со службами, которые эти данные используют. Во-вторых, запускать СУБД-подобные сервисы в режиме кластера. NoSQL решения умеют это очень хорошо, реляционные — заметно хуже, но все равно это возможно. В-третьих, можно поднять в рамках кластера любую распределенную файловую систему вроде GlusterFS или Ceph. Однако, подобное решение нужно оценить в точки зрения быстродействия. Эти вопросы обсуждались здесь.

Заключение

CoreOS сейчас переживает, не побоюсь этих слов, взрывной рост. Как и Docker, в общем-то. Количество различных проектов для CoreOS увеличивается с каждым днем. Так что, если сейчас вам чего-то не хватает для решения конкретной задачи, завтра эта возможность уже может появиться.

В рамках проекта CoreOS сейчас развивается альтернативный стандарт контейнеризациии Rocket. Однако… пока, видимо, лучше использовать Docker. Тем более, что CoreOS не собирается в будущем отказываться от Docker.

Что почитать?

Разумеется, можно почитать документацию. Однако мне больше всего понравился цикл статей на Digital Ocean о CoreOS. Собственно говоря, на его основе и под его влиянием и была написана данная статья 🙂

Fedora CoreOS. Мы Федоре не враги (Алексей Костарев, OSSDEVCONF-2021)

Алексей Костарев.jpg

В докладе будут рассмотрены история возникновения и ключевые особенности дистрибутива «Fedora CoreOS» компании RedHat и его аналогов. Возможность реализации основных идей дистрибутива в рамках операционной системы ALT Linux.

Видео

Презентация

Thesis

Как правило, в различных средах разворачиваются различные Linux-дистрибутивы с различными версиями операционных систем, системных библиотек и т. п.. В рамках каждой версии на различных узлах устанавливается различное программное обеспечение (ПО). Если число узлов в кластере относительно невелико (несколько узлов) администрирование операционных систем (установка обновлений, закрытие уязвимостей, …) на узлах является небольшой проблемой. Если же число узлов исчисляется десятками и сотнями, грамотное администрирование разнородных операционных систем с различных установленным ПО становится невозможным.

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

Исключения участие оператора при разворачивании операционной системы. Для каждого узла в файле конфигурации задаются параметры развёртывания (разбиение дисковой подсистемы, конфигурирование сетевых интерфейсов и DNS, настройка сервисов и контейнеров, …). Установка операционной системы на различные вышеперечисленные платформы производится без участия оператора.
Автоматическое обновления ядра и операционной системы из одного центра без участия оператора с возможностью приостановить автоматическое обновление и откатить на предыдущую ветку.

Использование OSTree (git для бинарных файлов) позволяет:

откатывать состояние системы на предыдущие коммиты (точки фиксации)

разделить файловую систему на неизменяемую (/usr/), изменяемую (/var/) и обновляемую (/etc) части. Что позволяет:

упростить обновление бинарного программного кода системы;
исключить случайное удаление программного кода;

Потоки разработки Fedora CoreOS

Релизы Fedora CoreOS выпускаются в трёх параллельных потоках:

next — реализация экперементального функционала. После стабилизации выпускаются мажоные версии дистрибутива.
testing — стабилизация RPM-пакетов. После стабилизации переводится в поток stable;
stable — самый надёжный поток из перечисленных (публикация каждый 2 недели).

Пользователи могут подключаться к любому из этих потоков и принимать участие в тестировании ближайщего или эксперементального функционала или использовать поток stable для повседневной работы.

Fedora CoreOS vs Fedora IoT

Наряду с дистрибутивом Fedora CoreOS компания RedHat продвигает близкое по концепции решение для Интернета Вещей: Fedora IoT.

Использование ostree, rpm-ostree для поддержания неизменяемой операционной системы с атомарными изменениями.
Использование igniion для автоматического разворачивания на множество аппаратных устройств.
Пользовательские приложения разворачиваются в контейнерной среде.
Поддержка TPM2, SecureBoot и автоматического расшифровки данных с устройств хранения с помощью Clevis.

поддержка различных аппаратных платформ: x86_64, aarch64, armhfp.
упор на поддержку интернет-устройств и драйвером к ним;
меньший объём дискового прострнства ~1.5GB
контейнеризация осуществляется через podman, поддержка клиент-серверной модели moby engine (docker) отсутствует;
веб-служба Zezere с помощью которого администраторы могут развёртывать и настраивать Fedora IoT масштабируемым образом без физической консоли.

Альт CoreOS

В настоящее время на основе репозитория Sisyphus «Базальт СПО» выпускает следующиую линейку дистриутивов: Альт Рабочая станция, Альт Сервер, Альт Сервер Виртуализации, Альт Образование, Simply Linux.

Использую технологии и программный код Fedore Core можно обеспечить выпуск и поддержку линейки дистрибутивов Альт CoreOS и, возможно, Альт IoT.

В настоящий момент в Sisyphus портированы большинство пакетов Fedora CoreOS:

ostree	Система обновления версий операционных систем на базе Linux	портирована
ignition	Утилита для управления дисками во время начальной установки системы	портирована
dracut	Инструментарий создания файловой системы начальной загрузки initramfs	портирован	В рамках ALTLinux используется собственный технологический процесс создания initrams
butane	Утилита конвертации файлов описания конфигурации из формата YAML в формат JSON Ignition	-	Достаточно простая утилита
coreos-installer	Программа установки CoreOs	-	Возможно создание собственной программы
rpm-ostree	Аналог программы apt-get установки RPM-пакетов в файловую систему ostree	-	Возможно потребуется не весь функционал

Для создания и продвижения дистрибутива Альт CoreOS необходимо:

портирование недостающих пакетов или создание собственных аналогов;
создание или использование существующего ПО для развёртывания дистрибутива в облачных средах, включая Yandex Cloud;
организация процедура создания образов дистрибутива и «выкатки» его на сервера.

Таким образом создание и поддержка в рамках репозитория Sisyphus линейки дистрибутивов Альт CoreOS, Альт IoT вполне решаемая задача.

Примечания и ссылки

Discuss on VK
Discuss on Facebook

Сайт Fedora CoreOS Documentation: https://docs.fedoraproject.org/en-US/fedora-coreos/
Сайт Ostee Documentation: https://ostreedev.github.io/ostree/
Презентация Fedora CoreOS Introduction — Dusty Mabe (Red Hat): https://www.youtube.com/watch?v=JepNm7R0LSo
Российский разработчик операционных систем «Альт»: https://www.basealt.ru/
Репозиторий Sisyphus: http://www.sisyphus.ru/

«0x1.tv»
Алексей Костарев
OSSDEVCONF-2021
Fedora CoreOS