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

Старая идея - облачный сервис поверх дешёвых 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-подключение, просто с другой функцией (ре)коннекта.

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

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

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

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

• ​CoreOS - линукс с атомарным самообновлением и встроенными etcd, fleet, rkt и docker
• etcd - Координатор кластера. Уебищная поделка от CoreOS, единое место уязвимости, при взломе которого ломается весь кластер. Мало того, что создаёт проблемы безопасности, так ещё и труден в настройке, администрировании и постоянно падает.
• registry - Docker Image Registry Server, сервер имиджей. Снова единая точка ломающая кластер. Уебищно небезопасен, взлом равноценен возможности запуска произвольного кода на всех машинах кластера.
• kubernetes
• fleet - удаленный деплоймент имиджей и запуск-останов контейнеров с ними. Классная штука, но работает через etcd и registry, из-за чего говно
• zookeeper - аналог etcd от Apache. Кроме недостатков etcd, невероятно прожорлив в плане требуемого объема памяти быстродействия диска. Так же единое место уязвимости, постоянно падает из-за пропадания консенсуса и т п.
• MesOS
• ...