TOC

Ubuntu 14.04でAnsibleを使用して複数のPHPアプリケーションをデプロイする方法

前書き

このチュートリアルは、Ubuntu 14.04でのAnsibleを使用したPHPアプリケーションのデプロイに関するシリーズの3番目です。 https://www.digitalocean.com/community/tutorials/how-to-deploy-a-basic-php-application-using-ansible-on-ubuntu-14-04 [最初のチュートリアル]には、デプロイの基本的な手順が記載されていますアプリケーション; https://www.digitalocean.com/community/tutorials/how-to-deploy-an-advanced-php-application-using-ansible-on-ubuntu-14-04 [2番目のチュートリアル]は、次のようなより高度なトピックをカバーしています。データベース、キューデーモン、およびタスクスケジューラ（cron）。

このチュートリアルでは、単一アプリケーションのAnsibleプレイブックを、1つまたは複数のサーバーへの複数のPHPアプリケーションのデプロイをサポートするプレイブックに変換することにより、前のチュートリアルで学んだことを基に構築します。 これは、Ansibleを使用して最小限の労力でアプリケーションを展開するという点で、パズルの最後のピースです。

例の一部として、いくつかの単純なhttp://lumen.laravel.com/[Lumen]アプリケーションを使用します。 ただし、これらの手順は、すでに独自のものがある場合は、他のフレームワークやアプリケーションをサポートするように簡単に変更できます。 プレイブックに変更を加えることに慣れるまで、サンプルアプリケーションを使用することをお勧めします。

前提条件

このチュートリアルを実行するには、次のものが必要です。

  • firstに従って2つのドロップレットをセットアップし、このシリーズのhttps://www.digitalocean.com/community/tutorials/how-to-deploy-an-advanced-php-application-using-ansible-on-ubuntu-14-04[second]チュートリアル。

  • https://www.digitalocean.com/community/tutorials/how-to-deploy-a-basic-php-application-using-ansible-onで元のPHPドロップレットのように設定された新しい（3番目の）Ubuntu 14.04ドロップレット-ubuntu-14-04 [最初のチュートリアル]、sudo非rootユーザーとSSHキーを使用。 1つのAnsibleプレイブックを使用して複数のアプリケーションを複数のサーバーに展開する方法を示すために使用されるこのドロップレット。 元のPHPドロップレットとこの新しいPHPドロップレットのIPアドレスをそれぞれ「」と「」と呼びます。

  • 次の行が追加された、ローカルコンピューター上の更新された `+ / etc / hosts +`ファイル。 このファイルの詳細については、https：//www.digitalocean.com/community/tutorials/how-to-set-up-apache-virtual-hosts-on-ubuntu-14-04-lts#step-six-をご覧ください。 ％E2％80％94-set-up-local-hosts-file-（オプション）[このチュートリアルのステップ6]。

/ etc / hostsのどこにでも追加する行

laravel.example.com one.example.com two.example.com
laravel.example2.com two.example2.com

このチュートリアルで使用するWebサイトの例は、「+ laravel.example.com 」、「 one.example.com 」、および「 two.example.com +」です。 独自のドメインを使用する場合は、https：//www.digitalocean.com/community/tutorials/how-to-set-up-and-test-dns-subdomains-with-digitalocean-を更新する必要があります代わりにs-dns-panel＃final-configuration [active DNS records]。

ステップ1-プレイブック変数の設定

このステップでは、プレイブック変数を設定して新しいアプリケーションを定義します。

前のチュートリアルでは、すべての構成の詳細をハードコーディングしました。これは、特定のアプリケーションに対して特定のタスクを実行する多くのプレイブックでは通常のことです。 ただし、複数のアプリケーションをサポートしたり、プレイブックの範囲を広げたい場合、すべてをハードコードすることは意味がありません。

前に見たように、Ansibleはタスク定義とファイルテンプレートの両方で使用できる変数を提供します。 まだ見ていないのは、変数を手動で設定する方法です。 プレイブックの上部で、「+ hosts 」および「 tasks 」パラメーターとともに、「 vars +」パラメーターを定義し、そこで変数を設定できます。

まだ行っていない場合は、前のチュートリアルからディレクトリを「+ ansible-php +」に変更します。

cd ~/ansible-php/

