81
速習!Ansible で Infrastructure as Code 2017/4/13 TAkeshi Kuramochi

速習!Ansible で - crash.academy · 自分で作る ... 本書は、ハンズオンをご自身の環境で行うための手引書です。 2つのパートに分かれています。

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

速習!Ansible で

Infrastructure as Code

2017/4/13

TAkeshi Kuramochi

2012 2014 2015 2016 2017

Ansible 誕生

Infrastructure as Code 社内外にて啓蒙

TIS Storage Vendor

Ansible 本格活用

with OpenStack and

Docker

『OSS+Storage』という観点で

PreSales , BizDev , R&Dを担当

Hadoop , OpenStack

インフラ技術本部でOSS推進担当中

Ansible と私

2013

・・・ SoftwareDesign

11/2014

Infrastructure

As Code

Ansible が注目される理由

Infrastructure as Code 構成管理+自動化+テスト+CI+CD

クラウドインフラ ソフトウェア化されたインフラ(Server,Network,Storage..)

ソフトウェアシステムで既に有効であると立証されているベストプラクティスをインフラにも同じように適用し、その恩恵を受ける事ができる。 (バージョン管理・繰り返し可能なビルド・テスト・CI・CD・・・)

今、これらを実現する簡単なソフトウェアや、管理ツールが充実

使うべき!

これまでのシステム構築・保守・運用

構築 OS設定

各種デバイス設定 通信設定(ドメイン、NTP、)

ミドルウェアインストール・設定

アプリケーションデプロイ

・・・

保守・運用 各種設定変更

アップデート

パッケージ導入

アカウント管理

アプリケーションデプロイ

・・・

■ 複数台作業による工数リニアに増加 ■ スクリプトを組んだとしても、汎用性を維持するのは困難 ■ 繰り返し作業による、人的ミスの誘発 ■ 運用者が変わった場合の引き継ぎの複雑性 ■ 設計書・手順書 と 実際の状態 との管理が複雑化

課題点

本日のアジェンダ 1. Ansible とは

2. 特徴

3. 使い方

4. YAML

5. 勢い

6. 参考

7. ハンズオン

一言で、

システム構築・運用において、

人が 楽 できる

簡単 な 自動化エンジン

何を自動化するか?

システムコンフィグレーション

オーケストレーション

アプリケーションデプロイメント

プロビジョニング アクティビティ

アプリケーションサービス デプロイメント

システムコンフィグレーション

クラウド、 VM、コンテナ起動

OS

インストレーション

Orchestration

Configuration

Bootstrapping

AWS Cobbler

OpenStack

Kickstart VMware

Capistrano

Fabric

Puppet

Chef

Azure

引用元:Provisioning Toolchain (Velocity2010) by Lee Thompson

Docker

Ansible

Ansible の特徴

Source : https://www.ansible.com/it-automation

SIMPLE

複雑ではない

インストールも習得も簡単!

共通 “言語”

スグに達人!

参考図書でみる学習コストの差

某OSS・・・400頁 or 670頁

Ansible・・・112頁

AGENTLESS

余計な導入物不要

セキュア

スグ試行

スグ本番適用

UNIX/Linux の場合

構成される側にエージェント不要

SSH 接続

Python 必要

SSH

構成される側 UNIX/Linux

Windows の場合

構成される側にエージェント不要

HTTP/HTTPS 接続

PowerShell 3.0以上必要

WinRM

構成される側 Windows

POWERFUL

自動化カバー範囲の多様さ

OS

ミドルウェア・各種ソフトウェア

ハードウェア

クラウド

Docker

冪等性(べきとうせい)

自動化カバー範囲(一部) OSの設定 ファイル編集 ファイルダウンロード アプリケーションやサービスの起動 クラウドイメージの管理(起動・停止など) 通知・ジョブ設定 ネットワーク機器設定 ストレージ機器設定 コマンド・シェル実行 コンテナコンフィグレーション・コントロール etc..

準備

必要なマシン Ansible がインストールされているマシン

必要なファイル Inventory(インベントリ) Playbook(プレイブック)

Inventory : hosts

Playbook : playbook.yml

Inventory

「何(対象物)に?」を示すファイル

192.168.2.200

hoge.example.co.jp

