Як я рік працював на CoreOS

Перший раз про 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. Це також дозволяло за кілька хвилин відтворити проблему, що виникла у користувача, і запропонувати рішення.
Рішення
На будь-яке питання користувача я намагався видати рішення або, як мінімум, обхідний шлях. Навіть доступ в кулуари 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/

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.