[和訳] Chef High Availability: AWS #opschef_ja #getchef_ja
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
この記事は High Availability: AWS の 2014/11/26 時点での和訳です。
本項ではChef ServerのHA (High Availability)をAmazon Web Services上にどのように構成するかを説明します。
事前準備
Chef Serverソフトウェアをインストールする前に、次を行います。
- Amazon Virtual Private Cloudを使用します。Amazon EC2-Classicはサポートしません。
- バックエンドインスタンスを含む適切なセキュリティグループを作成します。Chef Serverに必要なものは2つのバックエンドインスタンス間のICMPの許可だけです。Keepalivedが通信とハートビートのためにそれを用います。
- 2つのサーバを起動し、1つはプライマリバックエンドChef Server、もう1つはセカンダリバックエンドChef Serverとします。両バックエンドサーバを同一のプラットフォームとバージョンとするために同じAmazon Machine Images (AMI)を使用します。これらのサーバは同じアベイラビリティゾーンになければいけません。
- Chef Serverのデータを格納するためのAmazon Elastic Block Storeボリュームを作成します。EBSのボリュームタイプは、ボリュームのサイズに対して最大のIOPS率となるProvisioned IOPSを推奨します。
- バックエンドの仮想IPアドレス(VIP)となるIPアドレスを決定します。これはバックエンドマシンと同じネットワークセグメントになければいけません。これはインストール中にchef-server.rbファイルに指定され、High AvailabilityプラグインはプライマリインスタンスのElastic Network Interface (ENI)にVIPを自動的に割り当てます。
- 少なくとも本項末のリファレンスに記載してあるパーミッションでIdentity and Access Management (IAM)ユーザを作成します。このユーザのアクセスキーとシークレットキーを記録してください。これらはchef-server.rb設定ファイルで用います。
プライマリバックエンド
次の通りにプライマリバックエンドChef Serverの設定を行います。
- Amazon Elastic Block Storeボリュームを作成し、プライマリバックエンドにアタッチします。
- http://downloads.getchef.com/chef-server/とhttp://downloads.getchef.com/chef-ha/からパッケージをダウンロードします。
- chef-server-coreパッケージをインストールします。Red HatとCentOS 6では次のように、
$ rpm -Uvh /tmp/chef-server-core-<version>.rpm
Ubuntuでは次のようにします。
$ dpkg -i /tmp/chef-server-core-<version>.deb
数分でChef Serverがインストールされます。
- chef-haパッケージをインストールします。Red HatとCentOS 6では次のように、
$ rpm -Uvh /tmp/chef-ha-<version>.rpm
Ubuntuでは次のようにします。
$ dpkg -i /tmp/chef-ha-<version>.deb
- /etc/opscode/ディレクトリにchef-server.rbという名前でファイルを作成します。設定例と必要な値は次のchef-server.rbセクションを参照してください。ha['ebs_device']設定は、マシンのカーネルによって報告される実際の/devデバイス名を指定しなければいけません。これはAmazon Web Servicesによって報告される値と同じではないかもしれません。例えば、Amazon Web Servicesのマネージメントコンソールで参照できるボリュームが/dev/sdfでも、インスタンスのカーネルでは/dev/xvdfとして見えているかもしれません。
- logical volume manager (LVM)ツールをインストールします。Red HatとCentOS 6では次のように、
$ sudo yum install lvm2
Ubuntuでは次のようにします。
$ sudo apt-get install lvm2
- 次の一連のコマンドを用いて、物理ボリューム、ボリュームグループ、論理ボリュームを作成します。ボリュームグループと論理ボリュームの名前はそれぞれdataとchefでなければいけません。
$ sudo pvcreate /dev/xvdf
$ sudo vgcreate chef /dev/xvdf
$ sudo lvcreate -l 85%VG -n data chef
- 次の一連のコマンドを用いて、新しいボリュームをフォーマットしマウントします。
$ sudo mkdir -p /var/opt/opscode/drbd/data
$ sudo mkfs.ext4 /dev/mapper/chef-data
$ sudo mount /dev/mapper/chef-data /var/opt/opscode/drbd/data
- 次のコマンドを実行してChef Serverを設定します。
$ sudo chef-server-ctl reconfigure
これはChef Serverを再設定し、Keepalivedを起動し、VIPをElastic Network Interface (ENI)のセカンダリIPアドレスとして割り当て、マシンをプライマリバックエンドサーバとして設定します。
- マシンがプライマリバックエンドサーバであるか検証します。
$ sudo chef-server-ctl ha-status
サーバがPRIMARYですべてのサービスが起動していると表示されるはずです。
加えて、次のコマンドでイーサネットインターフェイスに設定されているVIPを検証できます。$ ip addr list dev eth0
注意: すべてのエイリアスが表示されないので、ifconfigは使わないでください。
chef-server.rb
HA構成の各Chef Serverは、各サーバの/etc/opscode/ディレクトリに同一のchef-server.rbファイルを置かなければいけません。このファイルはHA構成のトポロジを記述します。プライマリバックエンドマシンで、chef-server.rbという名前のファイルを作成して/etc/opscode/ディレクトリに保存します。
次の設定をchef-server.rbファイルに追加します。
- トポロジタイプを定義します。
topology "ha"
- プライマリバックエンドサーバを定義します。
server "FQDN",
:ipaddress => "IP_ADDRESS",
:role => "backend",
:bootstrap => true,
:cluster_ipaddress => "CLUSTER_IPADDRESS"
FQDNはサーバのFQDNに、IP_ADDRESSはサーバのIPアドレスに置き換えます。バックエンドマシンのroleは"backend"です。バックエンドマシンがChef Serverインストールのブートストラップに用いられる場合、CLUSTER_IPADDRESSをクラスタ通信に用いるインターフェイスのIPアドレスに置き換えます。例えば、KeepalivedとDRBDによって用いられる同じIPアドレスです。もしChef ServerがChef Serverインストールのブートストラップに用いられないなら、:cluster_ipaddressエントリは除外します。 - セカンダリバックエンドサーバを定義します。
server "FQDN",
:ipaddress => "IPADDRESS",
:role => "backend",
:cluster_ipaddress => "CLUSTER_IPADDRESS"
FQDNはサーバのFQDNに、IP_ADDRESSはサーバのIPアドレスに置き換えます。CLUSTER_IPADDRESSはクラスタ通信に割り当てられたサーバのインターフェイスのIPアドレスに置き換えます。そのように設定したインターフェイスがないなら、:cluster_ipaddressエントリは除外します。 - バックエンド仮想IPアドレスを定義します。
backend_vip "FQDN",
:ipaddress => "IP_ADDRESS",
:device => "eth0",
FQDNはサーバのFQDNに置き換えます。IP_ADDRESSはサーバの仮想IPアドレスに置き換えます。:deviceパラメタはフローティング仮想IPアドレスに結びつけられるイーサネットインターフェイスです。通常、サーバのパブリックインターフェイスです。 - 各フロントエンドマシンを定義します。
server "FQDN",
:ipaddress => "IP_ADDRESS",
:role => "frontend"
FQDNはフロントエンドマシンのFQDNに置き換えます。IP_ADDRESSはフロントエンドマシンのIPアドレスに置き換えます。:roleは"frontend"に設定します。
各フロントエンドマシン用のエントリはchef-server.rbファイル内に別々に追加します。 - API FQDNを定義します。
api_fqdn "FQDN"
FQDNは、ロードバランシングされた仮想IPアドレスのFQDN、つまりChef Serverが用いるサービスURIのFQDNと同じもので置き換えます。 - 次のコマンドを実行します。
$ sudo chef-server-ctl reconfigure
セカンダリバックエンド
次の通りにセカンダリバックエンドChef Serverの設定を行います。
- chef-server-coreパッケージをインストールします。Red HatとCentOS 6では次のように、
$ rpm -Uvh /tmp/chef-server-core-<version>.rpm
Ubuntuでは次のようにします。
$ dpkg -i /tmp/chef-server-core-<version>.deb
数分でChef Serverがインストールされます。
- chef-haパッケージをインストールします。Red HatとCentOS 6では次のように、
$ rpm -Uvh /tmp/chef-ha-<version>.rpm
Ubuntuでは次のようにします。
$ dpkg -i /tmp/chef-ha-<version>.deb
- logical volume manager (LVM)ツールをインストールします。Red HatとCentOS 6では次のように、
$ sudo yum install lvm2
Ubuntuでは次のようにします。
$ sudo apt-get install lvm2
- /etc/opscode/ディレクトリを作成し、プライマリサーバの/etc/opscode/ディレクトリにあるすべての証明書とchef-server.rbを含む内容全体をコピーします。
- 次のコマンドを実行します。
$ sudo chef-server-ctl reconfigure
これはChef Serverを再設定し、Keepalivedを起動し、マシンをセカンダリバックエンドサーバとして設定します。
- マシンがセカンダリバックエンドサーバであるか検証します。
$ sudo chef-server-ctl ha-status
サーバがBACKUPと表示されるはずです。
フェイルオーバーの検証
フェイルオーバーが動作しているか検証するには、プライマリマシンでKeepalivedを停止します。
- フェイルオーバーが起きたときの状態を観察するには、Keepalivedを停止する前に、プライマリバックエンドサーバとセカンダリバックエンドサーバの両方のターミナルウィンドウで次のコマンドを実行します。
$ watch -n1 sudo chef-server-ctl ha-status
- そしてプライマリバックエンドマシンでKeepalivedを停止します。
$ sudo chef-server-ctl stop keepalived
クラスタフェイルオーバーが起きるはずです。
- フェイルオーバーが成功した後、プライマリバックエンドマシンでKeepalivedを再び起動します。
$ sudo chef-server-ctl start keepalived
するとプライマリはセカンダリとなり、セカンダリはプライマリとなります。元のプライマリにフェイルバックしたいなら、新しいプライマリでこの手順を繰り返します。
フロントエンドのインストール
次の通りに各フロントエンドChef Serverの設定を行います。
- chef-server-coreパッケージをインストールします。Red HatとCentOS 6では次のように、
$ rpm -Uvh /tmp/chef-server-core-<version>.rpm
Ubuntuでは次のようにします。
$ dpkg -i /tmp/chef-server-core-<version>.deb
数分でChef Serverがインストールされます。フロントエンドマシンでは、Chef HAパッケージは必要ありません。
- /etc/opscode/ディレクトリを作成し、プライマリサーバの/etc/opscode/ディレクトリにあるすべての証明書とchef-server.rbを含む内容全体をコピーします。
- 管理者を作成するために、次のコマンドを実行します。
$ chef-server-ctl user-create user_name first_name last_name email password --filename FILE_NAME
RSA秘密鍵が自動的に生成されます。安全な場所に保存してください。--filenameオプションで指定したパスにRSA秘密鍵を保存します。
例:$ chef-server-ctl user-create stevedanno Steve Danno steved@getchef.com abc123 --filename /path/to/file.key
- Organizationを作成するために、次のコマンドを実行します。
$ chef-server-ctl org-create short_name full_organization_name --association_user user_name --filename FILE_NAME
Organization名は小文字の英字か数字で始まらなければならず、小文字の英字、数字、ハイフン、アンダースコアのみを含み、1〜255文字でなければいけません。例: chef
完全なOrganization名はホワイトスペース以外の文字で始まらなければならず、1〜1023文字でなければいけません。例: Chef Software, Inc.
--association_userオプションはuser_nameユーザをChef Serverのadminsセキュリティグループに結びつけます。
RSA秘密鍵が自動的に生成されます。安全な場所に保存してください。--filenameオプションで指定したパスにRSA秘密鍵を保存します。例:$ chef-server-ctl org-create chef Chef Software, Inc. --association_user stevedanno --filename /path/to/file.key
- 次のコマンドを実行します。
$ sudo chef-server-ctl reconfigure
機能の有効化
Chef Serverの追加機能を有効化しましょう! パッケージはインストールプロセス中に直接ダウンロードされるか、事前にローカルディレクトリにダウンロードしておいたものをインストールします。
ダウンロードしてインストールする
installサブコマンドはデフォルトではhttps://packagecloud.io/からパッケージをダウンロードします。ファイアウォールの背後にないシステムやhttps://packagecloud.io/と通信できる場合、次のようにパッケージをインストールできます。
機能 | コマンド |
---|---|
Chef Manage | Chefマネージメントコンソールは、ウェブUIからData Bag、Attribute、Run List、Role、Environment、Cookbookを管理するものです。フロントエンドマシンのみで次を実行します。
|
Chef Push Jobs | Chef Push Jobsは、アクションや実行するコマンドといったジョブをchef-clientの動作と独立してNodeに対して実行するものです。次を実行します。
|
Chef Replication | Chef Replicationは、単一のプライマリChef Serverから1つ以上のレプリカChef Serverに非同期にCookbook、Role、Data Bagを配布するものです。次を実行します。
|
ローカルパッケージをインストールする
installサブコマンドはデフォルトではhttps://packagecloud.io/からパッケージをダウンロードします。ファイアウォールの背後にあるシステムやhttps://packagecloud.io/と通信できない場合、パッケージを手動でインストールできます。まずプラットフォームに合ったパッケージをダウンロードしてローカルパスに保存します。そしてパッケージの位置を指定する--pathオプションを用いて、installコマンドを実行します。
$ chef-server-ctl install NAME_OF_PACKAGE --path /path/to/package
例:
$ chef-server-ctl install opscode-manage --path /home/vagrant
chef-server-ctlコマンドは/home/vagrantディレクトリにあるopscode-manageパッケージをインストールします。
Reportingのインストール
HA構成のChef Reporting Serverを構成するには次のようにします。
- Chef Serverが動作するすべてのマシンでパッケージをインストールします。
$ chef-server-ctl install opscode-reporting
- バックエンドプライマリサーバでChef Serverを再設定(bootstrap)します。
$ chef-server-ctl reconfigure
- バックエンドプライマリサーバでChef Reporting Serverを再設定(bootstrap)します。
$ opscode-reporting-ctl reconfigure
- /etc/opscode-reportingディレクトリのすべてをバックエンドプライマリマシンから、フロントエンドノードとバックエンドノードのすべてにコピーします。例えば、各サーバで次を行うか、
scp -r
:/etc/opscode-reporting /etc バックエンドプライマリマシンから次を行います。
$ scp -r /etc/opscode-reporting
:/etc - Chef ReportingサービスをインストールしたすべてのChef Serverを再設定します。
$ chef-server-ctl reconfigure
- 各サーバでChef Reportingサービスを再設定します。
$ opscode-reporting-ctl reconfigure
- インストールを検証します。
$ opscode-reporting-ctl test
リファレンス
次のセクションは、Chef HAにおけるchef-server.rbファイルの設定と、必要なIdentity and Access Management (IAM)のユーザパーミッションです。
chef-server.rb
次はchef-server.rbファイルの例です。
topology "ha"
ha['provider'] = 'aws'
ha['aws_access_key_id'] = '[DELETED]'
ha['aws_secret_access_key'] = '[DELETED]'
ha['ebs_volume_id'] = 'vol-xxxxx'
ha['ebs_device'] = '/dev/xvdf'
server 'ip-172-31-24-97.us-west-1.compute.internal',
:ipaddress => '172.31.24.97',
:role => 'backend',
:bootstrap => true
server 'ip-172-31-24-98.us-west-1.compute.internal',
:ipaddress => '172.31.24.98',
:role => 'backend'
backend_vip 'ip-172-31-24-180.us-west-1.compute.internal',
:ipaddress => '172.31.24.180',
:device => 'eth0',
:heartbeat_device => 'eth0'
server 'ip-172-31-30-47.us-west-1.compute.internal',
:ipaddress => '172.31.30.47',
:role => 'frontend'
api_fqdn 'ec2-54-183-175-188.us-west-1.compute.amazonaws.com'
Identity and Access Management (IAM)
次はIdentity and Access Management (IAM)のChef HAに必要なアクセスマネージメント設定の例です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeVolumes",
"ec2:AttachVolume",
"ec2:DetachVolume",
"ec2:AssignPrivateIpAddresses"
],
"Resource": [
"*"
]
}
]
}
高度なポリシードキュメントを用いてさらにアクセスを制限することが可能です。例えば、管理者はIdentity and Access Management (IAM)ユーザに対してChef Serverのデータボリュームに結びつけられたボリュームIDのみをアタッチ/デタッチし、すべてのボリュームではできないような許可を与えることができます。