web-dev-qa-db-ja.com

構成管理：プッシュベースとプルベースのトポロジ

PuppetやChefなどのより確立された構成管理（CM）システムは、プルベースのアプローチを使用します。クライアントは、集中型マスターを定期的にポーリングして更新を確認します。それらのいくつかはmasterlessアプローチも提供します（したがって、プッシュベース）が、それは「本番環境ではない」（Saltstack）または「スケーラブルではない」（人形）。私が知っている唯一のシステムは、最初からプッシュベースで、次点のAnsibleです。

プルベースのシステムに固有のスケーラビリティの利点は何ですか？なぜプッシュエージェントよりもプルマスターを追加する方が簡単なのでしょうか？

たとえば、 agiletesting.blogspot.nl は次のように書き込みます。

「プル」システムでは、クライアントは互いに独立してサーバーに接続するため、システムは「プッシュ」システムよりも全体としてスケーラブルです。

一方、Rackspaceは、プッシュベースのモデルで 15Kシステムを処理 できることを示しています。

infastructures.org 書き込み：

私たちは、SUP、CVSup、rsyncサーバー、またはcfengineなどのツールを使用して、インフラストラクチャを維持するためのプル方法論を誓います。クライアントに変更をプッシュするのではなく、個々のクライアントマシンごとに、起動時にゴールドサーバーをポーリングし、その後定期的に独自のリビジョンレベルを維持する必要があります。この視点を採用する前に、ssh、rsh、rcp、およびrdistに基づいて、プッシュベースの広範なスクリプトを開発しました。 rコマンド（またはssh）で見つかった問題は次のとおりです。変更をターゲットマシンにプッシュするためにrコマンドベースのスクリプトを実行すると、30を超えるターゲットホストがある場合、そのうちの1つがいつでもダウンしている。委託機械のリストを維持することは悪夢になります。これを修正するコードを作成する過程で、処理するための精巧なラッパーコードが作成されます。デッドホストからのタイムアウト。死んだホストのロギングと再試行。並列ジョブをフォークして実行し、妥当な時間内に多くのホストにヒットすることを試みます。最後に、すべてのアウトバウンドrshセッションでソースマシン上のすべての利用可能なTCPソケットを使い果たすケースを検出して防止します。その後、インストールしたものをすべて取得するという問題が引き続き発生します。将来インストールされるすべての新しいホストのイメージと、死んで明日再構築する必要のあるすべてのホストで同じイメージを繰り返します。トラブルシューティングを行った後、rコマンドベースのレプリケーションを実装したところ、価値がないことがわかりました。 。rコマンドやその他のプッシュメカニズムを使用してインフラストラクチャを再度管理する予定はありません。それらは、プルベースのメソッドほど拡張されません。

アーキテクチャ上の問題ではなく、実装上の問題ではありませんか？スレッド化されたプルクライアントよりもスレッド化されたプッシュクライアントの作成が難しいのはなぜですか？

puppetchefconfiguration-managementansiblesaltstack
22
Willem

プッシュベースのシステムの問題は、中央のプッシュノードにアーキテクチャ全体の完全なモデルが必要なことです。あなたが知らないマシンにプッシュすることはできません。

明らかに機能しますが、同期を保つには多くの作業が必要です。

Mcollectiveなどを使用して、Puppetおよび他のCMをプッシュベースのシステムに変換できます。一般的に、プルシステムをプッシュベースのシステムに変換するのは簡単ですが、他の方法を実行するのは必ずしも簡単ではありません。

組織政治の問題もあります。プッシュベースのシステムは、中央管理者のすべての制御の手を置きます。そのように複雑さを管理することは非常に難しい場合があります。スケーリングの問題は赤のニシンだと思います。クライアントの数だけを見ると、どちらのアプローチでもスケーリングされます。多くの点で、プッシュは拡張が簡単です。ただし、動的構成は多かれ少なかれ、少なくともプルバージョンのクライアント登録があることを意味します。

最終的には、どのシステムが組織のワークフローと所有権に一致するかについてです。原則として、プルシステムはより柔軟です。

8
Fred the Magic Wonder Dog

