皆さんこんにちは、Red Hat ソリューションアーキテクトの岡野です。
これから何回かに分けて、Ansible Tower について書いていきたいと思います。
第1回目は、 Tower を提案する際に良く聞かれる可用性、特に Ansible Tower クラスターについてご紹介したいと思います。
※なお、この記事は、現時点で最新の、Ansible Tower 3.6.3 をベースに記載しています。
将来のバージョンでは異なる動きとなる可能性もありますのであらかじめご了承ください。
Ansible Tower では可用性を担保する仕組みとして、以下の様な選択肢があります。
- クラスター（Active / Active）
- バックアップリストア
- Tower オブジェクト自体のコード化
どの仕組みを採用するかは災害発生時に許容される RPO/RTO に依存しますし、そもそも Ansible Tower が落ちても対象ノードのサービスが停止するわけではないのでそのあたりは可用性の要否をしっかり見極めた上で選択する必要がありますが、今回はその議論は置いておいて、まず、Ansible Tower のクラスターについてご紹介したいと思います。
1. Ansible Tower クラスター
Ansible Tower の主な構成要素は以下の通りです。
・Webサービス
・メッセージキュー
・データベース
上記コンポーネントを All in One で構成することも可能ですし、PostgreSQL の Database 部分のみ外出しにすることも可能ですが、クラスターを組む場合はデータベースを外出しにした上でそれ以外の部分を Active / Active で構成する形となります。クラスターのインストールは非クラスター構成と同様で、インストール用の構成ファイル（inventory）を編集するのみで極めて簡単です。ただし、残念ながら Ansible Tower のインストーラーでは PostgreSQL 部分の冗長化構成を作ることはできません。データベースの冗長化の部分に関しては別途ご検討いただく必要があります。この点はご注意ください 。
・Active / Active の部分は3台～最大20台で構成する事が出来ます。
奇数台数を基本とします。（台数が多くなると奇数である必要性は少なくなってきます）
・各クラスターノードが UI 及び API のエントリーポイントとして機能するため、ロードバランサーは必須ではありません。
3台の Active / Active クラスターと外部 PostgreSQL を利用した場合の inventory ファイルの例は以下の通りです。
[tower] clusternode1.example.com clusternode2.example.com clusternode3.example.com [database] [all:vars] ansible_become=true admin_password='password' pg_host='dbnode.example.com' pg_port='5432' pg_database='tower' pg_username='tower' pg_password='password' rabbitmq_port=5672 rabbitmq_vhost=tower rabbitmq_username=tower rabbitmq_password='password' rabbitmq_cookie=rabbitmqcookie # Needs to be true for fqdns and ip addresses rabbitmq_use_long_name=true
なお、インストールには root 権限が必要です。inventory ファイルの変数定義欄に、ユーザー、パスワード （または ssh 認証キー）など必要な情報を追記ください。
ansible_user=root ansible_ssh_password=”your_password_here”
クラスターは Active / Active で動作します。複数のジョブテンプレートの並列実行はもちろんですが、1つのジョブテンプレートの並列実行も可能です。例えば以下の例では、1つのジョブテンプレートの実行の際、クラスターを構成する3台の Ansible Tower ホストが並列で 10台ずつ、計 30 台のホストに対して Playbook を実行する様子を示しています。この様な動作をジョブスライスと呼んでいます。
ジョブスライスを実行するには、ジョブテンプレートに対し以下の2点の設定を行う必要があります。
・Job Slicing を 1 → 3 などスライス数に合わせて上げる
・同時実行ジョブの有効化にチェックを入れる
・実行ホストを絞りたい場合は、対象ホストを絞ったインスタンスグループを別途作成してジョブ実行することも可能（オプション）
上記設定を行うと、自動的にワークフロージョブとして同一の3つのジョブが同時実行されます。
なお、クラスター構成の場合主に管理面で少しばかり注意が必要です。
1つは、ローカルで作成した Playbook です。
Ansible Tower の場合、/var/lib/awx/projects/ 配下に Playbook を配置します。シングル構成の Ansible Tower であれば、そのホストにsshで接続して Playbook を作成、Ansible Tower のプロジェクトに登録してジョブテンプレートで利用、ということが可能ですが、クラスターの場合、1台ホストに記載するだけではそのホストがダウンした際にジョブテンプレートが実行できないことになります。このため、手動で、全ホストに対して Playbook を配置する必要があります。
これは、ホストダウンの時だけではなく、先ほどのジョブスライスでも同様で、並列実行対象の全ホストの/var/lib/awx/projects/ に Playbook を配置しておかないと Playbook が配置されてないホストで実行されたジョブが失敗します。
また、クラスター構成の場合、バックアップリストアの際も、このローカルに保存された Playbook は、リストア対象ではありません。このため、バックアップファイルをリストアした際には Playbook を個別に移動する必要があります。
※クラスター構成ではなく単独ホストの場合は /var/lib/awx/projects/ 配下の Playbook はバックアップリストア対象となっています。
勿論、上記制限は、全ホストからアクセス可能な、Git等のSCMを使って Playbook を管理している場合は全く問題ありません。
Ansible Tower を利用した場合は、Git 等の SCM を使って Playbook のバージョンと品質を管理することを推奨していますが、クラスターの場合は管理面でもこちらがお勧めということになりそうですね。♬
Ansible Tower のバックアップリストアと、 オブジェクト自体のコード化については次回以降にご紹介したいと思います。
Ansible Tower のバイナリーと評価ライセンスは以下から取得可能です。是非使ってみてください！！
・Ansible Tower バイナリーダウンロードはこちらから
・Ansible Towerの評価ライセンスリクエストはこちらから
