Cookbook情報
cookbook[apt]のレシピ編、LWRP編はこちら。
概要
debian/ubuntuのパッケージリポジトリ管理システムのaptの設定を行う。
解説
ubuntu系ではできるだけ入れておいたほうがよい。レシピの役割はパッケージリストの更新と、キャッシュサーバ/クライアントのセットアップ。
キャッシュサーバのクライアント設定はChefServerのSearchを使う参考になります。
サーバのインベントリを自動集約しておくと恩恵がありますよという例のひとつ。
ちなみにサーバをBootstrapしつつrun_listを適用する場合にはリポジトリ情報が古くてpackageリソースを含むCookbookはだいたいコケる。初めに読ませて更新させるか、include_recipeでrecipe[apt::default]を呼ぶとよい。
Recipes
レシピのコーナー
default
update-notifier-commonの導入と、apt-get updateの実行、それと他のレシピから呼べるようなexecuteリソースを定義している。
cacher-ng
apt-cacher-ngパッケージの導入とプロキシサービスの自動起動。レシピも短いので全て掲載。
package "apt-cacher-ng" do
action :install
end
service "apt-cacher-ng" do
supports :restart => true, :status => false
action [ :enable, :start ]
end
#this will help seed the proxy
include_recipe "apt::cacher-client"
このレシピを適用するとapt-cache-ngパッケージがインストールされプロキシとして動作する、ブラウザから確認できる。
と、同時にChefServerを使っていると、recipe[apt::cacher-ng]がrunlistに登録されたサーバというアトリビュートがnodeに対して付与される。この集中管理されたアトリビュートを理解することがChefをより活用するためのキーポイントにもなる、次のレシピが例。
cacher-client
aptのProxy設定をするレシピ、/etc/apt/apt.conf.d/01proxyファイルを編集して利用するProxyをコントロールする。
さて、肝心のProxyサーバアドレスを取得する仕組みをレシピを抜粋して紹介してみる、まずはservers変数にサーバリストを格納する部分。
servers = []
if node['apt'] && node['apt']['cacher_ipaddress']
cacher = Chef::Node.new
cacher.name(node['apt']['cacher_ipaddress'])
cacher.ipaddress(node['apt']['cacher_ipaddress'])
servers << cacher
end
unless Chef::Config[:solo]
query = 'recipes:apt\:\:cacher-ng'
query += " AND chef_environment:#{node.chef_environment}" if node['apt']['cacher-client']['restrict_environment']
Chef::Log.debug("apt::cacher-client searching for '#{query}'")
servers += search(:node, query)
end
初めにnode['apt']['cacher_ipaddress']があればそれを使うようにしている。EnvironmentやRoleで設定できる。
それよりやはりSearchを使った次のブロック(unless以降)に注目したい。
条件が沢山並ぶようだが、とりあえず一つ目のここだけquery = 'recipes:apt\:\:cacher-ng'わかればいい。
このクエリはChefのSearchAPIを使って、プロキシサーバとして指定するIPを決定するために使われる。
具体的にはrunlistにapt-cacher-ngがあるnodeを問い合わせて、そのnode情報を格納しているのだ。
実際にクエリしてみる、recipe[apt::cacher-ng]をrunlistに持つnodeが実際にいると引っかかるのがわかる。
そしてProxyを指定する設定ファイルにnodeの持つipaddressアトリビュートを当てはめている部分が下記。
if servers.length > 0
Chef::Log.info("apt-cacher-ng server found on #{servers[0]}.")
template '/etc/apt/apt.conf.d/01proxy' do
source '01proxy.erb'
owner 'root'
group 'root'
mode 00644
variables(
:proxy => servers[0]['ipaddress']
)
end.run_action(:create)
else
Chef::Log.info('No apt-cacher-ng server found.')
file '/etc/apt/apt.conf.d/01proxy' do
action :delete
end
end
要はChefServerを使っている場合、レシピによって作成してあるaptのProxyサーバがあれば、あとはclientのレシピを適用するだけで自動で適切なProxyを使ってくれるということになる。
apt-cacher-ngが適用されているNodeが変われば、全てのクライアントもサーバIPを変更してくれるし、apt-cacher-ng適用Nodeがなくなれば勝手にProxyを使うのをやめてくれる。
Attributes
node['apt']['cacher-client']['restrict_environment']
Proxyサーバに使うIPを種痘する際に、Environmentの一致を条件に入れるか設定できる。
ロケーション別にEnvironmentを分けている場合などに有効。
node['apt']['cacher_ipaddress']
defaultとして定義はされていないが、このアトリビュートを設定するとapt-cacher-ngが動作しているサーバを明示的に指定できる。
実行例
ほぼレシピの説明通りなので省略、Client側の設定ファイルが下記のようになる。
$ cat /etc/apt/apt.conf.d/01proxy
Acquire::http::Proxy "http://210.152.***.***:3142";
Attribute特に指定なし、サンプルのrunlistはこう。
- Proxy用nodeのrunlist:
"recipe[apt::default],recipe[apt::cacher-ng]"
- Clientのrunlist:
"recipe[apt::default],recipe[apt::cacher-client]"
あとがき
このレシピはRole（または各Nodeのアトリビュート）とSearchによるChefServerのインベントリ収集の強みがわかりやすいので紹介しました。
構築＝構成管理＝維持管理を同列に行うことで、コンフィグの変更を全サーバに適用するとか、わざわざ配布し直すとか、そういった作業が実際不要になるということがわかると思う。
