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

投稿日: 2022-07-31 2022-07-31
タグ: Ansible, ubuntu

序章

このチュートリアルは、Ubuntu14.04でAnsibleを使用してPHPアプリケーションをデプロイすることに関するシリーズの3番目です。最初のチュートリアルでは、アプリケーションをデプロイするための基本的な手順について説明します。 2番目のチュートリアルは、データベース、キューデーモン、タスクスケジューラ（cron）などのより高度なトピックをカバーしています。

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

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

前提条件

このチュートリアルに従うには、次のものが必要です。

このシリーズのfirstおよびsecondチュートリアルに従ってセットアップされた2つのドロップレット。
最初のチュートリアルの元のPHPドロップレットのようにセットアップされた新しい（3番目の）Ubuntu 14.04ドロップレットで、sudo非rootユーザーとSSHキーを使用します。このドロップレットは、1つのAnsibleプレイブックを使用して複数のアプリケーションを複数のサーバーにデプロイする方法を示すために使用されます。元のPHPドロップレットとこの新しいPHPドロップレットのIPアドレスを、それぞれyour_first_server_ipとyour_second_server_ipと呼びます。
次の行が追加された、ローカルコンピューター上の更新された/etc/hostsファイル。このファイルの詳細については、このチュートリアルのステップ6を参照してください。

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

your_first_server_ip laravel.example.com one.example.com two.example.com
your_second_server_ip laravel.example2.com two.example2.com

このチュートリアルで使用するWebサイトの例は、laravel.example.com、one.example.com、およびtwo.example.comです。独自のドメインを使用する場合は、代わりにアクティブDNSレコードを更新する必要があります。

ステップ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

  vars:
    wwwuser: www-data

  tasks:
. . .

次に、www-dataユーザーのすべての出現箇所を調べて、新しい変数{{ wwwuser }}で更新します。この形式は、ルック内およびルックアップで使用したため、おなじみのはずです。

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

注：上部に追加した変数宣言も変更されていないことを確認してください。交換が必要なwww-dataのインスタンスが11個あるはずです。

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

php.ymlのタスク例

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

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

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

- name: Run artisan migrate
  shell: php /var/www/laravel/artisan migrate --force
  sudo: yes
  sudo_user: "{{ wwwuser }}"
  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

    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を使用）、新しい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リストをループします。タスク自体の中で、laravel参照を変数{{ item.name }}に交換します。これは、以前に使用した形式からおなじみのはずです。

次のようになります。

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

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

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

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

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

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

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

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

今すぐプレイブックを保存して実行すると（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/{{ item.name }}
  with_items: applications
  notify:
    - restart php5-fpm
    - restart nginx

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

Configure nginxタスクの後に次のタスクを追加します。

php.ymlの新しいシンボリックリンクタスク

- 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/{{ item.name }}/public;
    index index.php index.html index.htm;

    server_name {{ item.domain }};

    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/{{ item.name }}/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 80{% if item.name == "laravel" %} default_server{% endif %};
    listen [::]:80{% if item.name == "laravel" %} default_server ipv6only=on{% endif %};

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

次に、プレイブックを実行します。

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

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

http://laravel.example.com/

Queue: YES
Cron: YES

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

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

次に、より複雑なループの例、具体的には登録された変数に取り組みます。さまざまな状態をサポートし、タスクが不必要に実行されるのを防ぐために、 Clone git repositoryタスクでregister: clonedを使用して、変数clonedを状態に登録したことを思い出してください。タスクの。次に、次のタスクでwhen: cloned|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/{{ item.name }}
    repo={{ item.repository }}
    update=yes
    version={{ item.branch }}
  sudo: yes
  sudo_user: "{{ wwwuser }}"
  with_items: applications
  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のcomposerタスクを更新しました

- name: composer create-project
  composer: command=create-project working_dir=/var/www/{{ item.0.name }} optimize_autoloader=no
  sudo: yes
  sudo_user: "{{ wwwuser }}"
  when: item.1.changed
  with_together:
    - applications
    - cloned.results

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

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

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

ステップ6—複雑な登録変数とループ

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

変換の最も複雑な部分は、MySQLデータベースのパスワード生成に使用している登録変数の処理です。とは言うものの、このステップで実行しなければならないことはまだ説明していません。一度にいくつかのタスクを更新する必要があります。

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

nano php.yml

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

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={{ item.name }} password={{ dbpwd.stdout }} priv={{ item.name }}.*:ALL state=present
  when: dbpwd.changed

- 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/{{ item.name }}/.env regexp='^DB_PASSWORD=' line=DB_PASSWORD={{ dbpwd.stdout }}
  when: dbpwd.changed

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

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

次に、with_togetherを追加して、データベースのパスワードを使用できるようにします。パスワード生成では、dbpwd.resultsをループする必要があり、applicationsはitem.0経由でアクセスされるため、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={{ item.0.name }} password={{ item.1.stdout }} priv={{ item.0.name }}.*:ALL state=present
  when: item.1.changed
  with_together:
  - applications
  - dbpwd.results

- 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/{{ item.0.name }}/.env regexp='^DB_PASSWORD=' line=DB_PASSWORD={{ item.1.stdout }}
  when: item.1.changed
  with_together:
  - applications
  - dbpwd.results

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

- name: Run artisan migrate
  shell: php /var/www/{{ item.0.name }}/artisan migrate --force
  sudo: yes
  sudo_user: "{{ wwwuser }}"
  when: item.1.changed
  with_together:
  - applications
  - dbpwd.results

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

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

  - 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

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

次に、プレイブックを実行します。

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

この手順は、composerが新しいアプリケーションをセットアップするときに時間がかかる場合があります。完了すると、いくつかのタスクが変更されていることに気付くでしょう。注意深く見ると、ループされた各アイテムが一覧表示されていることがわかります。最初に、元のアプリケーションはokまたはskippedと表示され、新しい2つのアプリケーションはchangedと表示されます。

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

最初のものは見覚えがあるはずです。他の2つは次のように表示されます。

http://one.example.com/

This is example app one!

と

http://two.example.com/

This is example app two!

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

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

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

一歩後退すると、プレイブック変数は優れていますが、同じプレイブックを使用してさまざまなアプリケーションをさまざまなサーバーにデプロイする場合はどうでしょうか。各タスクに対して条件付きチェックを実行して、タスクを実行しているサーバーを特定するか、ホスト変数を使用できます。ホスト変数は、そのように聞こえます。つまり、プレイブック全体のすべてのホストではなく、特定のホストに適用される変数です。

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

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

mkdir host_vars

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

Ansiblehostsファイル

[php]
your_first_server_ip ansible_ssh_user=sammy

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

nano host_vars/your_first_server_ip

プレイブックと同様に、ホストファイルはフォーマットに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

新しいhostsファイルを保存し、プレイブックを開いて編集します。

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

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

Ansiblehostsファイル

[php]
your_first_server_ip ansible_ssh_user=sammy
your_second_server_ip ansible_ssh_user=sammy

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

次に、最初に行ったように、新しいhostsファイルを作成する必要があります。

nano host_vars/your_second_server_ip

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の力であり、非常に柔軟で使いやすいものになっています。

getdocs

13036