Как стать автором
Обновить

Комментарии 3

а что бы вы порекомендовали прочитать про CoreOS?
зачем она нужна и чем она отличается от других ОС?

ну и… почему все 3 сервера у одной компании, а не у трех разных? что б защититься по полной? :)
Моей задачей является познакомить, а не сделать полностью отказоустойчивую систему. К сожалению, времени не хватает для того, чтобы делать «правильно», а без этого разнос по разным ДЦ — полумеры, которые лишь усложнят мне жизнь. Смысл?

Прочитать?.. Документацию на официальном сайте, issue и доку в гитхабе по всем компонентам, цикл статей про CoreOS от DigitalOcean.

Вообще, главное в этой ОС не сама ОС, а её компоненты. На уровне приложений: systemd, docker(systemd-nspawn, rocket), fleet, etcd, kubernetes, flannel и др. На более низком уровне: btrfs, overlayfs, kexec и др.

Зачем она нужна? Если говорить кратко, то она нужна таким компаниям, как Яндекс, Google, Facebook, Amazon — то есть тем, кто владеет огромным кол-вом серверов. Также, она может пригодиться для компаниям, которые хотят обладать своим PaaS(искать deis).
На кол-ве более тысячи хостов, привычные средства оркестрации, как Puppet, Chef, Salt становятся менее эффективны. Причем настолько, что переналить машину и прогнать на ней puppet/chef/salt бывает дешевле и быстрее, чем разобраться, из-за чего сломался к/л компонент сервиса на двух серверах из трех тысяч.

Чем отличается? Самое большое отличие — это в том, что корень RO: отсутствует пакетный менеджмент; проблематично запустить ч/л не через контейнер; нельзя «я сейчас тут быстренько либу обновлю»; нельзя «подниму быстренько nginx на этом сервере и забуду»; нельзя «щаз по крону подкостылю» — меняется парадигма деплоя и системного администрирования.

Если делать всё круто, то:
* программисты станут оперировать сервисами, которые не в make install / npm install / apt-get install, а в изолированном контейнере, который объявляется декларативно через Dockerfile(или архив, когда rocket выйдет в стейбл). Это уменьшает боль с dependency-hell, деплоем, rollback'ом
* администраторы станут оперировать датацентрами и pod'ами(термин kubernetes — некоторый стек контейнеров), а не отдельными серверами или отдельными группами серверов. Это поможет размазать нагрузку по кластеру; проще оперировать версиями сервисов, операционной систем; проще мониторить; проще админить и вообще, это же контейнеры! :)
* всем станет хорошо, когда появится «Один Большой init» — легко и быстро (пере)запустить/откатить/остановить/обновить любые сервисы, не думая о том, где они; легко разворачивать отказоустойчивость — достаточно указать «хочу, чтобы сервис был на трех машинах минимум в трех ДЦ»; легко управлять конфигами приложений — он сам определяет окружение(было и до CoreOS + etcd + confd, но стало заметно проще).

Плюс, есть разные ништяки, которые вряд ли пригодятся маленьким кластерам. Такие, как передача параметров при установке/загрузки через PXE, регистрация/конфигурация всего через SRV DNS-записи; преимущества постоянных релизов(не rolling releases как в дебиане/рхеле), дискавери сервисов, администрирование сервисов на более высоком уровне.

Вообще, вопрос «зачем?» и «чем лучше?» очень холиварный :)
Я готов продолжить разговор только тогда, когда systemd придет в Ubuntu LTS :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории