Как сейчас выглядит нормальная система сборки / мониторинга?
Здравствуйте! Веб-роект в котором тружусь, развивается и стало у нас как-то тяжко с системой развёртывания. Сейчас раскатываюсь shell-скриптами по ssh, собирая проект из нескольких гит-репо (фронт, бэк, пара лендингов и тд, лежащих отдельно), и сохраняя коммитом в отдельную ветку новую сборку перед деплоем.
Окружение самое простое, несколько голых vps с ubuntu от DO. Там крутится нода под присмотром pm2, между собой сервисы общаются по tcp. Да, не монолит. Периодияески одной из убунт хочется больше внимания и она обеспечивает мне пару незабываемых часов.
При ошибке в тестировании на препрод- инстансах (на которое иногда, конечно, кладется болт) или любых других проблемах со сборкой я ничем не защищён, не могу даже востановить предыдущую сборку и окружение в точности - ибо нет виртуализации/контейнеризации и состояние ОС меняется от сборки к сборке (пример - новая зависимость, требующая глобальной установки).
С ностальгией вспоминаю времена, когда приложение было маленьким MVP и хостилось на PaaS heroku.
Пожалуйста, подскажите к каким инструментам начинать читать спеку в первую очередь? Хочу позаимствовать у heroku фичу "безопасной авто сборки по пушу в мастер с автороллбэком при любой проблеме". И с командой "откатиться вот к этой сборке" которая на Heroku даже выведена в
GUI.
Чем сейчас умные люди пользуются, когда решают такие задачи? Направление мыслей следующее:
- Health checking слоя бизнес-логики. Сейчас все ограничивается pm2, который перезапускает упавшее приложение и сам стоит в автозагрузке ОС хоста. Хотелось бы связать health checking с развертыванием, чтоб откатываться автоматом если приложение поднимается криво, а среда - в порядке. Сейчас я вручную реагирую на алерты в телеграм от Uptime Robot.
- Docker для контейнеризации. Версионируемый итоговый образ должен включать в себя только мой код или еще и какой-нибудь node:latest (который, вроде, сам включает debian)? В последнем случае образ будет весить 900мб, при объеме клиентского кода в сотни кб - смешно. По идее, надо хранить только инструкции для docker, да? Это dockerfile в моем случае?
- Собственно, версионирование на основе гит-репо с исходным кодом и образом / инструкциями для docker. Писать скрипт для управление этим добром самому и запускать в отдельном vps или разбираться с каким-нибудь gitlab?
Как решать проблемы с самим хостом, если ОС вдруг устанет? Есть какие-то средства для мониторинга, которые могут перезагрузить / пересоздать VPS (хостинг сейчас do, но мы не привязаны).
Знаю, что в мире есть chef, puppet, k8s (и managed k8s, хех). Что-то из этого отвечает задаче на 100%, чтоб сконцентрироваться на изучении и за 2-3 недели получить продакшн-риди результат? Учусь быстро.
Забыл. Если мы пересоздаем VPS и он получает новый IP в локалке (private network), нужно передать этот IP в env для других сервисов. Получается, нужен какой-то централизованный env для моих скриптов?
Мне кажется вашей задаче отвечает любые инструменты для автоматизации развертывания, будь-то богом забытый chef, ansible или что-то еще. Если хоститесь в ДО есть смысл наверное попробовать их кубернетес сервис, это сейчас самое популярное решения для инфраструктуры, правда ее итоговая стоимость вырастет на порядок.
Либо посмотреть в сторону aws, у них есть например штука для развертывания elastic beanstalk, да и вообще есть практически все что надо для любого приложения, включая тот же кубернетес) К тому же у авса есть хорошие программы для стартапов, нам например давали 20к на два года на попробовать без каких-либо обязательств.
EchoStan, насчет managed от do не знаю, не трогал. А в целом, просто инфраструктура становится сложнее, появляется больше элементов чем node+pm2, больше элементов - больше ресурсов.
ИМХО, основные затраты на K8S это время - на изучение, имплементацию, отладку и т.д.
Не думаю, что при правильной архитектуре это удорожит инфраструктуру. Конечно если мы не говорим от ситуации, когда "сегодня все бежит на одном сервере за $10"
hOtRush, EchoStan, стоимость managed k8s в DO = стоимость рабочих узлов (на которых крутятся приложения, запускаемые в кластере), мастер-узлы с etcd предоставляет хостинг бесплатно (а они внезапно жрут больше и с жёсткими требованиями по отказоустойчивости).
Пример потребления ресурсов кластерными процессами на узле одного живого кластера: до 40% одного ядра Xeon на 2.3ГГц суммарно на всё нижеперечисленное, оперативка: kubelet - 450МБ (на узле 70 подов/137 контейнеров, больше подов → больше горутин → больше памяти), dockerd - 120МБ, calico - 96МБ, отправитель логов - 100МБ, итого чуть меньше 800. Всё остальное будет в вашем полном распоряжении (до той поры, пока oomkiller не разлучит вас).
chupasaurus, спасибо, что и здесь поделились опытом. С меня тогда новый глупый вопрос: если несколько контейнеров с разными сервисами проекта живут на одном VPS DO, больше ли вероятность падения всего сразу из-за падения ОС? Или это из области фантастики. Сейчас 7-15 сервисов раскиданы по $5 VPS
hOtRush, Vitaly Karasik, в таком случае вопрос немножко холиварный - а я потяну вообще managed k8s и облегчит ли он мою участь? И так уже фуллстечу этот проект (веб, 120-150к строчек суммарно) в одно лицо. В принципе, нормальная для меня нагрузка, но хочется бонусов от автоматизации в краткосрочной перспективе, хотя бы через 2-3 месяцы.
EchoStan, Честно говоря, не знаю. Мой стандартный ответ на большинство вопросов "зависит".
больше ли вероятность падения всего сразу из-за падения ОС
Нет. K8S умеет переносить аппликации на здоровый node (server) в таком случае.
а я потяну вообще managed k8s и облегчит ли он мою участь?
Я бы начал с "маленьких шагов" - без K8S, просто сделать более надежный CI/CD, с rollback и т.д.
Это возможно и без контейнеров.
Насчет автоматического rollback - можно деплоить предыдущую версию по тому же алерту.
Health checking - метрики на проверку выводить по отдельному URL и мониторить. Если есть возможность сделать бинарную метрику, отдающую HTTP 200/500, то в докер/cri-o/прочие рантаймы сами умеют отслеживать статус.
Docker-образ состоит из манифеста, в котором описываются экспортированные порты, анонимные тома и метаданные, а самое главное - список слоёв с данными. При обновлении с использованием Docker Registry вместо копирования блоба уже присутствующие слои скачиваться не будут.
IaaC же. Dockerfile + билдскрипты если надо в коде + сборочная система. Образы хранить в Registry крайне удобно, можно задавать теги по id коммита если надо прям прибивать к VCS.
Есть 2 путя: внешний мониторинг + система управления конфигурациями (первая пушит по алерту во вторую, которая создаёт сбоку новый сервер и глушит сбойный) или оркестратор, который сам разруливает подобные проблемы.
Про введение новых серверов: env ни разу не динамический, для этой цели используют динамические DNS-сервера (оборачивая красивым названием Service Discovery), балансировщики и очереди сообщений.
Примеры решений из личной практики. Без оркестратора: в AWS можно реализовать на SNS + Autoscaling, универсально - на Prometheus/Alertmanager или Zabbix или Nagios, которые будут запускать алертами джобы в Ansible Tower (его опенсурс версия AWX идёт со всеми фишками Enterprise-версии), но лучше всё же иметь что-то между для большего контроля над происходящим. С k8s всё проще: под Prometheus уже всё есть, сама система отслеживает потребление ресурсов и можно задавать лимиты по процу/оперативной памяти, только настроить масштабируемость рабочих узлов, но есть маленький ньюанс - у вас всё уже должно быть контейнеризовано; в DO кстати весьма адекватный managed кластер.
chupasaurus , здравствуйте и спасибо за развёрнутый ответ.
1) Метрика уже бинарная, чекеры бизнес-логики, consistency т.д. обёрнуты в http. Что посоветуете для первых домашних поделок с k8s, докер или cri-o? Мнения коммьюнити я не понял, тенденции на замещение тоже не уловил.
2) и 3) Посчёт Registry. Я так понял это вполне живой пакетный-менеджер с vcs. Почему-то сначала показалось, что by default он открытый всему миру, а не in-house. Но, думаю, умеет же быть приватным, да? Наверное, глупый вопрос.
4) и 5) Насколько слышал, docker умеет разруливать запросы между контейнерами, а несколько контейнеров на разных машинах объединяются нативно средствами docker или это уже к k8s?
6) Самый важный вопрос: контейнеризовано == обёрнуто в docker-образы? Пока кажется, что k8s будет хорошей серебряной пулей, лишь бы не оказалось у неё слишком вязкого сердечника =)
Cri-o чуть более легковесный и избавляет от ряда сложностей с Docker. Используйте что нравится, сам рантайм можно поменять. Я только из любопытства дёргал информацию из рантайма, сам к8с позволяет забыть о его существовании после установки (этот процесс меняется в зависимости от того, что на хостах).
Docker Registry естественно может быть self-hosted. Мы у себя пользуемся Harbor, проблем не испытывали. Едлинственный момент - актуальная версия API требует TLS, а значит валидного сертификата.
Docker как runtime - разруливает всё внутри одного хоста, оркестраторы Docker Swarm/k8s - на уровне кластера.
Это означает "приложение собирается и запускается в виде контейнера".
monit-it.ru
Для старта пойтет вот это
из особенностей
поддержка плагинов nagios
и главное, подключается по ssh и может выполнить команду вернуть себе код сделать выводы.
Ну и особо важное при алиарде можно выполнить консольную команду.
А главное это хрень облачное и не нужно следить за самой системой мониторинга.
Для мониторинга инфроструктуры яндекс явно не пойдет, а вот для своих проектов нормально.
Я монитрю в ней окол 20 серверов, 600 сайтов, в принципе хватает.
А главное как вы и просили минимальный уровень входа.
Честно говоря я бы не советовал какие-то платные ноунейм решения от каких-то российских ноунейм разработчиков, особенно когда в 2019 просто гигантский выбор решений для мониторинга, будь то elk-стэк, zabbix, grafana или что-то еще.
Ну и ~600/20 как бы наводит на мысль что сайтики по 30 штук на сервер мониторить одно, а большой распределенный проект - другое
hOtRush,
соотношение цена-качество и уровень входа как всегда ;(
Мне к примеру grafana не нравится, у меня все скрипты свои порой очень специфические, ну и полу интелектуальные решения для востановления работоспособности.
Скорее по 100 на сервера, а вот остальные там уже в зависимости от проекта, принципиально не держу говножелезо
И опять же вопрос должен быть в первую очередь коммерчески обоснован
В задаче ничего не стоит о объемах, однако я сразу написал что "большие проекты" а это не 20К в день, действительно нужно мониторить достаточно серьезно.
Но я не думаю что человек у которого есть сервис с 300К в день, спрашивает чем простеньким ему мониторить сервера.
zabbix хорош но для двух серверов смысл от него какой?
EchoStan, оснавная задача мониторинга это стабильность !!!
если он не стабилен толку от него даже самого крутого нет
как следствие это
1. незвисмыый сервер, желательно облако !
2. собственно сами настройки.
Если вы опишете размер проекта то будет проще выбрать решение.
Так же что именно вам нужно мониторить
Вот мне важно например на одном сервере где 200 сатов мониторить валидность выдачи https сертификатов Letseycrypt для сайтов заблаговременно выдавать алиард в случае проблеммы.
А для другого проекта мне нужно мониторить соответствие кода 200 , и не нулевого размера файла изображений пришедших с выгрузкой и даже при условие валидного завершения.
В общем от задач плясать тоже приходится.
1. Положить всё в докер. Гуглятся турториалы минимальных контейнеров alpine в зависимости от фреймворка
2. Тесты делать без деплоя в каком-нибудь gitlab-ci
3. Оркестрация самая простая swarm из коробки самого докера
