После двух лет разработки увидела свет (http://rancher.com/press-release-rancheros-ga/) операционная система RancherOS 1.0 (http://rancher.com/rancher-os/), предоставляющая средства для изолированного выполнения приложений. RancherOS 1.0 преподносится как первый стабильный выпуск, готовый к широкому внедрению. Проект основан (http://rancher.com/about/) несколькими известными разработчиками из компании Citrix и бывшими руководителями Cloud.com. Код системы написан на языке Go и распространяется (https://github.com/rancherio/os) под лицензией Apache.Размер загрузочного образа (https://github.com/rancherio/os/releases/) RancherOS составляет всего 54 Мб. Кроме установки на отдельный сервер, система также может быть развёрнута в окружении облачных платформ и систем виртуализации Amazon EC2, Digital Ocean, Docker Machine, GCE, KVM, OpenStack, Packet, Vagrant, VMware и VirtualBox.
RancherOS предоставляет минимальную обвязку для запуска изолированных контейнеров и по решаемым задачам напоминает проекты Atomic (https://www.opennet.me/opennews/art.shtml?num=39583) и CoreOS (https://www.opennet.me/opennews/art.shtml?num=40275), отличаясь от них отказом от системного менеджера systemd в пользу собственной системы инициализации, построенной непосредственно на базе инструментария Docker. Запуск сервисов в RancherOS осуществляется (https://docs.rancher.com/os/quick-start-guide/) через запуск готовых контейнеров с использованием compose-файлов (docker-compose.yml).
ОС RancherOS реализована (http://docs.rancher.com/os/) в виде набора контейнеров, которыми управляет системное окружение на базе ядра Linux, образа начальной загрузки (initrd) и минимального инструментария, необходимого для запуска контейнеров на базе системы Docker. Всё остальное, включая udev, dhcp, ntp, cloud-init и rsyslog, запускается внутри отдельных системных контейнеров. Над контейнерами функционирует только процесс Docker, выполняемый с PID 1. Пользовательский инструментарий и демон dockerd для запуска пользовательских контейнеров также выполняется в отдельном контейнере User Docker.
Имеется также специальный системный контейнер Сonsole, предоставляющий пользовательское окружения для управления RancherOS в консольном режиме. По умолчанию консольное окружение доступно по ssh и сформировано с использованием инструментария Busybox, но при желании в качестве консоли можно подключить полноценные программные окружения на основе Ubuntu, CentOS или Fedora. Для настройки также можно использовать web-интерфейс Rancher.io (https://github.com/rancherio/rancher).Обновление производится атомарно на уровне обновления целых контейнеров. В форме образов docker также обновляются ядро и образ начальной загрузки (initrd). Между перезапусками сохраняется только содержимое разделов /opt и /home, всё остальное возвращается в исходное состояние. Конфигурация окружения передаётся во время загрузки через механизм cloud-init или определяется командой "rancherctl config" и затем сохраняется в специальный файл конфигурации.
URL: http://rancher.com/press-release-rancheros-ga/
Новость: http://www.opennet.me/opennews/art.shtml?num=46370
Эта дурная мода на "кружочки" теперь и в презентации переползла, тьфу. Понятное дело, что в могильном интерфейсе круглые кнопки ближе к форме пальцев, но на десктопах выглядит неуместно.
да ладно, по большому счёту покер в какой формы кнопари мышом тыкать... кстати, сейчас большинство ноутов идут с тач экранами, тоже, по сути, почти могильный интерфейс :)
Проще попасть в кнопку большей площади. Площадь прямоугольника больше, чем площадь круга.
Хотя к картинкам в презенташке это никакого отношения не имеет.
только область касания все равно имеет форму круга
Интересно, это мода (помешательство, одержимость) докеризировать всё, что (шевелится :)) докеризируется или в этом есть реальный смысл и необходимость? В каких проектах такое может понадобится, что аж даже "Всё остальное, включая udev, dhcp, ntp, cloud-init и rsyslog, запускается внутри отдельных системных контейнеров" ?
IMHO, баловство всё это и оправдано только если а контейнере нет доступа с правами root. Если в контейнере есть возможность выполнить код под root, то создаётся лишь видимость защиты. Особенно радует user namespace для которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере подняться до полноценного root на стороне хост-системы.
> Особенно радует user namespace для которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере подняться до полноценного root на стороне хост-системы.так нашли же и пофиксили
или нашлись какие-то концептуальные архитектурные уязвимости ?
Проблема не в концептуальных архитектурных уязвимостях, проблема в том, что весь ядерный код писался без оглядки на эти самые user namespaces. Поэтому, пока коды нормально не перечитают, подобные уязвимости продолжат появляться довольно часто. Т.е. еще несколько лет -- точно.
> IMHO, баловство всё это и оправдано только если а контейнере нет доступа
> с правами root. Если в контейнере есть возможность выполнить код под
> root, то создаётся лишь видимость защиты. Особенно радует user namespace для
> которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере
> подняться до полноценного root на стороне хост-системы.Так ограничьте права. И не запускайте что не попадя от root
>> IMHO, баловство всё это и оправдано только если а контейнере нет доступа
>> с правами root. Если в контейнере есть возможность выполнить код под
>> root, то создаётся лишь видимость защиты. Особенно радует user namespace для
>> которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере
>> подняться до полноценного root на стороне хост-системы.
> Так ограничьте права. И не запускайте что не попадя от rootконтейнер к вам может попасть через жирный_пакет какой нить "как есть", с настройками контейнерного рута внутри
Смысл в том, что контейнер в котором разработано приложение и запускается пользователем.Вместе с приложением максимально переносится окружение.
Это позволяет избежать части багов появляющихся из-за разности в конфигурациях dev и prod.
Главный фактор - это лень.
> Главный фактор - это лень.Лень чинить баги - правильный фактов. Заставляет заранее снижать их количество ;)
Минорный плюс - контейнеры stateless. Для серверных приложений это позволяет динамически расширять и сжимать боевой кластер прямо на ходу.
Шо опять?
Нет..
Снова
> отличаясь от них отказом от системного менеджера systemd в пользу собственной системы инициализацииheretics!
>> отличаясь от них отказом от системного менеджера systemd в пользу собственной системы инициализации
> heretics!killing it by fire!!!!
Когда уже сделают экзоядро уже?
Это опять процессоры слишком мощные и памяти завались?
Т.е. сейчас все будет даже ls в контейнерахзапускаться? Модно типа?
А потом сделают контейнер на уровне CPU
> Это опять процессоры слишком мощные и памяти завались?Процессоры и память не причём, это к виртуализации.
Основной смысл современных систем управления о оркестровки - разорвать зависимость от локального хоста и запускать приложение на кластере, так же просто, как сейчас запускаем приложение на процессоре с несколькими ядрами.
http://web.eecs.umich.edu/~mosharaf/Readings/DC-Computer.pdf
https://youtu.be/CESGogWbjeIОС и системные сервисы, это просто среда и транспорт: https://youtu.be/HhNIttd87xs
Полезную работу делают приложения.ls как таковой не нужен в качестве приложения и смысла его в контейнере запускать нет.
Другое дело, что ls работает с файловой системой и если у нас в кластере несколько распределённых файловых систем, то может быть удобно просматривать списки файлов в каталогах запуская команду ls в контейнере, который запущен в группе с настроенной файловой системой. Запускаться этот ls может как внутри существующего контейнера, так и в отдельном (это задача обслуживания, а не реальной работы приложения, поэтому не так важно где).
> А потом сделают контейнер на уровне CPU
http://www.lowrisc.org/downloads/lowRISC-memo-2014-001.pdf
Есть наработки с тегированной памятью, но это ближе к системам типа selinux.Уроверь CPU как раз слишком низкий, нужен уровень нескольких вычислительных узлов. Времена, когда в стойку влезает несколько тысяч ядер/компьютеров уже наступили и одним локалхостом не обойтись.
Лучше бы микроядра пилили.
> Лучше бы микроядра пилили.нужно и то и сабж (и не факт что нужно вместе, но кому как)