Меня всегда интересовали облачные технологии. В том числе и наиболее трендовые из них — это децентрализация, кластеризация, оптимизация и распределенние всего: вычислительных ресурсов, данных, пончиков и власти. Поэтому я не мог пройти мимо CoreOS, о которой в IT-сообществе сейчас много разговоров, и которая стала для меня отправной точкой для экспериментов.

Чтобы совместить приятное с полезным, я стал искать подходящее приложение, на котором, с одной стороны, было бы интересно применить облачные технологии, а с другой, — могло бы пригодиться в будущем. Поэтому, я решил развернуть инсталляцию OwnCloud на базе CoreOS.
Теперь я расскажу, к чему это привело, и по ходу действия приведу ссылки, чтобы интересующийся мог углубить свои знания в предметной сфере. Но если возникнут вопросы — смело задавайте их в комментариях.

Итак, я поставил себе задачи:
  1. Установить CoreOS на bare-metal сервер
  2. Настроить распределенное хранилище данных
  3. Написать свой Dockerfile и запустить приложение в кластере
  4. Настрить автоматическое обновление и регистрацию контейнеров
  5. Рассмотреть неиспользованные технологии и придумать им применение(*)

В этой статье я расскажажу об установке 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.
Краткое объяснение
В тестируемых дальше продуктах для расчета fault tolerance используется формула (n-1)/2, из которой видно, что минимальное значение числа n равно трем. В нашем случае, пруфы можно найти в доке etcd и Percona XtraDB Cluster, обсудить — в комментарии.

Так как желающих приобрести сервера за такую цену очень много, стать счастливым обладателем своей железки «честным» путем довольно сложно. Лично я для их поимки воспользовался этим скриптом.
Различие серверов линейки KS-2
KS-2a — проц N2800, диск 2ТБ HDD(или я везунчик ^_^)
KS-2b — проц D425, диск 1ТБ HDD
KS-2c — проц N2800, диск 40ГБ SSD


Установка CoreOS


Как только сервера оплачены и прошли предпроверку, вы получите сертификат сервера по почте. Сразу же после этого сервера будут доступны через веб-админку.
Как избавиться от назойливого попапа в админке и нюансы refund политики
После появления сервера в админке Kimsufi, нам будут предлагать установить ОС до тех пор, пока мы не установим хоть что-нибудь через веб-интерфейс. После этого вы не сможете вернуть свои деньги за сервер.

Владельцы ДЦ могут оценить некоторые фичи

Для начала нам нужно попасть в рекавери, а дальше установка идет по официальной инструкции установки на диск.
Чтобы загрузиться в 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-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-init номер два
#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) и пр.
Примечание
Подробнее о партиционировании CoreOS в доке, в mail list'ах или на гитхабе.

Чтобы загрузиться в свежеустановленную ОС, нужно сменить порядок загрузки через веб-интерфейс -> Netboot на загрузку с жесткого диска и отправлить сервер в перезагрузку(командой reboot в терминале, либо кнопкой Restart в веб-админке).
Если вы не забыли положить ssh-ключ или в cloud-init'е указали своего пользователя, то вас должно пустить в систему. Если удалось — поздравляю! Если нет — что-то пошло не так.

Переразбивка диска


Как только система установлена, можно приступить к её изучению. А интересного много: etcd, fleet, systemd и связанные с этим технологии: kubernetes, confd и многое другое!
Но перед тем, как идти дальше, я решил создать две дополнительных партиции: для хранения пользовательских данных (распределенная) и для хранения контейнеров и системных приложений (btrfs).
Почему была выбрана btrfs, если она является экспериментальной? Потому что цель моего эксперимента в том, чтобы поэксперементировать с новыми технологиями. И несмотря на то, что btrfs была вот уже пару лет стабильно работает на десктопах/ноутбуках, в продакшне я её не использовал.
Историческая справка
Изначально под корень в CoreOS создавалась btrfs партиция. С недавних пор для корня используется ext4 с AUFS/OverlayFS. Причина ухода с btrfs связана с двумя неприятными багами, которые должны были исправить с версии ядра 3.18, в чем клянутся разработчики. Тем не менее, btrfs возможно до сих пор имеет некоторые проблемы при работе со большим кол-вом (несколько тысяч) слоёв (снэпшотов), но обсуждение этого выходит за рамки данной статьи. Пишите комментарии!

Для того, чтобы что-то выделить, нужно в начале освободить! Для этого нужно вернуться обратно в Rescue.
Если вы не можете загрузиться в Rescue
Я столкнулся с проблемой: после свежей установки CoreOS, машинка не захотела загружаться по PXE, в том числе и в rescue. Если и у вас беда приключилась, можно воспользоваться одноразовым хаком: через iptables блочим весь ICMP-трафик (systemctl show iptables-restore.service) и делаем Restart через веб-интерфейс. Автоматика посчитает, что сервер не загрузился, и инженер вручную загрузит его в 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)


  1. fear86
    25.04.2015 14:36
    +2

    Если кому интересно в пару кликов поднять и поиграться c CoreOS + Kubernetes то вот готовые cloud-config для DigitalOcean github.com/SergeyCherepanov/kubernetes-coreos-do


  1. mrpsycho
    28.04.2015 23:59

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

    ну и… почему все 3 сервера у одной компании, а не у трех разных? что б защититься по полной? :)


    1. 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 :)