192.168.3.200

[webservers]

192.168.2.200

192.168.3.200

http://docs.ansible.com/intro_inventory.html

Playbook

「何を?(どんな状態に?)」を書いたファイル

“YAML”というデータ・フォーマット

http://docs.ansible.com/playbooks_intro.html

---

- hosts: webservers

become: true

become_user: root

tasks:

- name: install apache

yum: pkg=httpd state=present

- name: start apache

service: name=httpd state=started enabled=yes

文章で書くと、「 webservers(192.168.2.200と192.168.3.200)に対して、スーパーユーザで yum を使って httpd をイ

ンストールし、 起動(次回再起動時も起動するように設定)」

yum: pkg=httpd state=present

実行

ansible-playbook コマンド実行

$ ansible-playbook -i hosts playbook.yml PLAY [192.168.2.200] ********************************************************** GATHERING FACTS *************************************************************** ok: [192.168.2.20] : : PLAY RECAP ******************************************************************** 192.168.2.20 : ok=2 changed=2 unreachable=0 failed=0

SSH # yum install httpd # service httpd start # chkconfig httpd on (or systemctl enabled httpd )

構成される側

YAML とは

データフォーマット

XMLやJSON と同じ類

人にやさしい よく見慣れた箇条書きに酷似

行指向で可読性優先 人が書いてソフトウェアが読むのに最適

(例) ・ 対象のサーバは、ABC

・ 設定項目は、MY ANSIBLE

・ IPアドレスは、192.168.0.2 ・ 処理内容

- 2つのパッケージを最新バージョンでインストール - パッケージは、expectとgit

YAML とは

データフォーマット

XMLやJSON と同じ類

人にやさしい よく見慣れた箇条書きに酷似

行指向で可読性優先 人が書いてソフトウェアが読むのに最適

(例) ・ 対象のサーバは、ABC

・ 設定項目は、MY ANSIBLE

・ IPアドレスは、192.168.0.2 ・ 処理内容

- 2つのパッケージを最新バージョンでインストール - パッケージは、expectとgit

YAML の中身

ファイル・ストリーム ( --- )で始まる(1文書なら省略可)

( --- )で切る

( --- )で終わる(省略可)

コメント “#”から行末までコメント

型 シーケンス( - )・・・ リスト

マッピング( : )・・・ ハッシュ、連想配列

スカラー・・・値、スカラー型は様々

--- - hosts: “{{ target }}” vars: name: “MY ANSIBLE” server_ip_addr: 192.168.0.2 tasks: - name: Package Install apt: pkg={{ item }} state=latest with_items: - expect - git

YAML の注意点

タブを使うのはタブー

2スペースインデント

サンプルを見ながら、書きながら感覚をつかむ

--- -+hosts:+“{{ target }}” ++vars: ++++name:+“MY ANSIBLE” ++++server_ip_addr:+192.168.0.2

Ansible 使っていくと・・・

台数や処理数が増えたら・・・

Playbook ファイルの分割や役割毎にまとめる (include , Role)

標準で出来ないことがあったら・・・

自分で作る (module)

巨人の肩の上に立つ

Role を公開している人が大勢

Ansible のトレンドは?

2012/4 2013/10 2015/3 2016/9 NOW

Global