誰にとっても興味がある場合は、最低限、ミッションクリティカルなシステムのマルチホストセットアップのパッチ管理のコンテキストで、Ansibleのすぐに使えるプッシュ機能を初めて使用したユーザーエクスペリエンスレポートを提供できます。アマゾンクラウド。私の先入観や偏見を理解するために、私はRubyが自動化スクリプトレベルで設定されており、マスターエージェントのパペット構成をプロジェクトごとに設定するようにプロジェクトを設定したことを説明します。過去の偏見があるとすれば、私の経験は過去の偏見とはかけ離れています。

私の最近の経験は、スケールアップまたはスケールダウン、終了、更新が可能な数十から数百のサーバーの変化する不動産への動的なプッシュに非常に有利でした。私の状況では、パッチを作成するために必要なのは、単純なAnsible 1.7アドホックコマンドだけでした。ただし、目的のためにVpcごとに（t2.microで）AnsibleControllerを設定することの有効性を考慮して、将来、より複雑な要件のためにこの手法を拡張するつもりです。

それでは、このスレッドで尋ねられた質問に戻りましょう。動的に変化する資産におけるPushの長所と短所。

私が対象としたサーバー資産の種類の想定は次のとおりです。

  • IPアドレスやAmazonが生成したローカルホスト名が長続きするとは限りません-どちらも出入りできます
  • すべてのインスタンスは、単一の特権管理ユーザーからsshアクセスを可能にする機能がすでにあるマシンイメージから作成されました
  • サーバーを個別化し、機能または開発の段階（例：テストまたは製品）に応じてサーバーをグループに分割することは、合意された従来の名前の特定のAmazonタグを起動することによって行われます。
  • LinuxサーバーとWindowsサーバーを別々にアドホックコマンドを使用して個別に管理します。したがって、Windowsサーバーへの接続時にLinux固有のログインが失敗するだけで十分です。

これらの条件を考慮して、AnsibleControllerのマシンイメージを作成して多数のVPCにドロップし、既存のサーバーアカウント内で（資格情報を使用して）その場で構成することは非常に簡単です。イメージから作成された各インスタンス内で自動化されます

  1. パッチを実行中のサーバーに定期的にプッシュして、必要な資産に定期的にアクセスできるようにするcronジョブ
  2. そのような間隔ごとにAnsibleインベントリを計算する方法。

2番目のアイテムは、必要に応じて（Ansibleインベントリの情報構造を介して）比較的洗練されたものにすることができます。ただし、高度な処理が必要ない場合は、各cron間隔ですべてのAmazon EC2インスタンスを計算し、その結果を適切なインベントリファイル（例：/ etc/ansible/hosts）に送るスクリプトの非常に簡単な例を次に示します。

#!/bin/bash
# Assumes aws-cli/1.3.4 Python/2.6.9 Linux/3.4.73-64.112.amzn1.x86_64 or greater
# http://aws.Amazon.com/releasenotes/8906204440930658
# To check yum list aws-cli
# Assumes that server is equipped with AWS keys and is able to access some or all
# instances in the account within it is running.
# Provide a list of Host IPs each on a separate line
# If an argument is passed then treat it as the filename, whether local or absolute 
# path, to which the list is written

function list-of-ips {
    /usr/bin/aws ec2 describe-instances --filters '[ {"Name": "instance-state-code", "Values": [ "16" ] } ]' | grep -w PrivateIpAddress | awk  '{x=$2; gsub("\"","", x); gsub(",","", x); if(x && FNR!=1){print x;}}' | uniq
 }

if [ -n "$1" ]; then
   list-of-ips > "$1"
else
   list-of-ips
fi

使用例の唯一の注意点は、patchコマンドがべき等であることです。パッチが意図したとおりに機能することを確認する一環として、これが満たされていることを完全に確認するために事前テストすることが望ましいです。

要約すると、動的プッシュが設定した目標に対して効果的である使用例を示しました。これは、繰り返し可能なソリューションです（複数のアカウントおよび領域に展開できるイメージにカプセル化されるという意味で）。これまでの私の経験では、動的なプッシュ技術は、現在利用可能なツールセットから利用可能な代替手段よりもはるかに簡単に提供でき、行動に移すことができます。

11
johnz