CoreOS — Linux для минималистичных кластеров. Коротко
Что такое CoreOS?
CoreOS — это операционная система на базе Linux для построения легко и гибко масштабируемых кластеров. CoreOS — минималистичный дистрибутив. Установочный ISO образ объемом всего в 136Мб, а в памяти на конечной машине после установки и запуска она займет всего 114Мб. CoreOS основан на ChromeOS, который в свою очередь базируется на Gentoo.
Фактически, CoreOS можно условно можно разделить на следующие части:
CoreOS умеет запускать службы systemd на нужных машинах кластера, следить за их состоянием, хранить их конфигурацию.
Systemd
В CoreOS используется обычный systemd, который сейчас можно встретить во многих дистрибутивах Linux. Это система локального управления Linux-службами.
Docker
О Docker уже не раз писали на Хабре. Если коротко и по-простому — Docker берет ядро хостовой операционной системы Linux, монтирует к нему указанный вами образ файловой системы и позволяет работать внутри этого образа как будто вы находитесь в виртуализованном окружении.
Обратите внимание, что Docker не использует виртуализацию. Для изоляции процессов используются cgroups и namespaces, что позволяет избавиться от довольно серьезного оверхеда, который дают такие инструменты как KVM. Конечно, Docker можно использовать и на Mac и на Windows, но в этом случае хостовая операционная система должна будет работать внутри VirtualBox или любой другой системы виртуализации, поскольку Docker для работы необходимо ядро Linux (см. Boot2Docker)
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:
3. Выполнить следующие команды:
4. Все! Получив последнюю команду, fleet, поскольку мы не дали ему никаких инструкций на этот счет, опеределит наименее загруженную машину кластера, возьмет наш юнит-файл, передаст его на выбранную машину, поместит туда, где systemd хранит свои службы и попросит systemd его запустить. А после запуска будет мониторить состояние. Если машина, на которой исполнялась служба, неожиданно «упадет», fleet перезапустит нашу службу на другой машине.
Рассмотрим наш пример поподробнее.
Файл конфигурации службы:
Команды, которые необходимо выполнить:
Посмотреть состояние служб можно командой 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 продолжит развитие 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 на данный момент называются:
Fedora CoreOS предназначен для использования в production, но это не относится к текущей предварительной версии. Ожидается, что систему объявят стабильной через полгода. Её предшественник в лице Fedora Atomic Host будет поддерживаться до конца жизни Fedora 29 (т.е. по конец ноября), и всем его пользователям рекомендуется мигрировать на Fedora CoreOS.
Образы для загрузки доступны здесь, а быстрая инструкция по запуску — здесь.
Анонсирован предварительный выпуск Fedora CoreOS
Fedora CoreOS — это автоматически обновляемая минимальная операционная система для безопасного и масштабного запуска контейнеров в рабочих средах.
В настоящее время она доступна для тестирования на ограниченном наборе платформ, но скоро появятся и другие.
Очередное Федорино Горе?
Прям вот даже интересно: ежикам не надоело кактус жевать?
Эксперты подтянулись, куда же без экспертов.
CoreOS — лучший кактус для серверов.
Тестовый полигон RedHat IBM!
Я наверное старею и становлюсь тупеньким.
The initial preview release of Fedora CoreOS runs on bare metal, QEMU, VMware, and AWS, on x86_64 only. It supports provisioning via Ignition spec 3.0.0 and the Fedora CoreOS Config Transpiler, automatic updates with Zincati and rpm-ostree, and running containers with Podman and Moby. In the coming months, we’ll be adding more platforms, building out
Но работникам индустрии не надоело ли каждую пятилетку полностью менять инструменты? Вертихвостки от ИТ!
Re: Я наверное старею и становлюсь тупеньким.
А еще удивляють слоупоченьки, которые наблюдали за Intel ClearLinux очередную пятилетку, а потом бросились догонять.
Шаман подтянулся. Куда уж без шамана. Бубна только не хватает.
На сайте с твоей почтой список уязвимостей длиной с «Войну и Мир». Ну как-то так.
Рад видеть, что от rpm-ostree не отказались и не выбрали в пользу того, что там было в CoreOS. Только неясно, когда был Atomic Host, он был по составу схож с Silverblue. Будут ли теперь как-то обобщать базы Fedora CoreOS и Silverblue, или последний ушел в свободное плавание? Опасаюсь за судьбу последнего. RH/IBM он не нужен, я так понимаю он вообще был больше лишь дополнением к Atomic Host, которого теперь нет.
Теперь бы разобраться в значении и предназначении всех этих прекрасных продуктов!
Хм. Может быть, стоит обновить круглокуб. А, может, пускай так живёт.
На этом ресурсе вроде неглупые люди обитают, способные читать. Я в вас верю, тем более что инструменты более чем простые.
P.S. Сам для теста на ноут залепил SilverBlue, система как система ничего страшного в ней нет. Минимальный гном в базе, для гуя флатпаки (жаль что их мало) для разработки в кли тоолбокс.
Бизнес на авантюры с Fedora CoreOS не согласится. У админов локалхоста потребности другого рода, им Fedora CentOS тоже вряд ли понадобится.
Так на кого, кроме разработчиков шапки, рассчитан данный дистрибутив?
Я немного не понимаю юзкейса, вместо накачиавния дистрибутива, там прохода по нему ансиблом, теперь нужно будет просто пускать этот кореос с ign файлом где я опишу все задачи и какие контейнера пускать. Но как быть на примерс с композом, его нет в базе, нужно создавать свой os-tree и его сопровождать, и что будет при апдейте, оно веренется в базовое состояние или сохранит мои изменения. Как голая пускалка докера или podman вроде зачетно, но как делать что-то кастомное мне не совсем ясно.
просто пускать этот кореос с ign файлом где я опишу все задачи и какие контейнера пускать. Но как быть на примерс с композом,
Не, я уже разуверился. Каждую пятилетку радикально новый инструментарий.
Даже лень искать что к чему.
примерс с композом, его нет в базе, нужно создавать свой os-tree и его сопровождать
Нет. rpm-ostree позволяет доустанавливать отсутствующие в базе пакеты. И при обновлении они обновляться тоже будут.
И вот ещё, оно больше про десктоп, но из пакетной базы федоры можно вовсе свою базовую систему создать и поддерживать на rpm-ostree.
Запилите новость про ORA EL8
Быстрее ЦентОСм выкатились.
система как система ничего страшного в ней нет
Я знаю. Проблема, что и альтернатив ей нет.
Я все таки верю в ИБМ, и думаю они не ограничатся только серверами, и припомнят кое-кому как их заставили свернуть OS/2.
Разве их кто-то заставил?
Сами сделали, сами закопали. Те. кто сотрудничал с МС, прикупили акций МС бггггг 🙂
не забывай, что ИБМ избавляется от тех проектов, которые выходят в массовое производство.
На странице проекта новости последние за 2018 год
Ну ign по сути провижн как по мне, ключ закинуть, файлик положить, или они на серьезных щах предлагают писать на каждый контейнер системд юнит?
Ладно там один для композа, но описывать все на юнитах это же безумие, с другой стороны c podman другого и нету, но хорошо хоть докер еще оставили.
Будут ли теперь как-то обобщать базы Fedora CoreOS и Silverblue, или последний ушел в свободное плавание?
Все они собираются из тех же RPM стандартной федоры, просто набор разный
они на серьезных щах предлагают писать на каждый контейнер системд юнит?
Никто не спорит, что на этом форуме никуда без модераторов.
Прям вот даже интересно: ежикам не надоело кактус жевать?
Теперь ты делай обзоры на дистрибутивы. Желательно даже с фантазией о маркетинговой позиции каждого дистра %-)
виндузятника сразу узнаешь по неадекватным заявлениям. На федоре уже 7 лет, я уже забыл когда с ней были проблемы. В отличии от бубунты
после заявления в fedora magazine что silverblue становится все более популярной я поставил ее себе правда на 15 минут. Так и не понял в чем крутизна этой readonly системы, после каждого пакета надо делать ребут. Или кто-то ее юзает? поделитесь впечатлениями
У ёжиков с кактусом немного другие траблы 🙂
А у юзеров RH другая проблема — кроличья. Они-то думали, что их любят, а на самом деле их просто разводили.
На федоре уже 7 лет, я уже забыл когда с ней были проблемы.
я правильно прочитал «второй»? При том что текущая версия 30. Хде логика??
Крутизна в ребейзах на другие ветки и трекинге /etc, например
На федоре уже 7 лет, я уже забыл когда с ней были проблемы.
Если систему использовать для интернета, просмотра видео и прослушивания аудио, то Fedora хороша, но есть много но. Приведу лишь малую часть из последних.
Бажная Anaconda. Забыл выполнить wipefs на luks разделе, тупо через fdisk создал новую таблицу разделов. После этого решил установить Fedora. В ручном режиме нарезал диск в Anaconda на нужные разделы, применил изменения и продолжил установку. Anaconda не смогла установить систему, так как при создании заделов были найдены сигнатуры от luks и она не смогла это проигнорировать. Змейка запаниковала и умерла.
Дано: ручная разбивка диска с использованием lvm в Anaconda, новый тип шифрования luks2. Итог: Змейка умнее меня, поэтому она решила использовать luks1.
После обновления с Феди 29 на 30 имеем нерабочий borg и траблы с установкой eclipse из-за системы модулей. Несколько недель приходится использовать костыли.
Федор 29 при очередном обновлении efivar и чего-то там, которое тоже связано с efi, получил чёрный экран после инициализации матери. Решение: отключение опции в биос csm boot или legacy что-то там. Название точно не помню.
Сейчас в Evince поиск кириллицы не работает.
И так по каждому релизу Fedora можно 100500 различных багов вспомнить. Всё это простительно. Раздражает то, что в одном версии Fedora могут успеть несколько раз поломать-сделать-поломать-сделать что-то.
Спасибо за обзор. Гляну сегодня еще раз
Я вроде писал уже выше. Там 3 вида установки пакетов:
Вот к примеру чел, залепил силверблуй, в базу воткнул НВИДИА, потом с флатпака стим и давай игоря мучить 🙂 https://fedoramagazine.org/set-up-fedora-silverblue-gaming-station/
На локалхоста с одним пользователем toolbox решение хорошее, но если пользователей несколько и не все с правами администратора, то печалька.
Пользователь без прав администратора выполнил (toolbox create. ), выполнил вход (toolbox enter. ), а нужный софт устанавливать нужно через sudo dnf install, а ему таких прав не давали. Придётся пилить заранее определённый image и его подгружать?!
Тут я хз, недавно только стал юзать силверблуй на ноуте на пробу. Сам я при установке выбрал себя админом и меня поди засунули в группу вхел. Но по крайне мере в отличие от докера подману для создания и запуска контейнера не нужно права рута.
пора уже вводить тэг «скоро». половина новостей о том, что кто-то что-то скоро.
спасибо за информацию, я так понял что приемуществ практически ноль. То что система становится непробиваемой, так линукс и сейчас практически самая защищенная после bsd. Ради этого юзать такой костыль смысла нет. А то я уже хотел обратно silverblue поставить )
у мне с lvm и на убунте при установке были проблемы, потому что разрулить уже существующий lvm нетривиальная задача. При обновлении efi я раз получил проблемы, но тогда вместа граба использовал systemd-boot. В еvince небось нахимичили с зависимыми пакетами, поэтому так. Хотя уж с ней то никогда проблем небыло. Если бы у меня полетел эклипс, я бы сразу пересел на другой дистр(правда давно уже не юзаю, для жабы только idea), но и тут не могу ничего припомнить. Имхо если ставить и компилить все подряд можно не удивлятся что при апдейтах что-то полетит. Ну действительно иногда бывают неприятные сюрпризы, но чтобы 100500. Зачем тогда ее вообще установили?
Fedora при всех ее минусах по соотношению качество/новизна/количество интересных разработок значительно лучше остальных дистрибутивов.
Преимуществ особо и нет, скорее даже наоборот. Сейчас много чего нет в флатпаках и приходится ставить в базу, это конечно получается таже федора но после каждой такой установки нужно делать ребут.
С другой стороны есть как минимум 2 ветки которые достапны сразу :
И что самое главное оно как бы дисциплинирует лишний раз подумаешь нести ли в систему всякую фигню. К примеру сроду не юзал VLC так он тащил за собой всякое г. тут ухнул его во флатпаке и как бы фиг с ним 😉
Попробуй лучше сразу NixOS.
И ребутаться после установки пакета для иммутабельности и декларативности не надо, это эксклюзивная травма Silverblue.
Я хз что это такое. На шапке я с 97года, и юзание Федоры дома мне помогает быстрее мигрировать на новые выпуски RHEL на работе.
Getting Started with Fedora CoreOS
Introduction
Streams
Each stream has a canonical URL representing its current state in JSON format, known as «stream metadata». For example, the stream metadata URL for stable is: https://builds.coreos.fedoraproject.org/streams/stable.json
For automating Fedora CoreOS installations, it is expected that you will interact with stream metadata. While Fedora CoreOS does automatic in-place updates, it is generally a good practice to start provisioning new machines from the latest images.
For more information on using stream metadata, see Stream Metadata. For more about the available streams, see Update Streams.
Provisioning Philosophy
Fedora CoreOS does not have a separate install disk. Instead, every instance starts from a generic disk image which is customized on first boot via Ignition.
Each platform has specific logic to retrieve and apply the first boot configuration. For cloud deployments, Ignition gathers the configuration via user-data mechanisms. In the case of bare metal, Ignition can fetch its configuration from the disk or from a remote source.
For more information on configuration, refer to the documentation for Producing an Ignition File.
Quickstart
Booting on a cloud VM (AWS example)
New AWS instances can be directly created from the public FCOS images. You can find the latest AMI for each region from the download page.
If you are only interested in exploring FCOS without further customization, you can use a registered SSH key-pair for the default core user.
To test out FCOS this way you’ll need to run the aws ec2 run-instances command and provide some information to get the instance up and running. The following is an example command you can use:
| You can find out the instance’s assigned IP by running aws ec2 describe-instances |
You now should be able to SSH into the instance using the associated IP address.
| By design, cloud-init configuration and startup scripts are not supported on FCOS. Instead, it is recommended to encode any startup logic as systemd service units in the Ignition configuration. |
Booting on a local hypervisor (libvirt example)
Fetch the latest image suitable for the qemu platform using coreos-installer (or download and verify it from the web). You can use coreos-installer as a container, or on Fedora install it from the repos.
| virt-install requires both the OS image and Ignition file to be specified as absolute paths. |
Exploring the OS
Once the VM has finished booting, its IP addresses will appear on the serial console. By design, there are no hard-coded default credentials.
If you set up an SSH key for the default core user, you can SSH into the VM and explore the OS:
Getting in touch
We recommend that all users subscribe to the low-volume coreos-status mailing list for operational notices related to Fedora CoreOS.
Bugs can be reported to the Fedora CoreOS Tracker.
For live questions, feel free to reach out on the #fedora-coreos IRC channel on Libera.Chat.
For doubts and longer discussions related to Fedora CoreOS, a forum and a mailing list are available.
All Fedora Documentation content available under CC BY-SA 4.0 or, when specifically noted, under another accepted free and open content license.
