Первый раз о CoreOS я услышал от Петра Леменкова на Yandex конференции “Дорога в облака” в сентябре 2013 года. Тогда я даже подумать не мог, что буду участвовать в разработке этой ОС.

Второй раз о CoreOS я вспомнил в октябре 2014, когда поступила задача о переводе микросервисов, написанных на Ruby (которые использовали, как это ни странно разные версии Ruby), в более благоприятную среду для continuous integration. Тогда я первый раз запустил CoreOS, и мне она показалось ужасно неудобной в использовании. Документация к ней была поверхностная. Сервисы, которые превращали CoreOS в кластерную ОС, имели множество недоработок и вызывали только чувство раздражения из-за постоянных ошибок. О переводе даже части инфраструктуры на CoreOS не было и речи.

В третий же раз, в марте 2015, поступила задача о предоставлении услуги поддержки в рамках community support для CoreOS. О том, как я справлялся, и пойдет речь.

Знакомство

Первой задачей было построить кластер, который выполняет функции, близкие к production системе одного из заказчиков, с которым я работал. Пришлось экспериментировать со связкой Kafka-Storm-Cassandra. За время выполнения proof-of-concept мне встретились всё те же недочеты в документации и коде etcd и fleet. Еще тогда мне показалось нелогичным поднимать кластер Zookeeper, когда в системе уже имеется etcd. К сожалению, пока ни у кого не возникло желания написать транслятор протокола Zookeeper Jute в REST API etcd. Наибольшие сложности тогда вызвало написание топологий для Apache Storm. Благодаря проекту https://github.com/Yelp/pyleus мне удалось избежать описания топологий на Java/Clojure. Работающий proof-of-concept был даже успешно продемонстрирован одному из потенциальных заказчиков для внедрения, но, к сожалению, из-за проблем с финансированием проект реализовать не удалось.

Практика

Используя полученный опыт и набитые шишки в процессе изучения CoreOS был дан старт улучшению. С официального IRC канала #coreos я получал вопросы, на которые отвечал и писал документацию. Самое главное — воспринимать все поступающие вопросы всерьез и стараться отвечать даже на самые глупые. Стоит отметить, что новые технологии, по которым я предоставлял поддержку, были для меня так же неизвестны, как и для пользователей, которые задают по ним вопросы. В то время, когда пользователь просто задавал вопрос, мне приходилось воспроизвести пользовательскую среду у себя и самому разбираться в деталях, лезть в исходный код, а иногда и исправлять там ошибки. Подобное боевое крещение позволило изучить многие нюансы работы systemd, ядра Linux, попрактиковаться в Си и научиться писать на Go.

Документация

Очень часто вопросы пользователей касались systemd. Хоть официальная документация systemd всё подробно расписывает, пользователям нужны примеры, им некогда читать (что не говори, но чтобы завоевать сердце пользователя, нужны готовые примеры, и много). В рамках поддержки CoreOS я написал немало примеров и дополнительной документации которая касается systemd. По некоторым из них Google даже выдавал первые ссылки на страницы документации CoreOS. Затем первенство перенял Wiki Archlinux. Примеры и пояснения должны были быть везде, где пользователь мог интерпретировать информацию не так. Почти любое недопонимание пользователя касательно документации или вопрос «а что если?», который возникал у меня в мыслях, превращались в pull request на github. Если ответа на вопрос пользователя нет в документации — исправь это.

Воспроизведение

