事後分析を実行する機能を失うことなく、不変サーバーパターンを実装する方法は？

不変サーバーパターンは、デプロイメントの再現性を優先するデプロイメントの分野です。これは、「一度デプロイされたサーバーは決して変更されず、単に新しい更新されたインスタンスに置き換えられる」という特徴があり、この規律を実装するにはサーバーのデプロイメントの自動化が必要です。この自動化には多くの運用上の利点があります。最も重要なものの1つは、インフラストラクチャ内の障害のあるインスタンスを迅速かつ確実に交換できるようにすることです。この自動化は、サーバーの展開がバージョン管理されたソフトウェアアーティファクトによって記述され、反復的な改善の対象となることも意味します。

この分野の実装の一般的な側面は、サーバーが起動された後のリモートアクセスメソッドの削除です（特にSSHアクセスの削除）。リモートアクセスを削除することで、サーバーの構成を、展開の自動化によって準備された構成と確実に一致させることができます。

ただし、事後分析でソフトウェア障害の原因を調査する場合、構造化された監視に依存するだけでは必ずしも十分ではなく、マシンへのリモートアクセスが必要になる場合があります。サーバーの監視がすべての障害の原因を網羅していない、またはサーバーの障害自体によって監視が損なわれる可能性があるのは一般的な実際の状況です。

事後分析を実行する機能を失うことなく、不変サーバーパターンを実装する方法は？

まず第一に、不変サーバーでsshを削除しても変更がないことは保証されません。リモートアクセスチャネルを削除して攻撃対象を減らすものを変更する必要がないためです。

一種の事後分析を維持する1つの方法は、ログの集中化です。ELKスタック、Splunk、syslogなど、それを実現する方法は無数にあります...

不変サーバーの事後分析を維持するためのもう1つのより大雑把な方法は、シャットダウンプロセスにスクリプトを置き（不変サーバーに障害が発生するとシャットダウンし、新しいサーバーを起動して置き換える）、プログラムのコアダンプを収集することです。メモリダンプし、ほとんどのログと一緒に分析のためにリモートシステムに送信します。

このソリューションの主な利点は、問題の発生時に障害のあるシステム情報のみが返されるため、定期的に取得するよりも大きな情報を収集できることです。

これを達成する方法をより具体的にすることは難しく、各ディストリビューションには何かを取得する方法がいくつかあり、私には一般的な例はありません。

SSHアクセスがないことは、マシンにアクセスする方法がないことを意味するものではありません。ほとんどの場合、それをクラウドオペレーターで実行することになります。この場合、次のことも実行できます。

• マシンのスナップショットを撮ります。後で分析するために、破棄する前にボックスのスナップショットを撮るだけで済みます。
• コンソールからマシンにアクセスします。これにはrootパスワードが必要になる可能性がありますが、一部のクラウドプロバイダーは、コンソールアクセス用にランダムなrootパスワードをいつでも挿入できます。

これらは基本的にはマシンへの「物理的な」アクセスであり、他のタイプのアクセスを削除した場合でも使用できます。ただし、これらのインターフェースを制限することもできます。

@Tensibaiが言ったようにこれとは別に、適切なロギングとモニタリングを設定することをお勧めします。そのため、事後分析を行う必要があるときはいつでも、それを行うのに十分なデータが利用可能です。