The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Первый стабильный выпуск RancherOS, минималистичной ОС на базе контейнерной изоляции

13.04.2017 08:47

После двух лет разработки увидела свет операционная система RancherOS 1.0, предоставляющая средства для изолированного выполнения приложений. RancherOS 1.0 преподносится как первый стабильный выпуск, готовый к широкому внедрению. Проект основан несколькими известными разработчиками из компании Citrix и бывшими руководителями Cloud.com. Код системы написан на языке Go и распространяется под лицензией Apache. Размер загрузочного образа составляет всего 54 Мб. Кроме установки на отдельный сервер, система также может быть развёрнута в окружении облачных платформ и систем виртуализации Amazon EC2, Digital Ocean, Docker Machine, GCE, KVM, OpenStack, Packet, Vagrant, VMware и VirtualBox.

RancherOS предоставляет минимальную обвязку для запуска изолированных контейнеров и по решаемым задачам напоминает проекты Atomic и CoreOS, отличаясь от них отказом от системного менеджера systemd в пользу собственной системы инициализации, построенной непосредственно на базе инструментария Docker. Запуск сервисов в RancherOS осуществляется через запуск готовых контейнеров с использованием compose-файлов (docker-compose.yml).

ОС RancherOS реализована в виде набора контейнеров, которыми управляет системное окружение на базе ядра 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.