Google Trend(https://trends.google.co.jp)2017/4/12調べ

Googleでのトレンドの推移(2012~Now) Ansible Chef Puppet SaltStack

Global

Japan

Google Trend(https://trends.google.co.jp)より 2017/1/23調べ

Googleでのトレンドの推移(Japan) Ansible Chef Puppet SaltStack

レッドハット社によるAnsible買収 2014~Now

過去1年

Google Trend(https://trends.google.co.jp)より 2017/1/23調べ

Ansible Galaxy(OSS化 , 2016/10)

2015/6・・・2600

2016/5・・・6296

2017/4・・・11022

https://galaxy.ansible.com , https://github.com/ansible/galaxy

Ansible Tower

現在、有償製品だがOSS化が予定されている! Source : https://www.ansible.com/tower

エンタープライズ志向

ネットワーク機器の対応 Cisco、Juniper、F5、A10、・・・

ストレージ機器の対応 NetApp、INFINIDAT

Windows の対応

クラウド の対応

Docker の対応

入門 Ansible 若山 史郎著

DevOps 導入指南 Infrastructure as Codeでチーム開発・サービス運用を効率化する

参考図書

参考Web

ドキュメント

http://docs.ansible.com

GitHub

https://github.com/ansible

ML http://groups.google.com/group/ansible-project

http://groups.google.com/group/ansible-devel

http://groups.google.com/group/ansible-announce

まとめ

楽=私達の貴重な『 時間 』を作るツール

SIMPLE 、 AGENTLESS 、 POWERFUL

エンタープライズ要素も盛り沢山!

あえぇんしぼー

( Ansible )

発音

速習!Ansible で

Infrastructure as Code 後半

ハンズオンテキスト

2017/4/13

TAkeshi Kuramochi

本書は、ハンズオンをご自身の環境で行うための手引書です。

2つのパートに分かれています。

準備編

ハンズオン入門編

確認済みの環境

*実施の際、インターネットにつながるPCをご用意ください。

本書について

VirtualBox Vagrant Ansible

5.0.24 1.74 1.9~v2.3

ハンズオンのゴール

AP

Web

DB

PHP

Apache

MariaDB

1.VirtualBox & Vagrant のインストール

2.VM の起動

-Windows PCの場合

-OS X or Linux PCの場合

3.“host”と“blog”間の SSH 接続の準備

4.Ansible のインストール

準備ステップ

VirtualBox

https://www.virtualbox.org/wiki/Downloads

上記URLから、自身の環境に該当するパッケージ(VirtualBox platform packages)をダウンロードしてインストールします。

Vagrant

https://www.vagrantup.com/downloads.html

上記のURLから、自身の環境に該当するパッケージをダウンロードしてインストールします。

VirtualBox & Vagrant のインストール

適当なディレクトリを作成

vagrant init により初期化

Vagrantfile の編集

次のページで、ファイル操作も含めてコマンドで示していますがディレクトリやファイル編集は普通にGUIで実施いただいてもかまいません。

VMの起動 Window PCの場合

VMの起動 Window PCの場合 C:¥> mkdir handson C:¥> cd handson C:¥> vagrant init C:¥handson> type Vagrantfile

Vagrant.configure(2) do |config| config.vm.define "host" do |node| node.vm.box = "ubuntu/trusty64" node.vm.hostname = "host" node.vm.network :private_network, ip: "192.168.2.10" end config.vm.define "blog" do |node| node.vm.box = "bento/centos-7.2" node.vm.hostname = "blog" node.vm.network :private_network, ip: "192.168.2.20" end end

起動には vagrant コマンドを使います。vagrant up を実行して VM を起動します。

それぞれ、running となっていれば OK です。

VMの起動 Window PCの場合

C:¥handson> vagrant up C:¥handson> vagrant status Current machine states: host running (virtualbox) blog running (virtualbox) This environment represents multiple VMs. The VMs are all listed above with their current state. For more information about a specific VM, run `vagrant status NAME`.

Windows PC の方は Windows から VM にアクセスするために下記のようなターミナルソフトをご導入願います。(既にインストール済みの方は不要です。)Putty というツールでも構いません。ここでは TeraTerm の例を挙げます。

TeraTerm

http://sourceforge.jp/projects/ttssh2/

Windows PC からその上で稼働する VM へアクセスする方法

TeraTermを起動します。

右のように値を入れて「OK」を押します。

ホスト:127.0.0.1

TCPポート#(P):2222

サービス:SSH

Windows PC からその上で稼働する VM へアクセスする方法

「続行」を押します。

Windows PC からその上で稼働する VM へアクセスする方法

右のように値を入れて「OK」を押します。

ユーザ名:vagrant

パスフレーズ:vagrant

Windows PC からその上で稼働する VM へアクセスする方法

これで、host に接続されました。

(blogに接続する場合は、途中TCPポート#(P)が2200となります。)

Windows PC からその上で稼働する VM へアクセスする方法

適当なディレクトリを作成

vagrant init により初期化

Vagrantfile の編集

VMの起動 OS X or Linux PCの場合

VMの起動 OS X or Linux PCの場合 $ mkdir handson $ cd handson $ vagrant init $ vi Vagrantfile Vagrant.configure(2) do |config| config.vm.define "host" do |node| node.vm.box = "ubuntu/trusty64" node.vm.hostname = "host" node.vm.network :private_network, ip: "192.168.3.10" end config.vm.define "blog" do |node| node.vm.box = "bento/centos-7.2" node.vm.hostname = "blog" node.vm.network :private_network, ip: "192.168.3.20" end end

起動には vagrant コマンドを使います。vagrant up を実行して VM を起動します。

それぞれ、running となっていれば OK です。

VMの起動 OS X or Linux PCの場合

$ pwd /home/hoge/handson $ vagrant up $ vagrant status Current machine states: host running (virtualbox) blog running (virtualbox) This environment represents multiple VMs. The VMs are all listed above with their current state. For more information about a specific VM, run `vagrant status NAME`.

以下のようにしてログインします。これは vagrant ユーザで host や blog に ssh でログインしている事と同じです。

OS X or Linux PCからその上で稼働する VM へアクセスする方法

hostにログイン・・・ $ vagrant ssh vagrant@host (略) vagrant@host:~$ blogにログイン・・・ $ vagrant ssh vagrant@blog (略) vagrant@host:~$

host 側で下記のように ~/.ssh/config をセットし、SSH の鍵を作ります。パスフレーズは空(そのまま Enter )でかまいません。

“host”と“blog”間の SSH 接続の準備

vagrant@host:~$ cat ~/.ssh/config Host blog HostName 192.168.2.20 vagrant@host:~$ chmod 600 .ssh/config vagrant@host:~$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/vagrant/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/vagrant/.ssh/id_rsa. Your public key has been saved in /home/vagrant/.ssh/id_rsa.pub. The key fingerprint is: eb:7c:1c:c3:9d:4d:1b:16:fb:f8:dd:cb:72:8b:a9:49 vagrant@host The key's randomart image is: +--[ RSA 2048]----+ | | ###(省略)

公開鍵の方を blog の方にコピーします。

“host”と“blog”間の SSH 接続の準備

vagrant@host:~$ ssh-copy-id vagrant@blog The authenticity of host '192.168.2.20 (192.168.2.20)' can't be established. ECDSA key fingerprint is 7c:29:da:58:13:bd:46:67:5b:8b:c6:58:f6:b9:d5:40. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys [email protected]'s password: (vagrant ユーザのパスワードは "vagrant" です) Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'blog'" and check to make sure that only the key(s) you wanted were added.

これで host 側から blog へノンパスでログインができるようになります。 vagrant@host:~$ ssh vagrant@blog Last login: Wed May 13 14:50:14 2015 from 192.168.2.10 [vagrant@blog ~]$

host 側に Ansible と git をインストールします。

インストールが終わったら host 側から以下のコマンドを叩いて success となるかを確かめます。ここではこのコマンドの意味はわからなくてもかまいません。Fail した場合は手順を見直してください。

ここまでで事前準備が完了です。

Ansible のインストール

$ sudo apt-get install software-properties-common $ sudo apt-add-repository ppa:ansible/ansible $ sudo apt-get update $ sudo apt-get install ansible git

vagrant@host:~$ echo "192.168.2.20" > hosts vagrant@host:~$ ansible all -i hosts -m ping 192.168.2.20 | success >> { "changed": false, "ping": "pong" }

1.Inventory ファイルの作成

2.Playbook ファイルの作成

3.Ansible を実行

4.冪等性の確認

5.ブラウザで確認

6.(参考)プレイブックの解説

ハンズオンステップ

今回は対象のホスト(blog)が1つですので下記のようなファイルを作成しておきます。

*事前準備でも hosts ファイルを用意してもらいましたがそれを使ってもかまいませんし、ansible_hosts にリネームしても構いません。今後のハンズオン上では ansible_hosts ファイルとして進めています。

Inventory ファイルの作成

vagrant@host:~$ cat ansible_hosts 192.168.2.20

まず、ハンズオンファイルをダウンロードします。

ここでは、playbook.yml というファイルを作ることにします

*なお、ca_ans_hands001/sample/ 以下には今回のハンズオンのサンプルが置いてありますがはじめは見ないで進めてください。

Playbook ファイルの作成

vagrant@host:~$ git clone https://github.com/tksarah/ca_ans_hands001.git vagrant@host:~$ cd ca_ans_hands001

Playbook ファイルの作成 - hosts: all vars: dbname: wordpress dbuser: wordpress dbpassword: password remote_user: vagrant become_user: root become: true tasks: - name: Install Packages yum: name={{ item }} state=latest with_items: - php - php-mysql - mariadb-server - MySQL-python

このプレイブックの解説は本書の後半に参考添付しています。

また、サンプルファイルを

ca_ans_hands001/sample/ に置いてあります。

Playbook ファイルの作成 ### 続き - name: Start and Enable mariadb service: name=mariadb state=started enabled=yes - name: Create Database for wordpress mysql_db: name={{ dbname }} state=present - name: Create user for wordpress mysql_user: name={{ dbuser }} password={{ dbpassword }} priv="wordpress.*:ALL" host=localhost state=present - name: Get WordPress get_url: url=http://ja.wordpress.org/latest-ja.tar.gz dest=/tmp/latest-ja.tar.gz owner=root - name: Unarchive a file unarchive: src=/tmp/latest-ja.tar.gz dest=/var/www/html copy=no creates=/var/www/html/wordpress - name: Copy wp-config.php template: src=./wp-config.php.j2 dest=/var/www/html/wordpress/wp-config.php mode=0666 - name: Change Owner and Group file: path=/var/www/html state=directory recurse=yes owner=apache group=apache - name: Start and Enable httpd service: name=httpd state=started enabled=yes

作り終わったら YAML の構文チェックをしましょう。下記のようになれば正しく書かれています。

*エラーが出たらメッセージ通りの部分を見直してください。スペースのズレやモジュールやオプション部分のTypoなど。

Playbook ファイルの作成

vagrant@host:~$ ansible-playbook -i ansible_hosts playbook.yml --syntax-check playbook: playbook.yml

ansible-playbook コマンドに引数をつけて実行します。

完了するまで少々時間(3~4分)がかかります。

ok=10 ・・・10 の処理が正常に行われたことがわかります。正常に実行または既に適用されている場合はカウントされます。

changed=9 ・・・ 対象ホストが処理により変更された事を示すアウトプットです。初回実行では当たり前ですがすべて実行され適用されているので結果は changed=9 となっていることがわかります。(ホスト情報の取得を示す GATHERING FACTS は変更が加わっているわけではないのでこの数に含まれていません。)

Ansible を実行

vagrant@host:~/ca_ans_hands001$ mv ~/ansible_hosts . vagrant@host:~/ca_ans_hands001$ ansible-playbook -i ansible_hosts playbook.yml PLAY [all] *********************************************************************** (省略) PLAY RECAP *********************************************************************** 192.168.2.20 : ok=10 changed=9 unreachable=0 failed=0

ここで、もう一度実行してみます。

注目すべきは changed=0 です。初回にすべてのタスクが正常に行われてるため、各処理は実際に適用されずに正常終了とみなされ結果が返されています。

たとえば、ここで一時的に /var/www/html のオーナーを別のオーナーに手動で変えて再度 ansible-playbook を実施してみてください。そうすると、Change Owner and Group の処理のみが実行されて完了することがわかると思います。これでわかるように、対象ホストは同じ Playbook で実行すればその Playbook に書かれているあるべき状態が保たれるようにコンフィグレーションが完了します。

冪等性の確認

vagrant@host:~/techcircle6/lesson1$ ansible-playbook -i ansible_hosts playbook.yml PLAY [all] *********************************************************************** (省略) PLAY RECAP *********************************************************************** 192.168.2.20 : ok=9 changed=0 unreachable=0 failed=0

PC上でブラウザを立ち上げ以下にアクセスします。

http://192.168.2.20/wordpress/

一般的には WordPress のファイル類を Web サーバ上に配置した後、上記URLにアクセスしてデータベース等の設定をブラウザ上で行ったあと、サイトの初期設定をすることになりますが、今回はデータベースの設定も wp-config.php を置き換える事で済ませてしまっているのでサイトの設定画面が現れます。

必要事項を入力して、以降 WordPress の操作を確認してください

ブラウザで確認

はじめの「---」YAML形式で複数ツリーを格納する際のデリミタです。「YAMLで書かれてるよ」という宣言のように捉えてもらえばとりあえずはいいです。

- hosts: allにより対象のホストを指定しています。この場合は all と指定されているので、先ほど作った ansible_hosts ファイルに書かれているすべてのホストが対象に対して以降の処理を実施することになります。

vars: セクションではいわゆる変数を定義しています。例えば、dbname: wordpress は「 dbname に wordpress を定義」しており、tasks: 以降の部分で{{ dbname }}とすることでその値を呼び出して使うことができます。

(参考)Playbook ファイルの解説

remote_user: vagrant

become_user: root

become: true

ここの意味は「 vagrant ユーザでターゲットホストにアクセスし( tasks: 以降の処理を)sudo し、root として実行する。」という部分です。

(参考)Playbook ファイルの解説

tasks: 以降、いよいよここから具体的な処理の実行内容の記述に入っていきます。まず - name: という部分でその処理の概略を書きます。その処理が何をするものかが一目でわかり、後に実行中やデバッグするようなときにも便利なのでわかりやすいものにしておきます。

通常プログラムコードを書くときは # を処理内容使ってコメントを書いたりしますが、そもそも - name: で記述しておけばそれをあえて書く必要もなくなるので見た目がスッキリします。

yum: で yum モジュールを使っています。yum を使ってphp,php-mysqlやらのパッケージをインストールする部分です。パッケージが1つであれば、name= のところで直接パッケージ名をかけばよいですが、今回は複数なので name={{ item }} とおき with_items でパッケージ名をリストして yum を実行するような記述形式になっています。よく使われる形です。

(参考)Playbook ファイルの解説

service: で service モジュールを使っています。これもモジュール名の通り&見たままの処理内容で、「MariaDBを起動し、システム起動時も起動するようにする」という処理内容です。service: で service モジュールを使っています。これもモジュール名の通り&見たままの処理内容で、「MariaDBを起動し、システム起動時も起動するようにする」という処理内容です。

mysql_db: と mysql_user: は MySQL 関連のモジュールで MariaDB にも適用可能です。ここでは、wordpress という名のデータベースを作り、そのデータベースへのアクセス権限のあるユーザ wordpress を定義しています。{{ dbname }}と{{ dbuser }} は前記した vars: で定義されているので、いずれも wordpress に変換されて処理されます。

(参考)Playbook ファイルの解説

get_url: で get_url モジュールを使っています。これはWeb上からなんらかファイルをダウンロードするときにつかいます。使い方は簡単で、 上記のように url=<url path> とするだけです。dest= で指定したところに保存され、ここではそのファイルのオーナーを root にし

unarchive: というモジュールを使って、ダウロードしたファイルを展開しています。

template: で template モジュールを使っています。ここでの template モジュールの使い方は文章で書くと「あるアプリケーション用の設定ファイルを用意しておき、対象ホストのしかるべき場所に配置する。ただしその際に用意されていた設定ファイルの中に規定のフォーマットで変数定義されている部分がある場合、そこに値を代入してから配置する。」です。今回は lesson1 ディレクトリ以下に WordPress の初期設定ファイル wp-config.php のテンプレートファイル wp-config.php.j2 を用意しています。このwp-config.phpとwp-config.php.j2の相違点は、通常は値を定義しておくところを{{ hoge }}のように置いている点です。これは Jinja2 と呼ばれているテンプレートの形式であり、ここに入る値は Ansible の template モジュール実行時に playbook.yml の中で vars: に定義された値に置き換わります。

(参考)Playbook ファイルの解説

wp-config.php.j2抜粋

define('DB_NAME', '{{ dbname }}');

/** MySQL database username */

define('DB_USER', '{{ dbuser }}');

/** MySQL database password */

define('DB_PASSWORD', '{{ dbpassword }}');

今回の場合は{{ dbname }}と{{ dbuser }}はともに wordpress、{{ dbpassword }}は password に変換されて、dest で指定された場所に wp-config.php として配置されます。

(参考)Playbook ファイルの解説

file: で file モジュールを使って /var/www/html 以下のオーナー・グループを apache に設定する処理です。

(参考)Playbook ファイルの解説