OpenStackクラウド基盤構築ハンズオンセミナー　第１日：講義No2

1

Copyright (C) 2014 National Institute of Informatics, All rights reserved.

OpenStackクラウド基盤構築ハンズオンセミナー

第1日講義資料 No.2

ver1.2 2014/02/18

2



目次■ サーバ構築自動化の考え方

■ Puppetによるアプリケーション導入の自動化

■ Git/GitHubによる設定ファイル管理

■ Cloud-InitによるOpenStackとの連携

注意：本テキストで扱うOpenStackは、RDO(Grizzly)がベースとなります。

3



サーバ構築自動化の考え方

4



自動化における管理対象について■ サーバ環境の構築を自動化する際は、管理対象を図のように分類して、それぞれについ

て、自動化の手法を検討します。

環境設定（Config）

アプリケーションプログラム

インフラ環境

データ

OS・アプリケーションの構成管理

アプリケーションの導入管理

物理サーバ/仮想マシン構成OSイメージなどの管理

クラウド（仮想化）環境ではどの範囲をイメージ化するかが

１つのポイント

5



クラウド/仮想化環境による自動化のパターン

■ 仮想アプライアンス（ゴールデンイメージ）方式

- アプリケーション導入済みの環境をマシンイメージ化して利用。

- 巨大なテンプレートファイルの保守管理、インフラ間の可搬性が課題。

■ JEOS(Just Enough Operating System)方式

- 最小限のOS環境をマシンイメージ化して利用。アプリケーションの導入・設定は、Puppetなどのツールで自動化。

■ 自動インストール方式

- OSのインストールからアプリケーションの導入・設定まで、すべての作業を自動化して適用。OSインストールの自動化には、KickStartなどを利用。

クラウドで主流になりつつある手法

これまでの仮想化環境で利用されてきた方法

6



メモとしてお使いください

7



Puppetによるアプリケーション導入の自動化

8



Puppetの機能概要■ Puppetは、OS上の各種設定処理を自動化する構成管理ツールです。

- パッケージ、サービス、ファイル、ユーザ/グループなど、規定の「リソース」について、「マニフェスト」と呼ばれる設定ファイルで指定した状態に自動構成します。

- マニフェストには、「システム構成の希望する状態」を記載します。Puppetは、現状の構成を調べて、希望する状態に変更するためのコマンドを自動判別して実行します。

■ Puppetサーバから複数のサーバを集中管理する方法と、サーバ個別にpuppetコマンドでマニフェストを適用する方法があります。

- サーバ個別にマニフェストを適用する場合は、そのサーバにマニフェストを配布する仕組みが必要です。この後で説明するようにGitHubからダウンロードする方法などがあります。

PuppetサーバPuppetクライアント

Puppetクライアント

マニフェストを配布

集中管理方式個別適用方式

マニフェストをダウンロード

9



簡単なマニフェストの例■ 右図は、Webサーバを構成する簡単なマニフェストの例です。

- 下表のリソースとその依存関係を定義しています。