Обновление производится атомарно на уровне замены целых контейнеров. В форме образов docker также обновляются ядро и образ начальной загрузки (initrd). Между перезапусками сохраняется только содержимое разделов /opt и /home, всё остальное возвращается в исходное состояние. Конфигурация окружения передаётся во время загрузки через механизм cloud-init или определяется командой "rancherctl config" и затем сохраняется в специальный файл конфигурации.

  1. Главная ссылка к новости (http://rancher.com/press-relea...)
  2. OpenNews: Выпуск Docker 1.7. Docker и CoreOS объединили усилия в разработке единого формата контейнеров
  3. OpenNews: Intel представил Clear Linux с контейнерами приложений на базе виртуализации
  4. OpenNews: RancherOS - новая ОС, построенная на идеях контейнерной изоляции
  5. OpenNews: Началось тестирование ОС Subgraph, использующей контейнерную изоляцию приложений на десктопе
  6. OpenNews: Выпуск cистемы управления контейнерной виртуализацией Docker 1.13
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/46370-rancher
Ключевые слова: rancher, docker, container
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (23) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 09:08, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Эта дурная мода на "кружочки" теперь и в презентации переползла, тьфу. Понятное дело, что в могильном интерфейсе круглые кнопки ближе к форме пальцев, но на десктопах выглядит неуместно.
     
     
  • 2.3, hoopoe (ok), 09:53, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    да ладно, по большому счёту покер в какой формы кнопари мышом тыкать... кстати, сейчас большинство ноутов идут с тач экранами, тоже, по сути, почти могильный интерфейс :)
     
     
  • 3.17, Аноним (-), 15:38, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Проще попасть в кнопку большей площади. Площадь прямоугольника больше, чем площадь круга.
    Хотя к картинкам в презенташке это никакого отношения не имеет.
     
     
  • 4.19, Аноним (-), 21:22, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    только область касания все равно имеет форму круга
     

  • 1.2, Аноним (-), 09:50, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Интересно, это мода (помешательство, одержимость) докеризировать всё, что (шевелится :)) докеризируется или в этом есть реальный смысл и необходимость? В каких проектах такое может понадобится, что аж даже "Всё остальное, включая udev, dhcp, ntp, cloud-init и rsyslog, запускается внутри отдельных системных контейнеров" ?
     
     
  • 2.4, Аноним (-), 09:56, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    IMHO, баловство всё это и оправдано только если а контейнере нет доступа с правами root. Если в контейнере есть возможность выполнить код под root, то создаётся лишь видимость защиты. Особенно радует user namespace для которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере подняться до полноценного root на стороне хост-системы.
     
     
  • 3.6, J.L. (?), 10:51, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Особенно радует user namespace для которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере подняться до полноценного root на стороне хост-системы.

    так нашли же и пофиксили
    или нашлись какие-то концептуальные архитектурные уязвимости ?

     
     
  • 4.22, derlafff (ok), 08:28, 14/04/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Проблема не в концептуальных архитектурных уязвимостях, проблема в том, что весь ядерный код писался без оглядки на эти самые user namespaces. Поэтому, пока коды нормально не перечитают, подобные уязвимости продолжат появляться довольно часто. Т.е. еще несколько лет -- точно.
     
  • 3.9, Аноним (-), 11:33, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > IMHO, баловство всё это и оправдано только если а контейнере нет доступа
    > с правами root. Если в контейнере есть возможность выполнить код под
    > root, то создаётся лишь видимость защиты. Особенно радует user namespace для
    > которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере
    > подняться до полноценного root на стороне хост-системы.

    Так ограничьте права. И не запускайте что не попадя от root

     
     
  • 4.14, J.L. (?), 13:22, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> IMHO, баловство всё это и оправдано только если а контейнере нет доступа
    >> с правами root. Если в контейнере есть возможность выполнить код под
    >> root, то создаётся лишь видимость защиты. Особенно радует user namespace для
    >> которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере
    >> подняться до полноценного root на стороне хост-системы.
    > Так ограничьте права. И не запускайте что не попадя от root

    контейнер к вам может попасть через жирный_пакет какой нить "как есть", с настройками контейнерного рута внутри

     
  • 2.7, VoDA (ok), 11:19, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Смысл в том, что контейнер в котором разработано приложение и запускается пользователем.

    Вместе с приложением максимально переносится окружение.

    Это позволяет избежать части багов появляющихся из-за разности в конфигурациях dev и prod.

     
     
  • 3.10, anon13 (?), 11:49, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Главный фактор - это лень.
     
     
  • 4.11, VoDA (ok), 12:03, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Главный фактор - это лень.

    Лень чинить баги - правильный фактов. Заставляет заранее снижать их количество ;)

     
  • 2.8, VoDA (ok), 11:20, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Минорный плюс - контейнеры stateless. Для серверных приложений это позволяет динамически расширять и сжимать боевой кластер прямо на ходу.
     

  • 1.12, Аноним (-), 12:30, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Шо опять?
     
     
  • 2.13, Аноним (-), 12:58, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Нет..
    Снова
     

  • 1.15, theoneandonly (?), 13:36, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > отличаясь от них отказом от системного менеджера systemd в пользу собственной системы инициализации

    heretics!

     
     
  • 2.18, J.L. (?), 16:18, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> отличаясь от них отказом от системного менеджера systemd в пользу собственной системы инициализации
    > heretics!

    killing it by fire!!!!

     

  • 1.16, Аноним (-), 14:24, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Когда уже сделают экзоядро уже?
     
  • 1.20, Петр Ильин (?), 21:35, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Это опять процессоры слишком мощные и памяти завались?
    Т.е. сейчас все будет даже ls в контейнерахзапускаться? Модно типа?
    А потом сделают контейнер на уровне CPU
     
     
  • 2.21, Аноним (-), 07:29, 14/04/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это опять процессоры слишком мощные и памяти завались?

    Процессоры и память не причём, это к виртуализации.

    Основной смысл современных систем управления о оркестровки - разорвать зависимость от локального хоста и запускать приложение на кластере, так же просто, как сейчас запускаем приложение на процессоре с несколькими ядрами.

    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 как раз слишком низкий, нужен уровень нескольких вычислительных узлов. Времена, когда в стойку влезает несколько тысяч ядер/компьютеров уже наступили и одним локалхостом не обойтись.

     

  • 1.23, Oinari (ok), 12:01, 16/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Лучше бы микроядра пилили.
     
     
  • 2.25, JL2001 (ok), 16:55, 19/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше бы микроядра пилили.

    нужно и то и сабж (и не факт что нужно вместе, но кому как)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру