🥇Ansible の高速化 | プロホスター

デフォルト設定では Ansible がその仕事を迅速に実行できないことは周知の事実です。この記事では、この理由をいくつか指摘し、実際にプロジェクトの速度を向上させる可能性が非常に高い、有用な最小限の設定を提供します。

ここと以下では、好みの方法で新しく作成した virtualenv にインストールされた Ansible 2.9.x について説明します。

インストール後、プレイブックの隣に「ansible.cfg」ファイルを作成します。この場所を使用すると、これらの設定をプロジェクトとともに転送でき、さらに、それらの設定は完全に自動的に読み込まれます。

パイプライン化

パイプラインを使用する必要性、つまりモジュールをターゲットシステムのファイルシステムにコピーするのではなく、Base64 でラップされた zip アーカイブを Python インタプリタの stdin に直接転送する必要性についてすでに聞いたことがある人もいるかもしれませんが、知らない人もいるかもしれませんが、実際には依然として事実です: この設定依然として過小評価されている。残念ながら、人気のある Linux ディストリビューションの一部では、デフォルトでは sudo の設定が適切ではなく、このコマンドには tty (ターミナル) が必要だったので、Ansible はこの非常に便利な設定をデフォルトで無効のままにしました。

pipelining = True

事実の収集

デフォルト設定では、Ansible はプレイごとに、それに参加するすべてのホストのファクトの収集を開始することをご存知ですか? 一般的に、知らなかったとしても、今は知っています。これを防ぐには、ファクトを収集するための明示的要求モード (明示的) またはスマートモードを有効にする必要があります。その中では、以前のプレイでは遭遇しなかったホストからのみ事実が収集されます。
更新。コピーするときは、これらの設定のいずれかを選択する必要があります。

gathering = smart|explicit

SSH接続の再利用

Ansible をデバッグモード (「v」オプション、XNUMX ～ XNUMX 回繰り返す) で実行したことがある場合は、ssh 接続が常に確立されたり切断されたりしていることに気付いたかもしれません。したがって、ここにもいくつかの微妙な点があります。

ssh 接続を XNUMX つのレベルで一度に再確立する手順 (ssh クライアントで直接行う場合と、マネージャーから管理対象ホストにファイルを転送する場合の両方) を回避できます。
オープン ssh 接続を再利用するには、必要なキーを ssh クライアントに渡すだけです。次に、次の処理を開始します。初めて ssh 接続を確立するときに、いわゆる制御ソケットを追加で作成し、その後の接続中に、このソケットの存在を確認し、成功した場合は、そのソケットを再利用します。既存の SSH 接続。これをすべて理解するために、非アクティブ時に接続を維持する時間を設定しましょう。詳細については、 SSHドキュメントまた、Ansible のコンテキストでは、必要なオプションを ssh クライアントに「転送」するだけです。

ssh_args = "-o ControlMaster=auto -o ControlPersist=15m"

管理対象ホストにファイルを転送するときに、すでに開いている ssh 接続を再利用するには、別の不明な設定 ssh_tranfer_method を指定するだけです。このテーマに関するドキュメントは非常に充実していますケチなこのオプションは非常にうまく機能するため、誤解を招きます。でも読んでるソースコードこれにより、実際に何が起こるかを理解できます。管理対象ホスト上で dd コマンドが起動され、目的のファイルを直接操作します。

transfer_method = piped

ちなみに、「develop」ブランチにもこの設定は存在しますどこにも行かない.

ナイフを恐れるな、フォークを恐れよ

もう 2.7 つの便利な設定はフォークです。同時にホストに接続してタスクを実行するワーカープロセスの数を決定します。言語としての Python の特性により、Ansible は依然として Python XNUMX をサポートしているため、スレッドではなくプロセスが使用されます。非同期は必要ありません。ここで非同期動作を導入する意味はありません。デフォルトでは Ansible が実行されます 5 ワーカーですが、正しく要求すると、さらに多くのワーカーが起動されます。

forks = 20

制御マシン上の利用可能なメモリ量に関連して、いくつかの問題が発生する可能性があることをすぐに警告します。言い換えれば、もちろん forks=100500 を設定することもできますが、それがうまくいくと誰が言ったのでしょうか?

すべてを一緒に入れて

その結果、ansible.cfg (ini 形式) の場合、必要な設定は次のようになります。

[defaults]
gathering = smart|explicit
forks = 20
[ssh_connection]
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=15m
transfer_method = piped

そして、健康な人の通常の YaML インベントリ内のすべてを非表示にしたい場合は、次のようになります。

---
all:
  vars:
    ansible_ssh_pipelining: true
    ansible_ssh_transfer_method: piped
    ansible_ssh_args: -o ControlMaster=auto -o ControlPersist=15m

残念ながら、これは「収集 = スマート/明示的」および「フォーク = 20」設定では機能しません。これらに相当する YaML は存在しません。これらを ansible.cfg で設定するか、環境変数 ANSIBLE_GATHERING および ANSIBLE_FORKS を通じて渡します。

マイトゲンについて
- これはミトゲンのどこにありますか？ - 親愛なる読者の皆さん、あなたには質問する権利があります。この記事のどこにもありません。しかし、コードを読んで、なぜプレイブックが Mitogen ではクラッシュするのに、バニラの Ansible では正常に動作するのか、あるいはなぜ同じ Playbook が以前は正常に動作していたのに、更新後に奇妙な動作をし始めたのかを理解する準備が本当にできているのなら、Mitogen です。あなたのツールになる可能性があります。応用して、理解して、記事を書いて、興味深く読みます。

私が個人的に Mitogen を使用しないのはなぜですか? グラジオラスは、タスクが本当に単純で、すべてが順調である場合にのみ機能するためです。しかし、あなたが少し左か右に曲がれば、それだけです、私たちは到着しました。それに応じて、いくつかの不明瞭な例外があなたに向かって飛んできます、そして全体像を完成させるために欠けているのは、共通のフレーズ「皆さんありがとう」だけです、誰もが自由です。」一般的に、私は次の「地下ノック」の理由を見つけるのに時間を無駄にしたくないだけです。

これらの設定の一部は読み取りプロセス中に発見されましたソースコード接続プラグインは、わかりやすい名前「ssh.py」で作成されます。他の人がソースを見て、読んで、実装を確認し、ドキュメントと比較するきっかけになればと願って、読書の結果を共有します。結局のところ、これらすべては遅かれ早かれ肯定的な結果をもたらすでしょう。幸運を！

登録ユーザーのみがアンケートに参加できます。ログインお願いします。

プロジェクトを高速化するために、次の Ansible 設定のうちどれを使用しますか?

視聴者の３８%がパイプライン化=true32
視聴者の３８%が収集 = スマート/明示的16
視聴者の３８%がssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
視聴者の３８%がtransfer_method = パイプされた 8
視聴者の３８%がフォーク = XXX29
視聴者の３８%がどれも、Mitogen3 だけです
視聴者の３８%がMitogen + これらの設定のどれをメモします4

46 人のユーザーが投票しました。 21 ユーザーが棄権しました。

Ansible についてもっと知りたいですか?

視聴者の３８%がはい、もちろん54
視聴者の３８%がはい、もっとハードコアなものが欲しいだけです!15
視聴者の３８%がいいえ、まったく必要ありません0
視聴者の３８%がいや、複雑だ!!!0

69 人のユーザーが投票しました。 7名のユーザーが棄権した。

出所： habr.com

Ansible の高速化