既存のプレイブックを開いて編集します。

nano php.yml

ファイルの先頭は次のようになります。

オリジナルのphp.ymlのトップ

---
- hosts: php
 sudo: yes

 tasks:
. . .

変数を定義するには、「+ hosts 」、「 sudo 」、「 tasks 」と一緒に「 vars 」セクションを追加するだけです。 物事を単純にするために、 ` www-data +`ユーザー名の非常に基本的な変数から始めます。

php.ymlの更新された変数

---
- hosts: php
 sudo: yes




 tasks:
. . .

次に、すべての出現した + www-data`ユーザーを新しい変数 + {{new user}} + `で更新します。 この形式は、ルック内およびルックアップで使用しているため、使い慣れている必要があります。

nanoを使用して検索および置換するには、 `+ CTRL + \ `を押します。 * Search（replace to）：*というプロンプトが表示されます。 * www-data *と入力して、 ` ENTER`を押します。 プロンプトが* Replace with：に変わります。 ここで、「 \ {\ {www user}} *」と入力し、もう一度「+ ENTER」を押します。 Nanoは、 `+ www-data`の各インスタンスを案内し、*このインスタンスを置き換えますか？*と尋ねます。 「+ y 」を押してそれぞれを1つずつ置き換えるか、「 a +」を押してすべてを置き換えることができます。

注：上部に追加した変数宣言も変更されないようにしてください。 置換する必要がある「+ www-data」のインスタンスが11個あるはずです。

先に進む前に、変数に関して注意する必要があることがあります。 通常、長い行内にある場合は、次のように追加できます。

php.ymlのタスク例

- name: create /var/www/ directory
 file: dest=/var/www/ state=directory owner= group= mode=0700

ただし、変数が文字列内の唯一の値である場合、YAMLパーサーがそれを正しく理解できるように、変数を引用符で囲む必要があります。

php.ymlの更新されたタスク

- name: Run artisan migrate
 shell: php /var/www/laravel/artisan migrate --force
 sudo: yes
 sudo_user:
 when: dbpwd.changed

あなたのプレイブックでは、これは `+ sudo_user：{{wwwuser}} +`があればいつでも発生する必要があります。 グローバル検索を使用して同じ方法で置き換え、* sudo_user：\ {\ {wwwuser}} を sudo_user：“ \ {\ {wwwuser}}” *に置き換えます。 この変更を必要とする4行があるはずです。

すべてのオカレンスを変更したら、プレイブックを保存して実行します。

ansible-playbook php.yml --ask-sudo-pass

変更されたタスクはありません。つまり、 `+ wwwuser +`変数は正しく機能しています。

ステップ2-複雑な構成のためのネストされた変数の定義

このセクションでは、複雑な構成オプションの変数のネストについて説明します。

前の手順では、基本的な変数を設定しました。 ただし、変数をネストし、変数のリストを定義することもできます。 これにより、サーバーにセットアップするサイトのリストを定義するために必要な機能が提供されます。

最初に、プレイブックで設定した既存のgitリポジトリについて考えてみましょう。

php.ymlの既存のgitタスク

- name: Clone git repository
 git: >
   dest=/var/www/laravel
   repo=https://github.com/do-community/do-ansible-adv-php.git
   update=yes
   version=example

次の有用な情報を抽出できます：名前（ディレクトリ）、リポジトリ、ブランチ、およびドメイン。 複数のアプリケーションを設定しているため、応答するためにはドメイン名も必要です。 ここでは、「+ laravel.example.com +」を使用しますが、独自のドメインがある場合は、それを置き換えることができます。

この結果、このアプリケーションに対して定義できる次の4つの変数が生成されます。

アプリケーション変数

name: laravel
repository: https://github.com/do-community/do-ansible-adv-php.git
branch: example
domain: laravel.example.com

次に、編集用のプレイブックを開きます。

nano php.yml

上部の `+ vars`セクションで、アプリケーションを新しいアプリケーションリストに追加できます。

php.ymlの更新されたアプリケーション変数

---
- hosts: php
 sudo: yes

 vars:
   wwwuser: www-data







...

すぐにプレイブックを実行する場合（ `+ ansible-playbook php.yml --ask-sudo-pass `を使用）、新しい ` applications `変数を使用するタスクをまだ設定していないため、何も変わりません。 ただし、ブラウザで「 http：//laravel.example.com/+」にアクセスすると、元のアプリケーションが表示されます。

ステップ3-タスク内の変数のループ

このセクションでは、タスク内の変数リストをループする方法を学びます。

前述のように、変数リストは、それらを使用する各タスクでループする必要があります。 `+ install packages +`タスクで見たように、アイテムのループを定義し、リスト内の各アイテムにタスクを適用する必要があります。

編集用にプレイブックを開きます。

nano php.yml

最初にいくつかの簡単なタスクから始めます。 プレイブックの途中で、次の2つの `+ env +`タスクを見つける必要があります。

php.ymlの既存のenvタスク

- name: set APP_DEBUG=false
 lineinfile: dest=/var/www/laravel/.env regexp='^APP_DEBUG=' line=APP_DEBUG=false

- name: set APP_ENV=production
 lineinfile: dest=/var/www/laravel/.env regexp='^APP_ENV=' line=APP_ENV=production

これらは現在、 + laravel +`ディレクトリでハードコーディングされていることに気付くでしょう。 各アプリケーションに `+ name +`プロパティを使用するように更新したいと思います。 これを行うために、 `+ with_items`オプションを追加して、 + applications`リストをループします。 タスク自体の中で、変数 `+ {{item.name}} `の ` laravel +`参照を交換します。これは、以前に使用したフォーマットからおなじみのはずです。

これは次のようになります。

php.ymlの.envタスクを更新しました

- name: set APP_DEBUG=false
 lineinfile: dest=/var/www//.env regexp='^APP_DEBUG=' line=APP_DEBUG=false


- name: set APP_ENV=production
 lineinfile: dest=/var/www//.env regexp='^APP_ENV=' line=APP_ENV=production

次に、2つのLaravel職人cronタスクに移動します。 これらは、 `+ env `タスクで行ったのとまったく同じように更新できます。 Ansibleはこのフィールドを使用して各cronエントリを一意に識別するため、 ` item.name `をcronエントリの ` name +`パラメータに追加します。 そのままにしておくと、同じサーバー上に複数のサイトを持つことができなくなります。それらは常に上書きされ、最後のサイトのみが保存されるからです。

タスクは次のようになります。

php.ymlの更新されたcronタスク

- name: Laravel Scheduler
 cron: >
   job="run-one php /var/www//artisan schedule:run 1>> /dev/null 2>&1"
   state=present
   user={{ wwwuser }}
   name=" php artisan schedule:run"


- name: Laravel Queue Worker
 cron: >
   job="run-one php /var/www//artisan queue:work --daemon --sleep=30 --delay=60 --tries=3 1>> /dev/null 2>&1"
   state=present
   user={{ wwwuser }}
   name=" Laravel Queue Worker"

今すぐプレイブックを保存して実行すると（ `+ ansible-playbook php.yml --ask-sudo-pass `を使用）、更新された2つの更新された ` cron `タスクのみが表示されます。 これは、 ` name +`パラメーターの変更によるものです。 それとは別に、変更はありませんでした。これは、アプリケーションリストが期待どおりに機能しており、プレイブックのリファクタリングの結果としてサーバーにまだ変更が加えられていないことを意味します。

ステップ4-テンプレートでのループ変数の適用

このセクションでは、テンプレートでループ変数を使用する方法について説明します。

テンプレート内の変数のループは非常に簡単です。 これらは、他のすべての変数と同様に、タスクで使用されるのとまったく同じ方法で使用できます。 いくつかの用途では、ファイル名を考慮に入れたり、新しいファイルのために他のコマンドを実行したりする必要があるため、ファイルパスと変数を考慮すると複雑さが生じます。

Nginxの場合、アプリケーションごとに新しい構成ファイルを作成し、Nginxに有効にする必要があることを伝える必要があります。 また、プロセスで元の `+ / etc / nginx / sites-available / default +`設定ファイルを削除します。

まず、編集用のプレイブックを開きます。

nano php.yml

`+ Configure Nginx +`タスク（プレイブックの中央付近）を見つけ、他のタスクで行ったように更新します：

php.ymlのnginxタスクを更新しました

- name: Configure nginx
 template: src=nginx.conf dest=/etc/nginx/sites-available/

 notify:
   - restart php5-fpm
   - restart nginx

ここにいる間に、上記のタスクをさらに2つ追加します。 最初に、新しいサイト構成ファイルについてNginxに通知します。 これは、 `+ / var / nginx / `の ` sites-available `ディレクトリと ` sites-enabled +`ディレクトリ間のシンボリックリンクで行われます。

`+ Configure nginx +`タスクの後にこのタスクを追加します：

php.ymlの新しいsymlinkタスク

- name: Configure nginx symlink
 file: src=/etc/nginx/sites-available/{{ item.name }} dest=/etc/nginx/sites-enabled/{{ item.name }} state=link
 with_items: applications
 notify:
   - restart php5-fpm
   - restart nginx

次に、 `+ default `対応のサイト構成ファイルを削除して、新しいサイト構成ファイルで問題が発生しないようにします。 これは ` file`モジュールで簡単にできます：

新しいファイルタスクphp.yml

- name: Remove default nginx site
 file: path=/etc/nginx/sites-enabled/default state=absent
 notify:
   - restart php5-fpm
   - restart nginx

単一のファイルを探しているので、 `+ applications +`をループする必要がないことに注意してください。

プレイブックのNginxブロックは次のようになります。

php.ymlで更新されたnginxタスク

- name: Configure nginx
 template: src=nginx.conf dest=/etc/nginx/sites-available/{{ item.name }}
 with_items: applications
 notify:
   - restart php5-fpm
   - restart nginx

- name: Configure nginx symlink
 file: src=/etc/nginx/sites-available/{{ item.name }} dest=/etc/nginx/sites-enabled/{{ item.name }} state=link
 with_items: applications
 notify:
   - restart php5-fpm
   - restart nginx

- name: Remove default nginx site
 file: path=/etc/nginx/sites-enabled/default state=absent
 notify:
   - restart php5-fpm
   - restart nginx

プレイブックを保存し、編集のために `+ nginx.conf`ファイルを開きます：

nano nginx.conf

変数を使用するように構成ファイルを更新します。

更新されたnginx.conf

server {
   listen 80 default_server;
   listen [::]:80 default_server ipv6only=on;

   root /var/www//public;
   index index.php index.html index.htm;

   server_name ;

   location / {
       try_files $uri $uri/ =404;
   }

   error_page 404 /404.html;
   error_page 500 502 503 504 /50x.html;
   location = /50x.html {
       root /var/www//public;
   }

   location ~ \.php$ {
       try_files $uri =404;
       fastcgi_split_path_info ^(.+\.php)(/.+)$;
       fastcgi_pass unix:/var/run/php5-fpm.sock;
       fastcgi_index index.php;
       fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
       include fastcgi_params;
   }
}

しかし、まだ終わっていません。 上部の `+ default_server `に注目してください。 デフォルトにするために、 ` laravel `アプリケーションにのみそれを含めたいです。 これを行うには、基本的なIFステートメントを使用して、「 item.name」が「+ laravel」と等しいかどうかを確認し、等しい場合は「+ default_server」を表示します。

これは次のようになります。

条件付きでnginx.confを更新

