Развертывание Linux при помощи Cobbler
service tftp
<
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
disable = no
per_source = 11
cps = 100 2
flags = IPv4
> Возможна аутентификация через веб-интерфейс несколькими способами: пароль, созданный утилитой htdigest (сохраняется в файле /etc/cobbler/users.digest), Kerberos, LDAP, Spacewalk/Satellite и тестовый (используется для отладки, всегда testing/testing). Но в настройках по умолчанию аутентификация через веб-интерфейс блокирована. Разрешим ее, для примера будем использовать digest-файл. Для чего в файле /etc/cobbler/modules.conf меняем значение параметра module в секции authentication: [authentication]
# module = authn_denyall # блокировка аутентификации
module = authn_configfile По умолчанию логин и пароль для регистрации – cobbler/cobbler. Его следует изменить при помощи команды: # htdigest /etc/cobbler/users.digest «Cobbler» cobbler Теперь – очередь шаблонов сервисов, которые находятся в каталоге /etc/cobbler в файлах с расширением .template. По своей структуре они соответствуют аналогичным файлам, в которых производятся настройки сервисов. Подробно структура некоторых из них описана в статье Андрея Маркелова [1]; кроме этого, шаблоны в файлах уже настроены (на сеть 192.168.1.0/24), и необходимо лишь уточнить текущие сетевые настройки – в частности, IP-адреса DNS-сервера, шлюза. Причем в файлах используются переменные, и в результирующих конфигурациях будут уже осуществлены подстановки из настроек текущей системы: например, /etc/cobbler/dhcp.template: # nano /etc/cobbler/dhcp.template
- Маркелов А. Создаем сервер сетевой установки Fedora/RHEL. //Системный администратор, №11, 2008 г. – C. 34-36.
- Сайт проекта Сobbler – https://fedorahosted.org/cobbler.
- Сайт проекта Ultimate Deployment Appliance – http://www.ultimatedeployment.org.
- Сайт проекта Quattor – http://sourceforge.net/projects/quattor.
- Сайт проекта FAI – http://www.informatik.uni-koeln.de/fai.
- Сайт проекта Spacewalk – http://www.redhat.com/spacewalk.
- Сайт проекта Symbolic – http://www.opensymbolic.org.
- Яремчук С. Централизованная настройка UNIX-систем с помощью Puppet. //Системный администратор, №7, 2007 г. – C. 58-61.
Как я автоматизировал разворачивание приложений на Linux на коленке с помощью Bash скриптов и Java
Когда вы написали серверное приложение, его нужно где-то развернуть. У нас в компании сейчас это реализовано с помощью 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. Но пока пришел к выводу, что текущая система более чем достаточна.
Любую систему нужно поддерживать, а чем система проще — тем проще ее поддержка. Я люблю простые и понятные решения, и не хочу слепо использовать технологии лишь из-за того, что они на слуху. Если команда разработки вырастет, и нас перестанет устраивать текущий подход — тогда задумаемся о его изменении, но не раньше.
Путь тимлидера
Как я уже упоминал, я сейчас руковожу отделом разработки. Это очень отличается от того, когда просто пишешь код. Нужно ставить задачи, определять их приоритетность, задумываться не только о технической, но и о бизнес части. Код при этом писать тоже нужно, пусть и меньше.
Нужно учитывать временные и финансовые ограничения. Учитывать особенности каждого разработчика. Я сейчас читаю много тематичной литературы, из последних прочитанных за месяц книг — «Как пасти котов», «Я, нерды и гики», «Программист-праграматик», «Роман о управлении проектами».
Это интересный и новый для меня путь. Я прохожу его, описывая свой прогресс в своем Телеграм канале — Программист и бизнес.
Пишу о бизнесе с точки зрения разработчика. Туда выкладываю короткие заметки, которые не подходят хабру по формату.