SyntaxHighlighter

2013/01/03

apt(LWRP)

Cookbook情報

cookbook[apt]LWRP編、レシピ編はこちら

概要

debian/ubuntuのパッケージリポジトリ管理システムのaptの設定を行う。

解説

cookbook[apt]の持つLWRPについて説明。任意のリポジトリ追加やパッケージのpinningが設定できる。

LWRP

LWRPはCookbook名+Resource名で指定でき、任意のレシピ内で使います。利用したいResourceをもつCookbookをrun_listに入れておき、他のCookbookを作る時に呼び出します。

apt_repository

aptのリポジトリを追加する。これによりpackageリソースで追加したリポジトリからのインストールが可能になる。

公式のREADMEではnginxの例が出ているので、自作のCookbookから例を。

Mongodbの10gen提供リポジトリを追加して、インストールするレシピ。https://github.com/higanworks-cookbooks/mongodb-10gen/blob/master/recipes/default.rb

apt_repository "mongodb-10gen" do
  uri "http://downloads-distro.mongodb.org/repo/ubuntu-upstart"
  distribution "dist"
  components ["10gen"]
  keyserver "keyserver.ubuntu.com"
  key "7F0CEB10"
end

これでリポジトリが追加され、ついでにapt-get updateされる。Ver10.14以前のChefではバグでupdateが走らないため、executeで明示的に呼ぶ必要がある。

apt_preference

こちらはpreferenceのパラメータを指定して、そのとおり設定ファイルを作成するResource

公式READMEから使い方。

apt_preference "libmysqlclient16" do
  pin "version 5.1.49-3"
  pin_priority "700"
end

こちらは有効なケースが結構限られるのであまり使っていない、ちなみに不要になったらaction:removeで除去出来る。

適用例

apt_repositoryを実際に適用したら、設定ファイルがこのように作成される。

$ cat /etc/apt/sources.list.d/mongodb-10gen.list deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen

過不足無し、リポジトリ追加完了。

あとがき

LWRPのお手軽さと、他のレシピからも使える汎用性を紹介したいのでLWRPだけに絞ったaptのcookbook紹介を作成しました。

Cookbookはなるべく各環境で専用の物を書くものではなく、できるだけ汎用的に作ってAttributeやLWRPを活用して環境を構築するという事の参考になるはず。

2013/01/02

apt(recipe)

Cookbook情報

cookbook[apt]のレシピ編、LWRP編はこちら。

概要

debian/ubuntuのパッケージリポジトリ管理システムのaptの設定を行う。

解説

ubuntu系ではできるだけ入れておいたほうがよい。レシピの役割はパッケージリストの更新と、キャッシュサーバ/クライアントのセットアップ。

キャッシュサーバのクライアント設定はChefServerSearchを使う参考になります。
サーバのインベントリを自動集約しておくと恩恵がありますよという例のひとつ。

ちなみにサーバをBootstrapしつつrun_listを適用する場合にはリポジトリ情報が古くてpackageリソースを含むCookbookはだいたいコケる。初めに読ませて更新させるか、include_reciperecipe[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パッケージがインストールされプロキシとして動作する、ブラウザから確認できる。

apt-cache-ng.png

と、同時に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']があればそれを使うようにしている。EnvironmentRoleで設定できる。
それよりやはりSearchを使った次のブロック(unless以降)に注目したい。

条件が沢山並ぶようだが、とりあえず一つ目のここだけquery = 'recipes:apt\:\:cacher-ng'わかればいい。

このクエリはChefのSearchAPIを使って、プロキシサーバとして指定するIPを決定するために使われる。

具体的にはrunlistにapt-cacher-ngがあるnodeを問い合わせて、そのnode情報を格納しているのだ。

実際にクエリしてみる、recipe[apt::cacher-ng]をrunlistに持つnodeが実際にいると引っかかるのがわかる。

$ knife search node 'recipes:apt\:\:cacher-ng'
1 items found

Node Name:   apt-test
Environment: apt-book-test
FQDN:        localhost
IP:          210.152.***.***
Run List:    recipe[apt::default], recipe[apt::cacher-ng]
Roles:       
Recipes:     apt::cacher-ng
Platform:    ubuntu 12.04
Tags:        

そして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のインベントリ収集の強みがわかりやすいので紹介しました。

構築=構成管理=維持管理を同列に行うことで、コンフィグの変更を全サーバに適用するとか、わざわざ配布し直すとか、そういった作業が実際不要になるということがわかると思う。