Необходимые технические требования для миграции 20


Мониторинг и реакция на инциденты


Мониторинг docker на всех машинах с ним. Динамический мониторинг с принятием решения об аварии на основе административных правил: мониторятся все контейнеры, которые на машине есть (а не по заранее заданным спискам), триггеры на все события (появление нового контейнера, исчезновение известного контейнера, запуск контейнера, остановка контйнера, перезапуск контейнера). При появлении триггера оператор должен свериться с текущим набором правил, и принять решение о наличии/отсутствии аварии.
Мониторинг всех HTTP сервсиов. Требуется проверять что все сервисы отдают правильные данные на простейший HTTP запрос (на / например, или /status). При этом нужно для каждого сервиса отдельно реализовать проверку тела ответа на соответствие валидному. Также нужно учитывать время овтета.
Мониторинг всех HTTP балансеров. Требуется проверять что балансировщик отвечает на HTTP запросы, и что ответ на 503 или 504 и время ответа приемлемое.
Мониторинг mount-ов с данными. Нужно настроить автоматическую проверку того, что на хосте примонтирован нужный сервису маунт, и что на этом маунте не кончилось место.



Сбор логов


Работоспособный кластер elasticsearch. Нужно собрать кластер elasticsearch под высокие нагрузки и большие объёмы (нагрузки на подсистему анализа логов во время миграции сильно превышают обычные наши нагрузки). Для этого нужно проверить физическое расположение ВМ кластера elasticsearch, конфигурацию самого кластера и JVM, настройки индексов и маппингов в elasticsearch/kibana.
Передача сообщений от приложения в elasticsearch без потерь. Требуется организовать устойчивый пайплайн: поменять fluentd на logstash (возможно - потвикать fluentd вместо этого), настроится все узлы elasticsearch, чтобы в случае отказа в одном писать в другой (вероятно это лучше, чем балансировщик), добавить очередь достаки логов, для того чтобы бороться с недостуностью elasticsearch без потери сообщений.
Включение логирования. Включить логирование в nginx, увеличить уровень логирования на основных компонентах (elasticsearch и система доставки должны справляться с нашим потоком).



Проблемы, вызванные системой деплоя


Смешивание стеков в docker-compose. Нужно подругому формировать docker-compose файл(ы), и раскладывать по директориям подругому.
Использование aufs. Нужно перейти к devicemapper + LVM thin pool.
Центральный docker registry. Нужен для организации пайплайнов разработки, тестирования и продакшена. До сих пор не работает, проблема с сертификатом и доменом.