Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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、)
ミドルウェアインストール・設定
アプリケーションデプロイ
・・・
保守・運用 各種設定変更
アップデート
パッケージ導入
アカウント管理
アプリケーションデプロイ
・・・
■ 複数台作業による工数リニアに増加 ■ スクリプトを組んだとしても、汎用性を維持するのは困難 ■ 繰り返し作業による、人的ミスの誘発 ■ 運用者が変わった場合の引き継ぎの複雑性 ■ 設計書・手順書 と 実際の状態 との管理が複雑化
課題点
プロビジョニング アクティビティ
アプリケーションサービス デプロイメント
システムコンフィグレーション
クラウド、 VM、コンテナ起動
OS
インストレーション
Orchestration
Configuration
Bootstrapping
AWS Cobbler
OpenStack
Kickstart VMware
Capistrano
Fabric
Puppet
Chef
Azure
引用元:Provisioning Toolchain (Velocity2010) by Lee Thompson
Docker
Ansible
自動化カバー範囲(一部) 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
エンタープライズ志向
ネットワーク機器の対応 Cisco、Juniper、F5、A10、・・・
ストレージ機器の対応 NetApp、INFINIDAT
Windows の対応
クラウド の対応
Docker の対応
参考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
本書は、ハンズオンをご自身の環境で行うための手引書です。
2つのパートに分かれています。
準備編
ハンズオン入門編
確認済みの環境
*実施の際、インターネットにつながるPCをご用意ください。
本書について
VirtualBox Vagrant Ansible
5.0.24 1.74 1.9~v2.3
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 へアクセスする方法
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" }
今回は対象のホスト(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 ファイルの解説