= Идеальная облачная платформа = Старая идея - облачный сервис поверх дешёвых 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 на продакшен = Непрерывная интеграция = = Готовые продукты и решения = - [https://coreos.com/ CoreOS] - линукс с атомарным самообновлением и встроенными etcd, fleet, rkt и docker - etcd - Координатор кластера. Уебищная поделка от CoreOS, единое место уязвимости, при взломе которого ломается весь кластер. Мало того, что создаёт проблемы безопасности, так ещё и труден в настройке, администрировании и постоянно падает. - registry - Docker Image Registry Server, сервер имиджей. Снова единая точка ломающая кластер. Уебищно небезопасен, взлом равноценен возможности запуска произвольного кода на всех машинах кластера. - kubernetes - fleet - удаленный деплоймент имиджей и запуск-останов контейнеров с ними. Классная штука, но работает через etcd и registry, из-за чего говно - zookeeper - аналог etcd от Apache. Кроме недостатков etcd, невероятно прожорлив в плане требуемого объема памяти быстродействия диска. Так же единое место уязвимости, постоянно падает из-за пропадания консенсуса и т п. - MesOS - ...