Nebh-X

Мысли разной степени связности о том, что не хватает контейнерам для нормального применения в боевых задачах. На полноту изложения не претендуют. Без предварительных комментариев могут плохо восприниматься - сорри, но так и задумано.

Материалы по теме

• https://www.facebook.com/mxsmirnov.arch/posts/691217340982083 + http://mxsmirnov.com/2015/06/02/paas/- подборка ссылок имени нашего любимого Максима Смирнова под кодовым именем "чему именно по этой теме радуются архитекторы в тяжёлом корпоративе"
• Ещё от Смирнова - ребята пишут про blue/green деплой в продакшн - http://blog.tutum.co/2015/06/08/blue-green-deployment-using-containers/ - тулзы у ребят имени себя
• https://www.openshift.org/ - заявлено, что это во многом о контейнерах для корпоратива. Серебряной пули и волшебных таблеток не ожидаем, но могут найтись ответы на часть вопросов. Текст про изнанку текущей dev-версии - https://blog.openshift.com/openshift-v3-deep-dive-docker-kubernetes/
• http://www.haifux.org/lectures/320/netLec8_final.pdf - Презентация с обзором технологий контейнеризации. Можно посмотреть как вводную.
• http://man7.org/linux/man-pages/man7/namespaces.7.html - Linux namespaces. Man, сжато по теме namespaces. Связанные man страницы тоже можно посмотреть.
• https://lwn.net/Articles/532593/ Серия от Michael Kerrisk про linux namespaces. Сравнительно подробный рассказ о namespaces с учебными примерами кода. Интересны все части серии.
• https://www.kernel.org/doc/Documentation/cgroups/ Документация ядра про cgroups.
• ...

Чуток про Google Kubernetes

Мысли по следам рассказа - http://www.redhat.com/summit/agenda/sessions/index.html#13503 - Craig McLuckie (Product Manager, Google) на Red Hat Summit.

• Google воспринимает Kubernetes как PaaS v2, который должен решить проблемы, собранные по итогам PaaS v1.
• Одна из ярких проблем - таки данные. В Kubernetes есть Volumes (ссылки по теме пока не нашёл), которые отвечают за привязаку к контейнерам сущностей уровня "папка FS", "NFS" или "блочный девайс".
• Необходимость сценариев вида "умный апдейт с ролбэком" товарищ Craig понимает, реализацию видит как кастомные расширения Kubernetes. (Это не в слайдах, это при обсуждении после, так что всё может в итоге оказаться чуток не так, как было рассказано.)
• Совсем сложные сценарии с кучей шагов, веток и условий обсудили на примере HPC (не совсем то, но так вышло). Пришли к тому, что (а) в Kubernetes в любом случае будет job scheduler для batch jobs, (б) конкретный сценарий - таки опять расширение, вероятно, сшитое с чем-то BPM-ного вида сбоку. Этот результат обсуждения не совсем про сабж Nebh-X, но так уж вышло. (Но сам по себе сценарий с batch jobs, кстати, важен.)
• Общее впечатление - Google правда делает что-то довольно осмысленное, оно обобщает проблемы прошлых итераций, оно задумано как изначально расширяемое, так как нет предела извращениям. Но на данный момент Kubernetes скорее PoC чисто шедулера контейнеров, 1 июля должен быть релиз 1.0, ориентированный на сетап в пределах 100 хостов.

Сущности

• "Бинарники" - собственно контейнеры. В них собранный код, скрипты и вот это всё. В текущем приближении вполне покрыты контейнерами как они есть в дикой природе. Реализация: тарбол, пакет rpm, скачанный файл... Стоит допустить, что в рамках одного контейнера могут приезжать сразу несколько видов "бинарников".
• "Конфиги" - те или иные настройки. С ними всё заметно хуже. Пихать их в контейнер - не дело. Можно хранить их в чём-то типа etcd. Можно разливать их чем-то типа ansible. Вопросы есть - например, конфиги бывают на ноду, а бывают на кластер. И второе не очень покрыто типовыми тулзами. Конфиги надо версионировать и допустить возможность шаблонизации.
• "Данные" - с чем работают бинарники, от статичных страничек до файлов с данными базы. С данными совсем капец. Они должны быть атомарно-транзакционными, примерно как "бинарники". Чисто теоретически тот же Docker предлагает с ними жить средствами OverlayFS. Идея выглядит не совсем очевидной - можно использовать снапшоты LVM (что более распространено), можно снапшоты btrfs (что более модно), можно снапшоты железных хранилок (что более энтерпрайзно). Ну и вообще ни черта в этой области не проверено пока.
• "Запускатор" - программа, стартующая контейнер. Можно не давать никаких ограничений на неё, но хотелось бы чтобы были базовые вещи: проверка живости содержимого, перезапуск, ... Во многих случаях этот функционал стандартен. Кажется тут уместно вспомнить systemd (шёпотом.)

Сценарии - крупными мазками

• Сборка контейнера. Оно не может быть "как-то где-то там, хз чем". В каком-то виде решение заявляет тот же Openshift - интеграция с Jenkins, сборка по коммиту (?), всё такое. Но сценарий "тут положите ваш произвольный билд-скрипт" - не лучшее решение, мало чем отличается от сборки не коленке хз где и чем. Две "крайности": сценарий сборки определен сравнительно жестко(пакеты), произвольный скрипт.
• Обновление контейнера. Наивные вопросы опять-таки заявляет Openshift (если есть новая сборка - авто-обновление всех задеплоенных). Но этого таки мало - бывают проблемы обновления, бывают откат обновления, бывает обновление кластера, которое должно быть синхронно, а не как получится, бывает связь этого всего с данными. Сценарий обновления может быть небанальный: обновить 10%, если все успешно, то написать письмо админу и ждать, если неуспешно, то откатить и написать письмо админу. Изменение настроек может потребовать перезапуска одного или нескольких контейнеров.
• ...

