Идеальная облачная платформа

Старая идея - облачный сервис поверх дешёвых VPS.

В полном объёме пока никем не реализован, но базовых компонентов уже больше, так что можно пробовать.

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

Облако

Клауд - это система с API, позволяющая программно запускать и переконфигурировать виртуальные машины, и деплоить на них софт.

В нашем случае будут динамически подниматься и опускаться новые сервера в Digital Ocean, а также контейнеры на "фиксированных" VPS.

Система двухуровневая: на VPS (Xen, KVM, OpenVZ) работают виртуальные машины, в которых внутри работают контейнеры (rkt, docker, chroot). Некоторые виртуальные машины могут программно подниматься-опускаться. Некоторые требуют (минимального) вмешательства админа.

Контейнеры

Идея контейнера в том, что для каждого процесса в системе собирается своя виртуальная машина со своими зависимостями и своей независимой файловой системой.

Я хочу, по многим соображениям, минимальные контейнеры:

• без инструментов администрирования (шелла, SSH)
• без инструментов компиляции и зависимостей, нужных только для компиляции (на продакшене только самый минимум, необходимый для работы приложения)
• без инструментов диагностики

Все дополнительные инструменты, не нужные для непосредственной работы процесса, находятся "снаружи" контейнера и могут быть использованы при необходимости для заглядывания внутрь, а изнутри не доступны.

Безопасность

Дизайн существующих продуктов (CoreOS, Docker Swarm, ..) противоречит самым базовым принципам построения безопасных систем (не только компьютерных - но, скажем, доэлектронные системы секретности на военных объектах), и на форумах полно жалоб от инженеров безопасности, которые не понимают, как с этим хипсторским говном можно жить.

В-общем, правильно спроектированная система минимизирует поверхность атаки и ущерб в случае успешного взлома. Говнопродукты же все как один имеют огромную поверхность атаки и центральное место, в случае взлома которого наступает полный пиздец - то есть, получается полный доступ ко всему кластеру.

Надо будет написать отдельный документ по безопасности.

В первом приближении предлагаемая архитектура выглядит так:

• слейвы наглухо закрыты - не слушают ни на одном порту, кроме SSH
• используются функции подсистем либо порт маппинга, поддерживаемые SSH и позволяющие добавлять SSH-авторизацию к произвольным TCP-серверам.
• если нужно залить имидж, он заливается мастером по SFTP.
• если нужно запустить или остановить контейнер - опять же мастер коннектится по SSH к маленькому серверку администрирования.

Таким же образом через SSH может работать и mtrg, и коллектор.

В случае mtrg к слейвам каждые 5 минут подключается zorro и собирает данные от bin/collect.sh

В случае коллектора у нас FIX работает поверх SSH port mapping. Т.е. backend подключается к коллектору по SSH, и для него это выглядит как обычное TCP-подключение, просто с другой функцией (ре)коннекта.

Деплоймент имиджами

Имиджи приложений

• приложение разделяется на постоянную и переменную части,
• постоянная часть тупо переписывается с компа разработчика, вместо текущей процедуры, при которой можно забыть запушить, или установить не ту ревизию, или забыть переустановить node_modules
• постоянная часть включает все системные пекеджи (в случае аналитикса - /bin/node и нужные ему библиотеки) и папку node_modules

В идеале сорцы лежат на винде, и в процессе разработки ты запускаешь в виндовой командной строке скрипт деплоя и перезапуска vmng, и оно отрабатывает за секунды.

Деплой на продакшен выглядит как команда клонирования vmng на production, так же запускаемая с винды.

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

Системные имиджи

Для поддержания слейва в безопасном состоянии его надо обновлять. Обновление версий библиотек и ноуда выполняется путём заливки нового имиджа.

Но для обновления SSH, ядра и управляющего софта необходима отдельная подсистема системных имиджей. Т.е. сервер, который принимает от нас имиджи и деплоит, должен уметь апгрейдить и даунгрейдить сам себя, а также передедеплоивать себя с нуля, если после апгрейда прийдёт в поломанное состояние.

Эластичность

Эластичность - возможность докупки новых серверов через Digital Ocean API в зависимости от нагрузки.

В случае Аналитикса-2 мы установим экспериментально, что 1 сервер тянет 23 кернела. И при запуске 24-го кернела мы проследим, чтобы оно запустилось уже на свежезакупленном сервере. Ну, и обратно - чтобы после падения нагрузки удалять простаивающие сервера.

В случае Скраббера аналогичная ситуация со слейвами.

Мониторинг и диагностика

• Сбор логов journalctl
• новый mrtg, при котором слейвы опрашиваются с zorro
• минимизация необходимости ходить по SSH на продакшен и vmng

Непрерывная интеграция

По каждому коммиту или мержу создается имилж на отдельном сервере интеграции, выполняется прогон тестов и пометка имиджей красными или зелёными.

В идеале, деплоймент на продакшен возможен только зелёного имиджа с сервера интеграции. Это исключает создание имиджей из незакоммиченного кода и деплоймент поломавшегося кода.

Готовые продукты и решения

• ​CoreOS - линукс с атомарным самообновлением и встроенными etcd, fleet, rkt и docker
• etcd - Координатор кластера. Уебищная поделка от CoreOS, единое место уязвимости, при взломе которого ломается весь кластер. Мало того, что создаёт проблемы безопасности, так ещё и труден в настройке, администрировании и постоянно падает.
• registry - Docker Image Registry Server, сервер имиджей. Снова единая точка ломающая кластер. Уебищно небезопасен, взлом равноценен возможности запуска произвольного кода на всех машинах кластера.
• kubernetes
• fleet - удаленный деплоймент имиджей и запуск-останов контейнеров с ними. Классная штука, но работает через etcd и registry, из-за чего говно
• zookeeper - аналог etcd от Apache. Кроме недостатков etcd, невероятно прожорлив в плане требуемого объема памяти быстродействия диска. Так же единое место уязвимости, постоянно падает из-за пропадания консенсуса и т п.
• MesOS
• ​https://sysdig.com/blog/the-container-ecosystem-project/ - обзор существующих прродуктов
• vmWare Photon OS
• Rancher OS
• Ubuntu Snap
• ...