Перший раз про 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/