Объединение всех процессов с помощью Supervisord и подготовка к хаос-инжинирингу
Привет, я бездарь.
Как у вас дела?
Вчера я катался на велосипеде в общей сложности 6 часов, по пути присоединившись к друзьям.
Был джазовый фестиваль, поэтому я гулял по городу, слушая музыку, и одежда пожилых людей была очень интересной и вдохновляющей.
Реальность людей, которых видишь на улице, гуляя по городу, правдивее, чем уличные снимки и тому подобное.
И поскольку друг собирался приготовить пасту болоньезе у себя дома, мы пошли в Gyomu Super (оптовый супермаркет) и решили попробовать приготовить ее с очень толстой лапшой под названием «PRAI Nest Pasta», и получилось невероятно вкусно.
Так что это был день, когда мы ходили в магазины винтажной одежды, делились впечатлениями от Project Mirai, узнавали об оптимальном транспорте и обработке естественного языка, болтали до 2 часов ночи, а затем я проехал десятки километров домой на своем фикс-байке.
Введение
Причина, по которой я недавно перестраиваю свою домашнюю инфраструктуру, заключается в том, что я хочу использовать ее в качестве тестовой среды для хаос-инжиниринга, которым я давно интересовался.
Раньше был такой проект, как ChaosMonkey, который Netflix выпустил первым, но, похоже, эти форкнутые обезьяны теперь находятся под угрозой исчезновения.
Они исчезают со скоростью, сравнимой с криптовалютами, но среди них есть OSS под названием ChaosBlade, который обновляется в реальном времени. Я хочу его запустить.
Это то, что внедряет китайская Alibaba Cloud, и информация о том, где оно фактически внедряется, собрана в Issues.
Who is using ChaosBlade
Информации на японском языке почти нет, но документация достаточно хорошо сделана, и она обновляется в реальном времени, так что ее можно использовать.
Я займусь деталями, как только начну работать над этим.
Запуск демонов до миграции на Supervisord
Было много вещей, которые я не ожидал продолжать так долго.
На самом деле, я запускал их, обернув скрипты, которые были записаны в rc.local сервера и запускались при старте.
В частности,
rc.local
$ sudo cat /etc/rc.local
[sudo] haturatu のパスワード`
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
#echo never > /sys/kernel/mm/transparent_hugepage/enabled
[ -d /etc/boot.d ] && run-parts /etc/boot.d
/root/serverboot.sh &
Таким образом, я запускал каждое приложение, используя serverboot.sh, который я небрежно создал в домашнем каталоге root.
Честно говоря, это просто запуск скрипта, так что вопрос о том, правильно ли называть это оберткой, оставим в стороне.
Однако, как вы, возможно, заметили, при таком подходе процессы могут падать, и файлы журналов не выводятся индивидуально.
Поэтому я управлял всем с помощью Supervisord.
После этого
Теперь, если процесс случайно упадет, Supervisor автоматически перезапустит его, и логи будут выводиться в соответствии с настройками для каждого процесса.
В общей сложности получилось 8 процессов.
Работа заняла меньше часа, так что я подумал, что стоило бы сделать это раньше, но так уж получилось. Ведь мы же люди.
Что еще нужно сделать
Например, использовать HA Proxy для балансировки нагрузки, но для этого нужен еще один сервер, а иметь второй сервер дома слишком бессмысленно, поэтому нужно найти какой-нибудь дешевый VPS.
Причина в том, что риски домашней среды, такие как отключение электроэнергии, высоки, поэтому мне кажется, что лучше иметь второй сервер в совершенно другом месте.
Я так думаю не только из-за домашней серверной среды, но и потому, что, насколько я помню, около 2021 года произошел крупный сбой в регионе US AWS. Когда я отслеживал, почему такие биржи, как Binance, не работали, оказалось, что причиной был AWS.
Использование избыточной конфигурации в одном и том же регионе в конечном итоге бессмысленно.
Сбои электропитания, или, например, я помню, что можно было посмотреть внутри Google DC в США через Youtube или Google Maps, и хотя это кажется абсолютно невозможным, если посмотреть, но это не значит, что этого никогда не произойдет.
Возможно, кто-то скажет: «Почему бы не использовать Nginx для балансировки нагрузки вместо HA Proxy?», но я помню, что видел это раньше.
Почему вы никогда не должны использовать Nginx для балансировки нагрузки
Кроме того, если веб-сервер и балансировщик нагрузки запускаются одним и тем же программным обеспечением, это может стать запутанным, поэтому я думаю, что использование HA Proxy будет более явным и понятным.
Но если спросить, имеет ли смысл сейчас создавать избыточную конфигурацию, то ответ будет категорически НЕТ, и использование бесполезных ресурсов в облаке с помощью такого программного обеспечения, как ChaosMonkey, может вызвать проблемы, а если делать это на уровне DNS, то это тоже...
Я подумаю еще немного, а затем запущу ChaosBlade.
Я еще не готов получать информацию с сервера во время хаос-инжиниринга, так что в некотором смысле это продолжение.
На этом все. До новых встреч.