package { 'httpd': ensure => latest, # 最新バージョンを導入}

service { 'httpd': ensure => running, # サービスを起動 enable => true, # サーバー起動時の自動起動を設定 hasrestart => true, # 「service xxxx restart」が利用可能 hasstatus => true, # 「service xxxx status」が利用可能} file { '/var/www/html/index.html': owner => 'apache', # ファイルオーナー group => 'apache', # ファイルグループ mode => '0600', # アクセス権 content => '<h1>This is $hostname.</h1>', # ファイルの内容}

exec { 'fw-http': path => '/usr/sbin', # コマンドのパス command => 'lokkit -s http', # 実行するコマンド}

Package['httpd'] -> File['/var/www/html/index.html'] -> Service['httpd'] -> Exec['fw-http']

リソース説明

package RPMパッケージを導入

service サービスを起動

file ファイルを作成

exec コマンドを実行

リソースの依存関係

<リソース> { '<ラベル>': <アトリビュート>, <アトリビュート>, ・・・}

マニフェストの書式

apache.pp

Facter変数

10



Puppetの動作原理■ マニフェストで指定された「希望の状態」と「現在の状態」を比較して、その差分を埋

めるコマンドを自動判別します。

- リソースの種類ごとに「現状確認コマンド、設定変更コマンド」などの”Intelligence”がビルトインされている事がPuppetの特徴です。ユーザが独自のリソースを追加することも可能です。

- この仕組みがあるために、最初のサーバの状態に依存せずに適切な設定処理が実施できる事がPuppetの特徴です。

希望の状態にシステムを更新

No

希望の状態現在の状態

package { 'httpd': ensure => latest,}

# yum list httpd

「現在の状態＝希望の状態」？

11



設定処理の「冪等性」について■ 指定のリソースについて、同じ設定処理を繰り返しても結果が変わらないことを「処理

の冪等性（べきとうせい）」と言います。Puppetは、現在の状態を確認してから設定処理を行うので、基本的には自動的に処理の冪等性が成り立ちます。（すでに設定されていれば、２回目は何もしないので。）

■ ただし、execリソースは実行するコマンドを直接に指定するので、冪等性が成り立たない場合があります。

- たとえば、/etc/hostsにエントリを追加する下記のコマンドを２回実行すると、同じエントリが重複して記載されてしまいます。

- このような場合は、冪等性が成り立つように次のオプションを指定します。

● creates: 指定ファイルが存在しない場合に実行する

● onlyif: 指定コマンドの返り値が0の時に実行する

● unless: 指定コマンドの返り値が0以外の時に実行する

# echo "xxx.xxx.xxx.xxx myserver.example.com" >> /etc/hosts

exec { 'initdb': path => '/sbin', command => 'service postgresql initdb', creates => '/var/lib/pgsql/data/PG_VERSION', }

DBが初期化されると、　このファイルが作成される

PostgreSQLのDBを初期化するコマンドの例

12



Facter変数の利用■ Puppetのマニフェスト内では、独自の環境変数（Facter変数）が利用できます。

- Facter変数の一覧は、facterコマンドで表示します。● facterコマンドは、システム環境を調査して、それぞれのFacter変数をセットします。● この例の場合、たとえば、「$hostname」は「test-1」に置換されます。

- 通常の環境変数を通じて、独自のFacter変数をセットすることもできます。● 環境変数「FACTER_XXXX」の値が、Facter変数「XXXX」にセットされます。

# facterarchitecture => x86_64augeasversion => 1.1.0facterversion => 1.6.18hardwareisa => x86_64hardwaremodel => x86_64hostname => test-1id => rootinterfaces => eth0,loipaddress => 172.16.1.9is_virtual => truekernel => Linux（以下省略）

# export FACTER_myvar=edubase# facter | grep myvarmyvar => edubase

13



puppetコマンドの使用例■ RHEL6.4の環境でPuppetを利用して、Webサーバを自動構築する例です。

- PuppetはEPELリポジトリで提供されており、次の手順でインストールします。

- 「簡単なマニフェストの例」のapache.ppをカレントディレクトリに用意します。

- --noopオプションで実行すると、マニフェストの文法チェックのみを行います。

- 次は実際に設定を適用する例です。

● 「--debug」オプションを指定すると、実行中の詳細情報が表示されます。

# yum install http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm# yum install puppet

# puppet apply apache.pp --noopwarning: Could not retrieve fact fqdnnotice: /Stage[main]//Package[httpd]/ensure: current_value absent, should be latest (noop)notice: /File[/var/www/html/index.html]/ensure: current_value absent, should be file (noop)notice: /Stage[main]//Service[httpd]/ensure: current_value stopped, should be running (noop)notice: /Stage[main]//Exec[fw-http]/returns: current_value notrun, should be 0 (noop)notice: Finished catalog run in 0.67 seconds

# puppet apply apache.ppwarning: Could not retrieve fact fqdnnotice: /Stage[main]//Package[httpd]/ensure: creatednotice: /File[/var/www/html/index.html]/ensure: defined content as '{md5}1661d7d216a61e36241de00fffb3dfcc'notice: /Stage[main]//Service[httpd]/ensure: ensure changed 'stopped' to 'running'notice: /Stage[main]//Exec[fw-http]/returns: executed successfullynotice: Finished catalog run in 4.96 seconds

14



Puppetマニフェストのその他の設定■ 「Class」によるモジュール化

- ひとまとまりの設定を「Class」にまとめて定義した後、必要に応じて「include」することで、設定のモジュール化ができます。（マニフェストを複数ファイルに分割することも可能です。）

- 依存関係を設定する際は、Class単位での依存関係の指定も可能です。

- 「第12回仮想マシン構築自動化演習」の例（PostgreSQLサーバ導入・設定用マニフェスト「pgsql.pp」）を参考にしてください。

■ 「通知関係」の設定

- 依存関係を指定する際は、単純な順序関係の他に、「通知関係」を指定することができます。（下図の例を参照）

- 通知関係を設定すると、順序関係も同時に設定されます。両方を設定する必要はありません。

# httpdパッケージ導入後にhttpdサービスを有効化Package['httpd'] -> Service['httpd']

# httpdパッケージが更新されるとhttpdサービスを再起動Package['httpd'] ~> Service['httpd']

通知関係の設定例（参考資料）http://tatsu-zine.com/books/puppet

15



Puppetを利用したインストールツールの例 (1)■ RDOに標準で付属するインストーラ「Packstack」は、Puppetを利用してOpenStackの

各種コンポーネントをリモートインストールします。

- Nova/Glance/Cinder/Neutron/Keystone/Horizonなどのコンポーネント別にPuppetマニフェストが用意されています。

- 下図は、Packstackがマニフェストを配布して、順番に適用している所です。

16



Puppetを利用したインストールツールの例 (2)■ PackstackはSSHでマニフェストを配布・適用するため、複数ノードを並列にインス

トールすることができます。

# packstack --gen-answer-file=answer.txt

# grep NOVA answer.txt CONFIG_NOVA_INSTALL=yCONFIG_NOVA_API_HOST=10.64.200.99CONFIG_NOVA_CERT_HOST=10.64.200.99CONFIG_NOVA_VNCPROXY_HOST=10.64.200.99CONFIG_NOVA_COMPUTE_HOSTS=10.64.200.99CONFIG_NOVA_CONDUCTOR_HOST=10.64.200.99CONFIG_NOVA_DB_PW=5ccf01bb5cdc4c9fCONFIG_NOVA_KS_PW=2a18ec2a72cf455cCONFIG_NOVA_SCHED_HOST=10.64.200.99CONFIG_NOVA_SCHED_CPU_ALLOC_RATIO=16.0CONFIG_NOVA_SCHED_RAM_ALLOC_RATIO=1.5CONFIG_NOVA_COMPUTE_PRIVIF=eth1・・・

# packstack --answer-file=answer.txt

answerファイルのテンプレートを作成

Nova Computeノードを複数指定可能

answerファイルに基づいてインストール

例としてNova関連オプションを確認

17




18




19



Git/GitHubによる設定ファイル管理

20



設定ファイルのバージョン管理■ Puppetを有効活用する上では、多数の「マニフェストファイル」をバージョン管理す

る必要があります。Gitなどのバージョン管理システムを利用すると、設定ファイルの変更内容を記録して、過去の内容を取り出したり、複数系列のバージョンを並行してメンテナンスすることができるようになります。

- Gitは、本来はプログラムのソースコードのバージョン管理に使用するツールですが、Puppetのマニフェストなどテキスト形式の設定ファイルの管理にも利用できます。

変更変更

設定ファイル一式

変更

複製

新たな「ブランチ」を作成

v1.0 v1.1

v2.0

Gitによるバージョン管理のイメージ過去の内容をID/タグで自由に呼び出し可能

21



GitHubの利用イメージ■ GitHubは、ローカルのGitで管理するリポジトリをそのままインターネット上のリポジ

トリにコピーして、一般公開するサービスです。

- GitHub上のリポジトリは、万人に公開されます。アクセス制限が必要な際は、有償のオプションサービスを利用します。

リポジトリの公開URL

特定の時点のコードをタグ名で指定

過去の変更履歴を全て保存

22



GitHubによるマニフェストの共有■ Gitで管理するマニフェストをGitHubで公開することにより、マニフェストを共有して

利用することができます。

- 利用者は、リポジトリのURLと「タグ」を指定することで、必要な設定に応じたマニフェストを入手して、適用します。図は、KickStartの%postスクリプトからマニフェストのダウンロードと適用を行うスクリプトの例です。

#!/bin/sh -x

GitRepository=https://github.com/enakai00/pgsql_puppet.gitConfigTag=f19

yum -y install puppet gitRepoName=${GitRepository##*/}RepoName=${RepoName%.git}mkdir -p /tmp/gittmpcd /tmp/gittmpgit clone $GitRepositorycd $RepoNamegit checkout $ConfigTagexport FACTER_manifest_dir="/tmp/gittmp/$RepoName"puppet apply main.pp

GitHubからマニフェストを取得して適用するスクリプトの例

GitHub

ローカルで作成したマニフェストをGitHubに保存

マニフェストをダウンロードして適用

ゲストOS

ローカルリポジトリ

23



カスタマイズスクリプトによる連携処理■ カスタマイズスクリプトからGitHub/Puppetを連携させることで、仮想マシンインスタ

ンスの起動時にアプリケーションの導入・設定をまとめて自動化することができます。

GitHubVM

YUMリポジトリ

アプリ設定情報（Puppetマニフェスト）

カスタマイズ・スクリプト

ソフトウェアパッケージ

pgsql

24




25




26




27



Cloud-Initとメタデータ

28



カスタマイズスクリプトによる自動化■ 仮想マシンインスタンス起動時に「カスタマイズスクリプト（User Data）」を与える

と任意のテキストをメタデータとしてゲストOSに受け渡すことができます。

■ Cloud-Initは、カスタマイズスクリプトを解釈してさまざまな自動化を実現します。

- 下図はシェルスクリプトを渡して、「/etc/motd」を設定しています。

- この他にもCloud-Init独自の構文で、処理内容を指示することができます。

● （参考） http://cloudinit.readthedocs.org/en/latest/

- Cloud-Initは「メタデータ」を利用して、カスタマイズスクリプトを取得します。

$ curl http://169.254.169.254/2009-04-04/user-data#!/bin/shecho 'Hello, World!' > /etc/motdexit 0

29



仮想マシンインスタンスのメタデータ■ OpenStackの仮想マシンインスタンスでは、「http://169.254.169.254」にアクセス

すると、そのインスタンスに固有の情報が取得できます。これを「メタデータ」と呼びます。

■ Cloud-Initは、仮想マシンインスタンス起動時にメタデータを利用して、ゲストOSの自動セットアップを行います。

- 一時ディスクのマウントやスワップ領域の構成は、Cloud-Initが行います。

$ curl http://169.254.169.254/2009-04-04/meta-data/hostnamevm03.novalocal$ curl http://169.254.169.254/2009-04-04/meta-data/local-ipv4192.168.101.4$ curl http://169.254.169.254/2009-04-04/meta-data/public-keys/0/openssh-keySsh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA5W2IynhVezp+DpN11xdsY/8NOqeF8r7eYqVteeWZSBfnYhKn8D85JmByBQnJ7HrJIrdMvfTYwWxi+swfFlryG3A+oSll0tT71FLAWnAYz26ML3HccyJ7E2bD66BSditbDITKH3V66oN9c3rIEXZYQ3A+GEiA1cFD++R0FNKxyBOkjduycvksB5Nl9xb3k6z4uoZ7JQD5J14qnooM55Blmn2CC2/2KlapxMi0tgSdkdfnSSxbYvlBztGiF3M4ey7kyuWwhE2iPBwkV/OhANl3nwHidcNdBrAGC3u78aTtUEwZtNUqrevVKM/yUfRRyPRNivuGOkvjTDUL/9BGquBX9Q== enakai@kakinoha

$ curl http://169.254.169.254/2009-04-04/meta-data/block-de-mapping/root/dev/vda$ curl http://169.254.169.254/2009-04-04/meta-data/block-device-mapping/ephemeral0/dev/vdb$ curl http://169.254.169.254/2009-04-04/meta-data/bloe-mapping/swap/dev/vdc

メタデータの例

ルートディスク/一時ディスク/スワップディスクに対応するデバイス名

30



(参考) Heatによるクラウドオーケストレーション■ カスタマイズスクリプトにより、単体の仮想マシンインスタンスに対するアプリケー

ションの導入・設定が自動化できます。しかしながら、『DBサーバを構築した後に、続けてWebアプリケーションサーバを構築して、DBサーバへの接続設定を自動で行う』など、複数の仮想マシンインスタンスを連携した自動化には対応できません。

- 例えば、DBサーバのIPアドレスなど、仮想マシンインスタンスの起動時に動的に決まるパラメータを事前にカスタマイズスクリプトに記載する方法がありません。

■ OpenStackでは、複数の仮想マシンインスタンスを連携した構築自動化のツールとして、「Heat」の開発を進めています。

- Heatを利用する際は、複数の仮想マシンインスタンスの構成情報と、それぞれに受け渡す「カスタマイズスクリプト」をまとめて記載した「テンプレート」を用意します。テンプレート内部では、「DBサーバのIPアドレス」など、動的に決まるパラメータをマクロ変数で記載することが可能です。

- HeatのAPIにテンプレートを送ると、指定の仮想マシンインスタンスを順番に自動構成していきます。この際、動的に決まるパラメータを自動で取得してマクロ変数の置換を行います。

- （参考資料）クラウドオーケストレーション「OpenStack Heat」に迫る!

● http://www.slideshare.net/enakai/open-stack-heat20140207

31


Technology

OpenStackクラウド基盤構築ハンズオンセミナー 第１日：講義No2

OpenStackクラウド基盤構築ハンズオンセミナー　第１日：講義No2