@EchoStan

Как сейчас выглядит нормальная система сборки / мониторинга?

Здравствуйте! Веб-роект в котором тружусь, развивается и стало у нас как-то тяжко с системой развёртывания. Сейчас раскатываюсь 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 недели получить продакшн-риди результат? Учусь быстро.
  • Вопрос задан
  • 383 просмотра
Пригласить эксперта
Ответы на вопрос 3
chupasaurus
@chupasaurus
Сею рефлекторное, злое, временное
Много вопросов, много ответов.
  1. Health checking - метрики на проверку выводить по отдельному URL и мониторить. Если есть возможность сделать бинарную метрику, отдающую HTTP 200/500, то в докер/cri-o/прочие рантаймы сами умеют отслеживать статус.
  2. Docker-образ состоит из манифеста, в котором описываются экспортированные порты, анонимные тома и метаданные, а самое главное - список слоёв с данными. При обновлении с использованием Docker Registry вместо копирования блоба уже присутствующие слои скачиваться не будут.
  3. IaaC же. Dockerfile + билдскрипты если надо в коде + сборочная система. Образы хранить в Registry крайне удобно, можно задавать теги по id коммита если надо прям прибивать к VCS.
  4. Есть 2 путя: внешний мониторинг + система управления конфигурациями (первая пушит по алерту во вторую, которая создаёт сбоку новый сервер и глушит сбойный) или оркестратор, который сам разруливает подобные проблемы.
  5. Про введение новых серверов: env ни разу не динамический, для этой цели используют динамические DNS-сервера (оборачивая красивым названием Service Discovery), балансировщики и очереди сообщений.
  6. Примеры решений из личной практики. Без оркестратора: в AWS можно реализовать на SNS + Autoscaling, универсально - на Prometheus/Alertmanager или Zabbix или Nagios, которые будут запускать алертами джобы в Ansible Tower (его опенсурс версия AWX идёт со всеми фишками Enterprise-версии), но лучше всё же иметь что-то между для большего контроля над происходящим. С k8s всё проще: под Prometheus уже всё есть, сама система отслеживает потребление ресурсов и можно задавать лимиты по процу/оперативной памяти, только настроить масштабируемость рабочих узлов, но есть маленький ньюанс - у вас всё уже должно быть контейнеризовано; в DO кстати весьма адекватный managed кластер.
Ответ написан
monit-it.ru
Для старта пойтет вот это
из особенностей
поддержка плагинов nagios
и главное, подключается по ssh и может выполнить команду вернуть себе код сделать выводы.
Ну и особо важное при алиарде можно выполнить консольную команду.
А главное это хрень облачное и не нужно следить за самой системой мониторинга.
Для мониторинга инфроструктуры яндекс явно не пойдет, а вот для своих проектов нормально.
Я монитрю в ней окол 20 серверов, 600 сайтов, в принципе хватает.
А главное как вы и просили минимальный уровень входа.
Ответ написан
inf
@inf
DevOps Engineer
1. Положить всё в докер. Гуглятся турториалы минимальных контейнеров alpine в зависимости от фреймворка
2. Тесты делать без деплоя в каком-нибудь gitlab-ci
3. Оркестрация самая простая swarm из коробки самого докера

зы 2-3 недели маловато будет))
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы