🥇Ansible の高速化

デフォルト設定では、Ansible がすぐに機能しない可能性があることは周知の事実です。この記事では、その理由をいくつか挙げ、プロジェクトの速度を実際に向上させる可能性のある、最小限の設定を紹介します。

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

インストール後、プレイブックの横に「ansible.cfg」ファイルを作成します。この場所により、これらの設定をプロジェクトと一緒に転送できるようになり、設定は自動的に読み込まれます。

コンベア化

パイプラインを使用する必要がある、つまり、モジュールをターゲットシステムの FS にコピーするのではなく、Base64 でラップされた zip アーカイブを Python インタープリターの stdin に直接転送する必要がある、という話を聞いたことがある人もいるかもしれませんが、次の事実は変わりません。この設定過小評価されている。残念ながら、人気のある流通 Linux 以前のsudoのデフォルト設定は少々不便だった。tty（端末）への接続が必要だったため、Ansibleはこの非常に便利な設定をデフォルトで無効にしていた。

pipelining = True

事実の収集

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

gathering = smart|explicit

SSH接続の再利用

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

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

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

管理対象ホストにファイルを転送するときに、すでに開いている SSH 接続を再利用するには、別の不明な設定 ssh_tranfer_method を指定するだけで十分です。この件に関する文書は非常にけちなこのオプションは非常にうまく機能するので、誤解を招く可能性があります。しかし、読むとソースコード正確に何が起こるかを理解できます。管理対象ホストで dd コマンドが起動され、必要なファイルを直接操作します。

transfer_method = piped

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

ナイフを恐れるのではなく、フォークを恐れなさい

もう一つの便利な設定はフォークです。同時にホストに接続してタスクを実行するワーカープロセスの数を定義します。言語としての Python の特殊性により、Ansible は引き続き Python 2.7 をサポートしているため、スレッドではなくプロセスが使用されます。asyncio がないため、ここで非同期性を生み出す必要はありません。デフォルトでは、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

残念ながら、これは「gathering = smart/explicit」および「forks = 20」設定では機能しません。YaML に相当するものはありません。これらを ansible.cfg で設定するか、環境変数 ANSIBLE_GATHERING および ANSIBLE_FORKS を介して渡します。

ミトジェンについて
— ミトゲンについてはどうですか？ — 読者の皆さんには質問する権利があります。この記事にはどこにも記載されていません。しかし、本当にそのコードを読んで、なぜプレイブックが Mitogen ではクラッシュするのに、標準の Ansible では問題なく動作するのか、または同じプレイブックが以前は問題なく動作していたのに、アップデート後に奇妙な動作を始めたのかを解明する準備ができている場合は、Mitogen が最適なツールとなる可能性があります。応用し、理解し、記事を書きます - 私はそれらを興味深く読みます。

なぜ個人的には Mitogen を使用しないのでしょうか?グラジオラスは、タスクが本当に単純ですべてが順調な場合にのみ機能します。しかし、少し左か右に曲がってみる価値はあります。そう、到着したのです。それに応じて、いくつかの漠然とした例外が飛び交い、全体像を完成させるには、お決まりのフレーズ「ありがとうございました。皆さんご自由にお帰りください」だけが欠けています。一般的に言えば、私は次の「地下ノック」の理由を理解しようとして時間を無駄にしたくないのです。

これらの設定の一部は、読んでいるときに発見されました。ソースコード名前が「ssh.py」である接続プラグイン。私が読んだ結果をシェアするのは、これが他の人に、ソースコードを見て、読んで、実装を確認し、ドキュメントと比較するきっかけになればいいなと思っているからです。結局のところ、これらすべてが遅かれ早かれ良い結果をもたらすのです。幸運を！

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

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

69,6%パイプライン = true32
34,8%収集 = スマート/明示的16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4%転送方法 = パイプ8
63,0%フォーク = XXX29
6,5%どれもなし、Mitogen3だけ
8,7%ミトゲン+これらの設定のどれかをメモします4

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

Ansible についてさらに詳しく知りたいですか?

78,3%はい、もちろんです54
21,7%うん、もっとハードコアなものが欲しいだけだよ！15
0,0%いいえ、無料ではありません0
0,0%いや、複雑ですよ!!!0

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

出所： habr.com