server {
   listen ;
   listen [::]:80;

それに応じて、 `+ nginx.conf +`を更新して保存します。

ここで、プレイブックを実行します。

ansible-playbook php.yml --ask-sudo-pass

Nginxタスクが変更済みとしてマークされていることに注意してください。 実行が終了したら、ブラウザでサイトを更新すると、前回のチュートリアルの最後に表示したものと同じように表示されるはずです。

http://laravel.example.com/

Queue: YES
Cron: YES

ステップ5-複数の変数を一緒にループする

このステップでは、タスクで複数の変数を一緒にループします。

今度は、より複雑なループの例、具体的には登録された変数に取り組むときです。 さまざまな状態をサポートし、タスクが不必要に実行されるのを防ぐために、_Clone git repository_タスクで `+ register：clone `を使用して変数 ` cloned `をタスクの状態に登録したことを思い出してください。 次に、次のタスクで「 when：cloneed | changed +」を使用して、タスクを条件付きでトリガーしました。 ここで、これらの参照を更新して、アプリケーションループをサポートする必要があります。

まず、編集用のプレイブックを開きます。

nano php.yml

_ gitリポジトリのクローン_タスクを探します：

php.ymlの既存のgitタスク

- name: Clone git repository
 git: >
   dest=/var/www/laravel
   repo=https://github.com/do-community/do-ansible-adv-php.git
   update=yes
   version=example
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 register: cloned

このタスクで変数を登録しているので、まだ行っていないことをする必要はありません。

php.ymlのgitタスクを更新

- name: Clone git repository
 git: >
   dest=/var/www/
   repo=
   update=yes
   version=
 sudo: yes
 sudo_user: "{{ wwwuser }}"

 register: cloned

次に、 `+ composer create-project`タスクが見つかるまで、プレイブックを下に移動します。

php.ymlの元の作曲家タスク

- name: composer create-project
 composer: command=create-project working_dir=/var/www/laravel optimize_autoloader=no
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when: cloned|changed

ここで、「+ applications 」と「 cloned 」の両方をループするように更新する必要があります。 これは、「 with_together」オプションを使用して行われ、「+ applications」と「+ cloned」の両方を渡します。 `+ with_together `は2つの変数をループするため、アイテムへのアクセスは ` item。＃`で行われます。ここで、 `＃+`は定義された変数のインデックスです。 だから、例えば：

with_together:
- list_one
- list_two

`+ item.0 `は ` list_one `を参照し、 ` item.1 `は ` list_two +`を参照します。

つまり、 + applications`の場合、 + item.0.name`を介してプロパティにアクセスできます。 `+ cloned `の場合、 ` cloned.results `からアクセスできるタスクからの結果を渡す必要があり、 ` item.1.changed +`で変更されたかどうかを確認できます。

これは、タスクが次のようになることを意味します。

php.ymlの作曲家タスクを更新

- name: composer create-project
 composer: command=create-project working_dir=/var/www/ optimize_autoloader=no
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when:

プレイブックを保存して実行します。

ansible-playbook php.yml --ask-sudo-pass

この実行による変更はありません。 ただし、ループ内で正常に動作する登録済み変数があります。

ステップ6-登録された複雑な変数とループ

このセクションでは、より複雑な登録変数とループについて学習します。

変換の最も複雑な部分は、MySQLデータベースのパスワード生成に使用している登録済み変数の処理です。 とはいえ、このステップではまだ説明していないことは多くなく、一度にいくつかのタスクを更新するだけです。

編集用にプレイブックを開きます。

nano php.yml

MySQLタスクを見つけ、最初のパスで、前のタスクで行ったように基本変数を追加します。

php.ymlのMySQLタスクを更新しました

- name: Create MySQL DB
 mysql_db: name= state=present


- name: Generate DB password
 shell: makepasswd --chars=32
 args:
   creates: /var/www//.dbpw

 register: dbpwd

- name: Create MySQL User
 mysql_user: name= password={{ dbpwd.stdout }} priv=.*:ALL state=present
 when: dbpwd.changed

- name: set DB_DATABASE
 lineinfile: dest=/var/www//.env regexp='^DB_DATABASE=' line=DB_DATABASE=


- name: set DB_USERNAME
 lineinfile: dest=/var/www//.env regexp='^DB_USERNAME=' line=DB_USERNAME=


- name: set DB_PASSWORD
 lineinfile: dest=/var/www//.env regexp='^DB_PASSWORD=' line=DB_PASSWORD={{ dbpwd.stdout }}
 when: dbpwd.changed

- name: Save dbpw file
 lineinfile: dest=/var/www//.dbpw line="{{ dbpwd.stdout }}" create=yes state=present
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when: dbpwd.changed

- name: Run artisan migrate
 shell: php /var/www//artisan migrate --force
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when: dbpwd.changed

次に、データベースパスワードを使用できるように、「+ with_together 」を追加します。 パスワードの生成には、「 db pwd.results」をループする必要があり、「+ item.0」を介して「+ applications」にアクセスするため、「+ item.1.stdout」からパスワードにアクセスできるようになります。 + `。

それに応じて、プレイブックを更新できます。

php.ymlのMySQLタスクを更新しました

- name: Create MySQL DB
 mysql_db: name={{ item.name }} state=present
 with_items: applications

- name: Generate DB password
 shell: makepasswd --chars=32
 args:
   creates: /var/www/{{ item.name }}/.dbpw
 with_items: applications
 register: dbpwd

- name: Create MySQL User
 mysql_user: name={{  }} password={{  }} priv={{  }}.*:ALL state=present
 when:




- name: set DB_DATABASE
 lineinfile: dest=/var/www/{{ item.name }}/.env regexp='^DB_DATABASE=' line=DB_DATABASE={{ item.name }}
 with_items: applications

- name: set DB_USERNAME
 lineinfile: dest=/var/www/{{ item.name }}/.env regexp='^DB_USERNAME=' line=DB_USERNAME={{ item.name }}
 with_items: applications

- name: set DB_PASSWORD
 lineinfile: dest=/var/www/{{  }}/.env regexp='^DB_PASSWORD=' line=DB_PASSWORD={{  }}
 when:




- name: Save dbpw file
 lineinfile: dest=/var/www/{{  }}/.dbpw line="{{  }}" create=yes state=present
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when:




- name: Run artisan migrate
 shell: php /var/www/{{  }}/artisan migrate --force
 sudo: yes
 sudo_user: "{{ wwwuser }}"
 when:

プレイブックを更新したら、保存して実行します。

ansible-playbook php.yml --ask-sudo-pass

プレイブックに加えたすべての変更にもかかわらず、データベースタスクに変更はありません。 この手順の変更により、単一のアプリケーションプレイブックから複数のアプリケーションプレイブックへの変換が完了しているはずです。

手順7-アプリケーションの追加

この手順では、プレイブックでさらに2つのアプリケーションを構成します。

変数を使用してアプリケーションを定義するようにプレイブックをリファクタリングしたので、サーバーに新しいアプリケーションを追加するプロセスは非常に簡単です。 それらを `+ applications +`変数リストに追加するだけです。 これは、Ansible変数の力が本当に輝く場所です。

編集用にプレイブックを開きます。

nano php.yml

上部の `+ vars `セクションで、 ` applications +`ブロックを見つけます：

php.ymlの既存のアプリケーション変数

applications:
 - name: laravel
   domain: laravel.example.com
   repository: https://github.com/do-community/do-ansible-adv-php.git
   branch: example

さらに2つのアプリケーションを追加します。

php.ymlの更新されたアプリケーション変数

applications:
 - name: laravel
   domain: laravel.example.com
   repository: https://github.com/do-community/do-ansible-adv-php.git
   branch: example

プレイブックを保存します。

これで、プレイブックを実行する時間です：

ansible-playbook php.yml --ask-sudo-pass

コンポーザーが新しいアプリケーションをセットアップするため、このステップには時間がかかる場合があります。 終了すると、いくつかのタスクが変更されていることに気付くでしょう。注意深く見ると、ループされた各アイテムがリストされていることがわかります。 最初に、元のアプリケーションは「+ ok 」または「 skipped 」と言う必要がありますが、新しい2つのアプリケーションは「 changed +」と言う必要があります。

さらに重要なことは、Webブラウザーで構成済みサイトの3つのドメインすべてにアクセスすると、3つの異なるWebサイトに気付くはずです。

最初のものはおなじみのはずです。 他の2つは表示するはずです：

http://one.example.com/

This is example app one!

and

http://two.example.com/

This is example app two!

これで、アプリケーションリストを更新するだけで、2つの新しいWebアプリケーションをデプロイしました。

ステップ8-ホスト変数の使用

このステップでは、変数をホスト変数に抽出します。

一歩下がって、プレイブック変数は良いのですが、同じプレイブックを使用して異なるサーバーに異なるアプリケーションをデプロイしたい場合はどうでしょうか？ 各サーバーで条件付きチェックを実行して、どのサーバーがタスクを実行しているかを調べることもできますし、_host variables_を使用することもできます。 ホスト変数とは、プレイブック全体のすべてのホストではなく、特定のホストに適用される変数です。

ホスト変数は、 `+ ansible_ssh_user `変数で行ったように、 ` hosts `ファイル内でインラインで定義できます。または、 ` host_vars +`ディレクトリ内の各ホストの専用ファイルで定義できます。

まず、 `+ hosts `ファイルとプレイブックと一緒に新しいディレクトリを作成します。 ディレクトリ ` host_vars +`を呼び出します：

mkdir host_vars

次に、ホスト用のファイルを作成する必要があります。 Ansibleが使用する規則は、ファイル名が `+ hosts `ファイルのホスト名と一致することです。 したがって、たとえば、 ` hosts +`ファイルが次のようになっている場合：

Ansibleホストファイル

[php]
ansible_ssh_user=sammy

次に、 `+ host_vars / your_first_server_ip +`というファイルを作成する必要があります。 それを今すぐ作成しましょう：

nano host_vars/

プレイブックと同様に、ホストファイルはフォーマットにYAMLを使用します。 つまり、 `+ applications`リストを新しいホストファイルにコピーできるため、次のようになります。

新しいhost_vars / your_first_server_ipファイル

---
applications:
 - name: laravel
   domain: laravel.example.com
   repository: https://github.com/do-community/do-ansible-adv-php.git
   branch: example

 - name: one
   domain: one.example.com
   repository: https://github.com/do-community/do-ansible-php-example-one.git
   branch: master

 - name: two
   domain: two.example.com
   repository: https://github.com/do-community/do-ansible-php-example-two.git
   branch: master

新しいホストファイルを保存し、編集用にプレイブックを開きます。

nano php.yml

トップを更新して、「+ applications +」セクション全体を削除します。

php.ymlのトップを更新

---
- hosts: php
 sudo: yes

 vars:
   wwwuser: www-data

 tasks:
. . .

プレイブックを保存して実行します。

ansible-playbook php.yml --ask-sudo-pass

変数をプレイブックからホストファイルに移動しましたが、出力はまったく同じに見えるはずであり、Ansibleによって報告される変更はないはずです。 ご覧のとおり、 `+ host_vars `は、プレイブックの ` vars +`とまったく同じように機能します。それらはホストに固有です。

`+ host_vars +`ファイルで定義された変数は、サーバーを管理するすべてのプレイブックからもアクセスできます。これは、一般的なオプションと設定に役立ちます。 ただし、異なるプレイブック間で異なることを意味する一般的な名前を使用しないように注意してください。

手順9-別のサーバーへのアプリケーションの展開

この手順では、新しいホストファイルを利用して、2番目のサーバーにアプリケーションを展開します。

最初に、新しいホストで `+ hosts`ファイルを更新する必要があります。 編集用に開きます。

nano hosts

そして、新しいホストを追加します。

Ansibleホストファイル

[php]
your_first_server_ip ansible_ssh_user=sammy
ansible_ssh_user=

ファイルを保存して閉じます。

次に、最初の場合と同様に、新しいホストファイルを作成する必要があります。

nano host_vars/

サンプルアプリケーションを1つ以上選択して、ホストファイルに追加できます。 たとえば、元の例と例2を新しいサーバーに展開する場合は、次を使用できます。

新しいhost_vars / your_second_server_ipファイル

---
applications:
 - name: laravel
   domain: laravel.example2.com
   repository: https://github.com/do-community/do-ansible-adv-php.git
   branch: example

 - name: two
   domain: two.example2.com
   repository: https://github.com/do-community/do-ansible-php-example-two.git
   branch: master

プレイブックを保存します。

最後に、プレイブックを実行できます。

ansible-playbook php.yml --ask-sudo-pass

Ansibleは2番目のサーバーですべてを設定しているため、実行に時間がかかります。 終了したら、ブラウザで選択したアプリケーションを開き（この例では、 `+ laravel.example2.com `と ` two.example2.com +`を使用）、正しく設定されていることを確認します。 ホストファイル用に選択した特定のアプリケーションが表示され、元のサーバーに変更はありません。

結論

このチュートリアルでは、完全に機能する単一アプリケーションプレイブックを取り上げ、複数のサーバーで複数のアプリケーションをサポートするように変換しました。 前のチュートリアルで説明したトピックと組み合わせることで、アプリケーションをデプロイするための完全なプレイブックを作成するために必要なものがすべて揃うはずです。 前のチュートリアルに従って、SSHを使用してサーバーに直接ログインしていません。

プレイブックの構造が完成したら、アプリケーションと別のサーバーを追加するのがいかに簡単であるかに気付くでしょう。 これがAnsibleのパワーであり、Ansibleを非常に柔軟で使いやすいものにします。

Related