Ansible Playbook を使用して複数のリモートサーバー上の複雑なタスクを自動化する方法 - パート 2
この Ansible シリーズの前回の記事では、Ansible が単一システムから複数のマシン (ノードとも呼ばれる) を迅速かつ効率的に管理し、それらへのデプロイメントを実行できるエージェントレス ツールであると説明しました。
コントローラー マシンにソフトウェアをインストールし、パスワードなしでログインするためのキーを作成してノードにコピーしたら、Ansible を使用してそのようなリモート システムを管理するプロセスを最適化する方法を学習します。
この記事と次回の記事では、次のテスト環境を使用します。すべてのホストはCentOS 7 ボックスです。
Controller machine (where Ansible is installed): 192.168.0.19
Node1: 192.168.0.29
Node2: 192.168.0.30
さらに、両方のノードがローカルの /etc/ansible/hosts ファイルの Webservers セクションに追加されていることにも注意してください。
そうは言っても、当面のトピックから始めましょう。
Ansible プレイブックの紹介
前のガイドで説明したように、ansible ユーティリティを使用して、次のようにリモート ノードでコマンドを実行できます。
ansible -a "/bin/hostnamectl --static" webservers
上の例では、node1 と node2 で hostnamectl --static
を実行しました。リモート コンピューター上でタスクを実行するこの方法は、短いコマンドの場合には問題なく機能しますが、さらによく構造化された構成パラメーターや他のサービスとの対話を必要とするより複雑なタスクの場合は、すぐに面倒になったり面倒になったりする可能性があることを理解するのに、それほど時間はかかりません。
たとえば、複数のホスト上でのWordPress のセットアップと構成 - これについては、このシリーズの次の記事で説明します)。ここでプレイブックが登場します。
簡単に言うと、プレイブックはYAML形式で書かれたプレーンテキストファイルで、1つ以上のキーと値のペア(「プレイブック」とも呼ばれる)を持つアイテムのリストが含まれています。 > ハッシュ 」または「辞書 」)。
各プレイブック内には、目的のタスクが実行されるホストのグループが 1 つ以上あります (これらのグループのそれぞれはプレイとも呼ばれます)。
公式ドキュメントの例は、以下を説明するのに役立ちます。
1. ホスト: これは、次のタスクが実行されるマシンのリストです (/etc/ansible/hosts による)。
2. remote_user: タスクの実行に使用されるリモート アカウント。
3. vars: リモート システムの動作を変更するために使用される変数。
4. タスクは、ホストに一致するすべてのマシンに対して一度に 1 つずつ順番に実行されます。プレイ内では、すべてのホストが同じタスク ディレクティブを取得します。
特定のホストに対して別の関連タスクのセットを実行する必要がある場合は、現在のプレイブックに別のプレイを作成します (つまり、プレイの目的は、特定のホストの選択を適切にマッピングすることです) -定義されたタスク)。
その場合は、一番下に hosts ディレクティブを追加して最初からやり直すことで、新しいプレイを開始します。
---
- hosts: webservers
remote_user: root
vars:
variable1: value1
variable2: value2
remote_user: root
tasks:
- name: description for task1
task1: parameter1=value_for_parameter1 parameter2=value_for_parameter2
- name: description for task1
task2: parameter1=value_for_parameter1 parameter2=value_for_parameter2
handlers:
- name: description for handler 1
service: name=name_of_service state=service_status
- hosts: dbservers
remote_user: root
vars:
variable1: value1
variable2: value2
…
5. ハンドラーは、各プレイのタスク セクションの最後にトリガーされるアクションで、主にサービスを再起動したり、リモート システムで再起動をトリガーしたりするために使用されます。
mkdir /etc/ansible/playbooks
そして、その中にapache.ymlという名前のファイルがあり、次の内容が含まれています。
---
- hosts: webservers
vars:
http_port: 80
max_clients: 200
remote_user: root
tasks:
- name: ensure apache is at the latest version
yum: pkg=httpd state=latest
- name: replace default index.html file
copy: src=/static_files/index.html dest=/var/www/html/ mode=0644
notify:
- restart apache
- name: ensure apache is running (and enable it at boot)
service: name=httpd state=started enabled=yes
handlers:
- name: restart apache
service: name=httpd state=restarted
次に、ディレクトリ /static_files を作成します。
mkdir /static_files
カスタム index.html ファイルを保存する場所:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"/>
</script>
</head>
<body>
<h1>Apache was started in this host via Ansible</h1><br>
<h2>Brought to you by linux-console.net</h2>
</body>
</html>
とはいえ、今度はこのプレイブックを使用して前述のタスクを実行します。 Ansible はホストごとに各タスクを一度に 1 つずつ実行し、そのようなタスクのステータスをレポートすることに注意してください。
ansible-playbook /etc/ansible/playbooks/apache.yml
次に、ブラウザを開いて 192.168.0.29 と 192.168.0.30 を指定すると何が起こるかを見てみましょう。
さらに一歩進んで、ノード 1 と ノード 2 で Apache を手動で停止して無効にしてみましょう。
systemctl stop httpd
systemctl disable httpd
systemctl is-active httpd
systemctl is-enabled httpd
それからまた走って、
ansible-playbook /etc/ansible/playbooks/apache.yml
今回、タスクは、Apache Web サーバーが起動され、各ホストで有効になったことを報告します。
上記の例は、Ansible のパワーを垣間見るものとして考えてください。これらのタスクは、少数のサーバーで実行する場合は比較的簡単ですが、同じことを複数 (おそらく数百) のマシンで実行する必要がある場合は、非常に面倒で時間がかかる可能性があります。
まとめ
この記事では、Ansible を使用してコマンドを実行し、複数のリモート ホスト上で複雑なタスクを同時に実行する方法について説明しました。公式ドキュメントと GitHub リポジトリには、Ansible を使用してほぼあらゆるタスクを達成する方法に関する多くの例とガイドが提供されています。
Ansible を使用してリモート Linux ホスト上のタスクを自動化する方法を学習し始めるにあたり、ご意見をお聞かせください。ご質問、ご意見、ご提案も随時受け付けておりますので、下記フォームよりお気軽にお問い合わせください。