Consolidando todos os processos com Supervisord e preparando-se para a engenharia do caos

Olá, sou um inútil.
Como vocês estão?
Ontem, saí para andar de bicicleta por um total de 6 horas, encontrando-me com amigos no caminho.

Como era um festival de jazz, caminhei pela cidade ouvindo música, e as roupas das pessoas mais velhas eram muitas vezes interessantes e inspiradoras.
A realidade das pessoas que saem e são vistas diretamente na cidade é mais verdadeira do que em fotos de rua, etc.

E então, como um amigo ia fazer massa à bolonhesa na casa dele, fomos ao Gyomu Super (supermercado atacadista) e decidimos tentar fazer com um macarrão super grosso chamado 'PRAI ネストパスタ'. Fizemos juntos e ficou incrivelmente delicioso.
Foi um dia em que fomos a lojas de roupas vintage, falamos sobre nossas impressões do Project Mirai, aprendemos sobre transporte ótimo e processamento de linguagem natural até cerca das 2 da manhã, e depois pedalei de volta por dezenas de quilômetros em minha bicicleta de pinhão fixo.

Introdução

A razão pela qual estou reestruturando meu ambiente de infraestrutura doméstica recentemente é porque quero usá-lo como um ambiente de teste para engenharia do caos, algo que me interessava há muito tempo.
Anteriormente, a Netflix lançou algo chamado ChaosMonkey, mas parece que esses macacos bifurcados agora estão em perigo de extinção.

Eles estão desaparecendo na velocidade de uma criptomoeda, mas, nesse meio tempo, existe um OSS chamado ChaosBlade que está sendo atualizado em tempo real. Eu quero executá-lo.
Este é um projeto implementado pela Alibaba Cloud da China, e há um resumo de onde ele está realmente implementado nos Issues.
Who is using ChaosBlade
Há pouca informação no Japão, mas a documentação é bem feita e os commits são feitos em tempo real, então deve ser utilizável.

Pretendo entrar em detalhes depois de começar a trabalhar nisso.

Inicialização do Daemon antes da migração para o Supervisord

Havia muitas coisas que eu nunca pensei que continuaria por tanto tempo.
Na verdade, eu os iniciava como um wrapper para scripts que eram escritos em rc.local do servidor e iniciados na inicialização.
Especificamente,

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 &  

Dessa forma, eu os iniciava fazendo com que cada aplicação fosse lançada a partir de um serverboot.sh que eu criei de forma desorganizada no diretório home do root.
Honestamente, é apenas a execução de um script, então se é correto chamar isso de wrapper ou não, deixemos de lado.

No entanto, como você deve ter percebido, com isso, os processos podem cair e os arquivos de log não são gerados individualmente.
Por isso, gerenciei tudo com Supervisord.

Depois disso

Com isso, mesmo que um processo caia por algum motivo, o Supervisor o reiniciará automaticamente e os logs serão gerados conforme configurado para cada um.
No total, são 8 processos.

Levou menos de uma hora para fazer, então eu deveria ter feito isso mais cedo, mas é assim que as coisas são. Afinal, somos humanos.

Outras coisas a fazer

Fazer balanceamento de carga com HA Proxy, para isso, eu precisaria de outro servidor, mas ter um segundo servidor em casa não faz muito sentido, então preciso encontrar um VPS barato de alguma forma.
A razão é que o risco do ambiente doméstico é alto devido a quedas de energia e outros riscos ambientais, então parece melhor ter o segundo servidor em um local completamente diferente.
A razão pela qual penso assim é que isso não se aplica apenas ao ambiente de servidor doméstico; lembro-me de uma grande falha na região US da AWS por volta de 2021. Ao investigar por que exchanges como a Binance estavam fora do ar, descobri que a causa era a AWS.
Ter uma configuração redundante na mesma região acaba sendo inútil.
Quedas de energia, ou o Google DC nos EUA, lembro-me de poder ver o interior no Youtube ou talvez no Google Map, e embora pareça algo que nunca aconteceria, nunca diga nunca.

Pode-se dizer 'Por que não usar Nginx para balanceamento de carga em vez de HA Proxy?', mas eu me lembro de ter visto isso no passado.
Razões pelas quais você nunca deve usar Nginx para balanceamento de carga
Além disso, se o servidor web e o balanceador de carga estiverem rodando no mesmo software, as coisas podem ficar confusas, então acho que usar HA Proxy é mais explícito e fácil de entender.

Mas, se me perguntarem se realmente faz sentido ter uma configuração redundante agora, a resposta é um completo NÃO. Usar software como ChaosMonkey para consumir recursos desnecessários na nuvem parece problemático, e fazer isso em nível de DNS também seria outra questão.
Vou pensar um pouco mais antes de executar o ChaosBlade.
Ainda não estou pronto para Get as informações do servidor durante a engenharia do caos, então, de certa forma, isso continuará como uma sequência.

Então. Até a próxima.