Когда вы написали серверное приложение, его нужно где-то развернуть. У нас в компании сейчас это реализовано с помощью VPS на Linux, bash скриптов, и небольшой Java программы. Это эволюционный процесс, и как по мне, получилось весьма неплохо.
В статье я хочу описать эволюцию такого подхода, почему так получилось, плюсы и минусы подхода. Если у вас есть похожая проблема — почитайте, возможно придут в голову полезные мысли.
КДПВ — архитектура системы, для части которой автоматизируем развертывание:
Немного предыстории
Я сейчас являюсь руководителем отдела разработки в компании, где я работаю. У нас небольшая, но сбалансированная команда — есть бекенд, фронтенд разработчики, QA, дизайнер, верстальщик.
Наша компания занимается образовательной деятельностью в IT, и софт мы пишем для себя. Это накладывает определенные ограничения — у нас нет огромных бюджетов на разработку, бывают размытые требования, потому что не до конца понятно, что же нужно людям.
В то же время, есть плюсы — пишем на чем хотим, и можем сами ставить и согласовывать сроки разработки. Также, поскольку пилим не стотысячный лендинг или интернет магазин, работать интересно. Развиваем несколько продуктов, собираем фидбек пользователей, и фиксим/добавляем фичи.
Таким образом, мы сами выбираем стек технологий, процесс развертывания приложений.
Архитектура системы
Один из наших продуктов имеет следующую архитектуру:
Есть один главный бекенд — центр. Именно к нему стучатся все фронтенды (их несколько). На главном бекенде хранятся данные юзеров, и сосредоточено большинство бизнес-логики.
Также есть несколько вспомогательных бекендов, которые физически вынесены на разные серверы. Сделано так по нескольким причинам:
- эти сервера запускают внешний непроверенный код. Следовательно, никаких данных там хранить нельзя, потому что рано или поздно внешний код выберется из песочницы;
- вспомогательные бекенды довольно нагруженные, именно они делают основную работу. Главный бекенд умеет распределять нагрузку, и в случае чего — мы добавляем еще вспомогательные бекенды для размазывания нагрузки.
- на вспомогательных бекендах используются разные технологии. Есть java, node.js, python.
Также особенность вспомогательных бекендов — их часто нужно перезапускать, потому что находятся различные мелкие правки (по большей части markdown файлов). Перезапуск такого вспомогательного бекенда никак не отражается на работе всей системы.
Я бекенд разработчик, написал главный бекенд, несколько вспомогательных. И я прошел велосипедный процесс автоматизации разворачивания вспомогательных серверов. Я разбил его на условные уровни.
Level 1
Все начиналось просто. Захожу по SSH на VPS, выкачиваю изменения с git, делаю mvn build, ну или npm i, дальше java -jar или выполняю другую команду для поднятия сервера.
Ничего не автоматизировано, все вручную. Частота — несколько раз в день.
Level 2
По происшествию какого-то времени я понял, что времени этот процесс занимает слишком много. Я ввожу дофига паролей от гитхаба и т.д.
Окей, в gihub добавляю SSH ключ VPS. Теперь git pull, не ввожу пароли. Вроде мелочь, но стало быстрее.
Level 3
И все же получается долго. Даже не так долго, как скучно.
Окей, пишу bash скрипт. В скрипте несколько команд:
- git pull, чтобы вытянуть последние изменения
- mvn package — делаем fatjar (описываю Java)
- pkill yourserverprocessname — убиваем текущий процесс
- java -jar yourfatjar.jar
Теперь мне нужно зайти на VPS, сделать cd ~/git/repository_name, и выполнить скрипт — ./deploy.sh
Level 4
Раз у нас есть один скрипт, почему не вызывать его удаленно?
Не забывайте, что все вращается на дешевых VPS. Поднимать что-то сложное я не хочу. Ищу простой сервер на C — чтобы занимал минимум ресурсов. Нахожу, пытаюсь пофиксить под свои нужды — не получается быстро. Я писал на C десять лет назад, и понимаю, что помню только синтаксис, но работу с сетью, сокетами забыл напрочь.
Окей, делаем возврат к Java. На коленке набрасываю сервер из нескольких десятков строк кода. Использую встроенный HttpServer. Умеет принять GET и POST запрос, вытянуть параметр token, если параметр правильный — запустить указанный bash скрипт.
Запускаю все это чудо.
Теперь на каждом VPS вращается две программы. Одна основная. Другая — вспомогательная, для перезапуска основной.
Итог — когда что-то поменяли на вспомогательном бекенде, просто переходим по определенному URL, выполняется bash скрипт, и сервер перезапускается с обновленным кодом.
Level 5
Остается последний шаг.
Открываю github, нахожу настройки webhook для нужных репозиториев. Смысл в том, что когда мы делаем определенное действие (push, etc) — github умеет дернуть указанный для этого репозитория URL. Точнее — отправить POST запрос по указанному адресу с параметрами события.
Я настроил webhook на любой push. Дергается именно тот URL, который делает обновление и рестарт сервера.
Теперь, если мы делаем git push, через минуту мы имеем обновленный и перезапущенный сервер.
Level 6 (bonus)
Как я уже упоминал, иногда вспомогательные бекенды падают. На них пользователи исполняют недоверенный код. Пусть и в песочнице, но тот же node.js все же иногда валится.
Для нас падение некритично, при условии что сервер быстро поднимется.
Окей, я начинаю искать сервисы для мониторинга доступности серверов. Нахожу UptimeRobot. По описанию все выглядит весьма прилично:
- раз в пять минут мониторит доступность указанного адреса
- если адрес недоступен — делает то или иное действие (отправляет POST/GET запрос, шлет оповещение по электронной почте и т.д.).
Прямо то что нужно! Настраиваю мониторинг, добавляю действие — если сервер упал, то дернуть URL перезагрузки. Также добавляю Телеграм бота, чтобы он оповещал команду о падении и восстановлении серверов.
Какое-то время работает нормально. Потом оказывается, что UptimeRobot мониторит нифига не раз в пять минут. Сервер упал, прошел час или что-то вроде того, и только тогда он обнаруживает падение.
Час — это долго. На коленке на Spring Boot набрасываю решение, аналогичное UptimeRobot, но сильно урезанное. Раз в минуту мониторим указанные адреса, если адрес недоступен — шлем оповещение про падение/поднятие сервера, ну и перезапускаем сам сервер.
В Телеграм канале, где есть все разработчики, видим вот такое:
Такое наколенное решение работает уже больше месяца, пока проблем не замечал.
Плюсы решения
Главный плюс описанной выше системы — простота. Примитивные bash скрипты с минимумом логики.
Все уровни автоматизации накладываются один на другой, и верхние слои зависят от нижних, но не наоборот. В любой момент можно откатиться на уровень вниз, и ничего не поломается.
Минусы решения
Главный минус — хрупкость.
Что, если не при каждом push на github мы хотим перезапускать сервер?
Что, если мы сделали push, а код не компилируется?
В некоторой мере эти минуса нивелируются малым количеством разработчиков, работающим над бекендом. Мы привыкли к этой системе, знаем ограничения. Поскольку даже такая автоматизация сильно упрощает работу, мы живем с этим.
По нормальному это решается CI/CD системой. Где код вначале проходит тесты, и лишь если все ок — доставляется на production.
Следуюет учесть, что мы начинали, и до сих пор частично находимся в стадии MVP. То есть, на данном этапе важно быстро выкатить продукт, собрать фидбек. Но сейчас потихоньку переходим в стадию, когда продукт начинает немного зарабатывать деньги, и ощутимо — экономить. Поэтому я задумываюсь про описанные выше минусы, и прикидываю способы их устранения.
Куда двигаться дальше?
Скорей всего, указанные выше минуса решатся довольно просто. В Java, при сборке Maven проекта, сначала прогоняются юнит тесты, потом собирается jar. Если тесты не проходят, либо же ошибка компиляции и билд не собрался — мы про это узнаем.
Поэтому нужно слегка дофиксить bash скрипт, чтобы он лишь в случае успешной сборки билда (появился .jar файл после mvn package) убивал текущий процесс и пытался запустить новый. Что-то похожее можно сделать и для node.js — если тесты не прошли, ничего не перезапускаем.
Также нужно вынести вебхук из github на внешний сервер, и обновлять сервер по определенным условиям (например, запланировать обновление на ночь, когда пользователей меньше).
Я думал про взрослые CI/CD системы, типо Jenkins, Gitlab, софт вида Ansible. Но пока пришел к выводу, что текущая система более чем достаточна.
Любую систему нужно поддерживать, а чем система проще — тем проще ее поддержка. Я люблю простые и понятные решения, и не хочу слепо использовать технологии лишь из-за того, что они на слуху. Если команда разработки вырастет, и нас перестанет устраивать текущий подход — тогда задумаемся о его изменении, но не раньше.
Путь тимлидера
Как я уже упоминал, я сейчас руковожу отделом разработки. Это очень отличается от того, когда просто пишешь код. Нужно ставить задачи, определять их приоритетность, задумываться не только о технической, но и о бизнес части. Код при этом писать тоже нужно, пусть и меньше.
Нужно учитывать временные и финансовые ограничения. Учитывать особенности каждого разработчика. Я сейчас читаю много тематичной литературы, из последних прочитанных за месяц книг — "Как пасти котов", "Я, нерды и гики", "Программист-праграматик", "Роман о управлении проектами".
Это интересный и новый для меня путь. Я прохожу его, описывая свой прогресс в своем Телеграм канале — Программист и бизнес.
Пишу о бизнесе с точки зрения разработчика. Туда выкладываю короткие заметки, которые не подходят хабру по формату.
