☰

Ansible で既に Serial を使用している場合は、他のホストにファンアウトします。

tag-icon • tag-icon ansible ansible-playbook envoyproxy
Ansible で既に Serial を使用している場合は、他のホストにファンアウトします。

アプリケーションを実行するホストが 80 台以上あり、ロード バランサーを変更するために既存の長い Ansible プレイブックを更新しています。現在のロード バランサー設定では、AWS CLI にシェルアウトすることで、1 回の Ansible プレイでロード バランサーにホストを追加または削除できます。ただし、少数の独自のホストで構成されたロード バランサーに切り替え、Ansible を使用してそれらのホスト上のテキスト ファイルを操作することで、ホストを出し入れします。基本的に、Serial を使用しながら、プレイブック内の異なるホストに内部ループが必要です。

serial: 25% で80 台のホストにデプロイしながら、blockinfileグループ内のホストにコマンドをファンアウトできるようにプレイブックを構成するのに問題があります。tag_Type_edgetag_Type_app

私が実現したいことは次のとおりです:

---
- hosts: tag_Type_app
  serial: "25%"
  pre_tasks:

    - name: Gathering ec2 facts
      action: ec2_metadata_facts

    - name: Remove from load balancers
      debug:
        msg: "This is where I'd fan out to multiple different hosts from group tag_Type_edge to manipulate
              text files to remove the 25% of hosts from tag_Type_app from the load balancer"

  tasks:
    - name: Do a bunch of work to upgrade the app on the tag_Type_app machines while out of the load balancer
      debug:
        msg: "deploy new code, restart service"


  post_tasks:
    - name: Put back in load balancer
        debug:
          msg: "This is where I'd fan out to multiple different hosts from group tag_Type_edge to manipulate
                 text files to *add* the 25% of hosts from tag_Type_app back into the load balancer"

tag_Type_edgeすべてのボックスで serial: 25% を使用しながら内部ループを許可するようにこれを構造化するにはどうすればよいですかtag_Type_app?

答え1

Ansibleでは、あるホストでタスクを別のホストに代わって実行する場合、次のような賢い方法が必要になることがあります。委任ドキュメント内の例では、実際にロード バランサーからホストが取り出されています。

他のタスクと同様に、いくつかのホスト名でループ内で複数回実行できます。再生ループではなく、タスク ループです。例を挙げて説明します。スケルトンを採用してください。

---
- name: Example loop over load balancers for each app server
  hosts: tag_Type_app
  serial: "25%"

  pre_tasks:
    - name: Gathering ec2 facts
      action: ec2_metadata_facts

    - name: Remove from load balancers
      debug:
        msg: "Remove app instance {{ inventory_hostname }} from edge node {{ item }}"
      delegate_to: "{{ item }}"
      loop: "{{ query('inventory_hostnames', 'tag_Type_edge') }}"

  tasks:
    - name: Do a bunch of work to upgrade the app on the tag_Type_app machines while out of the load balancer
      debug:
        msg: "deploy new code, restart service"

  post_tasks:
    - name: Put back in load balancer
      debug:
        msg: "Add app instance {{ inventory_hostname }} to edge node {{ item }}"
      delegate_to: "{{ item }}"
      loop: "{{ query('inventory_hostnames', 'tag_Type_edge') }}"

inventory_hostnames は、インベントリ パターンを実行する検索プラグインであり、任意のパターンをそこに使用できます。

これには、いくつかの注意点があります。「エッジ」ループで障害が発生すると、「アプリ」ホストが失敗します。これにより、一部のエッジ ホストが有効になり、一部が有効にならない状態が残ります。ブロックとレスキューによる解除などのバックアウト メカニズムがない限りは。

タスク ループであるため、一部のインベントリおよびプレイ関連の機能は適用されません。--limitコマンド ラインでエッジ ホストをさらに制限することはできません。また、serialバッチ処理に使用することもできません。これはすでにプレイ中です。

また、少なくともアプリ ✕ エッジ ✕ 2 という比較的多数のタスクを実行します。これは少し遅いかもしれません。フォークを増やすことでいくらか軽減できます。

複数のホストのロード バランサーに単一のコントロール プレーンがあれば、それほど多くのホストに触れる必要はありません。アプリケーション サーバーごとに 1 つのタスクを実行します。現時点ではこれが設定されていない場合がありますが、検討する価値があります。

関連情報