Como implementar o padrão de servidor imutável sem perder a capacidade de executar post-mortems?

O padrão imutável do servidor é uma disciplina de implantação que favorece a reprodutibilidade das implantações. É caracterizado pelo fato de que “ um servidor que uma vez implantado nunca é modificado, apenas substituído por uma nova instância atualizada ” e a implementação dessa disciplina exige uma automação da implantação do servidor. Essa automação possui inúmeras vantagens operacionais, uma das mais importantes é permitir a substituição rápida e confiável de instâncias com falha em uma infraestrutura. Essa automação também implica que a implantação do servidor seja descrita por artefatos de software com versão e esteja sujeita a aprimoramentos iterativos.

Um aspecto popular das implementações dessa disciplina é a remoção de métodos de acesso remoto ao servidor após o lançamento (especialmente remoção do acesso SSH). A remoção do acesso remoto é uma maneira fácil de garantir que a configuração do servidor corresponda à configuração preparada pela automação de implantação.

No entanto, ao investigar as causas de uma falha de software em um post-mortem , confiar no monitoramento estruturado nem sempre é suficiente e o acesso remoto à máquina pode ser necessário. É uma situação prática comum que o monitoramento do servidor não cubra todas as fontes de falha ou que o monitoramento pode ser prejudicado pela própria falha do servidor, o que provavelmente seria o caso se o servidor ficar sem memória ou atingir o limite do processo.

Como implementar o padrão de servidor imutável sem perder a capacidade de executar post-mortems?

Antes de tudo, remover o ssh em um servidor imutável não garante que não haverá alterações, é mais do que isso: como não deve haver necessidade de alterar algo, você reduz a superfície de ataque removendo um canal de acesso remoto.

Uma maneira de manter uma espécie de post-mortem é a centralização de logs. Há uma infinidade de métodos para alcançá-lo, pilha ELK, Splunk, syslog ...

Outra maneira mais grosseira de manter um post mortem para um servidor imutável é ter um script no processo de desligamento (uma falha imutável do servidor seria desligada e uma nova giraria para substituí-lo) para reunir um dump principal do programa, despejo de memória e envie-os para um sistema remoto para análise junto com a maioria dos logs.

A principal vantagem desta solução é que você recupera apenas informações do sistema com falha no momento do problema, permitindo coletar informações maiores do que obtê-las periodicamente.

É difícil ser mais específico sobre como conseguir isso, cada distribuição tem alguma maneira de obter as coisas e não tenho exemplo genérico.

O fato de você não ter acesso SSH não significa que não há como acessar a máquina. Provavelmente você o executará em algum operador de nuvem, onde você também pode fazer o seguinte:

• tire uma foto da máquina. Você pode simplesmente tirar um instantâneo da caixa antes de destruí-la, para análise posterior.
• acesse a máquina através do console. Você provavelmente precisará ter a senha de root para isso, mas alguns provedores de nuvem podem injetar uma senha de root aleatória para acesso ao console a qualquer momento.

Estes são essencialmente acesso "físico" à sua máquina e estarão disponíveis mesmo se você remover outros tipos de acesso. Você também pode limitar essas interfaces.

Além disso, como o @Tensibai disse, a melhor coisa a fazer é ter o registro e o monitoramento adequados configurados; portanto, sempre que você precisar fazer um post mortem, haverá dados suficientes disponíveis para isso.