Чтобы совместить приятное с полезным, я стал искать подходящее приложение, на котором, с одной стороны, было бы интересно применить облачные технологии, а с другой, — могло бы пригодиться в будущем. Поэтому, я решил развернуть инсталляцию OwnCloud на базе CoreOS.
Теперь я расскажу, к чему это привело, и по ходу действия приведу ссылки, чтобы интересующийся мог углубить свои знания в предметной сфере. Но если возникнут вопросы — смело задавайте их в комментариях.
Итак, я поставил себе задачи:
- Установить CoreOS на bare-metal сервер
- Настроить распределенное хранилище данных
- Написать свой Dockerfile и запустить приложение в кластере
- Настрить автоматическое обновление и регистрацию контейнеров
- Рассмотреть неиспользованные технологии и придумать им применение(*)
В этой статье я расскажажу об установке CoreOS. О настройке и дальнейших экспериментах — в дальнейших.
Установливаем CoreOS на bare-metal сервер
Чтобы установить OwnCloud на сервер, нужно обзавестись сервером.
Инсталляция на виртуальные сервера «за деньги» или такие же виртуальные сервера на локальной машине не столь интересна, как установка на «живое» железо. Но с текущем курсом доллара арендовать сервера — дорогое удовольствие. Поэтому был совершен рейд на гугл, чтобы найти провайдера, предлагающего дешевое и «металлическое» решение.
Гугл предложил мне две компании, обе французские: Kimsufi и Online.
Kimsufi — дочка OVH, одного из крупнейшего хостера.
Online — дочка iliad, одной из крупнейших телекоммуникационных компаний.
Обе компании предлагают дешевые и при этом мощные решения. Хоть по отзывам у online.net сеть лучше, мой выбор пал на Kimsufi по двум субъективным причинам: 1) сервер на VIA® Nano® U2250 слишком медленный, а за следующий в линейке просят уже 16 евро — жаба душит; 2) наличие верифицированного аккаунта у OVH/Kimsufi.
Регистрация
О регистрации, подтверждении и снятии VAT у провайдера Kimsufi было много сказано (хабр). Единственное, о чем стоит предупредить — это о времени ожидания. Создается впечатление, что поддержка у Kimsufi работает по остаточному принципу — проблемы кастомеров решаются только когда от «большого брата» (OVH) нет задач. Стоит это иметь в виду, если хотите размещать там production.
Покупаем сервера
Я заказал три сервера. Почему три? Потому что только три сервера могут гарантировать отказоустойчивость и отсутствие split-brain.
Так как желающих приобрести сервера за такую цену очень много, стать счастливым обладателем своей железки «честным» путем довольно сложно. Лично я для их поимки воспользовался этим скриптом.
KS-2b — проц D425, диск 1ТБ HDD
KS-2c — проц N2800, диск 40ГБ SSD
Установка CoreOS
Как только сервера оплачены и прошли предпроверку, вы получите сертификат сервера по почте. Сразу же после этого сервера будут доступны через веб-админку.
Для начала нам нужно попасть в рекавери, а дальше установка идет по официальной инструкции установки на диск.
Чтобы загрузиться в Rescue, в веб-интерфейсе кликаем на Netboot -> Rescue. После этого сервер нужно перезагрузить, проще всего это сделать жмякнув на кнопку Restart. Пароль для входа придет на почту.
Как только авторизовались на сервер по SSH, загружаем скрипт установки
wget https://raw.github.com/coreos/init/master/bin/coreos-install
chmod +x coreos-install
./coreos-install --help
Пишем свой cloud-init файл и процесс установки через coreos-install -C stable -c /path/to/cloud-init -d /dev/sda.
После того, как установка завершится, можно внести изменения вручную: добавить ssh-ключ или отредактировать cloud-init. Для этого необходимо примонтировать ROOT партицию — она под номером девять. Например:
mount /dev/sda9 /mnt
echo 'ssh-rsa AAAAB... user@domain' > /mnt/home/core/.ssh/authorized_keys
Либо же можно положить ключ через cloud-init:
#cloud-config
hostname: core1
coreos:
write_files:
- path: /home/core/.ssh/authorized_keys
permissions: 0600
owner: core
content: |
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+jxun+xn31x4tP7NdM6nMFI5b00bbk+VK4JM5mdyS+30/lIhhArMWnhla7NTw0BINdvutErZRFzhIqf5yaR/+O7/Oqc9J53dWJiEnz0si9hutbVSYA/Peo0Z9nFBm6Aep3816AzJYNzKIZg17JwqTKpEnV/ArXOmbCek9hi50R7yuZvtehWmJMNqTxKhqb5aD1joARd2iTMfS39pFsLsrxn8b2mGfcQH9v0+HwmNEiCGpq+HCMFTpt9Z1SOukeTpKOWOiBEzQPqaeaIeqXTDHHj2zWHv0/elIuRBFpxgC00DvoshlAzmB6CwCttBkigGQP2Mlcnovuo0RyuJRAlw1 user@domain
#cloud-config
hostname: core1
coreos:
write_files:
- path: /etc/ssh/sshd_config
owner: root
content: |
# Use most defaults for sshd configuration.
UsePrivilegeSeparation sandbox
Subsystem sftp internal-sftp
ClientAliveInterval 180
UseDNS no
AuthorizedKeysFile %h/.ssh/authorized_keys.d/coreos-cloudinit
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+jxun+xn31x4tP7NdM6nMFI5b00bbk+VK4JM5mdyS+30/lIhhArMWnhla7NTw0BINdvutErZRFzhIqf5yaR/+O7/Oqc9J53dWJiEnz0si9hutbVSYA/Peo0Z9nFBm6Aep3816AzJYNzKIZg17JwqTKpEnV/ArXOmbCek9hi50R7yuZvtehWmJMNqTxKhqb5aD1joARd2iTMfS39pFsLsrxn8b2mGfcQH9v0+HwmNEiCGpq+HCMFTpt9Z1SOukeTpKOWOiBEzQPqaeaIeqXTDHHj2zWHv0/elIuRBFpxgC00DvoshlAzmB6CwCttBkigGQP2Mlcnovuo0RyuJRAlw1 user@domain
Во время первой загрузки системы запускаются скрипты, которые делают некоторую магию (чинят GPT, делают resize корневой файловой системы(/dev/sda9) и пр.
Чтобы загрузиться в свежеустановленную ОС, нужно сменить порядок загрузки через веб-интерфейс -> Netboot на загрузку с жесткого диска и отправлить сервер в перезагрузку(командой reboot в терминале, либо кнопкой Restart в веб-админке).
Если вы не забыли положить ssh-ключ или в cloud-init'е указали своего пользователя, то вас должно пустить в систему. Если удалось — поздравляю! Если нет — что-то пошло не так.
Переразбивка диска
Как только система установлена, можно приступить к её изучению. А интересного много: etcd, fleet, systemd и связанные с этим технологии: kubernetes, confd и многое другое!
Но перед тем, как идти дальше, я решил создать две дополнительных партиции: для хранения пользовательских данных (распределенная) и для хранения контейнеров и системных приложений (btrfs).
Почему была выбрана btrfs, если она является экспериментальной? Потому что цель моего эксперимента в том, чтобы поэксперементировать с новыми технологиями. И несмотря на то, что btrfs была вот уже пару лет стабильно работает на десктопах/ноутбуках, в продакшне я её не использовал.
Для того, чтобы что-то выделить, нужно в начале освободить! Для этого нужно вернуться обратно в Rescue.
Я уменьшил размер ФС, затем уменьшил размер партиции и уже после создал новые.
Корень находится на девятой партиции: /dev/sda9. Приступим:
e2fsck -yf /dev/sda9 # проверяем ФС на наличие ошибок
resize2fs /dev/sda9 100G # изменяем размер корневой ФС до 100ГБ
gdisk /dev/sda # меняем размер партиции
resize2fs /dev/sda9 100G # чтобы убедиться, что всё ок
В gdisk'е нужно удалить партицию и создать новую с измененным размером.
Если мне не изменяет память, то сочетания клавиш будут сделующие: d -> 9 -> n -> 9 -> -> +100G -> -> c -> 9 -> ROOT -> w -> Y ->
Если вы сделали всё верно, то можете спокойно загрузиться с жесткого диска и увидеть, что /dev/sda9 занимает 100ГБ или 93ГиБ.
core3 ~ # df -h /dev/sda9
Filesystem Size Used Avail Use% Mounted on
/dev/sda9 97G 128M 93G 1% /
Несмотря на то, что я устанавливаю CoreOS на сервера Kimsufi, инструкция подходит и другим провайдерам. Если вы столкнулись с нюансами при установки — пишите, обсудим.
На этом рассказ об установке CoreOS на bare-metal сервер Kimsufi завершен.
Who's next?
В следующей статье я расскажу, как создать партиции из освободившегося места, как настроить RTM (Real Time Monitoring — скрипт мониторинга для отрисовки красивых графиков в веб-админке OVH), etcd, fleet и как развернуть распределенную ФС.
Комментарии (3)
mrpsycho
28.04.2015 23:59а что бы вы порекомендовали прочитать про CoreOS?
зачем она нужна и чем она отличается от других ОС?
ну и… почему все 3 сервера у одной компании, а не у трех разных? что б защититься по полной? :)reji Автор
30.04.2015 22:28+1Моей задачей является познакомить, а не сделать полностью отказоустойчивую систему. К сожалению, времени не хватает для того, чтобы делать «правильно», а без этого разнос по разным ДЦ — полумеры, которые лишь усложнят мне жизнь. Смысл?
Прочитать?.. Документацию на официальном сайте, 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 :)
fear86
Если кому интересно в пару кликов поднять и поиграться c CoreOS + Kubernetes то вот готовые cloud-config для DigitalOcean github.com/SergeyCherepanov/kubernetes-coreos-do