d2c.ioの内部では、Ansibleを使用します。 これにより、クラウドプロバイダーで仮想マシンを作成し、ソフトウェアをインストールし、クライアントアプリケーションでDockerコンテナーを管理します。
Ansibleは、ほとんど、またはまったく調整することなく動作する便利なツールです。 これは、エージェント（エージェントレスシステム）がないため可能です。そのため、サービスを提供するホストに事前にインストールする必要はありません。
ほとんどの場合、 ssh使用してホストに接続します。 ただし、すべてのロジックは管理サーバー上にあり、Ansibleは各タスクをローカルで形成し、SSH接続を介して実行するため、このコインの裏側には一定の遅さがあります。 その後、結果を取得して分析し、次のステップに進みます。 この記事では、Ansibleを高速化する方法について説明します。
測定から始めましょう
測定できないものを改善することは不可能であるため、実行時間を計算する小さなスクリプトを作成します。
最初に、テストプレイブックを作成します。
test.yml --- - hosts: all # gather_facts: no tasks: - name: Create directory file: path: /tmp/ansible_speed state: directory - name: Create file copy: content: SPEED dest: /tmp/ansible_speed/speed - name: Remove directory file: path: /tmp/ansible_speed state: absent
次に、実行時間を計算するスクリプトを作成します。
time_test.sh #!/bin/bash # calculate the mean average of wall clock time from multiple /usr/bin/time results. # credits to https://stackoverflow.com/a/8216082/2795592 cat /dev/null > time.log for i in `seq 1 10`; do echo /usr/bin/time -p -a -o time.log $@ rm -rf /home/ubuntu/.ansible/cp/* done file=time.log cnt=0 if [ ${#file} -lt 1 ]; then echo exit 1 elif [ ${#file} -gt 1 ]; then samples=(`grep --color=never real ${file} | awk '{print $2}' | cut -dm -f2 | cut -ds -f1`) for sample in `grep --color=never real ${file} | awk '{print $2}' | cut -dm -f2 | cut -ds -f1`; do cnt=$(echo ${cnt}+${sample} | bc -l) done # Calculate the 'Mean' average (sum / samples). mean_avg=$(echo ${cnt}/${#samples[@]} | bc -l) mean_avg=$(echo ${mean_avg} | cut -b1-6) printf ${#samples[@]} ${mean_avg} grep --color=never real ${file} fi
テストプレイブックを10回起動し、平均値を取得します。
SSH多重化
ローカルネットワークでは：7.68秒でしたが、2.38秒になりました
リモートホストでは：26.64秒でしたが、10.85秒になりました
最初に確認することは、SSH接続の再利用が機能するかどうかです。 AnsibleはSSHを介してすべてのアクションを実行するため、接続の確立に遅延があると、プレイブック全体が大幅に遅くなります。 デフォルトでは、この設定はAnsibleで有効になっています。 構成ファイルでは、次のようになります。
[ssh_connection] ssh_args = -o ControlMaster=auto -o ControlPersist=60s
ただし、何らかの理由でssh_argsパラメーターをオーバーライドする場合は、 ControlMasterとssh_argsの値を明示的に指定する必要があることに注意してください。そうしないと、Ansibleはそれらを「忘れ」ます。
以下のように、SSH接続の再利用がケースで機能するかどうかを確認できます-vvvvパラメーターでAnsibleを起動します。
ansible test -vvvv -m ping
出力には、必要なパラメーターを指定したSSH起動が表示されます。
SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s ... -o ControlPath=/home/ubuntu/.ansible/cp/7c223265ce
さらに、多くのデバッグ情報の中から：
Trying existing master Control socket "/home/ubuntu/.ansible/cp/7c223265ce" does not exist setting up multiplex master socket
また、タスクの完了後60秒以内に、開いているソケットがファイル（この例では/home/ubuntu/.ansible/cp/7c223265ce ）として観察されることを確認できます。
注意： 1台の制御マシン（青/緑展開、ステージ/製品）から複数の同一の環境で作業している場合は、足元を撃たないようにしてください！ たとえば、最初に販売から現在の設定をダウンロードし、次のステップで新しいバージョンのコンポーネントでテスト環境を更新し、SSHソケットを販売から開いたままにした場合は、これらの環境でControlPathを変更するか、ウィザードを強制的に閉じる必要があります別の環境で作業を開始する前に、セッションを開始するか、ソケットを削除します。
パイプライン処理
ローカルネットワークでは：2.38秒でしたが、1.96秒になりました
リモートホスト：10.85秒でしたが、5.23秒になりました
デフォルトでは、Ansibleは次のようにターゲットホストでモジュールを実行します。
- ターゲットマシンで実行するためのモジュールとそのパラメーターを含むPythonファイルを生成します
- SSH経由で接続し、ユーザーのホームディレクトリを認識します
- SSH経由で接続し、作業用の一時ディレクトリを作成します
- SSH経由で接続され、SFTP経由でPythonファイルを一時ディレクトリにコピーします
- SSH経由で接続し、ターゲットマシン上でPythonファイルを実行し、一時ディレクトリを削除します
- モジュールの実行結果を標準出力から取得します
リスト全体が各タスクに対して実行されることを考慮すると、オーバーヘッドが大きくなります。 このプロセスを高速化するために、Ansibleにはパイプラインモードがあり、Linuxのコマンド間のI / Oパイプラインに似ています。 構成ファイルでは、モード設定は次のようになります。
[ssh_connection] pipelining = true
パイプラインモードを使用する場合、Ansibleは次のように機能します。
- ターゲットマシンで実行するためのモジュールとそのパラメーターを含むPythonファイルを生成します
- SSH経由で接続し、Pythonインタープリターを実行します
- Pythonファイルの内容を標準インタープリター入力に送信します
- モジュールの実行結果を標準出力から取得します
合計：4つのSSH接続といくつかの追加コマンドがありましたが、現在は1つです。 特にWANのリモートサーバーの場合、スピードアップは明らかです。
パイプライン処理が機能しているかどうかを確認するには、次のように、高度なロギングを使用してAnsibleを実行する必要があります。
ansible test -vvv -m ping
出力に次の形式の複数のssh呼び出しが含まれる場合：
SSH: EXEC ssh ... SSH: EXEC ssh ... SSH: EXEC sftp ... SSH: EXEC ssh ... python ... ping.py
そのため、コンベアモードは機能していません。 ssh呼び出しが1つの場合：
SSH: EXEC ssh ... python && sleep 0
したがって、パイプラインは機能します。
重要：デフォルトでは、この設定はsudo設定のrequiretty要件と競合する可能性があるため、Ansibleで無効になっています。 この記事の執筆時点では、Amazon EC2のUbuntuとRHELの最新のイメージは切断するrequirettyため、パイプラインを安全に使用できます。
PreferredAuthenticationsおよびUseDNS
ローカルネットワークでは：1.96秒でしたが、1.92秒になりました
リモートホストでは：5.23秒でしたが、4.92秒になりました
多数のターゲットマシンを制御する場合、接続速度に影響を与える些細なことが重要です。 そのような些細なことの1つは、特にローカルDNSサーバーが使用されている場合、サーバーおよびクライアント側での逆DNSクエリです。
UseDNS
UseDNSはSSHサーバー設定（ファイル/ etc / ssh / sshd_config）であり、クライアントIPアドレスのPTRレコードを強制的にチェックします。 幸いなことに、最新のディストリビューションではデフォルトで無効になっています。 ただし、念のため、プライマリSSH接続が遅い場合は、ターゲットホストを確認する価値があります。
PreferredAuthentications
これは、クライアントが使用できる認証方法についてサーバーに通知するSSHクライアント設定です。 デフォルトでは、Ansibleは
-o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey
また、Amazon EC2のRHELイメージのように、 GSSAPIAuthenticationサーバーで有効になっている場合、このモードが最初にテストされます。 これにより、不必要な手順が発生し、クライアントからのPTRレコードを検証しようとします。
ほとんどの場合、キーによる認証のみが必要であるため、これをansible.cfg明示的に示します。
[ssh_connection] ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o PreferredAuthentications=publickey
このセットアップにより、サーバーとの不必要なネゴシエーションからクライアントが保護され、マスターセッションのインストールが高速化されます。
ファクトコレクション
ローカルネットワークでは：1.96秒でしたが、1.47秒になりました
リモートホスト：4.92秒でしたが、4.77秒になりました
プレイブックを再生するとき（アドホックコマンドは適用されません）、Ansibleはデフォルトでリモートシステムに関する情報を収集します。 この手順は、 setupモジュールの起動に似ており、同様に別のSSH接続が必要です。 テストプレイブックでは、単一のファクトを使用しないため、playbookパラメーターを指定してこの手順をスキップできます。
gather_facts: no
ファクトを使用してプレイブックを頻繁に開始するが、ファクトの収集がプレイブックの速度に大きく影響する場合は、外部ファクトキャッシングシステムの使用を検討してください（これについては、Ansibleのドキュメントで部分的に説明されています ）。 たとえば、Redisをセットアップします。Redisは1時間に1回、新しいファクトで満たされ、すべての作業中のプレイブックでは、ファクトの強制収集をオフにします。 これらは、ローカルキャッシュから取得されます。
WAN→LAN
4.77秒でしたが、1.47秒になりました
高速通信チャネルにもかかわらず、ローカルネットワークでは、通常、すべてがグローバルネットワークよりも高速に動作します。 そのため、eu-west-1リージョンのAmazon EC2など、さまざまなサーバーでプレイブックを頻繁に実行する場合、メイン管理サーバーは同じプラットフォームに配置する必要があります。 使用シナリオによっては、管理サーバーをターゲットサーバーの近くに移動すると、プレイブックの実行を大幅に高速化できます。
プルモード
1.47秒でしたが、1.25秒になりました
さらに速度が必要な場合は、ターゲットサーバーでローカルにプレイブックを作成できます。 これにはansible-pullユーティリティがあります。 また、 公式のAnsibleドキュメントでそれについて読むこともできます 。 次のように機能します。
- リポジトリをローカルディレクトリに複製する
- 指定したプレイブックをローカルで開始します（
-c localオプションを使用） - プレイブックが指定されていない場合、実行を試みます：
<fqdn>.yml<hostname>.ymllocal.yml
ユースケースの1つは、何かが変更された場合にリポジトリとプレイブックのポーリングをスケジュールすることです（ --only-if-changedパラメーター）。
フォーク
前のセクションでは、各ホストのプレイブックを個別に高速化することについて説明しました。 しかし、一度に数十台のサーバーのプレイブックを起動すると、「フォーク」の数（異なるサーバーでタスクを実行するための別個の並列プロセス）がボトルネックになることがあります。 構成ファイルでは、この設定は次のとおりです。
[defaults] forks = 20
デフォルトのフォーク値は5です。これは、Ansibleが一度に最大5つのホストと通信することを意味します。 多くの場合、管理サーバーのCPUと通信チャネルの機能により、より多くのホストに同時にサービスを提供できます。 最適な量は、特定の環境で実験的に選択されます。
同時実行性に関するもう1つのポイントは、スレッドの数が少なく、サーバーが多い場合、sshマスターセッションが「悪くなる」可能性があり、本格的なSSHセッションを再インストールする必要が生じることです。 これは、デフォルトでは、Ansibleがlinear実行戦略を使用するためです。 すべてのサーバーで1つのタスクが完了するまで待機してから、次のタスクに進みます。 「最初の」サーバーがタスクを迅速に完了し、 ControlPersist時間が経過するまで他のすべてのサーバーでタスクが実行されるまで待機する場合があります。
ポーリング間隔
ターゲットサーバーでモジュールを起動すると、制御マシンのAnsibleプロセスは、モジュールの実行結果のポーリングモードに入ります。 これをどれほど積極的に行うかは、制御マシンのCPU負荷に影響します。 また、並列プロセスの数を増やすにはプロセッサ時間が必要です（前のセクションを参照）。 このような内部ポーリング間のタイムアウト設定は、設定ファイルに秒単位で示されます。
[defaults] internal_poll_interval = 0.001
多数のホストで「長時間プレイ」タスクを実行する必要がある場合、その結果はそれほど頻繁にチェックする意味がないか、制御マシンに多くの空きCPUがない場合は、たとえば0.05などのポーリングを実行できます。
-
PS：ハイライトのうち、おそらくそれがすべてです。 プレイブック自体の最適化では、すでにさらなる速度を追求する必要がありますが、これはまったく別の話です。