Обновление контейнера чуть подробнее

• Наивно есть стадии - Prepare, Switch, Rollback или Commit (Success, Go - не суть). И на этих стадиях нужно помнить, что бывают "бинарники", "конфиги" и "данные".
• Стадия Prepare может быть медленной, может быть по-разному медленной на куче хостов. И может запускаться автоматически и идти фоново - человек тут не нужен.
• Скорее всего, хочется иметь несколько версий контейнера, готовых к запуску. Уже на хостах исполнения, чтобы при операциях уровня "Ну, поехали!" или "@#%, верните всё как было!" не тупить на разливке и т.п. Скорее всего, нужны N (2?) последних версий плюс те, что явно помечены как важные релизы.
• Стадия Switch, скорее всего, бывает над нодами (если каждая может обновляться сама) и над группами нод (если это должно быть синхронно над кластером).
• После Switch должен прогоняться какой-то набор проверок, что оно вообще ожило. Далее должен быть минимальный мониторинг, живо ли оно вообще в данный момент времени.
• При сбое должен быть возможен Rollback. Самое весёлое - связь с данными. Не всегда мы хотим откатить всё до старого "бинарника" и старых "данных". Мы можем хотеть старый бинарник и новые данные ("новая АБС быстро упала в сегфолт, но вообще-то успела провести какие-то платежи перед этим").
• Сценарии обновления группы контейнеров могут быть сложными и ветвящимися.
• Есть опять же две крайности: жестко прошитый сценарий обновления или полностью кастомные скприпты. Если сделать сценарий жестким, то не будут удовлетворены хотелки типа: "Обновление на новую мажорную версию требует обратиться к некому API, послать команду перед завершением процесса, перед стартом конвертировать базу итд", если сценарий произвольный, то получается бардак и неясен текущий стейт. Если говорить иначе то это декларативный vs императивный подход. Часть систем работают с неким state конфигурации и собственно процесс обновления - это процесс перехода из одного стейта в другой (по определенным в системе правилам). Плюсы велики, но часто гибкости не хватает и начинается содомия. Другие системы позволяют поьзователю самому определить действия при обновлении системы, тут гибкость велика, но иногда содомия начинается сразу и получается неподдерживаемый набор скприптов. Где баланс?

Комплексные сущности

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

• Люди мыслят сервисами. Сервис может состоять из группы машин с приложением А, группы машин с приложением Б, балансера и кучи файл-шар.
• Для конфигов кирпичиков хочется иметь буквально объектную модель. Пример: есть базовая вин-машина, есть базовая лин-машина, есть база на лин, есть приклад на лин. И есть инфраструктура, в которой это всё должно развернуться (VXLAN-ы, адреса из IPAM и хз что ещё). Текущий конфиг имени Cloud Init достаточно страшен тем, что машинке передаётся ровно одна user_data. Эту юзер дату можно зашить в конфиг базового сервиса - "вот юзер дата для базы, вот юзер дата для приклада" и т.д. Но это довольно больно, потому что они процентов так на 90 повторяют друг друга. Где-то здесь выползут вопросы: (а) где и как это хранить, (б) как клеить гипотетическую иерархию юзер даты в единый сценарий для машины, для того же Cloud Init это неочевидно, (в) как это счастье отлаживать IRL, когда оно рассыплется на кучу однострочников, extend-ящих и override-ящих друг друга (!?) (привет, Alfresco).
• Кирпичики зависят друг от друга - машинки должны прицепить шары, балансер настроиться на машинки. Из этого простого факта следует, что в правильном мире деплой идёт в понятной очерёдности, и результат деплоя одного кирпичика (условно - адрес и имя шары) является входом другого кирпичика (параметры монтирования для машинки). Творчество на чудо-скриптах - милый выход. Но хочется разумной строгости. Текущая фантазия - делаем буквально workflow деплоя. Есть квадратики на диаграме, есть общая схема. У квадратиков и схемы есть какие-то свои карты параметров, которые можно читать и писать (сигналить?). Квадратик - это деплой чего-то простого. кКвадратик описывается кодом на разумном языке - что взять на вход, что из него обязательное и что опциональное, что с ним сделать, что является выходом. (Внимание, вопрос - как этот код про "взаимодействие" кирпичиков сшивается с кодом скриптов(?) настройки внутри машинки? Наивно получается, что "внешний" код эти скрипты должен чуть ли не генерить на лету.) У квадратика есть некие строгие статусы уровня "взлетел успешно" или "упал нафиг при старте". (Кто за них отвечает? И неужели итоги прогона тестов приклада квадратика тоже внутри этих статусов?) Из квадратиков строится схема деплоя. И что-то кажется, что вот тут не должно быть никакого @#$дского творчества на скриптах - только соединение стрелочками входов и выходов ("когда этот раздел будет создан, передать его volumeUrl вот сюда для использования в роли appHome"). Максимум - в этой же схеме могут быть типовые элементы уровня "собрать настройки сетевой папки из вот этих адреса, имени, логина и пароля". Часть параметров пишется руками (размеры шар, параметры монтирования и т.д.) - это норма. Но это параметры из жестко специфицированного списка. Нужен кирпичик с нестандартным набором параметров - велкам, пишите (наследуйтесь?) и добавляйте в "палитру".