タグ付けされた質問 「immutable-servers」

不変のサーバーについては、次のような質問があります。 事後分析を行う能力を失うことなく、不変のサーバーパターンを実装する方法は？ 構成管理ツールは、不変のインフラストラクチャでどのような役割を果たしますか？ サーバー（私が得た部分）に関係していることは明らかです。そして不変の文法を消化するだけで、「ミュートすることは不可能」と関係があると思います。その推測が近い場合、私は正確にミュートすることができないものの手掛かりを持っていないだろう（と私はそれがサウンドカードまたは何かに関係しているとは思わない...）。 私の質問： （DevOpsのコンテキストで）実際に「不変サーバー」とは何ですか？ なぜ使用されるのですか？

23 terminology  immutable-servers 

不変のサーバー/コンテナを使用している場合、Chef、Puppet、Ansible、Saltなどのツールが必要ですか？これらの構成管理ツールは、構成を確立してから維持するように設計されています。 不変サーバーを展開する場合、構成管理ツールは初期プロビジョニングにのみ使用する必要がありますか？

12 containers  immutable-servers 

不変サーバーパターンは、デプロイメントの再現性を優先するデプロイメントの分野です。これは、「一度デプロイされたサーバーは決して変更されず、単に新しい更新されたインスタンスに置き換えられる」という特徴があり、この規律を実装するにはサーバーのデプロイメントの自動化が必要です。この自動化には多くの運用上の利点があります。最も重要なものの1つは、インフラストラクチャ内の障害のあるインスタンスを迅速かつ確実に交換できるようにすることです。この自動化は、サーバーの展開がバージョン管理されたソフトウェアアーティファクトによって記述され、反復的な改善の対象となることも意味します。 この分野の実装の一般的な側面は、サーバーが起動された後のリモートアクセスメソッドの削除です（特にSSHアクセスの削除）。リモートアクセスを削除することで、サーバーの構成を、展開の自動化によって準備された構成と確実に一致させることができます。 ただし、事後分析でソフトウェア障害の原因を調査する場合、構造化された監視に依存するだけでは必ずしも十分ではなく、マシンへのリモートアクセスが必要になる場合があります。サーバーの監視がすべての障害の原因を網羅していない、またはサーバーの障害自体によって監視が損なわれる可能性があるのは一般的な実際の状況です。 事後分析を実行する機能を失うことなく、不変サーバーパターンを実装する方法は？

12 immutable-servers  post-mortem 

DevOpsの多くは、不変のインフラストラクチャを実装し、変更が必要な場合に（変更するのではなく）再展開することで、ペットではなく牛の考え方を適用しています。 構成管理には、べき等の同様の原則があります。不変性と無力の比較の利点、類似点、欠点は何ですか？どちらがより効率的ですか？これらを相乗的に使用できますか（例：構成管理を使用したVMまたはDockerコンテナーの定期的な削除と再デプロイ？）

8 configuration-management  immutable-servers  cattle-vs-pet 

Terraformを使用してインフラストラクチャの展開を自動化し、Packerを使用してTerraformによって展開されるマシンイメージを作成します。不変のインフラストラクチャ設計原則に従って、パッチが適用された新しいイメージを作成してパッチを実装し、インフラストラクチャを再展開します。 この設定で、ベースイメージ内のパッケージまたはOS自体を更新してビルドパイプラインをトリガーする必要があるときを自動的に検出するために使用できる追加のツールはありますか？ Chef Automateは私が探しているものに近いようですが、イメージマニフェスト自体を分析するのではなく、実行中のノードのコンプライアンスをスキャンするようです。 ありがとう！

7 chef  terraform  infrastructure-as-code  packer  immutable-servers