Представлено (http://coreos.com/blog/new-filesystem-btrfs-cloud-config/) значительное обновление проекта CoreOS (http://coreos.com/), в рамках которого развивается не похожее на традиционные Linux-дистрибутивы серверное окружении, напоминающее по сути ChromeOS, но нацеленное на массовое развёртывание серверных систем. Отмечается, что опубликованная сборка является первым релизом на пути к полной стабилизации кодовой базы и обеспечения готовности для промышленного использования. Готовые базовые образы CoreOS подготовлены (http://storage.core-os.net/coreos/amd64-generic/268.1.0/) для запуска c использованием PXE-загрузки, Amazon EC2, Google Compute Engine, OpenStack, VirtualBox, VMware, Vagrant и QEMU/KVM. Наработки проекта распространяются (https://github.com/coreos/) под лицензией Apache 2.0.
Система содержит только минимальный набор компонентов, достаточный для выполнения изолированных контейнеров (cgroups+namespaces), которые в свою очередь содержат произвольную начинку для запуска необходимых серверных приложений. По сути, в состав базовой системы входит только ядро Linux, системный менеджер systemd и ряд служебных сервисов для управления конфигурацией и установки обновлений. Системный раздел монтируется в режиме только для чтения и не изменяется в процессе работы.
Для установки обновлений используется подход ChromeOS, при котором одновременно создаётся два дисковых раздела. Один из разделов является активным, а второй используется для копирования обновления, после установки которого активным становится второй раздел, а первый остаётся для установки следующего обновления и предоставляет возможность быстрого отката изменений. Таким образом, при каждом обновлении разделы меняются местами. Обновления могут устанавливаться автоматически, по аналогии с ChromeOS. По задумке разработчиков, обновление серверов на базе CoreOS должно производиться также просто, как в настоящее время осуществляется обновление браузеров.Вместо традиционных пакетных менеджеров предлагается использовать преднастроенные изолированные контейнеры, содержащие все необходимые компоненты для выполнения того или иного серверного приложения. Упаковка приложений в произвольные обособленные контейнеры позволяет не задумываться об особенностях базовой ОС и свободно переносить контейнеры от одной ОС к другой и с сервера на сервер. В качестве системы управления контейнерами поддерживается
Docker (https://www.opennet.ru/opennews/art.shtml?num=36532), предоставляющий средства для автоматизации создания изолированных окружений для запуска произвольных процессов и возможности по переносу и клонированию окружений на другие серверы. При этом Docker не является обязательным, присутствует возможность создания контейнеров вручную или использования уже готовых образов, пригодных для использования с инструментарием LXC.
Другой особенностью CoreOS являются средства автоматического определения доступных сервисов, использования единой конфигурации для группы серверов и объединения набора серверов во взаимосвязанные кластерные системы. Для обмена и управления конфигурацией используется система etcd (https://github.com/coreos/etcd), развиваемая специально для CoreOS. Код etcd написан на языке Go и поставляется под лицензией Apache. Etcd представляет собой высоконадёжное хранилище параметров конфигурации в форме ключ/значение. Для доступа к конфигурации предоставляется простой интерфейс, основанный на использовании HTTP и JSON (запросы могу отправляться при помощи утилиты curl или специальной утилиты etcdctl). Аутентификация выполняется на основе SSL-ключей. Хранилище конфигурации и логи реплицируются на все узлы и поддерживается в синхронизированном состоянии с использованием протокола Raft (https://github.com/goraft/raft).
Новый выпуск примечателен переходом к новой раскладке файловой системы, в которой раздел /etc допускает запись, а /usr примонтирован отдельно в режиме только для чтения. Если ранее весь корень монтировался в режиме только для чтения, то теперь отдельно монтируется раздел /etc, а вся специфичная для системы функциональность, подлежащая обновлению вынесена в раздел /usr, который монтируется отдельно и используется для цикличного обновления системы.
Реализация Docker обновлена до выпуска 0.9 (https://www.opennet.ru/opennews/art.shtml?num=39282), в том числе с возможностью использования файловой системы Btrfs. В частности, Btrfs теперь используется для корневой ФС и статических разделов. Для настройки сетевых параметров задействована новая подсистема systemd-networkd (https://www.opennet.ru/opennews/art.shtml?num=38358).
На этапе инициализации задействована система CloudInit (https://github.com/coreos/coreos-cloudinit/), позволяющая задавать конфигурацию окружения на этапе загрузки в отдельном файле cloud-config.yml. В том числе, через заданные в cloud-config.yml параметры можно создавать пользователей, добавлять ssh-ключи, записывать юниты systemd и контролировать их запуск, создавать произвольные файлы в ФС, передавать параметры сети. Таким образом общий загрузочный образ может быть унифицирован и не привязан к конкретным конфигурациям.URL: http://coreos.com/blog/new-filesystem-btrfs-cloud-config/
Новость: https://www.opennet.ru/opennews/art.shtml?num=39432
На базе Linux но на него не похоже, написано информативно. А главное отражает суть проекта
Что, используемое в CoreOS ядро не похоже на Linux?
> Что, используемое в CoreOS ядро не похоже на Linux?Ядро то как раз Linux, отличие только в другой иерархии каталогов, что в принципе не значит ничего фундаментально нового, разве что "удобства" будет больше. Это конечно не все идеи проекта, но это все равно тот же Linux. Иными словами все что они хотят сделать при желании и прямых руках можно сделать на любом дистрибутиве Linux.
Судя по тому, что написано в новости, иерархия каталогов больше похожа на UNIX, чем на Linux.
на базе линукс, и без архаики юникс
Без архаики - не труЪ.
ТруЪ - это когда обязательно наличие systemd :)
> ТруЪ - это когда обязательно наличие systemd :)Нет, это называется "хипстерофобия".
Тогда уж хипстерофилия
> Тогда уж хипстерофилияСпорный вопрос, хуже ли это чем некрофилия.
Можно ведь посмотреть на этот вопрос и под таким углом: хороший хипстер - ну, вы поняли.
Plan9 что ль?
> Plan9 что ль?Избавляться от архаики можно разными путями. В Plan9 это путь радикальных изменений, в CoreOS изменения не так масштабны и направлены на решение практических задач.
> Для обмена и управления конфигурацией используется система etcd, развиваемая специально для CoreOS. Код etcd написан на языке Go и поставляется под лицензией Apache. Etcd представляет собой высоконадёжное хранилище параметров конфигурации в форме ключ/значение. Для доступа к конфигурации предоставляется простой интерфейс, основанный на использовании HTTP и JSON (запросы могу отправляться при помощи утилиты curl или специальной утилиты etcdctl). Аутентификация выполняется на основе SSL-ключей. Хранилище конфигурации и логи реплицируются на все узлы и поддерживается в синхронизированном состоянии с использованием протокола Raft.А вот и бинарный реестр, о котором так долго говорили большевики. Со встроенным HTTP-сервером и репликацией.
Выглядит вкусно, кстати.
Ну и зачем оно нужно?
Админу локалхоста оно нафиг не сдалось, да.А вот разворачивать массовые хостинги SaaS/PaaS - самое то.
Теоретик локалхоста?
Если нет то приведи пример кто использует подобные решения.
> Теоретик локалхоста?
> Если нет то приведи пример кто использует подобные решения.Почти любой SaaS-хостинг, например.
>> Теоретик локалхоста?
>> Если нет то приведи пример кто использует подобные решения.
> Почти любой SaaS-хостинг, например.Список огласишь? Или так и будешь тыкать пальчиком в марсиан?
zookeeper - система, решающая те же задачи, что и etcd (+ другие задачи). используется в yahoo, rackspace, ebay.
Вот здесь основные моменты разъясняются, четко и по полочкам:
http://tech.yandex.ru/events/yagosti/devops/talks/1600/
Я о том почему не сделать решение которое можно развернуть без проблем на стандартном дистрибутиве линукса.
> Я о том почему не сделать решение которое можно развернуть без проблем
> на стандартном дистрибутиве линукса.Потому что оно будет ограничено архитектурой "стандартного линукса".
Впрочем, и Марк, и редхат тоже пристально присматриваются к идее "каждому приложению - свой контейнер". Так что, возможно, CoreOS - первый прототип будущего стандарта дистрибутивов Linux.
Какие конкретно ограничения большынства дистрибутивов линукса мешают или усложняют реализацию легковесных контейнеров. Тотже Docker вполне приличный пример в противовес CoreOS.
Авторам кто-нибудь говорил, что задачи и условия эксплуатации серверов несколько отличаются от задач десктопов? Или в их понимании эта разница как в винде состоит в приоритете между программами и службами?
Тaщемта, сабж как раз и спроектирован строго под серверные задачи. Десктопами там и не пахнет.
> Тaщемта, сабж как раз и спроектирован строго под серверные задачи.Правда, админы множества хостинговых компаний, известных под названием localhost inc, полета инженерной мысли не оценят - для их задач оно совершенно избыточно.
> Правда, админы множества хостинговых компаний, известных под названием localhost inc,
> полета инженерной мысли не оценят - для их задач оно совершенно
> избыточно.На сколько понимаю, должны как раз оценить именно они, не?
> На сколько понимаю, должны как раз оценить именно они, не?Мне кажется, "хостинги на десктопе юзера Васи" ничего не решают на рынке хостинга.
Даже тестовое внедрение обычно проводят на выделенных стендах, на задачах, аналогичных боевым.
SmartOS, IllumOS выглядит лучше в плане утилизации ресурсов, памяти, дискового пространства.
Веб морда http://blog.smartcore.net.au/fifo-smartos-gui-web-management.../
> SmartOS, IllumOS выглядит лучше в плане утилизации ресурсов, памяти, дискового пространства.https://project-fifo.net/download/attachments/1507405/vm.png
https://project-fifo.net/download/attachments/1507405/image2...
https://project-fifo.net/download/attachments/1507405/main.png
https://project-fifo.net/download/attachments/1507405/machin...
Бесполезно. В мэйнстрим пойдет CoreOS всё равно. Посмотрите кто основатели CoreOS и сколько там уже венчурных инвесторов сбежалось. И Greg K-H сбоку улыбается.
> Бесполезно. В мэйнстрим пойдет CoreOS всё равно. Посмотрите кто основатели CoreOS и
> сколько там уже венчурных инвесторов сбежалось. И Greg K-H сбоку улыбается.Естественно. Люди выбирают живой и актуальный Linux, а не полудохлый опенсолярис с микроскопическим сообществом.
То, о чем вы пытаетесь троллить, в данном случае вообще неважно. И, кстати, это не особенно Линукс, а скорее уж серверный Андроид.Дело в том что правильные связи всегда били, бьют и будут бить преимущества в технологиях. И не только в случае тендеров на пост-советском пространстве. Вы что думаете, у CoreOS на сайте просто так написано про "online civil liberty activists", потому что место было нечем занять?
> То, о чем вы пытаетесь троллить, в данном случае вообще неважно. И,
> кстати, это не особенно Линукс, а скорее уж серверный Андроид.
> Дело в том что правильные связи всегда били, бьют и будут бить
> преимущества в технологиях. И не только в случае тендеров на пост-советском
> пространстве. Вы что думаете, у CoreOS на сайте просто так написано
> про "online civil liberty activists", потому что место было нечем занять?Думаю, именно поэтому. Звонкая трескотня ни о чем.
Ну вот зря.
> Естественно. Люди выбирают живой и актуальный Linux, а не полудохлый опенсолярис с
> микроскопическим сообществом.Люди выбирают, чаще всего то, что проще и дешевле. Ну это вроде как разумно. Линукс-среда сейчас довольно трудоёмка в плане развёртывания всякой рутины. Ну там, кластер забабахать, сервер приложений поставить, балансировщик, выдачу сертификатов прикрутить... Богатство вариантов сшибает с толку. Это как времена Ant-а сменили времена Maven-а. Конфигурирование вместо разработки велосипедов.
> SmartOS, IllumOS выглядит лучше в плане утилизации ресурсов, памяти, дискового пространства."Я поставил себе А и что-то там потыкал, а про Б только слышал" != "А выглядит лучше, чем Б, в плане утилизации ресурсов, памяти, дискового пространства".
> SmartOS, IllumOS выглядит лучше в плане утилизации ресурсов, памяти, дискового пространства.Ресурсы на стадии прототипа не важны. Важно, что не нужно держать в команде инженера по инфре на стадии разработки. Хотя сомнительная экономия, если чё.
у мозилы - лучше аналог.
впрочем все чаще вижу и в конфиге и в коде мозиллы - отсылки в компонентам хрома.
походу и файрфокса с креведкой - ждет миграция на вебкит. увы и ах.
> у мозилы - лучше аналог.
> впрочем все чаще вижу и в конфиге и в коде мозиллы -
> отсылки в компонентам хрома.
> походу и файрфокса с креведкой - ждет миграция на вебкит. увы и
> ах.Вы вот сейчас опу с пальцем сравнили.
Видимо, перепутали с хромоосью.
> Код etcd написан на языке Go и поставляется под лицензией Apache. Etcd представляет собой высоконадёжное хранилище параметров конфигурации в форме ключ/значение.На Си ниасилили, системд-то - весьма сомнительная поделка, тем не менее принятая многими дистрибутивами, призваная заменить медленные скрипты, а тут опять вкорячивание какой-то хрени лишь бы работало, чтобы потом не знать как ее оттуда выпилить. Xерней бы не маялись, а написали нормальную nosql бд, на нормальном языке, на том, что и вся система.
>> Код etcd написан на языке Go и поставляется под лицензией Apache. Etcd представляет собой высоконадёжное хранилище параметров конфигурации в форме ключ/значение.
> На Си ниасилили, системд-то - весьма сомнительная поделка, тем не менее принятая
> многими дистрибутивами, призваная заменить медленные скрипты, а тут опять вкорячивание
> какой-то хрени лишь бы работало, чтобы потом не знать как ее
> оттуда выпилить. Xерней бы не маялись, а написали нормальную nosql бд,
> на нормальном языке, на том, что и вся система.прочитайте про etcd и systemd, поймите, что это разные инструменты, удалите свой коммент. А лучше возвращайтесь обратно в подъезд к пиву и семкам
> прочитайте про etcd и systemd, поймите, что это разные инструменты,Я сравнил лишь, то, на чем они написаны. Т. к. нет смысла писать часть скриптов на питоне, часть на го, часть еще хер его знает на чем, и системд, пример, эпического выпиливания одного и впиливания другого.
> удалите свой коммент. А лучше возвращайтесь обратно в подъезд к пиву и семкам
Да походу придется, с такими собеседниками на опеннете. соседский кот всегда молчит = чуши не несет.
си-пуризм отдаёт гомосятиной ;) Понимает, единообразие ради его самого не лучший архитектурный стимул.
> си-пуризм отдаёт гомосятиной ;) Понимает, единообразие ради его самого не лучший архитектурный
> стимул.А уже есть что-то лучше? комиляторов си миллион, на любой вкус, под любую архитектуру, даже 8-битные чипы прошиваются скомиленным си-кодом. Я очень давно жду появления чего-то стольже гибкого и переносимого, не так давно перечитывал спеки по языку D, по Go, по Dart, по Lua, и все они какие-то однобокие, каждый заточен под задачу далее которой ни-ни. Написал пару скриптов на lua, т.к. он самый распространненый и "типа универсальный", с притензией на легкую переносимость и все такое, получилась откровенно хрень. Конечно оно работает, может у меня отсутствует опыт работы именно с этим языком, но развивать это во что-то большее я пути не вижу, т.к. на втором же этапе разработки библиотечные функции кончились, а задача отправки ICMP пакета решается через разбор результата вызова внешней команды ping, а в чем тогда профит, можно ведь и на shell'е сразу в 15 строк реализовать всю логику, в документации есть отсылка к некой библиотеке для работы с сокетами, но примеров там нет, и сокеты онли-бсд-стайл, и зачем херачить 500 строк кода на lua, когда можно в 150 уложиться для своей либы на си, которая будет делать то, что нужно и как нужно, а какой тогда, опять же, смысл.
JS надежды подавал, но мозила с ее "собственным" взглядом на разработку, сотворила хрен знает что, с миллионом непонятных библиотек в зависимостях, исходники которых хрен знает где брать, версии которых хрен знает как идут, не совсем понятно как это собирать, и совсем не понятно кто за что отвечает, поскольку все идет с готовыми make-файлами и если путь к заголовочному файлу не верен, то получи 5000 строк ошибок.
Согласен полностью. Но, увы, жизнь пока диктует иное.
Попахивает напильником.
>> При этом Docker не является обязательныммне одному кажется, что правильнее было бы перевести так :
При этом Docker не обязателен