Перед тем как публиковать ответ, по возможности его необходимо проверить в stable, beta и alpha релизах CoreOS. Для этого мне пришлось адаптировать bash скрипт, который с помощью libvirt поднимал виртуальные машины для внутренней инфраструктуры(возможно напишу об этом отдельный пост), используя уже готовые cloud VM образы Ubuntu. Скрипт при необходимости скачивает официальный образ CoreOS заданного релиза (https://stable.release.core-os.net/amd64-usr/current/), создает на его основе snapshot и поднимает виртуальную машину с примонтированным к ней cloud-config. При использовании shapshot'ов процесс создания «чистой» виртуальной машины занимает всего 20 секунд (при использовании SSD еще быстрее). При создании кластера виртуальных машин будет использоваться один базовый образ, что экономит дисковое время и место. К примеру, кластер из трех виртуальных машин поднимается всего за 30 секунд. Преимущество libvirt-qemu решения перед Vagrant в скорости работы. Даже libvirt provider в Vagrant не давал такой скорости. За день мне приходилось создавать и удалять кластеры, повторяющие пользовательское окружение, по несколько десятков раз. Конфигурация всего кластера формировалась при помощи всего одного cloud-config. Сейчас вместо cloudinit активно внедряется Ignition, который выполняется на стадии начальной загрузки системы.

Рулевой

Не стоит забывать и о проекте Kubernetes, который тесно используется с продуктами CoreOS. Для изучения Kubernetes я написал cloud-config, который воспроизводит конфигурацию точно так, как изложено в официальной документации, написанной Kubernetes командой из CoreOS. Это также позволяло за несколько минут воспроизвести проблему, возникшую у пользователя, и предложить решение.

Решение

На любой вопрос пользователя я старался выдать решение или, как минимум, workaround. Даже доступ в кулуары CoreOS мне не сильно помогал, т.к. я предоставлял поддержку в европейской части света, а вся команда CoreOS работала в тихоокеанской временной зоне. Чтобы не ждать, пока мои коллеги проснутся на другом конце Земли, я часто изучал исходный код для понимания процесса работы ПО, а порой сразу исправлял ошибки в коде.

Мнение

До сих пор очень многие скептически и категорично смотрят в сторону контейнеризации. Стоит только упомянуть Docker или CoreOS, так на тебя выливается ушат **вна. Я всегда стараюсь обратить внимание на то, что у каждой задачи есть свой инструмент решения. И у каждого инструмента есть свои плюсы и минусы. Если система уже работает на виртуальных машинах и не стоит задачи что-либо изменить или испортить улучшить, то пускай она работает дальше. Никто тебя не заставляет переводить всё на контейнеры. Но вот если задача уже поставлена или есть свободное время поиграться с контейнерам, то тут возникает недопонимание. Люди, привыкшие работать с виртуальными машинами, kickstart'ами, и системами управления конфигурацией, применяют старый подход к контейнерам, а потом жалуются на то, что контейнеры не работают. Не буду разводить флейм, просто еще раз дам ссылку на http://12factor.net/ и напомню, что контейнеры в большинстве случаях не должны хранить внутри конфигурацию и быть зависимыми от хоста.

Совершенство

Нет предела совершенству. Работа была всегда. В спокойные дни я тратил время на свой TODO-list. Все мелкие идеи или недочеты я записывал в список, и этот список никогда не заканчивался.

Контекст

Самым сложным было хранить в голове и работать над несколькими задачами. Порой я вел переписку одновременно с пятью пользователями в IRC канале. Это очень хорошо тренирует мозги, но продолжительное переключение контекста сильно выматывает.

Флот

Как только количество обращений по поддержке стало падать, я вступил в небольшую команду, работающей над проектом fleet. На тот момент проект был заброшен, т.к. всё внимание переключилось на Kubernetes. Но остались пользователи, которым необходимо было работать с systemd как с кластером. За три месяца мы написали около 15 новых функциональных тестов, реализовали автоматическую их проверку в https://semaphoreci.com. К выходу версии v0.12.0 мы закрыли 36 проблем и внесли в код 20 изменений. К версии v0.13.0 мы планируем закрыть около 20 проблем и внести 16 изменений в код.

Сегодня

На сегодняшний день команда поддержки CoreOS сформирована в Сан-Францизско, а я переключился на работу с другими проектами. За год работы мне посчастливилось пообщаться с такими людьми как Matthew Garrett, Brian 'redbeard' Harrington, Lennart Poettering, Kelsey Hightower и другими.

P.S. Полагаю я немного подпортил доход по предоставлению коммерческой поддержки:

nalum: anyone using the CoreOS managed linux service?
balboah: no we just ask kayrus :)
nalum: Who is kayrus?
balboah: the man that answers all the questions, usually

P.P.S. На следующей неделе в Берлине проходит конференция CoreOS Fest. Желающие поучаствовать могут еще успеть купить билеты: https://coreos.com/fest/