Представлен (http://rancher.com/rancheros-1-1-0/) выпуск операционной системы RancherOS 1.1 (http://rancher.com/rancher-os/), предоставляющей средства для изолированного выполнения приложений. Проект основан (http://rancher.com/about/) несколькими известными разработчиками из компании Citrix и бывшими руководителями Cloud.com. Код системы написан на языке Go и распространяется (https://github.com/rancherio/os) под лицензией Apache. Размер загрузочного образа (https://github.com/rancherio/os/releases/) составляет всего 59 Мб. Кроме установки на отдельный сервер, система также может быть развёрнута в окружении облачных платформ и систем виртуализации Amazon EC2, Digital Ocean, Docker Machine, GCE, KVM, OpenStack, Packet, Vagrant, VMware и VirtualBox, а также установлена на платах Raspberry Pi.Небольшой размер загрузочного образа объясняется тем, что 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). Между перезапусками сохраняется только содержимое разделов /opt и /home, всё остальное возвращается в исходное состояние. Конфигурация окружения передаётся во время загрузки через механизм cloud-init или определяется командой "rancherctl config" и затем сохраняется в специальный файл конфигурации.Ключевые новшества RancherOS 1.1:
- Обновлены системные компоненты, в том числе ядро Linux 4.9.45 и инструментарий Docker. По умолчанию предлагается Docker 17.03.2, но в качестве опции доступен выпуск 17.06.1 и более ранние версии, начиная с 1.12;- Добавлена поддержка гипервизора VMWare ESXi, который автоматически определяется и для него активируется набор модулей open-vm-tools во время загрузки. Также автоматически загружаются настройки, определённые в VMWare;
- Обеспечена предварительная поддержка загрузки модулей для гипервизоров Xen, KVM и HyperV, но соответствующие сервисы для них пока не включены в поставку;
- Добавлена поддержка автоопределения систем виртуализации vbox, xen и paralells;
- Реализовано интерактивное загрузочное меню на базе Syslinux с опциями для отладки, входа, восстановления и редактирования настроек;
- Добавлена консоль для восстановления в случае сбоя, вызываемая на раннем этапе загрузки;
- Добавлен сервис для ротации логов и cron для периодического выполнения заданий;- Обеспечено сохранение отладочной информации в файл /var/log/boot и добавлена возможность использования параметров ядра netconsole для отправки логов на внешний сервер;
- Добавлена возможность перезагрузки с использованием kexec (reboot --kexec) при которой ядро перезагружается без передачи управления BIOS;
- Добавлена возможность монтирования сетевых разделов по NFS в конфигурации на базе cloud-config.
URL: http://rancher.com/rancheros-1-1-0/
Новость: http://www.opennet.me/opennews/art.shtml?num=47129
Я уже подумал операционистку написали на Golang.По факту Linux для запуска контейнеров. В целом годная штука.
> В целом годная штука (под смузи)./fixed
Ты сначала попробуй поработать с масштабированием без докера на голом lxc, тогда и говори про смузи.
>Ты сначала без докера на голом lxc, тогда и говори про смузи."попробуй поработать с масштабированием" :-) А в чём суть вашей работы?
А так да - хуже докера пока ничего не придумали. Ди и его придумали чтобы рябе-программы хоть как то у клиентов а не на машине программиста работали :-))))
> Ты сначала попробуй поработать с масштабированиемМалыш, тебя обманули: enlarge your penis != масштабирование.
А таки почему в качестве масштабируемого решения не рассматриваете тот же lxd?
> всё на go, докер един
> ядро линуксвооооу. Я думал, там нормальные контейнеры, а там докер.
А нормальные это какие? (ничуть не ратую за Docker, сделайте define просто)
Нормальные у нас одни — lxc
Так докер и так поверх lxc работает, разве нет?
> Нормальные у нас одни — lxcТы неправ, есть еще и сыстемд! Вполне себе нормальный контейнер.
>> Нормальные у нас одни — lxc
> Ты неправ, есть еще и сыстемд! Вполне себе нормальный контейнер.systemd-nspawn? Смотрел один раз, если надо быстро запустить и дропнуть что-то может и подойти, для нормальной работы есть lxc.
Rancher - нормальная штука, значительно проще kubernetes.
Чем лучше CoreOS?
> По решаемым задачам система напоминает проекты Atomic и CoreOS, отличаясь от них отказом от системного менеджера systemd в пользу собственной системы инициализации, построенной непосредственно на базе инструментария Docker.
> Над контейнерами функционирует только процесс Docker, выполняемый с PID 1.Воу, вот это да. Не, спасибо.
Но зачем?
Кто-то из защитников концепции всеобщей докеризации, скажите, зачем изолировать ntpd от dhcp?
Кабы чё не вышло, а то вона как будеть!
> Кто-то из защитников концепции всеобщей докеризации, скажите, зачем изолировать ntpd от dhcp?Почему только одно от другого? Все эти сервисы выполняются на тех же самых узлах, что и остальные контейнеры. Изолируют всех от всех.
А если использовать не модифицируемые образы, чётко указав где будут данные записываться на диск, то заодно изолируются от конкретного сервера, где выполняются. Сломался сервер, ушел в перезагрузку после установки обновлений, или просто стал недоступен -- приложение за минимальное время переезжает на другой сервер. Само, этим планировщик кластера постоянно занимается.
Миграция на уровне приложений без потери данных и соединений между различными облачными провайдерами и не парясь с настройкой окружения? По этой же причине и изолируют ntpd от dhcpd.
чем лучще Alpine Linux?
Alpine внутри контейнера, а этот снаружи?