はじめに

さくらのVPSのCentOS 6.3環境にRails実行環境を構築してみましたのでその手順まとめです。

Railsの実行環境は、production(本番運用環境)、test(本番環境と同等テスト実行環境)、development(開発環境)の3つがあります。一般的にproducution環境はApacheやNginxなどのWebサーバと連携して利用し、development環境はRailsに付属されているWEBrickというWebサーバを使ってローカル環境で動作確認するために使うことが良さそうですが、ここではNginx,Unicornも含めた開発環境のテスト構築のため、development環境のみにて環境構築をしています。

RailsはRubyで記述されたWebアプリケーションフレームワークです。MVC(Model/View/Controller)アーキテクチャに基づいて構築します。
RailsにおけるMVCアーキテクチャの概要については以下等が参考になるかと思います。

• MVCとRailsの基本構成を学ぼう (1/3)

Railsアプリケーションを利用する上でRack対応httpサーバに何を選択するかは重要かと思いますが、ここではhttpサーバに最近主流になりつつあるUnicornを選択しています。

• Unicorn: Rack HTTP server for fast clients and Unix
• Rack: a Ruby Webserver Interface

Unicorn単体でもRailsを動作させることができますが、一般的にはWebサーバとなるソフトウェア(Apache/Nignx等)をリバースプロキシとして利用して画像などの静的ファイルを処理させ、アプリケーションへのアクセスはUnicornへ渡し、Railsでの処理を行うのが一般的です。
NignxとUnicorn間の通信はUnix Domai SocketかTCPが用いることができますが、ここではUnix Domai Socketを利用することにしています。

なお、データベースにはSQLite、MySQL、PostgreSQLを選択することが可能で、デフォルトではSQLiteが選択されますが、ここではデータベースにはPostgreSQLを利用します。
NginxとPostgreSQLはRPMパッケージでインストールされているものとします。
また、Rubyはrbenv+ruby-buildでインストールされているものとします。

環境

インストール環境は以下です。

プラットフォーム

利用するソフトウェア類

その他環境補足情報

Rails実行環境構築

Railsのインストール

Railsをインストールします。
インストールはrootで行います。

$ su -
パスワード:

最初にgemを最新化します。

# gem update

Railsをインストールします。

# gem install rails

環境変数($PATH)の再読み込みします。

# source ~/.bashrc

Railsがインストールされていることを確認します。

# which rails
/usr/local/src/rbenv/shims/rails

bundlerのインストール

bundlerというRailsアプリケーション毎にgemパッケージ/ライブラリを独立して管理するためのツールをインストールします。

# gem install bundler

# exit

新規Railsアプリケーション作成と初期設定

テスト用にrailsappという名前のRailsアプリケーションを作成します。
-dオプションでデータベースにPostgreSQLを指定します。--with-pg-configオプションにはpg_configのPATHを指定します。PostgreSQL 9.2のRPMパッケージでインストールした場合は/usr/pgsql-9.2/bin/pg_configとなっていると思います。
また、新規Railsアプリケーション作成(rails new実行)時、Gemfileに基づいたgemパッケージ/ライブラリ類のインストール(bundle install)が自動で実行されますが、Gemfileは後に編集するため、最初は--skip-bundleのオプションを指定して、bundle installを実行しないようにします。

$ cd /home

$ rails new railsapp -d postgresql --with-pg-config=/usr/pgsql-9.2/bin/pg_config --skip-bundle

database.ymlを編集し、Railsからのデータベースへの接続情報(ユーザ名,パスワード)を設定します。

$ cd /home/railsapp/config

$ vim database.yml
### 以下を修正
development:
  adapter: postgresql
  encoding: unicode
  database: railsapp_development
  pool: 5
  username: rails                 #<-Railsアプリ接続用のPostgreSQLユーザを設定
  password: rails                 #<-Railsアプリ接続用のPostgreSQLパスワードを設定

Gemfile内に必要なgemパッケージ/ライブラリを追記します。

$ cd /home/railsapp

$ vim Gemfile
…
gem 'pg'            # <- 利用するDB(ここではPostgreSQL)のgemパッケージ

gem 'execjs'        # <- javascriptランタイムライブラリ
gem 'therubyracer'  # <- javascriptランタイムライブラリ
…
gem 'haml-rails'    # <- hamlライブラリ
…
gem 'unicorn'       # <- Unicornライブラリ 
…

Gemfileを編集したらbundle installを実行し、Gemfileに記述されたパッケージ/ライブラリをインストールします。
このとき--pathオプションを指定することで、そのRailsアプリケーションの任意のディレクトリ配下にgemパッケージ/ライブラリ類をインストールできます($RAILS_ROOT/vendor/bundlerディレクトリにインストールするのが一般的です)。
これによりインストールしたgemパッケージ/ライブラリは、このRailsアプリケーションのみで利用可能な状態となり、他の環境に影響を与えません。

$ cd /home/railsapp

% bundle install --path vendor/bundle

これでRailsアプリケーションの作成は完了です。

PostgreSQLの設定

Railsアプリで利用するためのデータベースを作成します。 まず、PostgreSQLサーバにログインします。

$ psql -U postgres
psql (9.2.2)
"help"でヘルプを表示します.

postgres=# 

Rails接続用のユーザを作成します。

# CREATE USER rails WITH PASSWORD '************' CREATEDB CREATEUSER;
CREATE ROLE

Rails用のデータベースを作成します。

# CREATE DATABASE railsapp_development;
CREATE DATABASE

Unicornの設定

configディレクトリ配下にunicorn.rbというファイルを作成し、以下のような内容を記載します。

$ cd /home/railsapp/config

$ vim unicorn.rb
application = 'railsapp'

worker_processes 2
working_directory "/home/#{application}"

listen "/var/run/unicorn/unicorn_#{application}.sock"   # Unix Domain Socket

pid "/var/run/unicorn/unicorn_#{application}.pid"       # PIDファイル出力先

timeout 60

preload_app true

stdout_path "/var/log/unicorn/unicorn.stdout_#{application}.log"  # 標準出力ログ出力先
stderr_path "/var/log/unicorn/unicorn.stderr_#{application}.log"  # 標準エラー出力ログ出力先

GC.respond_to?(:copy_on_write_friendly=) and GC.copy_on_write_friendly = true

before_fork do |server, worker|
  defined?(ActiveRecord::Base) and ActiveRecord::Base.connection.disconnect!

  old_pid = "#{server.config[:pid]}.oldbin"
    if old_pid != server.pid
      begin
        sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
        Process.kill(sig, File.read(old_pid).to_i)
      rescue Errno::ENOENT, Errno::ESRCH
      end
    end

    sleep 1
  end

after_fork do |server, worker|
  defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection
end

UnicornログファイルやPIDファイル用のディレクトリを作成します。

$ su -
パスワード:

# mkdir /var/log/unicorn

# chmod 777 /var/log/unicorn

# mkdir /var/run/unicorn

# chmod 777 /var/run/unicorn

Nginxの設定

Unicornと連携するためのNginxの設定ファイルを作成します。
デフォルトのnginx.confを編集したくないので、/etc/nginx/conf.d配下にnginxの設定ファイル(ここでは仮としてrails.conf)を新規に作成します。
前述のとおり、バックエンドのUnicornとの通信にはUnix Domain Socketを利用します。TCP通信を利用したい場合はproxy_passにTCPのものを適用してください。

$ su -
パスワード:

# cd /etc/nginx/conf.d

# vim rails.conf

    ### バックエンドのUnicornとの通信にはUnix Domain SocketかTCPのいずれかを利用
    ### ここではUnix Domain Socketを利用
    upstream unicorn-unix-domain-socket {
        ### unicorn.rbで指定したUnicornのソケットを指定:
        server unix:/var/run/unicorn/unicorn_railsapp.sock fail_timeout=0;
    }

    upstream unicorn-tcp {
        ### unicornのポートを指定 ※ここでは、Unicorn起動時にポート 13000で起動させるものとします。
        server 127.0.0.1:13000;
    }

    server {
        listen 80;
        server_name xxxxx.sakura.ne.jp;

        root /home/railsapp/public;

        access_log  /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        location / {
            if (-f $request_filename) {
                break;
            }

            proxy_set_header X-Real-IP  $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;

            proxy_pass http://unicorn-unix-domain-socket;      # unix domain socketを使う場合
            # proxy_pass http://unicorn-tcp;                   # tcpを使う場合
         }

         location ~* \.(ico|css|js|gif|jpe?g|png)(\?[0-9]+)?$ {
            expires 1y;
         }
     }

デフォルトの設定ファイルが読み込まれないようにリネームしておきます。

# mv default.conf _default.conf_

# service nginx restart
Stopping nginx:                                            [  OK  ]
Starting nginx:                                            [  OK  ]

確認

Unicornの起動

Nginxの設定ファイルに記述したとおりに、Unicornを使ってRailsをポート13000(-pオプション)を使ってデーモンモード(-Dオプション)としてバックグラウンドで起動させます。環境はdevelopment(-Eオプション)とします。

$ unicorn_rails -c /home/railsapp/config/unicorn.rb -E development -D -p 13000

さくらのVPS環境にブラウザからhttpでアクセスすると、以下のような画面が表示されると思います。

http://xxx.xxx.xxx.xxx # <- さくらのVPSのホストのIPアドレス

"About your application’s environment"を押下して、以下のようにRailsの環境情報が表示されればWebサーバやDBサーバとの連携が正常に行えていることになります。

おわりに

以上で、CentOS 6.3上でUnucornを使ったRails実行環境ができました。 Railsと合わせてUnicornやNginxについても勉強しながらもっと環境整備をできればと思います。 あとはCapistranoを使ってのデプロイ自動化も行っていきたいです。

はじめに

• オープンソースカンファレンス2013 Tokyo/Spring : 覚えて楽するシェル一行野郎、10選！- 魅せます☆華麗なシェル芸！

FizzBuzzワンライナー

おわりに

はじめに

第15回FreeBSD勉強会へ行ってきましたのでそのまとめです。
理解できていなかった部分や聞き取れなかった部分等は後で調べたりして記載していますが、誤りなどがあれば申し訳ありません。

• 第15回FreeBSD勉強会 インストーラを使わないでFreeBSDをインストールする方法

勉強会の概要

FreeBSDに限った話ではないと思いますが、Unix/Linux系OSの多くはインストーラを利用してインストールを行うことが多いと思います。インストーラはディスクのパーティショニング、kernel等各種ファイルの展開，その他基本的な初期設定などを代替で行ってくれるものですが、その裏ではコマンドを実行してこれらの処理を実行しているだけであり，インストーラを使わなくてもFreeBSDをインストールすることができます。
今回の勉強会では、FreeBSDのインストーラが実施している内容やブートの仕組みについての解説、実際にインストーラを使わない方法でのFreeBSDのインストールを実演していただき、FreeBSDのインストールの仕組みを理解しよう、というものでした。

インストーラとその役割

まずは、FreeBSDのboot(起動)処理の仕組みについてのお話でした。

FreeBSDのインストーラ

FreeBSDのインストーラには以下の２つがあります。

• sysinstall(FreeBSD 8.X以前)
• bsdinstall(FreeBSD 9.X以降)

インストーラの役割

インストーラは以下のことを実行するための手助けをしてくれます。これらは処理としては設定を行うためのコマンドが裏で実行されているだけです。

• インストールメディアから、OSを起動するためのプログラムをディスクの決められた場所に配置する
• ファイルシステムを作成する
• ファイルシステムに必要な配布物/ソフトウェア類をコピーする
• その他必要なOS初期設定を行う

FreeBSDのboot処理

FreeBSDのboot処理についてのお話です。

MBRによるboot処理

1. BIOSがboot0を読み込む。

• HWに搭載されているBIOSと呼ばれるプログラムがHDDの先頭512バイトを読み込んで実行する。
• HDDの先頭512バイトはboot0と呼ばれるブートローダプログラムが書き込まれており、これが呼び出される。MBRに相当する。

• boot0はboot1を検索し実行するためのプログラム。boot1/2はファイルシステムの外のディスクの決まった位置にあるためboot0はそこを読みに行く。

• boot1はboot2を検索し実行するためのプログラム。boot1は512バイトのサイズである必要があるという制約があり、boot2と分かれている。

• boot2はUFS上の/boot/loaderを検索して起動するプログラム。UFSファイルシステムを認識することができる。

BIOS → MBR(boot0) → boot1 → boot2 → /boot/loader → kernel → init
----    ----------    --------------    ------------------------------
BIOS    MBR           起動セクタ        UFSパーティション
※boot0/1/2はファイルシステムの外側にある

GPTとUEFIの特徴とFreeBSDの対応

MBRでは2TBを越えるディスクを管理できない(HDDの1セクタ512バイトの場合(512バイト×4バイト(=2の32乗(LBA(Logical Block Addressing)でアクセスできるセクタ数の上限)))という問題があり、昨今の大容量化するディスクに対応できません。そこで新たな規格としてGPTが出てきました。
さらに、FreeBSDではFreeBSD 9.0からGPTが正式にサポートされました。そのため、今後ブートの規格はMBRではなくGPTへ移行され、GPT化に伴って、従来のBIOSからGPTをサポートしている新しいBIOSであるUEFI(Unified Extensible Firmware Interface)へ移行される予定とのことです。

• GPTでは、最大8ZB迄の領域を管理できる。
• MBRは512Bの領域を必要とする。4パーティションまでしか扱えない。GPTは17kBの領域を必要とする。128パーティションまで扱える。
• GPTヘッダーとパーティションテーブルはディスクの先頭と最後部の両方に書き込まれている。
• UEFIはFreeBSDではまだ未対応であり、今後開発が進められていく予定(UFS2に対応できていない)



※補足

• GUIDパーティションテーブル
• Unified Extensible Firmware Interface

GPTによるboot処理

1. BIOSがpmbrを読み込む。
2. pmbrはFreebsd-bootパーティションを読み込み、そこにあるgptbootを実行する。
3. gptbootはfreebsd-ufsパーティションを読み込み、UFSファイルシステム上の/boot/loaderを実行する。

BIOS → pmbr → gptboot      → /boot/loader → kernel → init
----    ----    ------------    ------------------------------
BIOS    GPT     freebsd-boot    freebsd-ufs

4. loaderは起動オプションに従ってkernelをロードする。
5. kernelはデバイスやドライバの認識/初期化し、デバイスツリーを作成する。
6. initを実行する。

PMBR(Protective Master Boot Record)

• GPTで利用されるブートローダ。BIOS/UEFIから実行可能。現在のFreeBSDではBIOSからboot0/1/2と同じような形で必要なファイルを読み込み、起動している。
• freebsd-bootパーティションを探し出し、gptbootを実行する。
• MBRの場合と比べて起動時の処理が一つ減る。

インストーラとコマンドの対応

インストーラが裏で実際に行っていることは、以下のように設定に必要なコマンドを実行しているだけであり、インストーラを使わずともコマンドを実行していくことでFreeBSDをインストールすることができます。実演された内容の一部を記載します。

• キーマップの選択

% kbdmap = printf 'keymap="jp.106.kbd"\n'>> /etc/rc.conf

※単にkbdmapコマンドを実行すると、キーボード設定用のコンソール画面が起動して設定できるので便利とのことでした。

GPTパーティション作成

% gpart create -s gpt /dev/da0

1番目のスライスにfreebsd-bootパーティション作成

% gpart add -s 64K -b 34 -t freebsd-boot -l /boot/boot0 /dev/da0

3番目のスライスにfreebsd-swapパーティション作成

%gpart add -s 1G -t freebsd-swap -l swap0 /dev/da0

※ディスクフォーマット

% newfs -U /dev/デバイス名

% printf '********' | pw usermod -n root -h 0

% tzsetup Asia/Tokyo

% printf 'dumpdev="AUTO"\n'>> /etc/rc.conf
% dumpon /dev/ada0p3
% ln -sf /dev/ada0p3 /dev/dumpdev

これらインストーラと同じ処理を行うコマンドを利用することで、インストール処理をスクリプトで自動化できるということです。
また、上記でechoではなくprintfを利用しているのは、echoはPOSIXに準拠されていないためのようで、移植性を考えるとprintfを利用した方が良いとのことです。

その他

• AsiaBSDCon 2013

講師の後藤大地様よりAsiaBSDCon 2013のお知らせです。なお、スポンサーとして500万以上出すとG○○gle様より上に名前が載るそうです。

• CloudCore VPS｜KDDIウェブコミュニケーションズ

会場を御提供していただいたKDDIウェブコミュニケーションズ様よりCloudCore VPSの御紹介がありました。

おわりに

次回のFreeBSD勉強会では今回の内容を絡めた内容となるようですね。

カスタマイズした自分だけのFreeBSD LiveUSBメモリスティックを作りたい方は、今回のFreeBSD勉強会の内容も聞いておいた方がよいかと思います atnd.org/events/35877

— Daichi GOTOさん (@daichigoto) 2013年2月22日

最後になりましたが、関係者の皆様、このような機会を提供いただきまして誠にありがとうございました。

• 実践 FreeBSD サーバ構築・運用ガイド

はじめに

2013/02/24 Ruby 2.0.0p-0がリリースされたとのことで、rbenv管理でインストールしてみました。

• Ruby 2.0.0-p0 リリース

rbenvとruby-buildは、以前こちらの内容の通りにGithubから取得してインストールしていましたが、そのままではRuby 2.0.0-p0が含まれておらず、インストール出来ません。ruby-buildを最新にアップデートし、インストールを実施する必要があります。

以下にruby-buildのアップデートとRuby 2.0.0-p0のインストールの手順をまとめましたので記載致します。

インストール環境

インストール環境は以下です。

事前準備

Ruby 2.0.0-p0のインストールに当たってopenss-develパッケージが必要です。 openss-develパッケージがない場合はあらかじめインストールしておきます。

# yum install openssl-devel

rbenv環境の最新化

ruby-buildのアップデート

公式手順通りにアップデートします。

• Installing as a standalone program (advanced) - sstephenson / ruby-build

rootにスイッチします。

$ su -
パスワード:

ruby-build取得先ディレクトリへ移動します。

# cd /usr/local/src/rbenv/plugins/ruby-build

git pullして最新のソースを取得します。

# git pull origin master
remote: Counting objects: 245, done.
remote: Compressing objects: 100% (89/89), done.
remote: Total 217 (delta 139), reused 184 (delta 110)
Receiving objects: 100% (217/217), 24.65 KiB, done.
Resolving deltas: 100% (139/139), completed with 14 local objects.
From git://github.com/sstephenson/ruby-build
 * branch            master     -> FETCH_HEAD
Updating a6395eb..97fc5c5
Fast-forward
 CHANGELOG.md                    |   16 ++++++
 README.md                       |   17 +------
 bin/rbenv-install               |   15 +++++-
 bin/ruby-build                  |  105 ++++++++++++++++++++++++++++++++++-----
 share/ruby-build/1.9.3-p385     |    2 +
 share/ruby-build/1.9.3-p392     |    2 +
 share/ruby-build/2.0.0-dev      |    3 +-
 share/ruby-build/2.0.0-p0       |    2 +
 share/ruby-build/2.0.0-preview1 |    3 +-
 share/ruby-build/2.0.0-preview2 |    3 +-
 share/ruby-build/2.0.0-rc1      |    3 +-
 share/ruby-build/2.0.0-rc2      |    2 +
 share/ruby-build/jruby-1.7.3    |    1 +
 share/ruby-build/rbx-2.0.0-dev  |    1 +
 14 files changed, 142 insertions(+), 33 deletions(-)
 create mode 100644 share/ruby-build/1.9.3-p385
 create mode 100644 share/ruby-build/1.9.3-p392
 create mode 100644 share/ruby-build/2.0.0-p0
 create mode 100644 share/ruby-build/2.0.0-rc2
 create mode 100644 share/ruby-build/jruby-1.7.3

インストールスクリプトを実行します。

# ./install.sh
Installed ruby-build at /usr/local/src/rbenv

以上で、ruby-buildのアップデートは完了です。

インストール可能なRubyの一覧を見ると、Ruby 2.0.0-p0があることがわかります。

# rbenv install -l
Available versions:
  1.8.6-p383
  1.8.6-p420
  1.8.7-p249
  1.8.7-p302
  1.8.7-p334
  1.8.7-p352
  1.8.7-p357
  1.8.7-p358
  1.8.7-p370
  1.8.7-p371
  1.9.1-p378
  1.9.2-p180
  1.9.2-p290
  1.9.2-p318
  1.9.2-p320
  1.9.3-dev
  1.9.3-p0
  1.9.3-p125
  1.9.3-p194
  1.9.3-p286
  1.9.3-p327
  1.9.3-p362
  1.9.3-p374
  1.9.3-p385
  1.9.3-p392
  1.9.3-preview1
  1.9.3-rc1
  2.0.0-dev
  2.0.0-p0
  2.0.0-preview1
  2.0.0-preview2
  2.0.0-rc1
  2.0.0-rc2
  jruby-1.5.6
  jruby-1.6.3
  jruby-1.6.4
  jruby-1.6.5
  jruby-1.6.5.1
  jruby-1.6.6
  jruby-1.6.7
  jruby-1.6.7.2
  jruby-1.6.8
  jruby-1.7.0
  jruby-1.7.0-preview1
  jruby-1.7.0-preview2
  jruby-1.7.0-rc1
  jruby-1.7.0-rc2
  jruby-1.7.1
  jruby-1.7.2
  jruby-1.7.3
  maglev-1.0.0
  maglev-1.1.0-dev
  rbx-1.2.4
  rbx-2.0.0-dev
  rbx-2.0.0-rc1
  ree-1.8.6-2009.06
  ree-1.8.7-2009.09
  ree-1.8.7-2009.10
  ree-1.8.7-2010.01
  ree-1.8.7-2010.02
  ree-1.8.7-2011.03
  ree-1.8.7-2011.12
  ree-1.8.7-2012.01
  ree-1.8.7-2012.02

Ruby 2.0.0-p0のインストールと設定

Ruby 2.0.0-p0のインストール

Ruby 2.0.0-p0のインストールを行います。

# rbenv install 2.0.0-p0
Downloading ruby-2.0.0-p0.tar.gz...
-> http://ftp.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p0.tar.gz
Installing ruby-2.0.0-p0...
Installed ruby-2.0.0-p0 to /usr/local/src/rbenv/versions/2.0.0-p0

インストールされたRubyのバージョン一覧と現在設定されているRubyのバージョンを確認してみます。
(現在設定されているRubyのバージョンには"*"が付与されます。)

# rbenv versions
* 1.9.3-p374 (set by /usr/local/src/rbenv/version)
  2.0.0-p0

利用するRubyを2.0.0-p0へ切り替え

システム全体で使用するRubyのバージョンを変更します。

# rbenv global 2.0.0-p0

rbenv rehashを実行し、gemなどのツールの実行ファイルを作成します。

# rbenv rehash

再度、現在設定されているRubyのバージョンを確認してみます

# rbenv versions
  1.9.3-p374
* 2.0.0-p0 (set by /usr/local/src/rbenv/version)

# ruby -v
ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-linux]

以上でrbenv管理でのRuby 2.0.0-p0がインストールできました。

おわりに

以下を見るとRuby 2.0.0で多くの新機能や改善がなされたようですが、ものすごいボリュームに加えてまだまだRuby初心者なので全く読み切れてません。

• Ruby 2.0.0 リリース特集

はじめに

いろいろな書籍や雑誌、WEBサイトの記事等を読んでいくなかで、Linuxカーネルのソースコードを見たい時(きちんと読める訳ではありませんが…)が何度かありましたので、自身のCentOS 6.3環境にソースコードを取得して、それを参照できるようにしてみました。

環境

実施した際の環境は以下の通りです。

カーネルのソースコードのダウンロード手順

Yumリポジトリの設定

CentOS 6.2からソースコードが http://vault.centos.orgに配置されているようですので、yumでこれを参照できるようにリポジトリの設定を行います。

• 7. Sources - CentOS 6.2 Release Notes
• 8. Sources - CentOS 6.3 Release Notes

rootにスイッチします。

$ su -
パスワード：

CentOS-Source.repoというリポジトリ設定ファイルを作成し、以下のような内容を記載します。

# cd /etc/yum.repos.d

# vim CentOS-Source.repo
[base-source]
name=CentOS-$releasever - Base Source
baseurl=http://vault.centos.org/$releasever/os/Source/
gpgcheck=1
enabled=0
gpgkey=http://vault.centos.org/RPM-GPG-KEY-CentOS-6

[updates-source]
name=CentOS-$releasever - Updates Source
baseurl=http://vault.centos.org/$releasever/updates/Source/
gpgcheck=1
enabled=0
gpgkey=http://vault.centos.org/RPM-GPG-KEY-CentOS-6

[extras-source]
name=CentOS-$releasever - Extras Source
baseurl=http://vault.centos.org/$releasever/extras/Source/
gpgcheck=1
enabled=0
gpgkey=http://vault.centos.org/RPM-GPG-KEY-CentOS-6

リポジトリの設定はこれで完了です。

ソースコードのRPMパッケージのダウンロード

ソースコードをRPMパッケージをダウンロードします。
作業用のディレクトリを作成します。ここでは/tmp配下にkernelというディレクトリを作成しています。

# mkdir -p /tmp/kernel

作成したディレクトリに移動します。

# cd /tmp/kernel

CentOS 6.3のカーネルをダウンロードします。--releaseverオプションでバージョンを指定します。

# yumdownloader --source kernel --releasever=6.3

以下のファイルが取得されています。

# ls
kernel-2.6.32-279.22.1.el6.src.rpm

RPMパッケージからソースコードのファイルの取得

RPMパッケージからファイルを取り出します。これを実施するにはRPMパッケージをcpio形式のアーカイブファイルに変換し、cpioコマンドで取り出すことができます。具体的なオペレーション手順としては、rpm2cpioコマンドでRPMファイルをcpioファイルに変換し、標準出力に出力されるcpio形式のアーカイブをパイプでcpioに渡して展開します。

# rpm2cpio kernel-2.6.32-279.22.1.el6.src.rpm | cpio -id
167602 blocks

いくつかのファイルが生成されますが、その中にlinux-2.6.32-279.22.1.el6.tar.bz2というファイルがあります。これを展開します。

# tar -xjvf linux-2.6.32-279.22.1.el6.tar.bz2

linux-2.6.32-279.22.1.el6ディレクトリが作成され、その配下にカーネルのソースコード類が配置されています。

# cd linux-2.6.32-279.22.1.el6

# ls
COPYING        Makefile         block     include   lib      security
CREDITS        Makefile.common  crypto    init      mm       sound
Documentation  README           drivers   ipc       net      tools
Kbuild         REPORTING-BUGS   firmware  kabitool  samples  usr
MAINTAINERS    arch             fs        kernel    scripts  virt

これでCentOS 6.3のソースコードの取得ができました。
私はApacheのドキュメントルート以下のディレクトリにシンボリックリンクを張って、httpでWEB上から参照できるようにしています。

おわりに

カーネルのソースコードを解読するのは今の自分にかなりハードルが高いですが、OSの仕組みを知る上ではカーネルの仕組みを理解するのは大事なことだと思いますので、少しずつ目を通して理解を深めていきたいと思います。

はじめに

PostgreSQLのベンチマークを行う際、pgbenchというツールはPostgreSQLに付属していることもあり、よく用いられると思います。

• pgbench — PostgreSQL 9.2.X文書
• pgbenchの使いこなし — Let's Postgres

pgbenchはTPC-B(銀行の窓口業務をモデルにした単純なトランザクションによる性能評価基準)をベースとしたベンチマークで、もう少し高度なベンチマークを実施してみようと思い、TPC-Cベースのベンチマークが実行できるTPCC-UVaというツールを利用してみました。

• TPCC-UVa: A free, open-source implementation of the TPC-C Benchmark — Diego R. Llanos

開発が終わっているのか2006年を最後にリリースが止まっていますが、PostgreSQL 9.2に対しても実行できましたので、その手順等をまとめておきます。

TPCのベンチマーク基準

概要

一般的にデータベースのベンチマークには「TPC（Transaction Processing Performance Council)」という団体が定義している「TPC-A」「TPC-B」「TPC-C」「TPC-D」「TPC-H」「TPC-R」「TPC-W」という性能評価基準があります。このうち、TPC-A、B、D、R、Wは既に廃止(observe)となっていることもあり利用が少なく、現在ではTPC-CやTCP-E、TPC-Hあたりがよく利用されるものと思います。
TPC-C,E,Hの概要についてはTPCのサイトを参照していただければと思いますが、極簡単に記載しますと、

• TPC-C
卸売り会社の業務をモデルとしたトランザクション処理をシミュレートして性能を評価するベンチマーク
• TPC-E
証券会社の株取引業務をモデルとしたトランザクション処理をシミュレートして性能を評価するベンチマーク
• TPC-H
大型基幹業務向け意思決定支援環境をシミュレートして性能を評価するベンチマーク

となります。

特にTPC-Eはかなり複雑なモデルですがテストデータも実際のデータが用いられているようで、その分より正確なベンチマーク結果が得られると考えられますが、これらのベンチマークテストはそれぞれCPUやディスクのどちらにより負荷がかかるかなどが異なりますので、ベンチマークの仕様を把握して、実際に利用するシステムの目的に即したものを選択するのが良いと思います。

PostgreSQLのTPC-Cのベンチマークツール TPCC-UVa

公式サイトに記載がありますが、TPCC-UVaはLinux環境で実行できるC言語で書かれたPostgreSQL用のTPC-Cベースのベンチマークツールです。Diego R. Llanos氏、Eduardo Hernández Perdiguero氏、Julio Alberto Hernández Gonzalo氏らがスペインのバリャドリード大学の卒業研究として開発されたもののようです。

Although the TPC-C specifications are public, there was not a public implementation: each company develops and uses its own. We have developed an open-source version of the TPC-C benchmark, following the terms of the GPL license. This version, called TPCC-UVa, is written entirely in C language and can be run in any Linux system. It uses the PostgreSQL database system and a simple transaction monitor. This benchmark can be used to measure the speed of different computers or to analyze the behavior of individual components, either hardware or software, and its impact on the overall performance of the system. The development was started by Eduardo Hernández Perdiguero and Julio Alberto Hernández Gonzalo as their Bachelor's Thesis in the Escuela Universitaria Politécnica, University of Valladolid, with the advise of Diego R. Llanos. 

また、これはPostgreSQL向けのTPC-Cのシンプルな実装であり、他のTPC-Cによる結果とは比較できないとのことです。

Note: To release TPCC-UVa as an open-source program, we use our own version of a very simple Transaction Monitor (TM), instead of using any commercial TM. Because of that, the results obtained with TPCC-UVa, particularly our performance parameter "TPCC-UVa Transactions per minute (tpmC-uva)" should not be compared  with values of tpmC obtained with other implementations.

実行環境情報

インストールやベンチマークを実行する環境を以下に示します。

HW環境

HW環境は以下の通りです。

インストールディレクトリ

取得したTPCC-UVaのアーカイブの中にTPCC-UVaの他にPostgreSQL 8.1.4, GunPlotが含まれていますので、それらを全てインストールすることとして、インストール先ディレクトリ/作業ディレクトリをそれぞれ以下とします。
※TPCC-UVaの利用にはPostgreSQL 8.1.4(の中に含まれているlibecpg.so.5.1というライブラリ)が必要になります。

インストール事前準備

作業は全てrootで実行しています。

$ su -
パスワード:

必要なパッケージのインストール

PostgreSQL 8.1.4のインストール時に下記のパッケージが必要になりますので、存在しない場合はインストールを行います。

# yum install zlib readline gcc

インストール先ディレクトリの作成

インストール先ディレクトリを作成します。

# mkdir /home/tpccuva

TPCC-UVaのソースコードの取得

/tmp配下にTPCC-UVaのソースコードを取得して展開します。

# cd /tmp

# wget http://www.infor.uva.es/~diego/tpccuva/tpccuva-1.2.3-tarball.tar.gz

# tar -zxvf tpccuva-1.2.3-tarball.tar.gz

展開したファイルの中にtpccuva-guide.pdfというPDFがあります。 基本的にここに記載されている手順に沿ってインストールを行います。

インストール

PostgreSQL 8.1.4のインストール

PostgreSQL 8.1.4のアーカイブファイルを展開します。

# cd /tmp/tpccuva-1.2.3-tarball

# bzip2 -dc postgresql-base-8.1.4.tar.bz2 | tar xvf -

展開して作成されたディレクトリに移動し、makeファイルを作成します。--prefixでインストール先を指定します。

# cd /tmp/tpccuva-1.2.3-tarball/postgresql-base-8.1.4

# ./configure --prefix=/home/tpcc-uva/pgsql

コンパイル、およびインストールを行います。

# gmake && gmake install

gunplot 3.7.1のインストール

続いて付属されているgunplotのインストールを行います。

# cd /tmp/tpccuva-1.2.3-tarball

# tar -zxvf gnuplot-3.7.1.tar.gz

# cd /tmp/tpccuva-1.2.3-tarball/gnuplot-3.7.1

# ./configure --prefix=/home/tpcc-uva/bin --without-x

# make && make install

TPCC-UVaのインストール

ログ生成先となるディレクトリを作成します。

# mkdir -p /home/tpcc-uva/var/tpcc

TPCC-UVaのファイルを展開します。

# cd /tmp/tpccuva-1.2.3-tarball

# tar -zxvf tpccuva-1.2.3.tar.gz

展開して作成されたファイルに移動し、Makefileを環境に合わせて修正します。Makefileはバックアップを取得しておきます。

# cd /tmp/tpccuva-1.2.3-tarball/tpccuva-1.2.3

# cp -p Makefile Makefile.backup

# vim Makefile
=== 修正内容 ===
 # VARDIR stores where the auxiliary files will be stored during the
 # benchmark execution. Do not forget the last slash!
-VARDIR = $(HOME)/tpcc-uva/var/tpcc/
+#VARDIR = $(HOME)/tpcc-uva/var/tpcc/
+VARDIR = /home/pgsql/tpcc-uva/var/tpcc/

 # EXECDIR stores where the executable files will be stored during the
 # installation. Do not forget the last slash!
-EXECDIR = $(HOME)/tpcc-uva/bin/
+#EXECDIR = $(HOME)/tpcc-uva/bin/
+EXECDIR = /home/pgsql/tpcc-uva/bin/

 # INCLUDEPATH stores the location of PostgreSQL include files.
-export INCLUDEPATH = $(HOME)/tpcc-uva/pgsql/include/
+#export INCLUDEPATH = $(HOME)/tpcc-uva/pgsql/include/
+export INCLUDEPATH = /home/pgsql/tpcc-uva/pgsql/include/

 # LIBSPATH stores the location of PostgreSQL library files.
-export LIBSPATH = $(HOME)/tpcc-uva/pgsql/lib/
+#export LIBSPATH = $(HOME)/tpcc-uva/pgsql/lib/
+export LIBSPATH = /home/pgsql/tpcc-uva/pgsql/lib/

環境変数を設定します。 これは各種プログラムを実行する上で必要ですので、必要であれば実行ユーザの.bashrcなどに記載しておくと良いと思います。

# export PATH=$PATH:/home/tpcc-uva/pgsql/bin:/home/tpcc-uva/bin
# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/tpcc-uva/pgsql/lib

コンパイルして、インストールを実施します。

# make && make install

以上で、インストール作業が完了しました。

ベンチマークの実行

ベンチマークを実行してみます。
ベンチマーク対象はPostgreSQLサーバは9.2.2で、あらかじめインストールされているものとします。特にパラメータは変更しておらず、インストール時のデフォルトとしています。
実行に必要な環境変数を設定します。※インストール時に設定したものと同様の内容です。

# export PATH=$PATH:/home/tpcc-uva/pgsql/bin:/home/tpcc-uva/bin/
# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/tpcc-uva/pgsql/lib

TPCC-UVaによるベンチマークプログラム、benchを実行します。

# /home/tpcc-uva/bin/bench



    +---------------------------------------------------+
    | BENCHMARK TPCC  --- UNIVERSIDAD DE VALLADOLID --- |
    +---------------------------------------------------+




        1.- CREATE A NEW TEST DATABASE







        8.- Quit





SELECT OPTION:

※接続できない場合

もし、以下のようなエラーが出る場合、接続ユーザが存在していない可能性があります。 (私の環境ではpostgresユーザを含むOS上のどのユーザで実行しても、rootで接続しようとしてエラーとなっていました。接続ユーザを制御する方法があるのかはわかっていません。)

Error number: -402
        Could not connect to database template1 in line 4208.
Error checking if database exists.
Error number: -220
        No such connection NULL in line 4216.

PostgreSQLにrootユーザを作成します。最低限DB作成権限を与えておきます。

# psql -U postgres

postgres=# CREATE USER root CREATEDB CREATEUSER;

postgres=# select * from pg_user;
 usename  | usesysid | usecreatedb | usesuper | usecatupd | userepl |  passwd  | valuntil | useconfig
----------+----------+-------------+----------+-----------+---------+----------+----------+-----------
 postgres |       10 | t           | t        | t         | t       | ******** |          |
 pgbench  |    16491 | f           | f        | f         | f       | ******** |          |
 root     |    16517 | t           | t        | t         | f       | ******** |          |
(5 rows)

初回実行時は"1.- CREATE A NEW TEST DATABASE"を選んでベンチマーク用のデータベースを作成します。 しばらく待つとベンチマーク用のデータベースとテーブルが作成されます。

SELECT OPTION: 1

warehouses(倉庫)をいくつ作成するか問われます。ここでは1を選択しています。
データが作成されると"Continue..."となるのでEnterキーを押下します。

Enter the number of warehouses: 1
Continue? (y/n): y
Starting to populate database.
Start time: 2013-03-10 11:28:31
POPULATING DATABASE WITH 1 WAREHOUSES...
…
POPULATION COMPLETED.
Start time: 2013-03-10 11:28:31
End time: 2013-03-10 11:39:58

Continue...

続いて以下のような画面となりますが、一旦オプションの"8.- Quit"を選択して実行を終了し、PostgreSQLサーバにログインして、テストデータベースの情報をみてみます。

    +---------------------------------------------------+
    | BENCHMARK TPCC  --- UNIVERSIDAD DE VALLADOLID --- |
    +---------------------------------------------------+




        2.- RESTORE EXISTING DATABASE.
        3.- RUN THE TEST.
        4.- CHECK DATABASE CONSISTENCY.
        5.- DELETE DATABASE.

        7.- CHECK DATABASE STATE.


        8.- Quit





SELECT OPTION:

PostgreSQLサーバにログインすると、tpccというデータベースが作成されており、その中に以下のようなテーブルが作成されていることが分かります。

# psql -U root tpcc

tpcc=# \l
             List of databases
        Name         |  Owner   | Encoding
---------------------+----------+----------
 pgbench             | pgbench  | UTF8
 postgres            | postgres | UTF8
 template0           | postgres | UTF8
 template1           | postgres | UTF8
 tpcc                | root     | UTF8
(9 rows)

tpcc=# \d
          List of relations
 Schema |    Name    | Type  | Owner
--------+------------+-------+-------
 public | customer   | table | root
 public | district   | table | root
 public | history    | table | root
 public | item       | table | root
 public | new_order  | table | root
 public | order_line | table | root
 public | orderr     | table | root
 public | stock      | table | root
 public | warehouse  | table | root
(9 rows)

各テーブルは以下のようなデータが作成されています。 テーブルの中にはデタラメな値が入力されています。

続けます。再度benchを実行します。

# bench




    +---------------------------------------------------+
    | BENCHMARK TPCC  --- UNIVERSIDAD DE VALLADOLID --- |
    +---------------------------------------------------+




        2.- RESTORE EXISTING DATABASE.
        3.- RUN THE TEST.
        4.- CHECK DATABASE CONSISTENCY.
        5.- DELETE DATABASE.

        7.- CHECK DATABASE STATE.


        8.- Quit





SELECT OPTION:

オプションの"3.- RUN THE TEST."を選択し、ベンチマークテストを実行してみます。選択肢の

SELECT OPTION: 3
->Enter number of warehouses 1
->Enter number of terminals per warehouse (max. 10) 10
->Enter ramp-up period (minutes) 20
->Enter measurement interval (minutes) 300
Continue? (y/n): y
->Do you want to perform vacuums during the test? (y/n): y
        ->Enter interval between vacuums (minutes): 60
->Do you want to specify the maximum number of vacuums? (y/n): y
        ->Enter the maximum number of vacuums: 1
->Performing vacuums every 60 minutes, to reach a maximum number of 1.
Start the test? (y/n): y

• Number of warehouses：
warehousesの数。先ほど作成した数を指定します。
• Number of terminals per warehouse：
1つのwarehousesに対する同時接続数。TPC-C公式仕様書では10となっているようです。
• Ramp-up period：
ベンチマークの記録を開始するまでの時間(分単位)。データがメモリにキャッシュされるまでの時間待つのが望ましいため、プログラム実行開始からベンチマーク計測開始までの待ち時間を指定できます。ユーザガイドには20分程度と記載されていますが、環境に合わせて指定します。
• Measurement period：
ベンチマーク測定を行う時間(分単位)。2時間(120min)から最大で8時間(480min)の値を指定します。
• interval between vacuums：
バキュームを行う間隔(分単位)。
• maximum number of vacuums：
バキュームを行う最大回数。

以下のような処理が流れ続けます。終了するまで待ちます。

…
>> NEW_ORDER Transaction.    Terminal 6.        Done.
>> PAYMENT Transaction.      Terminal 8.        Done.
>> PAYMENT Transaction.      Terminal 1.        Done.
>> PAYMENT Transaction.      Terminal 9.        Done.
>> PAYMENT Transaction.      Terminal 0.        Done.
>> NEW_ORDER Transaction.    Terminal 7.        Done.
>> ORDER_STATUS Transaction. Terminal 3.        Done.
>> DELIVERY Transaction.     Terminal 7.        Done.
>> NEW_ORDER Transaction.    Terminal 2.        Done.
>> PAYMENT Transaction.      Terminal 5.        Done.
>> NEW_ORDER Transaction.    Terminal 6.        Done.
>> PAYMENT Transaction.      Terminal 2.        Done.
>> PAYMENT Transaction.      Terminal 8.        Done.
…

結果データの取得

処理が完了したら、結果のデータを収集します。
データの保存先として以下のディレクトリを作成しておきます。

# mkdir -p /tmp/tpccuva_result

benchコマンドを実行し、オプションの"6.- SHOW AND STORE TEST RESULTS"を選択します。 benchを実行した際のカレントディレクトリに*.datというグラフの生成に必要なファイルが作成されますので、出力結果を保存する先のディレクトリに移動しておきます。

# cd /tmp/tpccuva_result

# /home/tpcc-uva/bin/bench  





    +---------------------------------------------------+
    | BENCHMARK TPCC  --- UNIVERSIDAD DE VALLADOLID --- |
    +---------------------------------------------------+




        2.- RESTORE EXISTING DATABASE.
        3.- RUN THE TEST.
        4.- CHECK DATABASE CONSISTENCY.
        5.- DELETE DATABASE.
        6.- SHOW AND STORE TEST RESULTS
        7.- CHECK DATABASE STATE.


        8.- Quit




SELECT OPTION: 6

以下のようなデータが結果が表示されますが、最後にファイルに出力できるのでそのままEnterキーを押下し続けます。

Computation of performance test done on 2013-03-10 at 13:25:27 for 1 warehouses.

Start of measurement interval: 20.000083 m

End of measurement interval: 320.000083 m

COMPUTED THROUGHPUT: 12.537 tpmC-uva using 1 warehouses.
 8642 Transactions committed.
NEW-ORDER TRANSACTIONS:
  3761 Transactions committed into measurement interval. Total transactions: 4015.
  Percentage of Total transactions: 43.520%
  Percentage of "well done": 100.000%
  Response time (min/avg/max/90th): 0.012 / 0.047 / 0.277 / 0.040
  Percentage of rolled-back transactions: 1.064% .
  Average number of items per order: 9.360 .
  Percentage of remote items: --- (One warehouse only).
  Think time (min/avg/max): 0.000 / 12.167 / 109.000

Continue...

PAYMENT TRANSACTIONS:
  3757 Transactions committed into measurement interval. Total transactions: 4019.
  Percentage of Total transactions: 43.474%
  Percentage of "well done": 100.000%
  Response time (min/avg/max/90th): 0.002 / 0.018 / 0.299 / 0.000
  Percentage of remote transactions: --- (One warehouse only)
  Percentage of customers selected by C_ID: 40.964% .
  Think time (min/avg/max): 0.000 / 12.141 / 109.000

Continue...

ORDER-STATUS TRANSACTIONS:
  372 Transactions committed into measurement interval. Total transactions: 400.
  Percentage of Total transactions: 4.305%
  Percentage of "well done": 100.000%
  Response time (min/avg/max/90th): 0.003 / 0.018 / 0.218 / 0.000
  Percentage of customers selected by C_ID: 42.742% .
  Think time (min/avg/max): 0.000 / 9.642 / 50.000

Continue...

DELIVERY TRANSACTIONS:
  376 Transactions committed into measurement interval. Total transactions: 402.
  Percentage of Total transactions: 4.351%
  Percentage of "well done": 100.000%
  Response time (min/avg/max/90th): 0.000 / 0.000 / 0.001 / 0.000
  Percentage of execution time < 80s : 100.000%
  Execution time min/avg/max: 0.031/0.061/0.171
  No. of skipped districts: 0 .
  Percentage of skipped districts: 0.000%.
  Think time (min/avg/max): 0.000 / 5.136 / 25.000

Continue...

STOCK-LEVEL TRANSACTIONS:
  376 Transactions committed into measurement interval. Total transactions: 402.
  Percentage of Total transactions: 4.351%
  Percentage of "well done": 100.000%
  Response time (min/avg/max/90th): 0.003 / 0.020 / 0.150 / 0.000
  Think time (min/avg/max): 0.000 / 4.987 / 25.000

Continue...


Longest checkpoints:
Start Time      Elapsed time since test start (s)       Execution time (s)
Sun Mar 10 13:45:27 2013        1200.029000             11.729000
Sun Mar 10 16:45:44 2013        12016.485000            4.010000
Sun Mar 10 14:45:39 2013        4812.168000             3.007000
Sun Mar 10 18:15:48 2013        17421.301000            0.601000
Continue ...


Longest vacuums:
Start Time      Elapsed time since test start (s)       Execution time (s)
Sun Mar 10 14:25:27 2013        3600.040000             7.242000

>> TEST PASSED
Continue...

ここでファイルに出力するかどうか問われます。
"y"を入力し、ファイル名を適当に付けて保存します。ここでは/tmp/tpccuva_result配下にtpcc-uva_result_20130310.tpcとして出力させることとし、/tmp/tpccuva_result/tpcc-uva_result_20130310.tpcという形で指定しています。なお、ディレクトリを指定しない場合、ファイルはbenchを実行した際のカレントディレクトリに出力されます。
ここで保存し忘れても再度"6.- SHOW AND STORE TEST RESULTS"を指定して出力できます。

Do yo want to store the results into a file? (y/n): y
   Enter file name (prefereably with .tpc extension)
   filename: /tmp/tpccuva_result/tpcc-uva_result_20130310.tpc
   Results have been written on file /tmp/tpccuva_result/tpcc-uva_result_20130310.tpc.
Continue...

Gnuplotでのグラフ出力

Gnuplotで結果をグラフ出力します。付属のPDRファイル：tpccuva-guide.pdfのP17～P18ページの内容を元に以下のようなスクリプトを作成します。

# vim /tmp/tpccuva_result/tpccuva_result/516.gnp
set terminal postscript 22
set size 1 , 1
set pointsize 1
set output "/tmp/tpccuva_result/561-NewOrder.eps"
set title "Response Time Distribution, New Order transactions"
set xlabel "Response Time (s)"
set ylabel "Number of Transactions"
plot [0: XX ] "/tmp/tpccuva_result/g1NewOrder.dat" with lines

set output "/tmp/tpccuva_result/561-Delivery.eps"
set title "Response Time Distribution, Delivery transactions"
set xlabel "Response Time (s)"
set ylabel "Number of Transactions"
plot [0: XX ] "/tmp/tpccuva_result/g1Delivery.dat" with lines

set output "/tmp/tpccuva_result/561-OrderStatus.eps"
set title "Response Time Distribution, Order Status transactions"
set xlabel "Response Time (s)"
set ylabel "Number of Transactions"
plot [0: XX ] "/tmp/tpccuva_result/g1OrderStatus.dat" with lines

set output "/tmp/tpccuva_result/561-Payment.eps"
set title "Response Time Distribution, Payment transactions"
set xlabel "Response Time (s)"
set ylabel "Number of Transactions"
plot [0: XX ] "/tmp/tpccuva_result/g1Payment.dat" with lines

set output "/tmp/tpccuva_result/561-StockLevel.eps"
set title "Response Time Distribution, Stock Level transactions"
set xlabel "Response Time (s)"
set ylabel "Number of Transactions"
plot [0: XX ] "/tmp/tpccuva_result/g1StockLevel.dat" with lines

"set output"で出力するファイル名を指定します。
グラフのサイズは"set size X, X"で調整します。
"plot[0: XX]"の"XX"は各ベンチマーク結果の"Response time (min/avg/max/90th)"の"90th"の4倍の値を指定します。

作成したスクリプトを実行します。

# /home/tpcc-uva/bin/bin/gnuplot /tmp/tpccuva_result/516.gnp

作成されたファイルの1つを画像ビューアで観てみますと以下のような形となります。

以上のように結果やグラフを収集し、分析/チューニングをしていくことになります。

まだ結果をきちんと確認できていませんが、上記の内容で実行した際にはCPUの%user使用率が100%に張り付いた状態となり、ほとんどI/O負荷は発生しませんでした。 "COMPUTED THROUGHPUT: 12.537"となっており、CPUがネックなのかCPUに負荷がかかる仕様なのか分かりませんが、まずは、ベンチマークの内容を見直してみる必要があるように思っています。

おわりに

PostgreSQLのベンチマーク、パフォーマンスチューニング等のために使えるかと思ってTPCC-UVaを試してみました。開発が進んでいないように思え残念ですが、ベンチマーク用のDBの作成やベンチマーク結果出力、ベンチマーク用のテーブルの削除などがインタラクティブに実行できる点は割と使いやすいように思いました。
ただ、最近ではPostgreSQLに対応したベンチマークツールは最近では他にももっと良いツールがあるかも知れません。

はじめに

MyNA会(日本MySQLユーザ会) 2013年3月 へ参加してきました。

• MyNA News : MyNA(日本MySQLユーザ会)会 2013年3月 のお知らせ
• MyNA(日本MySQLユーザ会)会 2013年3月 : ATND

私はDBエンジニアというわけではありませんが、最近MySQLデータベースをさわりはじめたので、いきなりはハードルが高いかと思いながらも少しでも勉強になればと思い参加させていただきました。
以下は、復習を兼ねた自分なりのメモや追加でほんの少し調べてみたことなどのまとめです。

セミナー概要

セッション

ライトニングトーク

講演

平塚様：チューニンガソン5の復習 MySQL 5.6 新機能編

MySQLのOracle Aceとなられた平塚様のお話。
チューニンガソン5の内容について振り返り後、チューニンガソンで登場した6種類のクエリに対して、MySQL5.6でのチューニング手法、ノウハウを御紹介いただきました。 資料が公開されていますのでそれを見ていただくのが良いのは間違いないですが、自身のメモ/復習のために以下に内容をまとめておきます。

チューニング内容

• MySQL5.6へのアップデート
• インデックスの追加
• Optimizer Traceの利用
• オプティマイザの精度向上
• ヒューリスティックの排除
• オプティマイザ・ヒントの付与
• サブクエリのマテリアライゼーション
• テーブルの非正規化

MySQL5.6へのアップデート

MySQL 5.6ではパフォーマンススキーマがデフォルトで有効になっていることやメタデータロックの仕組みにCPUスケーラビリティがないことが原因で、MySQL 5.5より性能面が低下しているとのことでした。

インデックスの追加 - Optimizer Traceの利用

チューニングとしては、Covering Indexなどインデックスの張り方の見直しを実施されてましたが、オプティマイザの判断によってはIndexを利用されないケースもあるようです。そういった際にはMySQL 5.6の新機能であるOptimizer Traceという機能でオプティマイザの内部動作を確認できるそうです。
ただ、Optimizer TraceはJSON形式で数百行も出力される上にマニュアルがないので、読むのは慣れ…

オプティマイザの精度向上(レンジ分析範囲の修正)/ヒューリスティクスの排除

上述の、"オプティマイザがインデックスを利用しない実行計画を選ぶ"といったような良くない判断をする原因として、InnoDBでの"インデックスに保存されているレコードの読み取り数の見積もり方が良くない"とのこと。InnoDBは読み取るレコード数をコスト計算に利用し、インデックス内の読み取りレコード数を11ページのリーフページで見積もる動作であり、今回のように大量のデータに対するクエリでは、読み取りレコード数の見積もりが正確ではなかったため、インデックスを利用した場合のコストが大きいとオプティマイザが判断したようです。
平塚様がちょっとだけ本気を出されてInnoDBのソースから、InnoDBのレンジ分析の精度をあげるためにアクセスするリーフページ数の割合を本来の10倍に変更したり、ヒューリスティックなアルゴリズムを除去する修正をされていました。

オプティマイザ・ヒントの付与

STRAIGHT_JOINを使ってJOINの順序を強制し、Force Indexを使って利用するインデックスを強制することで、クエリにLoose Index Scanという手法を用いるようにしていました。

サブクエリのマテリアライゼーション

サブクエリに対して中間テーブルを用いることで、クエリを高速化する手法を用いられていますが、バッドノウハウとのこと。 マテリアライゼーションは、tmp_table_sizeの値までのデータであればMEMORYストレージエンジンが用いられるそうですが、tmp_table_sizeの値を越えるデータ量になると、MyISAMストレージエンジン(つまりディスク上)に切り替わるようです。tmp_table_sizeで収まる場合はメモリ内でデータが処理できるので効果があるとのこと。

テーブルの非正規化

大量のレコードを処理するクエリに対しては、テーブルの非正規化を行うことで高い効果を得られるそうです。

yoku様：意外と話題に上がらない、mysqld以外の5.6新機能

mysql_install_db, mysql_config_editor, mysqlbinlogを中心としたMySQL付属ツールの御紹介。 この辺りのツールやユーティリティはまだきちんと使ったことがないものばかりだったので今後調べて使ってみようと思ってます。

mysql_install_db

MySQLを初期化するプログラム。rpmインストール時には最後に自動で実行されます。 MySQL5.6では--random-passwordsオプションにより初期ランダムパスワードが設定されるようになっていたり、パスワードの有効期限(password_expired)設定が有効になっていたりとセキュリティ面を考慮したような変更点があるそうです。 あと、my.cnfの作成先が/etc/my.cnfから$MySQL_DATA(RPMインストール時の標準は/usr/share/mysql)/my.cnfに変わったようです。

mysql_config_editor

これもセキュリティ面の改善となるのでしょうか。MySQL 5.6からmysql_config_editorというコマンドを使用して、.mylogin.cnfというファイルにパスワードを暗号化して保存できるようになったとのこと。

mysqlbinlog

MySQLサーバが生成するバイナリログをテキスト形式で確認するツール。
--read-from-remote-master, --stop-never, --row, --result-file といった様々なオプションが登場しましたが、mysqlbinlog自体を使ったことも無い身としては追いきれませんでしたので、別途調べていきたいと思います。

奥野様：MySQL 5.6 新機能(熱)

プロプライエタリなディスプレイドライバがうまく動作しなかったようで、プロジェクタに映像が出ないというトラブルがあり、木村様のPCを借りられてのスタートだった模様。 MySQLの歴史についてのお話から始まり、「5.6の新機能紹介」のデモ…の予定でしたが、上述のトラブルにより事前に御準備いただいていたデモ環境が利用できない状態だったため、その場でMySQL SandBoxという複数のMySQL環境を手軽に構築できるツールを利用しての環境作成から行われていました。

MySQL SandBoxのことは知りませんでしたが、CPAN経由でのインストールが容易にインストールできるようです。 利用したいMySQLのソースコードを取得し、シェルの環境変数を一つ設定して、make_sandboxコマンドでMySQLのビルドを行えばMySQL SandBoxでのMySQLインストールが可能なようで、ポートはMySQLのバージョンに応じて自動で決定されるようなので、容易に複数のバージョンをインストールして試すといったことができるようです。

時間の都合もあり、予定していたデモを全て実施いただけなかったため、当日実施予定だったデモの内容は改めてYoutubeに公開いただけるそうです。楽しみです。
また、MySQL5.6の新機能については昨年のdb tech showcase 2012の資料が奥野様のSlideShareへ公開されておりました。

• MySQL 5.6新機能解説@dbtechshowcase2012 by @nippondanji on @slideshare
• Mysql Sandbox

LT(ライトニングトーク)

木村様：performance_schemaとinformation_schemaを5分で語る

ps_helperというものを用いたperformance_schema(統計情報)の解析についてのお話。 まだ使い方はよく分かりませんが、以下のリンクを見ると図が作成できたりと面白そうでした。

• ps_helper | Mark Leith
• dump_thread_stack() - ps_helper | Mark Leith

執筆された下記書籍をじゃんけん大会の商品として提供していただき、見事に勝ち残られた方は和歌山からいらっしゃった方でした。

• プロになるための データベース技術入門　~MySQLforWindows困ったときに役立つ開発・運用ガイド [大型本]

梶山様：MySQL Connect 2013

今秋(9月)にサンフランシスコで開催されるMySQL Connect 2013についてのお話。当日の講演者を募集されているそうです。 参加するには敷居が高い…

• MySQL Connect

MySQLのnode.js APIなどについてもちらほら…

• New MySQL Cluster 7.3 Previews: Foreign Keys, NoSQL Node.js API and Auto-Tuned Clusters

木下様：特別登壇

前述のトラブルの影響もあって、InnoDBの開発者である木下様の登壇のお時間がありました。

• InnoDBのプロは寡黙な紳士―木下靖文さん : EnterpriseZine

最初のセッションでの平塚様のInnoDBに関する指摘のあとでの登壇でしたが、むしろ今後のInnoDBの伸びしろを感じてほしいとのこと！
MySQL5.6がリリースされて、MySQL5.7にも取り組んでいるそうですが、公式アナウンスが無い現状では話せることがないそうです。

司会の坂井様とのやり取り(漫談？)も面白かったです。

おわりに

MySQLに限った話ではないと思いますが、こういったセミナーでいろいろなお話を聞くと、やはりそのソフトウェアなりアプリケーションなりの仕組みを理解するというのは重要だということを思います。
MySQLだと、SQLがどのように動作するか、オプティマイザがどういう判断をするか、ストレージエンジンがどういう仕組みになっているか、どういう機能があってどういうことが出来るのか等々。使い込まないと見えてこない部分もたくさんあると思うので、理解を深めるためには積極的にいろいろ使っていければと思います。 ソースコードが参照可能なので、そのレベルで理解して対応できれば最高なんでしょうけど、MySQL初心者の私にとっては凄いテクニックも様々な有効な機能もまだ理解しきれない部分が多々あったので、とりあえず聞いたことを噛み砕いて整理している段階ですが…

最後になりましたが、スタッフの皆様、スピーカー/登壇者の皆様、貴重なお話を誠にありがとうございました。

参考

公開いただいている当日の発表資料をしっかり読み返したいと思います。

セミナー資料

• 坂井様：日本MySQLユーザ会会2013.03開催しました - sakaikの日々雑感～(T)編
• 平塚様：チューニンガソン5の復習 MySQL 5.6 新機能編 - SH2の日記
• チューニンガソン5の復習 MySQL 5.6 新機能編 - PDF資料
• yoku様：日々の覚書: MyNA 2013/03 行ってきました
• MySQL Clients!at MySQL Nippon Association

Togetter

• MyNA会2013年3月 - Togetter

はじめに

最近注目され始めているChefをようやく自分でも触り始めているところですが、一旦Chef Server/Clientの構築周りについて整理します。ここでは2台のマシンを用いて、1台のマシンにChefのServer環境とWorkstation環境を、もう1台のマシンにChefのNode環境を構築する手順をまとめています。NodeへのRecipeの実行する手順などは記載しません。

AWSなどのクラウドサービスや仮想化ソフトの機能の充実で、OS丸ごと(インスタンス)のコピーを作成することも容易となっているなかで、構築自動化やサーバ構成情報の管理にどれだけのメリットがあるのかは規模や環境によるのかもしれませんが、個人的にどんなものか興味があったので、いろいろ調べてみたり触ってみたりしています。 最初は慣れない用語がいろいろ出てきたり、ドキュメントの内容も多かったりと取っ付きにくかったので、自分の理解を整理する意味も込めてメモ程度に記載しています。

chefとは

ChefはRubyで記述されたシステム構成管理/構築自動化ツールです。Opscode社によって開発されていますが、オープンソースとして公開されています。

• 概要 - tily - Opscode Open Source Wiki

実際にどういうことができるか極簡単に記載すると、サーバ等の各種設定ファイルをChefサーバへ保存しておき(サーバ設定ファイルの一元管理)、その設定ファイルをサーバに配布して反映させる(環境構築/デプロイ自動化)ことができます。参照する手順書の誤り、手動で構築することでの設定漏れやミスといった問題も解消が望める、というのはよく言われています。

なお、類似のツールとしては、代表的なものはOSSのPappetがあり、よく比較対象となっていますが、Pappetを使ったことがないのでどういう違いがあるのかはよくわかりません。

Chefの種類

最近ではChefというとオープンソース版のものを指すことが多いように思いますが、Opscode社によりサービスも提供されています。

オープンソース版

自分でChefの環境を構築して使用するタイプ。Server/Client構成のタイプと、Chef Soloという小機能ですが単体で利用できるタイプがあります。

ホスティングサービス

Opscode社が提供しているChefのホスティングサービス。 5ノードまで無料で使えるようです。

• Hosted Chef - Opscode

商用ライセンス

Opscode社が提供しているChefの商用製品。 国内ではクリエーションライン社が商用ライセンス販売、保守サポート、コンサルティングなどを行っているようです。

• Opscode社のサーバ設定管理ツール「Chef」の日本でのサービス提供を開始 « CREATIONLINE, INC.

Chef 11の構成要素とツール群

Chefの構成やツールはたくさんあるためややこしく、自分の理解も完璧ではないと思いますがとりあえず分かっている内容を記載しておきます。

各構成要素/役割

基本的にはChef-ServerとChef-Clientによるサーバ/クライアント構成となります。

• chef-server

各設定ファイルを集約して管理する環境。通常1台のみです。
Node等のデータの保存にはCouchDBが用いられていましたが、Chefのバージョン11からPostgreSQLに変更されたようです。検索エンジンにはSolrが利用されます。Chef Serverから受け取ったデータをPostgreSQLへ渡す際にはRabbitMQが利用されます。フロントはNignxです。
各ClientとはJSON/RESTスタイルで通信されます。

• chef-client

Chef Serverに接続して情報をやりとりするツールやホスト。

• Node(chef-client)

Chefで管理するホスト。

• workstation

Chef ServerやClient(Node)に対して指示を出す環境。knifeコマンドを利用されます。

ツール

• knife

Chefを管理するコマンドラインツール。NodeではないClientのひとつであり、Workstation環境で実行される。

• knife-solo

knifeのプラグイン。chef-soloと組み合わせて使われます。他サーバへrecipeを配布し、chef-soloを実行して設定を反映させることができます。

• ohai

各Client(node)のシステム構成情報を取得するためのツール。出力はjson形式。

• chef-solo

上述の通り、サーバ無しでレシピを実行するツール。

Chef 11環境(Server/Workstation/Node)の構築

さくらのVPSのCentOS6.4環境へChef 11環境を構築しました。Chef 11ではRHEL系のRPMパッケージが公開されていますので、これを使うことで特に問題なくインストールできました。
なお、本環境ではサーバは2台で構成し、1台のサーバへChef Server、Workstationを構築し、もう1台のサーバへNodeの環境を構築します。

以下に構築時の手順を記載致します。

環境

Chef Server, Client(Workstation)環境

Node環境

Cher Serverの構築

以下の公式手順を参考に、Chef Server Ver.11のパッケージをインストールし、初期構築を行います。
ここでChef Serverとなる環境はhoge01.sakura.ne.jpとします。

• Install Chef Server 11.x — Chef Docs

パッケージの取得

Chef Ver.11からはRHEL系OS用にRPMパッケージが公開されているため、以下のページからRPMパッケージを取得できます。

• Install Chef | Opscode

ここでは最新バージョンのChef-Server 11.0.8を取得します。

# wget https://opscode-omnibus-packages.s3.amazonaws.com/el/6/x86_64/chef-server-11.0.8-1.el6.x86_64.rpm

インストール

取得したパッケージをインストールします。

# rpm -ihv chef-server-11.0.8-1.el6.x86_64.rpm
warning: chef-server-11.0.8-1.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 83ef826a: NOKEY
Preparing...                ########################################### [100%]
   1:chef-server            ########################################### [100%]
Thank you for installing Chef Server!

The next step in the install process is to run:

sudo chef-server-ctl reconfigure

Chef Serverの初期セットアップ

インストール時のメッセージにchef-server-ctl reconfigure(rootであればsudo不要)を実行する旨のメッセージが出ますので、コマンドを実行してChef-Serverの初期セットアップを行います。

NginxやPostgreSQLなど、Chef-Serverで利用されるアプリケーションも同時にインストールされるため、それらのデフォルトポート番号を使用しているプロセスがある場合、あらかじめ停止しておく必要があります。でなければ、初期セットアップを正常に行えなかったり、WEB管理画面が参照できないなどの事象が発生します。

# chef-server-ctl reconfigure
Starting Chef Client, version 11.4.0
Compiling Cookbooks...
Recipe: chef-server::default
…
…
Chef Client finished, 91 resources updated
chef-server Reconfigured!

API動作テスト

確認のため、APIのテストを実行してみます。

# chef-server-ctl test
Configuring logging...
Creating platform...
Starting Pedant Run: 2013-04-25 00:32:40 UTC
setting up rspec config for #
Configuring RSpec for Open-Source Tests
 _______  _______  _______  _______  _______  ______   _______
|       ||       ||       ||       ||       ||      | |       |
|   _   ||    _  ||  _____||       ||   _   ||  _    ||    ___|
|  | |  ||   |_| || |_____ |       ||  | |  || | |   ||   |___
|  |_|  ||    ___||_____  ||      _||  |_|  || |_|   ||    ___|
|       ||   |     _____| ||     |_ |       ||       ||   |___
|_______||___|    |_______||_______||_______||______| |_______|

     _______  _______  ______   _______  __    _  _______
    |       ||       ||      | |   _   ||  |  | ||       |
    |    _  ||    ___||  _    ||  |_|  ||   |_| ||_     _|
    |   |_| ||   |___ | | |   ||       ||       |  |   |
    |    ___||    ___|| |_|   ||       ||  _    |  |   |
    |   |    |   |___ |       ||   _   || | |   |  |   |
    |___|    |_______||______| |__| |__||_|  |__|  |___|

"Accuracy Over Tact"

                  === Testing Environment ===
                 Config File: /var/opt/chef-server/chef-pedant/etc/pedant_config.rb
       HTTP Traffic Log File: /var/log/chef-server/chef-pedant/http-traffic.log

Running tests from the following directories:

･･･
･･･

Deleting client pedant_admin_client ...
Deleting client pedant_client ...
Pedant did not create the user admin, and will not delete it
Deleting user pedant_non_admin_user ...
Deleting user knifey ...

Finished in 39.37 seconds
70 examples, 0 failures

※プロセスの確認

# ps auxfwww
root     28688  0.0  0.0   4088   376 ?        Ss   02:43   0:00 runsvdir -P /opt/chef-server/service log: ...........................................................................................................................................................................................................................................................................................................................................................................................................
root     28701  0.0  0.0   3936   320 ?        Ss   02:43   0:00  \_ runsv rabbitmq
root     28702  0.0  0.0   4080   416 ?        S    02:43   0:00  |   \_ svlogd -tt /var/log/chef-server/rabbitmq
497      28339  9.2 12.5 1197868 128044 ?      Ssl  09:58  14:27  |   \_ /opt/chef-server/embedded/lib/erlang/erts-5.9.2/bin/beam.smp -W w -K true -A30 -P 1048576 -- -root /opt/chef-server/embedded/lib/erlang -progname erl -- -home /var/opt/chef-server/rabbitmq -- -noshell -noinput -sname rabbit@localhost -boot /var/opt/chef-server/rabbitmq/db/rabbit@localhost-plugins-expand/rabbit -kernel inet_default_connect_options [{nodelay,true}] -rabbit tcp_listeners [{"127.0.0.1",5672}] -sasl errlog_type error -sasl sasl_error_logger false -rabbit error_logger {file,"/var/opt/chef-server/rabbitmq/log/rabbit@localhost.log"} -rabbit sasl_error_logger {file,"/var/opt/chef-server/rabbitmq/log/rabbit@localhost-sasl.log"} -os_mon start_cpu_sup true -os_mon start_disksup false -os_mon start_memsup false -mnesia dir "/var/opt/chef-server/rabbitmq/db/rabbit@localhost"
497      28446  0.0  0.0   4052   408 ?        Ss   09:58   0:00  |       \_ /opt/chef-server/embedded/lib/erlang/lib/os_mon-2.2.10/priv/bin/cpu_sup
497      28447  0.0  0.0  10796   512 ?        Ss   09:58   0:00  |       \_ inet_gethost 4
497      28448  0.0  0.0  12900   648 ?        S    09:58   0:00  |           \_ inet_gethost 4
root     29016  0.0  0.0   3936   320 ?        Ss   02:43   0:00  \_ runsv postgresql
root     29017  0.0  0.0   4080   416 ?        S    02:43   0:00  |   \_ svlogd -tt /var/log/chef-server/postgresql
496      28328  0.0  2.2 305688 22480 ?        Ss   09:58   0:00  |   \_ /opt/chef-server/embedded/bin/postgres -D /var/opt/chef-server/postgresql/data
496      28330  0.0  0.1 305824  1332 ?        Ss   09:58   0:00  |       \_ postgres: checkpointer process
496      28331  0.0  0.2 305824  2920 ?        Ss   09:58   0:00  |       \_ postgres: writer process
496      28332  0.0  0.1 305824  1232 ?        Ss   09:58   0:00  |       \_ postgres: wal writer process
496      28333  0.0  0.2 306688  2456 ?        Ss   09:58   0:00  |       \_ postgres: autovacuum launcher process
496      28334  0.0  0.1  26420  1176 ?        Ss   09:58   0:00  |       \_ postgres: stats collector process
496      28373  0.0  0.7 309040  7280 ?        Ss   09:58   0:02  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(49384) idle
496      28374  0.0  0.6 309064  6916 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(42658) idle
496      28375  0.0  0.6 309064  6884 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(35318) idle
496      28376  0.0  0.6 309064  6888 ?        Ss   09:58   0:02  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(51364) idle
496      28377  0.0  0.6 309156  6880 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(42970) idle
496      28378  0.0  0.6 309156  6888 ?        Ss   09:58   0:02  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(36269) idle
496      28379  0.0  0.6 309156  6884 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(49813) idle
496      28380  0.0  0.6 309156  6876 ?        Ss   09:58   0:02  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(52888) idle
496      28381  0.0  0.6 309156  6876 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(51499) idle
496      28382  0.0  0.6 309156  6880 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(58353) idle
496      28383  0.0  0.6 309156  6872 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(46938) idle
496      28385  0.0  0.6 309156  6884 ?        Ss   09:58   0:02  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(42873) idle
496      28386  0.0  0.6 309156  6880 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(35625) idle
496      28388  0.0  0.6 309156  6892 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(52568) idle
496      28389  0.0  0.6 309156  6880 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(35742) idle
496      28390  0.0  0.6 309156  6880 ?        Ss   09:58   0:02  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(35117) idle
496      28391  0.0  0.6 309156  6880 ?        Ss   09:58   0:02  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(34362) idle
496      28394  0.0  0.6 309156  6880 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(40086) idle
496      28422  0.0  0.6 309156  6868 ?        Ss   09:58   0:02  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(48803) idle
496      28438  0.0  0.6 309156  6872 ?        Ss   09:58   0:01  |       \_ postgres: opscode_chef opscode_chef 127.0.0.1(53051) idle
root     29105  0.0  0.0   3936   324 ?        Ss   02:44   0:00  \_ runsv chef-solr
root     29106  0.0  0.0   4080   416 ?        S    02:44   0:00  |   \_ svlogd -tt /var/log/chef-server/chef-solr
497      28273  0.0  7.1 1506812 72776 ?       Ssl  09:58   0:08  |   \_ java -Xmx249M -Xms249M -XX:NewSize=24M -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8086 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dsolr.data.dir=/var/opt/chef-server/chef-solr/data -Dsolr.solr.home=/var/opt/chef-server/chef-solr/home -server -jar /var/opt/chef-server/chef-solr/jetty/start.jar
root     29157  0.0  0.0   3936   324 ?        Ss   02:44   0:00  \_ runsv chef-expander
root     29158  0.0  0.0   4080   416 ?        S    02:44   0:00  |   \_ svlogd -tt /var/log/chef-server/chef-expander
497      28239  0.0  2.6 176556 27416 ?        Ssl  09:58   0:01  |   \_ ruby /opt/chef-server/embedded/service/chef-expander/bin/chef-expander -n 2 -c /var/opt/chef-server/chef-expander/etc/expander.rb
497      28255  1.5  2.8 180668 28864 ?        Sl   09:58   2:24  |       \_ chef-expander worker #1 (vnodes 0-511)                                         
497      28257  1.5  2.5 177864 26060 ?        Sl   09:58   2:25  |       \_ chef-expander worker #2 (vnodes 512-1023)                                      
root     29184  0.0  0.0   3936   324 ?        Ss   02:44   0:00  \_ runsv bookshelf
root     29185  0.0  0.0   4080   416 ?        S    02:44   0:00  |   \_ svlogd -tt /var/log/chef-server/bookshelf
497      28218  0.0  4.4 255352 45208 ?        Ssl  09:58   0:06  |   \_ /opt/chef-server/embedded/service/bookshelf/erts-5.9.2/bin/beam.smp -- -root /opt/chef-server/embedded/service/bookshelf -progname bookshelf -- -home /var/opt/chef-server/bookshelf -- -noshell -boot /opt/chef-server/embedded/service/bookshelf/releases/0.2.1/bookshelf -embedded -config /opt/chef-server/embedded/service/bookshelf/etc/app.config -name bookshelf@127.0.0.1 -setcookie bookshelf -- runit
root     29242  0.0  0.0   3936   308 ?        Ss   02:44   0:00  \_ runsv erchef
root     29243  0.0  0.0   4080   416 ?        S    02:44   0:00  |   \_ svlogd -tt /var/log/chef-server/erchef
497      28288  1.4  3.2 588004 33624 ?        Ssl  09:58   2:13  |   \_ /opt/chef-server/embedded/service/erchef/erts-5.9.2/bin/beam.smp -K true -A 5 -- -root /opt/chef-server/embedded/service/erchef -progname erchef -- -home /var/opt/chef-server/erchef -- -noshell -boot /opt/chef-server/embedded/service/erchef/releases/1.2.6/erchef -embedded -config /opt/chef-server/embedded/service/erchef/etc/app.config -name erchef@127.0.0.1 -setcookie erchef -smp enable -- runit
497      28371  0.0  0.0  10796   520 ?        Ss   09:58   0:00  |       \_ inet_gethost 4
497      28372  0.0  0.0  10796   436 ?        S    09:58   0:00  |           \_ inet_gethost 4
root     29359  0.0  0.0   3936   324 ?        Ss   02:44   0:00  \_ runsv chef-server-webui
root     29360  0.0  0.0   4080   416 ?        S    02:44   0:00  |   \_ svlogd -tt /var/log/chef-server/chef-server-webui
497      28243  0.0  2.1  87028 21608 ?        Ssl  09:58   0:01  |   \_ unicorn master -E chefserver -c /var/opt/chef-server/chef-server-webui/etc/unicorn.rb /opt/chef-server/embedded/service/chef-server-webui/config.ru
497      28267  0.0  5.3 144572 54136 ?        Sl   09:58   0:04  |       \_ unicorn worker[0] -E chefserver -c /var/opt/chef-server/chef-server-webui/etc/unicorn.rb /opt/chef-server/embedded/service/chef-server-webui/config.ru
497      28269  0.0  5.3 144608 54264 ?        Sl   09:58   0:04  |       \_ unicorn worker[1] -E chefserver -c /var/opt/chef-server/chef-server-webui/etc/unicorn.rb /opt/chef-server/embedded/service/chef-server-webui/config.ru
root     29538  0.0  0.0   3936   348 ?        Ss   02:44   0:00  \_ runsv nginx
root     29539  0.0  0.0   4080   368 ?        S    02:44   0:00      \_ svlogd -tt /var/log/chef-server/nginx
root     28318  0.0  0.3  78020  3456 ?        Ss   09:58   0:00      \_ nginx: master process /opt/chef-server/embedded/sbin/nginx -c /var/opt/chef-server/nginx/etc/nginx.conf
497      28320  0.0  0.5  82032  5320 ?        S    09:58   0:00          \_ nginx: worker process                                                          
497      28321  0.0  0.5  82032  5320 ?        S    09:58   0:00          \_ nginx: worker process                                                          
497      28322  0.0  0.1  78192  1544 ?        S    09:58   0:00          \_ nginx: cache manager process                                                   
497      28718  0.0  0.0  10828   420 ?        S    02:43   0:00 /opt/chef-server/embedded/lib/erlang/erts-5.9.2/bin/epmd -daemon

WEB管理画面

初期セットアップが完了した段階で、WEB管理画面が参照できます。さくらのVPSは普通に外部からアクセス可能な環境ですが、管理画面のログインユーザID/パスワードのデフォルトは画面左に表示されているため、ログイン後に速やかに変更します。

adminユーザパスワード変更

初期ログイン後、パスワード変更画面が表示されますので、新規パスワードを入力して保存します。この際、秘密鍵を再度生成(Regenerate Private Key にチェック)します。

次の画面で秘密鍵(Private Key)の内容が表示されますので、コピーして、/etc/chef-server/admin.pemをその内容に変更します。

念のため、ログアウト前に別のブラウザを立ち上げるなどして新しいパスワードでログインを確認します。ログインできれば完了です。

Workstationの構築

公式手順を参考に、Chef Serverを操作するためのClietn環境(Workstation)を構築します。
ここでWorkstationとなる環境はChef Serverと同じhoge01.sakura.ne.jpとします。

• Install Chef 11.x on a Workstation — Chef

Chefクライアントインストールスクリプト/パッケージの取得

以下のページからインストールスクリプト、あるいはRPMパッケージを取得できます。

• Install Chef | Opscode

Chefクライアントのインストール

インストールスクリプトを実行します。

# curl -L https://www.opscode.com/chef/install.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
101  6471  101  6471    0     0   6595      0 --:--:-- --:--:-- --:--:-- 36767
Downloading Chef  for el...
Installing Chef
warning: /tmp/tmp.DG3OQCP9/chef-.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 83ef826a: NOKEY
Preparing...                ########################################### [100%]
   1:chef                   ########################################### [100%]
Thank you for installing Chef!

証明書ファイルのコピー

Chef-Serverへアクセスするための秘密鍵(/etc/chef-server/admin.pem)をクライアントにコピー(ここでは同一ホストの/etc/chef/admin.pem)します。

# cp -p /etc/chef-server/admin.pem /etc/chef/admin.pem

新規Chef Client(Workstaion/Node)をChef Serverへ登録する際に必要な、Chef Server上のchef-validator.pem(/etc/chef-server/chef-validator.pem)という鍵ファイルをChef Client環境にコピー(ここでは同一ホストの/etc/chef/validator.pem)します。

# cp -p /etc/chef-server/chef-validator.pem /etc/chef/validation.pem

※chef-validatorは、Chef Serverへ新しいChef Client(Node/Workstation)を登録するための特別な専用クライアントです。
Chef ClientによるAPI実行時、Chef ServerはChef Client(Node/Workstation)の秘密鍵をチェックしますが、NodeやWorkstationが初めてchef-clientを実行しようとする際には認証できずChef ServerのAPIを実行できません。 秘密鍵が存在しない場合、そのChef Client(Node/Workstation)をChef Serverへ登録するためにchef-validatorのChef Clientの証明書を一時的に利用します。

Chefの新規ユーザ作成

knifeコマンドで、Chef Serverにオペレーションするためのユーザを作成します。ここで作成するユーザは、主にWorkstationからChef-Serverに対してknifeコマンドによるAPIを実行するためのユーザです。ファイル名や作成先ディレクトリはデフォルトのままで問題ありません。ServerのURL項目の修正とパスワードは入力します。

# knife configure -i
WARNING: No knife configuration file found
Where should I put the config file? [/root/.chef/knife.rb]
Please enter the chef server URL: [http://hoge01.sakura.ne.jp:4000] https://hoge01.sakura.ne.jp  # <-httpsへ変更
Please enter a name for the new user: [hogehoge]
Please enter the existing admin name: [admin]
Please enter the location of the existing admin's private key: [/etc/chef/admin.pem]
Please enter the validation clientname: [chef-validator]
Please enter the location of the validation key: [/etc/chef/validation.pem]
Please enter the path to a chef repository (or leave blank):
Creating initial API user...
Please enter a password for the new user:
Created user[hogehoge]
Configuration file written to /root/.chef/knife.rb

rootのホームディレクトリ以下に作成したユーザの秘密鍵(/root/.chef/hogehoge.pem)が作成されます。今後はこの秘密鍵でChef Serverに認証することができます。

# ls /root/.chef/
hogehoge.pem  knife.rb

# cat /root/.chef/knife.rb
log_level                :info
log_location             STDOUT
node_name                'hogehoge'
client_key               '/root/.chef/hogehoge.pem'
validation_client_name   'chef-validator'
validation_key           '/etc/chef/validation.pem'
chef_server_url          'https://hoge01.sakura.ne.jp'
syntax_check_cache_path  '/root/.chef/syntax_check_cache'

作成したユーザでWEB管理画面へログインできるか確認し、ログインできれば問題ありません。

※登録ユーザ一覧の確認

# knife user list
admin
hogehoge

Nodeの構築

Chef Serverから設定ファイルを取得して構成を反映させるためのClietn環境(Node)を構築します。
Nodeとなるサーバはhoge02.sakura.ne.jpとなります。

Chef Serverでの事前作業

Chef Server(hoge01.sakura.ne.jp)上で以下のとおりknifeコマンドを実行して、Nodeを登録するために必要な設定ファイル(client.rb)と鍵ファイル(validation.pem)を生成します。
ファイルの生成先は任意で指定でき、ここでは/tmpとしています。

# knife configure client /tmp
Creating client configuration
Writing client.rb
Writing validation.pem

Nodeの登録

もう1台のサーバ(hoge02.sakura.ne.jp)をNodeとしてChef Serverへ登録するに当たって、hoge02.sakura.ne.jpへChef Clientのパッケージをインストールします。

# curl -L https://www.opscode.com/chef/install.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6510  100  6510    0     0   8146      0 --:--:-- --:--:-- --:--:-- 42272
Downloading Chef  for el...
Installing Chef
warning: /tmp/tmp.RzL9HsIq/chef-.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 83ef826a: NOKEY
Preparing...                ########################################### [100%]
   1:chef                   ########################################### [100%]
Thank you for installing Chef!

Chef Server(hoge01.sakura.ne.jp)上で作成した設定ファイル(client.rb)と鍵ファイル(validation.pem)を、Nodeとなるサーバ(hoge02.sakura.ne.jp)の/etc/chef以下にscpやコピペするなどして設置します。

# mkdir /etc/chef

# ls /etc/chef/
client.rb  validation.pem

hoge02.sakura.ne.jp上でchef-clientコマンドを実行して、Chef Server(hoge01.sakura.ne.jp)へNodeとして登録します。

# chef-client
Starting Chef Client, version 11.4.4
[2013-05-13T23:01:12+09:00] INFO: *** Chef 11.4.4 ***
[2013-05-13T23:01:12+09:00] INFO: [inet6] no default interface, picking the first ipaddress
Creating a new client identity for hoge02.sakura.ne.jp using the validator key.
[2013-05-13T23:01:13+09:00] INFO: Client key /etc/chef/client.pem is not present - registering
[2013-05-13T23:01:16+09:00] INFO: Run List is []
[2013-05-13T23:01:16+09:00] INFO: Run List expands to []
[2013-05-13T23:01:17+09:00] INFO: Starting Chef Run for hoge02.sakura.ne.jp
[2013-05-13T23:01:17+09:00] INFO: Running start handlers
[2013-05-13T23:01:17+09:00] INFO: Start handlers complete.
resolving cookbooks for run list: []
[2013-05-13T23:01:17+09:00] INFO: Loading cookbooks []
Synchronizing Cookbooks:
Compiling Cookbooks...
[2013-05-13T23:01:17+09:00] WARN: Node hoge02.sakura.ne.jp has an empty run list.
Converging 0 resources
[2013-05-13T23:01:17+09:00] INFO: Chef Run complete in 0.311768246 seconds
[2013-05-13T23:01:17+09:00] INFO: Running report handlers
[2013-05-13T23:01:17+09:00] INFO: Report handlers complete
Chef Client finished, 0 resources updated

Workstationにて、登録されたNodeの確認

Workstation(hoge01.sakura.ne.jp)にてknife node listコマンドを実行することで、登録されているNodeを確認できます。

# knife node list
hoge02.sakura.ne.jp

管理画面上でも登録されているNodeを確認できます。

以上で、Nodeの初期構築は完了です。

おわりに

ここでは2台のさくらのVPSのCentOS 6.4環境を利用して、Chef 11環境(Server/Workstation/Node)を構築してみました。
Chef 11では RHEL系のパッケージが準備されているため、インストール自体は比較的簡単にできると思います。とはいえサーバ2台程度の環境ならChef-Soloで十分かと思いますが･･･。
また、外部から自由にアクセス可能な環境なので、例えば管理画面など(ID/PASSが必要とは言え･･･)はセキュリティを考慮すると、別途iptablesなど何らかの設定を設けたほうが良いかも知れません。※Basic認証を設定するとChefのAPIも認証ではじかれてしまい、実行できなくなります。

環境が整ったので、次はCookbooksの作成、Recipeの実行などをやってみようと思ってます。

はじめに

前回は、2つのさくらのVPSのCentOS環境を用意して、1台にChef-Server、及びWorkstation環境を、もう1台にNode環境をセットアップしました。

今回はこれらの環境を利用して、Cookbooks、Recipe作成し、Nodeへ設定を適用する動作を確認してみます。
具体的には、単純に1台のNodeに対して、iptablesの設定ファイルを適用するという内容から、ChefのServer / Client構成の動作を確認することを主目的とします。
※Cookbook、Recipeの作成について細かい内容について説明していません。

Nodeの登録とCookbookの作成/Recipeの実行環境構築

環境

上述の通り、今回は2台のマシンを用います。1台は前回セットアップしたChef Server兼Workstation環境で、もう1台がNodeと呼ばれるChefによる構成管理対象のClient環境です。
いずれもCentOS 6.4環境です。

Chef Server, Client(Workstation)環境

Node環境

Chefリポジトリの取得

まず、Workstation(hoge01.sakura.ne.jp)へChefのリポジトリを準備する必要があります。

• About the Repository — Chef Docs

リポジトリにはChefの実行に必要なファイル(Cookbooks, role, environments…)が含まれており、KnifeコマンドでChef ServerへリポジトリのデータをアップロードしてNodeの管理に利用します。
なおこのリポジトリはGitやSubversionなどのバージョン管理システムで管理することが推奨されていますが、ここではその設定は省きます。

雛型レポジトリが Github で公開されていますので、これを取得します。ここでは/usr/local/src以下に配置します。

# cd /usr/local/src

# git clone https://github.com/opscode/chef-repo

Cookbook作成

Workstation(hoge01.sakura.ne.jp)上からknfieコマンドを実行して、Cookbookを作成します。CookbooksはRecipeやtemplateなどの設定情報です。

• About Cookbooks — Chef Docs

ファイル名はcentos6_iptablesとしています。Cookbookのディレクトリはデフォルトでは/var/chef/cookbooks以下に作成されるようですが、-oオプションで作成先を指定できます。ここでは、先ほど取得したリポジトリ内の/usr/local/src/chef-repo/cookbooks以下に作成します、

# knife cookbook create centos6_iptables -o /usr/local/src/chef-repo/cookbooks
** Creating cookbook centos6_iptables
** Creating README for cookbook: centos6_iptables
** Creating CHANGELOG for cookbook: centos6_iptables
** Creating metadata for cookbook: centos6_iptables

Recipeの作成

Workstation(hoge01.sakura.ne.jp)上でRecipeのファイルを作成します。Recipeはサーバの設定内容やNodeへの反映処理をRubyで記述したファイル類です。

• About Recipes — Chef Docs

ここでは、CentOS6のFW(iptables)の設定ファイルを作成することにします。

まず、/usr/local/src/chef-repo/cookbooks/centos6_iptables/templates/default以下に設定ファイルの雛形を作成します。
※IPアドレスの箇所は適宜読み替えてください。

# cd /usr/local/src/chef-repo/cookbooks/centos6_iptables/templates/default

# vim iptables
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [88:5535]
:LOG_PINGDEATH - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -s XXX.XXX.XXX.0/23 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -f -j LOG --log-prefix "[IPTABLES FRAGMENT] : "
-A INPUT -f -j DROP
-A INPUT ! -s XXX.XXX.XXX.0/23 -p tcp -m multiport --dports 135,137,138,139,445 -j DROP
-A INPUT ! -s XXX.XXX.XXX.0/23 -p udp -m multiport --dports 135,137,138,139,445 -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -j LOG_PINGDEATH
-A INPUT -d 255.255.255.255/32 -j DROP
-A INPUT -d 224.0.0.1/32 -j DROP
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -m limit --limit 1/sec -j LOG --log-prefix "[IPTABLES INPUT] : "
-A INPUT -j DROP
-A INPUT -s 10.0.0.0/8 -i eth0 -j DROP
-A INPUT -s 172.16.0.0/12 -i eth0 -j DROP
-A INPUT -s 192.168.0.0/16 -i eth0 -j DROP
-A INPUT -d 10.0.0.0/8 -i eth0 -j DROP
-A INPUT -d 172.16.0.0/12 -i eth0 -j DROP
-A INPUT -d 192.168.0.0/16 -i eth0 -j DROP
-A INPUT -d 255.255.255.255/32 -i eth0 -j DROP
-A INPUT -d 224.0.0.1/32 -i eth0 -j DROP
-A FORWARD -m limit --limit 1/sec -j LOG --log-prefix "[IPTABLES FORWARD] : "
-A FORWARD -j DROP
-A OUTPUT ! -d XXX.XXX.XXX.0/23 -p tcp -m multiport --sports 135,137,138,139,445 -j DROP
-A OUTPUT ! -d XXX.XXX.XXX.0/23 -p udp -m multiport --sports 135,137,138,139,445 -j DROP
-A LOG_PINGDEATH -m limit --limit 1/sec --limit-burst 4 -j ACCEPT
-A LOG_PINGDEATH -j LOG --log-prefix "[IPTABLES PINGDEATH] : "
-A LOG_PINGDEATH -j DROP
COMMIT

/usr/local/src/chef-repo/cookbooks/centos6_iptables/recipes以下にRecipeのファイルを作成します。
デフォルトでdefault.rbというファイルがありますがこれは修正せず、別途iptables.rbというファイルを以下の内容で作成します。
これは上記で作成したiptablesというTemplateファイルを用いて、/etc/sysconfig/iptablesというファイルをユーザ/グループをroot、パーミッション0を600で生成し、その後iptablesを再起動する、というRecipeです。

# cd /usr/local/src/chef-repo/cookbooks/centos6_iptables/recipes

# vim iptables.rb
template "/etc/sysconfig/iptables" do
  source "iptables"
  group "root"
  owner "root"
  mode "0600"
end

service "iptables" do
  supports :status => true, :restart => true
  action [ :enable, :start ]
end

/usr/local/src/chef-repo/cookbooks/centos6_iptables以下に、NodeからChef Serverに対してchef-clientコマンドによるAPIが実行された際に適用するレシピがJSON形式で定義されたファイルを作成します。
run_listはNodeに対して適用するRecipeを指定したリストを指し、その中の"recipe[centos6_iptables::iptables]"はcentos6_iptablesというCookbookのrecipes/iptables.rbというファイルの内容を実行する、という内容を表します。

# cd /usr/local/src/chef-repo/cookbooks/centos6_iptables/recipes

# vim iptables.json
{
"run_list": [
"recipe[centos6_iptables::iptables]"
  ]
}

以上で、Cookbook、Recipeの作成は完了です。

Cookbookのアップロード

Workstation(hoge01.sakura.ne.jp)からChef Server(hoge01.sakura.ne.jp)へ、作成したCookbookをアップロードして登録します。 ※ここではChef ServerとWorkstationは同一のサーバです。

# knife cookbook upload -a -o /usr/local/src/chef-repo/cookbooks
Uploading centos6_iptables [0.1.2]
Uploaded all cookbooks.

# knife cookbook list
centos6_iptables   0.1.0

# knife recipe list
centos6_iptables::iptables

NodeへのRecipe追加

Chef Server(hoge01.sakura.ne.jp)へ登録したCookbookのRecipeを、適用したいNode(hoge02.sakura.ne.jp)へ追加します。

# knife node run_list add hoge2.sakura.ne.jp "recipe[centos6_iptables::iptables]"
hoge2.sakura.ne.jp:
  run_list:
    recipe[centos6_iptables]
    recipe[centos6_iptables::iptables]

Workstaton(hoge01.sakura.ne.jp)上からNode(hoge02.sakura.ne.jp)の状態を確認し、Recipeが登録されていることを確認します。

# knife node show hoge2.sakura.ne.jp
Node Name:   hoge2.sakura.ne.jp
Environment: _default
FQDN:        hoge2.sakura.ne.jp
IP:          XXX.XXX.XXX.XXX
Run List:    recipe[centos6_iptables::iptables]
Roles:
Recipes:    centos6_iptables::iptables
Platform:    centos 6.4
Tags:

Recipeの実行

Node(hoge02.sakura.ne.jp)からchef-clientコマンドを実行し、Recipeの内容をNodeへ反映します。

% sudo chef-client
Starting Chef Client, version 11.4.4
[2013-05-18T02:30:12+09:00] INFO: *** Chef 11.4.4 ***
[2013-05-18T02:30:12+09:00] INFO: [inet6] no default interface, picking the first ipaddress
[2013-05-18T02:30:13+09:00] INFO: Run List is [recipe[centos6_iptables], recipe[centos6_iptables::iptables]]
[2013-05-18T02:30:13+09:00] INFO: Run List expands to [centos6_iptables, centos6_iptables::iptables]
[2013-05-18T02:30:13+09:00] INFO: Starting Chef Run for hoge2.sakura.ne.jp
[2013-05-18T02:30:13+09:00] INFO: Running start handlers
[2013-05-18T02:30:13+09:00] INFO: Start handlers complete.
resolving cookbooks for run list: ["centos6_iptables", "centos6_iptables::iptables"]
[2013-05-18T02:30:13+09:00] INFO: Loading cookbooks [centos6_iptables]
Synchronizing Cookbooks:
  - centos6_iptables
Compiling Cookbooks...
Converging 2 resources
Recipe: centos6_iptables::iptables
  * template[/etc/sysconfig/iptables] action create[2013-05-18T02:30:13+09:00] INFO: Processing template[/etc/sysconfig/iptables] action create (centos6_iptables::iptables line 1)
[2013-05-18T02:30:13+09:00] INFO: template[/etc/sysconfig/iptables] updated content
[2013-05-18T02:30:13+09:00] INFO: template[/etc/sysconfig/iptables] owner changed to 0
[2013-05-18T02:30:13+09:00] INFO: template[/etc/sysconfig/iptables] group changed to 0
[2013-05-18T02:30:13+09:00] INFO: template[/etc/sysconfig/iptables] mode changed to 600

    - create template[/etc/sysconfig/iptables]
        --- /tmp/chef-tempfile20130518-17671-jz7mdd     2013-05-18 02:30:13.497129975 +0900
        +++ /tmp/chef-rendered-template20130518-17671-19zoijp   2013-05-18 02:30:13.497129975 +0900
        @@ -0,0 +1,57 @@
        +*filter
        +:INPUT DROP [0:0]
        +:FORWARD DROP [0:0]
        +:OUTPUT ACCEPT [88:5535]
        +:LOG_PINGDEATH - [0:0]
        +-A INPUT -i lo -j ACCEPT
        +-A INPUT -s XXX.XXX.XXX.0/23 -j ACCEPT
        +-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
        +-A INPUT -f -j LOG --log-prefix "[IPTABLES FRAGMENT] : "
        +-A INPUT -f -j DROP
        +-A INPUT ! -s XXX.XXX.XXX.0/23 -p tcp -m multiport --dports 135,137,138,139,445 -j DROP
        +-A INPUT ! -s XXX.XXX.XXX.0/23 -p udp -m multiport --dports 135,137,138,139,445 -j DROP
        +-A INPUT -p icmp -m icmp --icmp-type 8 -j LOG_PINGDEATH
        +-A INPUT -d 255.255.255.255/32 -j DROP
        +-A INPUT -d 224.0.0.1/32 -j DROP
        +-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
        +-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
        +-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
        +-A INPUT -m limit --limit 1/sec -j LOG --log-prefix "[IPTABLES INPUT] : "
        +-A INPUT -j DROP
        +-A INPUT -s 10.0.0.0/8 -i eth0 -j DROP
        +-A INPUT -s 172.16.0.0/12 -i eth0 -j DROP
        +-A INPUT -s 192.168.0.0/16 -i eth0 -j DROP
        +-A INPUT -d 10.0.0.0/8 -i eth0 -j DROP
        +-A INPUT -d 172.16.0.0/12 -i eth0 -j DROP
        +-A INPUT -d 192.168.0.0/16 -i eth0 -j DROP
        +-A INPUT -d 255.255.255.255/32 -i eth0 -j DROP
        +-A INPUT -d 224.0.0.1/32 -i eth0 -j DROP
        +-A FORWARD -m limit --limit 1/sec -j LOG --log-prefix "[IPTABLES FORWARD] : "
        +-A FORWARD -j DROP
        +-A OUTPUT ! -d XXX.XXX.XXX.0/23 -p tcp -m multiport --sports 135,137,138,139,445 -j DROP
        +-A OUTPUT ! -d XXX.XXX.XXX.0/23 -p udp -m multiport --sports 135,137,138,139,445 -j DROP
        +-A LOG_PINGDEATH -m limit --limit 1/sec --limit-burst 4 -j ACCEPT
        +-A LOG_PINGDEATH -j LOG --log-prefix "[IPTABLES PINGDEATH] : "
        +-A LOG_PINGDEATH -j DROP
        +COMMIT

  * service[iptables] action enable[2013-05-18T02:30:13+09:00] INFO: Processing service[iptables] action enable (centos6_iptables::iptables line 8)
 (up to date)
  * service[iptables] action restart[2013-05-18T02:30:13+09:00] INFO: Processing service[iptables] action restart (centos6_iptables::iptables line 8)
[2013-05-18T02:30:15+09:00] INFO: service[iptables] restarted

    - restart service service[iptables]

[2013-05-18T02:30:15+09:00] INFO: Chef Run complete in 1.948886938 seconds
[2013-05-18T02:30:15+09:00] INFO: Running report handlers
[2013-05-18T02:30:15+09:00] INFO: Report handlers complete
Chef Client finished, 2 resources updated

Node(hoge02.sakura.ne.jp)上から、iptablesの設定が反映されていることを確認します。

% sudo service iptables status
Table: filter
Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
2    ACCEPT     all  --  XXX.XXX.XXX.0/23      0.0.0.0/0
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
4    LOG        all  -f  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `[IPTABLES FRAGMENT] : '
5    DROP       all  -f  0.0.0.0/0            0.0.0.0/0
6    DROP       tcp  -- !XXX.XXX.XXX.0/23      0.0.0.0/0           multiport dports 135,137,138,139,445
7    DROP       udp  -- !XXX.XXX.XXX.0/23      0.0.0.0/0           multiport dports 135,137,138,139,445
8    LOG_PINGDEATH  icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 8
9    DROP       all  --  0.0.0.0/0            255.255.255.255
10   DROP       all  --  0.0.0.0/0            224.0.0.1
11   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22
12   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
13   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
14   LOG        all  --  0.0.0.0/0            0.0.0.0/0           limit: avg 1/sec burst 5 LOG flags 0 level 4 prefix `[IPTABLES INPUT] : '
15   DROP       all  --  0.0.0.0/0            0.0.0.0/0
16   DROP       all  --  10.0.0.0/8           0.0.0.0/0
17   DROP       all  --  172.16.0.0/12        0.0.0.0/0
18   DROP       all  --  192.168.0.0/16       0.0.0.0/0
19   DROP       all  --  0.0.0.0/0            10.0.0.0/8
20   DROP       all  --  0.0.0.0/0            172.16.0.0/12
21   DROP       all  --  0.0.0.0/0            192.168.0.0/16
22   DROP       all  --  0.0.0.0/0            255.255.255.255
23   DROP       all  --  0.0.0.0/0            224.0.0.1

Chain FORWARD (policy DROP)
num  target     prot opt source               destination
1    LOG        all  --  0.0.0.0/0            0.0.0.0/0           limit: avg 1/sec burst 5 LOG flags 0 level 4 prefix `[IPTABLES FORWARD] : '
2    DROP       all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
1    DROP       tcp  --  0.0.0.0/0           !XXX.XXX.XXX.0/23     multiport sports 135,137,138,139,445
2    DROP       udp  --  0.0.0.0/0           !XXX.XXX.XXX.0/23     multiport sports 135,137,138,139,445

Chain LOG_PINGDEATH (1 references)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           limit: avg 1/sec burst 4
2    LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `[IPTABLES PINGDEATH] : '
3    DROP       all  --  0.0.0.0/0            0.0.0.0/0

以上で、Node(hoge02.sakura.ne.jp)に対して、Recipeの内容が実行されたことが確認できました。

おわりに

ここでは単純にChefのServer / Client構成の動作を確認するために、iptablesの設定を例として簡単に設定ファイルを作成して、Nodeへ反映するという動作を確認してみました。 細かい動作や用語などまだ分からない部分もたくさんありますが、いろいろ弄っている中でとりあえず初歩的な部分は把握できたような気がします。
Chefの環境構築とその基本動作が確認できたので、もう少し凝ったRecipeの作成などをやってみようかと思います。

はじめに

FreeBSD 9.1でDTraceを試してみようとと思い、その機能を有効にしてみました。その手順をまとめてみます。
※ここでは、DTraceの機能を有効にする手順を記載しており、使い方などは記載していません。

DTraceとは

DTraceとは，Sun Microsystems社(現Oracle社)によって開発された、実行中のプログラムのトレース(解析や診断)を動的に行なうためのフレームワークです。DTraceを使うことで、動作中のプログラムの実行状況をリアルタイムに確認することができるため、その時のHWリソースの使用状況やボトルネックの特定、それによるチューニングなどを行えます。

• DTrace ユーザーガイド ー Oracle Document

ライセンス形態はSun Microsystems社(現Oracle社)が策定したフリーソフトウェア向けのCommon Development and Distribution Licenseというもので、ライセンス上問題ないことからFreeBSDでは7.1-RELEASEから取り込まれていました。当時はカーネルのみのサポートだったようですが、FreeBSD 9系からはユーザランドもサポートされたものが組み込まれているようです。

DTrace機能の有効化

デフォルトではDTraceの機能は無効になっていますので、有効にしてみます。

環境

環境は以下の通りです。

事前準備

前述の通り、DTraceは標準では有効になっていません。

# dtrace -l | head
dtrace: failed to initialize dtrace: DTrace device not available on system

DTraceを有効にするには、カーネルのコンフィグレーションファイルに必要なオプションを追記し、カーネルの再構築を行う必要があります。公式手順を参考にカーネルの再構築を実施します。

• カスタムカーネルの構築とインストール

既存のカーネルコンフィグレーションファイル(GENERIC)を直接編集してはいけませんので、事前準備として、既存のカーネルコンフィグレーションファイル(GENERIC)を適当な別名(ここではGENERIC-CUSTOM)でコピーして、それをDTraceを有効にするための新カーネルコンフィグレーションファイルとして利用します。ファイルの作成先はどこでも構いませんが、公式手順通りに/root/kernelsとしています。新カーネルコンフィグレーションファイルを/usr/src/sys/amd64/confにシンボリックリンクとして作成します。

# mkdir /root/kernels 

# cd /usr/src/sys/amd64/conf 

# cp -p GENERIC /root/kernels/GENERIC-CUSTOM

# ln -s /root/kernels/GENERIC-CUSTOM

# ls -l /usr/src/sys/amd64/conf
total 37
-rw-r--r--  1 root  wheel    491  1月  1 23:38 DEFAULTS
-rw-r--r--  1 root  wheel  14189  1月  1 23:38 GENERIC
lrwxr-xr-x  1 root  wheel     28  5月 19 21:27 GENERIC-CUSTOM -> /root/kernels/GENERIC-CUSTOM
-rw-r--r--  1 root  wheel    791  1月  1 23:38 GENERIC.hints
-rw-r--r--  1 root  wheel    143  1月  1 23:38 Makefile
-rw-r--r--  1 root  wheel  16552  1月  1 23:38 NOTES
-rw-r--r--  1 root  wheel    646  1月  1 23:38 XENHVM

カーネルコンフィグレーションファイルへDTraceオプションの追加

公式手順を参考に、新カーネルコンフィグレーションファイル(GENERIC-CUSTOM)にDTraceを有効にするためのカーネルオプションを追加します。

• DTrace on FreeBSD

FreeBSD 9系の場合は以下のオプションを追記します。

# vim /root/kernels/GENERIC-CUSTOM
…
### USE DTrace ###
options         KDTRACE_HOOKS
options         DDB_CTF
options         KDTRACE_FRAME
makeoptions     WITH_CTF=1

カーネルの再構築とインストール

カーネルの再構築(コンパイル)を実行します。KERNCONFオプションに、新カーネルコンフィグレーションファイル(ここではGENERIC-CUSTOM)を指定します。

# cd /usr/src

# make buildkernel KERNCONF=GENERIC-CUSTOM
--------------------------------------------------------------
>>> Kernel build for GENERIC-CUSTOM started on Sun May 19 22:35:01 JST 2013
--------------------------------------------------------------
===> GENERIC-CUSTOM
…
…
…
objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols
objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug zlib.ko
--------------------------------------------------------------
>>> Kernel build for GENERIC-CUSTOM completed on Sun May 19 22:10:11 JST 2013
--------------------------------------------------------------

新カーネルをインストールします。

# make installkernel KERNCONF=GENERIC-CUSTOM

※ここで、新カーネルは /boot/kernelに/boot/kernel/kernelという名前で保存され、古いカーネルは/boot/kernel.old/kernelという名前で保存されます。

# ls -l /boot/kernel*
/boot/kernel:
total 376898
…

/boot/kernel.old:
total 357491
…

システムを再起動して、新カーネルで起動します。

# shutdown -r now

カーネルモジュールの読み込み

システムを再起動しても、この時点ではまだDTraceは有効化されていません。

# dtrace -l | head
dtrace: failed to initialize dtrace: DTrace device not available on system

再起動後にDTrace関連のカーネルモジュールが作成されます。dtraceall.koモジュールを読み込むことで、DTrace関連のモジュールが全て読み込まれ、DTraceの機能が有効化されます。

# kldload dtraceall

確認

# dtrace -l 
   ID   PROVIDER            MODULE                          FUNCTION NAME
    1     dtrace                                                     BEGIN
    2     dtrace                                                     END
    3     dtrace                                                     ERROR
    4   dtmalloc                                       nfsclient_req malloc
    5   dtmalloc                                       nfsclient_req free
…
…
…
55380    profile                                                     tick-1
55381    profile                                                     tick-10
55382    profile                                                     tick-100
55383    profile                                                     tick-500
55384    profile                                                     tick-1000
55385    profile                                                     tick-5000

以上で、DTraceの機能が有効化ができました。

※ユーザランドDTraceの設定(参考)

ユーザランドDTraceをより有効に活用できるように以下の設定をしておきます。これによって、スタックトレースが動作し、より多くの情報を表示できるようになります。

# vim /etc/make.conf
STRIP=
CFLAGS+=-fno-omit-frame-pointer
WITH_CTF=1

ベースシステムを再構築します。

# cd /usr/src

# make buildworld

# shutdown -r now

# boot -s

ベースシステムをインストールします。

# make installworld

システムを再起動して、さくらのVPSコントロールパネルからシングルユーザモードで起動します。

# shutdown -r now

さくらのコントロールパネル上からVNCコンソールを開き、以下の画面で「6」キーを入力します。"[S]ingle User"項目がOnになったことを確認して、起動させます。

以下はシングルユーザモードでのオペレーションとなります。

ファイルシステムを読み書き可能な状態にします。

# mount -u /

ベースシステムのインストールを行います。

# cd /usr/src

# make installworld

以上で、ユーザランドDTraceの機能を拡張できました。

おわりに

ここでは、DTraceを有効化する手順を記載しました。実際の使用法や動作についてはまだきちんと確認できていませんが、Solarisでも導入されているこの機能を有効に使っていければと思います。

はじめに

2013年6月5日(水)、6日(木)の2日間、東京で開催されたAmazon Web Serviceのクラウドカンファレンス「AWS Summit Tokyo 2013」のDay2(6日(木))へ行ってきました。

• アマゾンのクラウドカンファレンス開催！| AWS SUMMIT TOKYO 2013 (2013/6/5～6）

いろいろな話を聞いたりTwitterの内容を見たりしていると、いろいろな理由で現状ではAWS(やその他クラウド)の利用に乗り出せない企業様も多くいらっしゃるように思いましたが、本カンファレンスではそういったクラウドに移行するために、オンプレミスと比較した場合の導入コストや運用方法を中心に、それに伴う人的リソース、セキュリティやデータ保全等の障壁をどうクリアしていけば良いのか、といった点に注目が集まっていたように思います。
私自身もAWSを全く使ったことはないので、AWSの既存機能や用語などについて詳しく分かっていない部分も多々ありましたが、上記のような点についてイメージしながら今後使いどころを考えていければと思って参加しました。

聴講してきたセッションのうち以下について、祖末ながら取ったメモを復習の意味も兼ねて以下に簡単にまとめて残しておきます。

• 【EP】 中とろより価値あるITを。あきんどスシローのクラウド活用術
• 【Tech】Amazon Redshiftが切り開くクラウド・データウェアハウス
• 【CS】大規模案件の裏側 ～巨大AWSインフラ事例のご紹介～
• 【Tech】ネット選挙クラウド　～オバマ大統領選挙の事例：データ解析からネット募金まで～

セッション

【EP】 中とろより価値あるITを。あきんどスシローのクラウド活用術

株式会社あきんどスシロー 情報システム部 部長の田中 覚 様より、AWS上で構築された企業ホームページ、すしの売り上げ分析システム、テイクアウトの受注システムについてのお話でした。

AWS選択の経緯や導入後の運用実績、既存の業務などビジネス面を考慮した上でのデータ活用事例などについて具体的にご説明されていて、個人的にはこのセッションが一番面白かったです。

また、やるべきことや問題点が明確で、その要件に合ったインフラ基盤としてAWSがベストでそれを有効活用している、というイメージでした。データ分析をきちんと行っており、実際にどういったことをやっているのかの概要を知ることができたのも良かったです。

• ASCII.jp：寿司もITも鮮度が一番！あきんどスシローのAWS活用術 (1/2)

企業ホームページのAWS移行

AWSを選択した経緯としては、「中トロ販売もIT投資もどちらも投資、どちらがよりお客様に喜ばれるか」という企業としてのIT/システム投資に関する捉え方、従業員3万人超に対して情シス5人という体制からの運用や管理面を考慮してだそうです。

最初にAWSへ移行したのはホームページだったそうです。あきんどスシロー社のホームページにはメニューや店舗の場所などが載っているため、平日では10万PV程のアクセスが土日や大型連休になると来店される方が増えるため18万PVほどになり、TVで同社が放送されるようなことがあると、さらにリアルタイムにアクセスが増え、お願いランキングで紹介されたときは45万PVまで達したとのことでした。
テレビ放送があるときは事前に知らされているため、その日にあわせて事前にサーバを増強するようにスケジューリングしておくことで対応したとのこと。具体的にはAWSのイメージコピーをスケジューリングし、さらに現在はスマートフォンやタブレットなどのデバイスも主流であるため、テレビ放送された瞬間にリアルタイムに突発的なアクセス増が発生するため、トラフィックに応じて動的にサーバ増設できるようオートスケールも設定して備えていたそうです。
オートスケールは便利だが費用が高いため、基本は低コストで済む事前のサーバ増設で対応し、念のために可用性確保の目的としてオートスケールを仕掛けておき、最終的にはオートスケールも使わずに済んだため、最終機には準備・対応にかかった追加費用は5万円程度で済んだとのことでした。また、イメージバックアップのコピーはDRとしても活用しているそうです。
このような特性のWEBサイトの運用はAWSのような柔軟性のある基盤はマッチしているんだろうな、と思いました。

蓄積された大量データをAWSでの分析

続いて、同社が既に保持しているデータの活用についてでした。
新鮮な寿司を提供するために、皿の裏にICタグをつけておき、15分経過すると自動で廃棄する仕組みや、来店するお客様の家族構成や注文内容のデータから、着席後の需要予測を各店舗の店長が見てレーンにネタの内容や量を決めているらしいが、そうしたデータが現状約40億件蓄積されていたが、それを扱う手段が無かったとのこと。そこでクラウドを使うことを検討し、過去2年分のデータを使い、ウィングアーク社の「Dr.Sum EA」で集計し、BIツール「Motion Board」で可視化するという分析基盤環境をAWSで作成し、それを持って役員を説得し、導入に至ったとのことでした。
なお、検証環境の構築にかかった期間は2日、費用は10万円程度だったそうで、ちょっと作って試すという使い方も十分という利点が示されたように思います。これからはこういった使われ方も一般的になっていきそうです。

この分析基盤を利用して、流通サイドからはネタの売れ筋からロングテール商品や地域毎の人気ネタを見て店舗ごとに商品の提供をコントロールしたり、営業サイドからは新規店舗と既存店舗の廃棄率の差を確認等を行っているようです。

現在は、各店舗内でテイクアウト(持ち帰り)の注文をとれるシステムの導入を検討しているとのこと。手書き伝票で受注管理している既存の方式だと、お客様にも分かりにくく、店舗側もミスや人的コストも発生しがちな点が課題だそうです。クラウド上で試験的に構築し、うまくいかなければすぐやめるというスタンスでチャレンジしているそうです。

あきんどスシロー社の開発運用体制

気になる開発・運用体制ですが、システム設計やデザインは東京のベンダーが、開発やテスト、運用監視は国外(中国)にオフショア、クラウド利用時に不安点としてあげられがちなセキュリティについては、第3者(NTT Data社)へ委託しているとのこと。また、データ保護や災害対策として、最も低コストで実現できるやり方をAmazonデータサービスの営業の方に相談し、AWSのストレージゲートウェイをシンガポールのS3にコピーすることで実現しているようです。

【Tech】Amazon Redshiftが切り開くクラウド・データウェアハウス

アマゾンデータサービスジャパンの八木橋 徹平 様による、AWS上のデータウェアハウス(DWH)サービス「Amazon Redshift」についての紹介でした。 6月5日に東京リージョンでの提供も開始されたそうです。

• AWS日本法人の長崎社長が多様なクラウドの使い方を紹介、Redshiftの実機評価結果も ～AWS Summit Tokyo 2013 2日目レポート

講演内容の結論としては「スケールすることで性能向上」「バッチ処理は得意」「チューニングは新しい概念で」「利用料課金は安い」。
ただ、私はこの分野はまだ勉強不足なので、あまり利用イメージがわきませんでした。以下はとりあえず聞いたことのまとめです。

オンプレミスでDWHを構築する場合の課題

まず、オンプレミスのDWHについての課題として、初期投資や運用管理、データ量増加を見越したシステムを構築しようとした場合の成長予測とその費用対効果が見えない点をあげられていました。 Amazon Redshiftを利用することで、これらの問題点を改善できるだろう、とのことです。

Redshiftのアーキテクチャ

RedshiftはElastic MapReduce(EMR)と同じく分析処理向けのサービスであるが、PostgreSQLベースでJDBCドライバによりSQLを扱える点がEMRと大きく異なるとのことです。
構成例として、RDSやDynamo DBなどの様々なデータストアからS3/EMRにデータを蓄積してRedshiftで読み込む方法が紹介されました。

また、カラムナ(列指向)型データベースで集計などの処理を高速に実行可能、ノード数を増やすことで数TB〜数PBまでスケールさせることでクラスタ構成をとることができるそうです。
各マルチノードクラスタは1台のリーダーノードと2つ以上のコンピュータノードを持つことになり、リーダーノードは接続、クエリの解析、実行計画の構築、およびコンピュータノードでのクエリ実行を管理します。 コンピュータノードはデータを保存し、計算を行い、リーダーノードによって指示されたクエリを実行します。リーダーノードではC+のCodeを生成してクエリを並列化し、全コンピュータノードで分散・並列処理をさせることが可能になります。バックアップやクラスタのリサイズは管理画面上から実施可能とのことです。バックアップはS3と連携しての増分/差分バックアップを取得できるようです。
クラスタのリサイズは、バックエンドで別のクラスタが用意され、そこにデータがコピーされ、DNSによりエンドポイントが切り替わりが行われるような動作となるとのことでした。

野村総研(NRI)様によるRedshift検証結果報告

続いて、2012年末にRedshiftが限定公開されていたときに、先行して評価に参加していた野村総研(NRI)様による検証結果などを解説いただきました。

大きなテーブル(500億件のデータ)からの検索処理、データのロード処理、小さな(?)テーブル(1.2億件のデータ)の検索処理の2ノード、4ノード、8ノードでの性能評価で、いずれもスケールアウトすることで性能が向上したようです。唯一小さなテーブルでの検索処理で4ノードから8ノードへスケールした際に性能が落ちたようですが、分散することによるオーバーヘッドではないか、とのことでした。
他、EMRとRedshiftの比較においては、1.5TB、500億件でのJOIN＋集計処理ではRedshiftの方が性能が良くなったと紹介されてました。

Redshiftのチューニングポイントとして、Indexが存在しないため、代わりとしてDistribution Keyの利用をあげられていました。小さなテーブル(1.2億件のデータ)におけるDistribution Keyを指定する場合としない場合の検索処理においてはDistribution Keyを指定した場合の処理時間の向上が見られたとのことです。Sort Keyを入れると各ノードへの割り振りに時間がかるのでデータロードがその分遅くなるようです。

具体的には分かりませんでしたがRedshiftも不得意なデータ形式があるため、そのようなデータがある場合は、それに適した他のAWSサービスを利用する等が良いようです。NRI様ではそのようなデータをEMRで処理するようにした、とのことでした。

Redshift対応のソフトウェアの御紹介

最後に、Redshiftに対応したソフトウェア類を御紹介されていました。現在オンプレミスにあるデータをRedshiftへ移行するツールとしてはインフォテリアのEAI製品「Asteria Warp」、BIツールとしてはKSKアナリティクスが販売する「Pentaho」、ワークブレイン・ジャパンが販売する「Jaspersoft」がRedshiftを正式にサポートしているそうです。

参考

• Amazon redshiftのご紹介

【CS】大規模案件の裏側 ～巨大AWSインフラ事例のご紹介～

アイレット様のcloudback事例の御紹介でした。ケンコーコム様のSAPの事例をはじめ、日本テレビ様、トヨタ様、ローランド様など数々のAWS導入・移行を手がけ、200社超の顧客を手がけているそうです。資料が公開されています。

• 大規模案件の裏側 ～巨大AWSインフラ事例のご紹介～ - SlideShare

日本TV様のソーシャルテレビエンターテインメント JoinTVのシステムのAWSの活用事例

日本テレビが提供する、テレビを見ながらスマートフォンやリモコンで番組に参加できるサービス"JoinTV"のAWS活用事例でした。

テレビという大きな規模ではピーク時のオートスケールでは処理が間に合わないので、事前のプロビジョニングが必須だったとのことです。具体的にはリクエスト処理をSQSでキューに蓄積し、非同期処理でレスポンスを返す等の施策をとられた、と御説明されてました。
簡単ではないのでしょうけど、正しいタイミングできちんとスケールアウトできる構成にした上で、高負荷時の対策をしっかりやっていれば、この規模のシステムのAWSでの柔軟性ある運用もメリットありということでしょうか。高負荷時のパフォーマンスチューニングをどうやったのか等は気になります。

ケンコーコム様のシステムのAWS活用事例

東日本大震災を機に、システム全体をオンプレミスからAWSへ移行されたとのことです。構成としてはEC2を50台、RDSを5台。元々SiteGuardを導入していたそうですが、クラウドでの利用がライセンス面で問題があったため、CDPのWAF Proxyを固定台数用意する構成をとられたとのこと。

AWS移行は実績やノウハウが多い会社(人柱となってきた会社…)に任せたほうがオンプレミス設計のズレなどの吸収、帳尻合わせが容易になるため良いとのことで、これはおっしゃれた通りだと思いました。AWS自体は誰でも手軽に利用できるものだと思いますが、既存システムを何も改変せずに自分たちだけでそのまま移行しようとするのは危険そうです。

TOYOTA社のAWS活用事例

サイトの規模としては月間1億PVと大規模。特に新車発表時のアクセスは3倍になるそうです。DRとしては東京リージョンの障害時に備えてシンガポールリージョンを利用されているそうです。あきんどスシロー様もDRにシンガポールリージョンを利用されていたので、やはりそれが一番ということでしょうか。バックアップについてはAWSを信用せずオンプレミス環境に取得しているという点も面白いです。CloudFormationを使ってテンプレートから一発で環境構築可能にしているそうです。

参考

• 導入事例: ケンコーコム株式会社 | アマゾン ウェブ サービス（AWS 日本語）

TOYOTA様のシステムのAWS活用事例

【Tech】ネット選挙クラウド　～オバマ大統領選挙の事例：データ解析からネット募金まで～

Miles Ward氏による英語での講演でした。内容としては基本的に以下の記事の内容とほぼ同じような感じだったと思います。

• 「Obama For America」の開発チームが作り上げた大規模な選挙キャンペーンシステムの舞台裏（前編）
• 「Obama For America」の開発チームが作り上げた大規模な選挙キャンペーンシステムの舞台裏（後編）

参考

• システム構成

作成されたRailsアプリの一つだそうです。

• democrats/voter-registration · GitHub

おわりに

最後になりましたが、このような機会を設けていただいたアマゾン データ サービス ジャパン株式会社様をはじめとする関係者の皆様、ありがとうございました。大変勉強になり、また、楽しませていただきました。

AWSいつやるの？今でしょ！

その他参考

2日間のセッションの様子は下記の通りにまとめられていました。

• #awssummit AWS Summit Tokyo 2013 Day1 つぶやきまとめ - Togetter
• #awssummit AWS Summit Tokyo 2013 Day2 つぶやきまとめ - Togetter

はじめに

日本語フォントを利用しているのにZabbixのグラフで日本語文字が文字化けしてしまいました。
原因は、長いタイトルの通りPHP GD(グラフィックライブラリ)のJIS-mapped Japanese font support (文字列をSJISへ変換するオプション)が影響していたためであったようで、それについて調べたことをまとめておきます。

環境

確認した環境は以下の通りです。

Zabbixグラフの文字化けの原因と対策

Zabbixはユーザごとに管理画面からWebインタフェースの表示言語を設定することができますが、特に何もしないまま"日本語"を選択すると、グラフの日本語文字部分が以下の通り文字化けしてしまいます。

文字化けの原因は英語フォントを利用しているためですので、通常は日本語フォントを指定すれば日本語を表示することができます。
FreeBSDではPortsにIPAフォントが用意されていますので、これをインストールします。

# cd /usr/ports/japanese/font-ipa-uigothic

# make install clean

インストール後、/usr/local/share/font-mplus-ipa/fonts以下に ipagui.ttfが設置されますので、Zabbixフロントエンドのfontsディレクトリ以下に設置します。ここではシンボリックリンクを作成しています。

# ln -s /usr/local/share/font-mplus-ipa/fonts/ipagui.ttf /usr/local/www/zabbix2/fonts/ipagui.ttf

Zabbixフロントエンドの /usr/local/www/zabbix2/include/defines.inc.phpファイルの38行目を修正します。
フォント名を DejaVuSansから ipaguiに変更します。

//define('ZBX_GRAPH_FONT_NAME', 'DejaVuSans'); ※コメントアウト
define('ZBX_GRAPH_FONT_NAME', 'ipagui');

設定を反映させるためにApacheを再起動します。

# service apache24 restart

通常、これで文字化けは解消されるはずですが、私の環境では以下のように文字化けしておりました。

文字化け原因はPHP GD(画像生成ライブラリ)の日本語処理

最初は原因が分からず、DB側の文字コードを見直してみたりしましたが、解消されませんでした。そして、さらに調べるとPHP GD(グラフィックライブラリ)に日本語処理オプションがあるようで、これが影響していることが分かりました。

Zabbixで日本語文字をグラフに埋め込む処理は /usr/local/www/zabbix2/include/graphs.inc.phpに記載されています。Zabbix 2.0.6では663行目にあります。

if ($gdinfo['FreeType Support'] && function_exists('imagettftext')) {

詳しい説明は省略しますが、PHPでグラフを扱うには、GDというライブラリをインストールする必要があります。
また、ここで指定されている imagettftext()関数はTrueTypeフォント(拡張子が".ttf",".ttc"のもの)を扱うための関数で、この関数を利用するにはマニュアルによるとFreeTypeというフォントライブラリをインストールする必要があります。
これらのライブラリはPHPコンパイル時に--with-gd[=DIR], --with-freetype-dir[=DIR]のオプションが指定されていればでインストールされています。

通常これらのライブラリがあれば、日本語フォントを指定することでZabbixのグラフを日本語化できます。

しかし、それでも文字化けが発生するのは、PHPコンパイル時に JIS-mapped Japanese font support (--enable-gd-jis-conv)が有効になっている場合です。
imagettftext()関数は本来、UTF-8で文字列を扱いますが、JIS-mapped Japanese font supportが有効な場合、内部でSJISに変換される処理が行われてしまうため、UTF-8の文字列もSJISに変換され、上記のような文字化けが発生していたようです。

※補足

GDライブラリの設定情報は以下のコードで表示可能です。
[JIS-mapped Japanese Font Support] ==>> OKと表示されれば、JIS-mapped Japanese font supportが有効になっています。

<?php
    $buf_info = "";
    $arrInfo = gd_info();
    foreach ($arrInfo as $idx => $buf) {
        if (is_bool($buf)) {
            $buf_info .= "<p>" .htmlspecialchars("[$idx]  ==>>" .($buf ? "OK" : "No Support"))."</p>";
        } else {
            $buf_info .= "<p>" .htmlspecialchars("[$idx]  ==>> $buf") ."</p>";
        }
    }
    echo $buf_info;
?>

対応策

これを解決するためには、日本語フォントサポート(JIS-mapped Japanese font support)オプションを無効になるようにPHPを再コンパイルするか、/usr/local/www/zabbix2/include/graphs.inc.phpの664行目にSJISからUTF-8へ変換する以下3行の処理を追加する必要があります。

if ($gdinfo['FreeType Support'] && function_exists('imagettftext')) {
    // JIS-mapped Japanese Font Supportが有効になっている場合、UTF-8 から SJISへの変換する処理を追加
    if ($gdinfo['JIS-mapped Japanese Font Support']) {
        $string = mb_convert_encoding($string, "SJIS", "UTF-8");
    }

ここでは /usr/local/www/zabbix2/include/graphs.inc.phpに上記の処理を追加しました。設定を反映させるため、Apacheを再起動します。

# service apache24 restart

再度グラフを確認してみますと、以下の通り日本語が正常に表示されていることを確認できました。

おわりに

PHPの知識が無かったのでこの問題になかなか気付けませんでしたが、Zabbixのソースを見たりPHPのマニュアルを読んで少しですが理解が出来たのでよかったです。

ただ、PHPがZabbixのみで使用されている環境であれば、JIS-mapped Japanese font supportが無効になるようPHPを再コンパイルしてしまうほうが良いかも知れません。

参考

• （Zabbix1.8.1）グラフの日本語の文字化けについて | ZABBIX-JP
• zabbix-1.8.3 グラフの日本語処理について | ZABBIX-JP

はじめに

普段はあまりないかも知れませんが、HW構成などに関する詳細な情報を確認しなければならないことがあります。

例えば、サーバで物理的な故障が発生したとき、メーカー製のサーバであればサポートへ問い合わせて保守対応をしていただくことになりますが、問い合わせを行ったとき、故障した箇所や内容によってそのHWに関する情報を求めらることがあります。
HWシリアル番号、BIOSのバージョン情報、搭載されているメモリモジュールのメモリサイズ・数…等です。

そういった情報が分からないときにわざわざ電源を落としてBIOSの画面等から調べる…といったことはなかなか出来ないことが多いですが、Linux系OSであれば、そういった情報を知りたいときにdmidecodeというコマンドを利用できます。

RHEL系5系,6系であればdmidecodeパッケージをインストールする必要があります。
※CentOS6.4 x86_64の例

% rpm -qf /usr/sbin/dmidecode
dmidecode-2.11-2.el6.x86_64

以下はdmidecodeコマンドについてのメモです。

dmidecodeコマンド

dmidecodeはハードウェア情報をDMI(SMBIOS)に格納されている内容を解析して人間に読めるようなフォーマットとして報告します。
SMBIOS(System Management BIOS)とは簡単に言うとハードウェアの情報をBIOSに格納するための規格です。

• dmidecode

オプションなしでコマンドを実行すると、取得可能な全ての情報が表示されます。
-qオプションで不明な情報や無効な情報、メーカー固有の情報を省いたり、-s オプションでキーワード文字を指定したり、-t でタイプを指定してできます。
※詳しくはmanを参照してください。

-sオプションで指定可能なキーワード

# dmidecode -s
dmidecode: option requires an argument -- 's'
Valid string keywords are:
  bios-vendor
  bios-version
  bios-release-date
  system-manufacturer
  system-product-name
  system-version
  system-serial-number
  system-uuid
  baseboard-manufacturer
  baseboard-product-name
  baseboard-version
  baseboard-serial-number
  baseboard-asset-tag
  chassis-manufacturer
  chassis-type
  chassis-version
  chassis-serial-number
  chassis-asset-tag
  processor-family
  processor-manufacturer
  processor-version
  processor-frequency

-tオプションで指定可能なタイプ

 # dmidecode -t
dmidecode: option requires an argument -- 't'
Type number or keyword expected
Valid type keywords are:
  bios
  system
  baseboard
  chassis
  processor
  memory
  cache
  connector
  slot

動作確認

環境

実行環境は以下です。

実行

dmidecodeコマンドを実行していくつか情報を取得してみます。

BIOSの情報一覧を取得してみます。KVMゲストから実行したものですが、実際のBIOSから取得できた情報なのか分かりません...

# dmidecode -t bios
# dmidecode 2.11
SMBIOS 2.4 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
 Vendor: Seabios
 Version: 0.5.1
 Release Date: 01/01/2007
 Address: 0xE8000
 Runtime Size: 96 kB
 ROM Size: 64 kB
 Characteristics:
  BIOS characteristics not supported
  Targeted content distribution is supported
 BIOS Revision: 1.0

サーバのモデル名を取得してみます。KVM環境だと以下のような情報が取得できました。

# dmidecode -s system-product-name
KVM

HWのシリアルナンバーを取得してみます。KVMの環境だと取得できないようです。

# dmidecode -s system-serial-number
Not Specified

おわりに

HWに関する情報を取得するdmidecodeコマンドについて簡単に記載しました。

システムを停止したり、メーカーの管理ツールを使ったり、構成情報の資料を見たりしないと確認できないと思っていた情報でもコマンドで簡単に確認できるものもあります。
上記ではKVM環境で実行してみました結果ですが、物理マシン上で実行すると、システム製造元、モデル名、シリアル番号、BIOS バージョンやメーカー固有の情報(DELL製HWだとサービスタグ等)やメモリスロットに何GBのメモリモジュールが挿さっているかといった情報まで、細かい情報が確認できます。
管理がされていない詳細不明なHWでも情報を整理していけるかもしれません。

はじめに

2013年9月9日にオープンソースのRDBであるPostgreSQLの最新版となる「PostgreSQL 9.3」が正式にリリースされましたので、CentOS 6.4環境へインストールしてみました。

• PostgreSQL: PostgreSQL 9.3 released!
• PostgreSQL 9.3.0 Documentation

以下ではCentOS 6.4環境へのPostgreSQL 9.3のインストールからデータベースへ接続するまでを記載しています。

PostgreSQL 9.3のインストール

環境

インストール環境は以下です

事前準備

事前に必要なパッケージをインストールします。libossp-uuid.so.16というライブラリが必要になりますので、そのライブラリが含まれるuuidのパッケージをインストールします。
他にも必要なパッケージがあるかもしれませんが、その際は必要なものをインストールします。

# yum install uuid

インストール

スーパーユーザにスイッチします。

$ su -
パスワード:

pgdgリポジトリ(PostgreSQL Yum Repository)をインストールしても良いのですが、リポジトリの管理も手間なので、以下のようにRPMコマンド実行時にRPMファイルのURLを直接指定する形でインストールします。¥で改行していますが、一行で記載いただいて構いません。

# rpm -ihv http://yum.postgresql.org/9.3/redhat/rhel-6.4-x86_64/postgresql93-9.3.0-1PGDG.rhel6.x86_64.rpm \
http://yum.postgresql.org/9.3/redhat/rhel-6.4-x86_64/postgresql93-server-9.3.0-1PGDG.rhel6.x86_64.rpm \
http://yum.postgresql.org/9.3/redhat/rhel-6.4-x86_64/postgresql93-libs-9.3.0-1PGDG.rhel6.x86_64.rpm \
http://yum.postgresql.org/9.3/redhat/rhel-6.4-x86_64/postgresql93-contrib-9.3.0-1PGDG.rhel6.x86_64.rpm \
http://yum.postgresql.org/9.3/redhat/rhel-6.4-x86_64/postgresql93-devel-9.3.0-1PGDG.rhel6.x86_64.rpm

インストールはこれだけで完了です。

起動してみます。

# service postgresql-9.3 start

/var/lib/pgsql/9.3/data is missing. Use "service postgresql-9.3 initdb" to initialize the cluster first.
                                                           [FAILED]

データベースクラスタを初期化しろ、と怒られてしまいました。
PostgreSQLを使用できる状態にするには、データベースクラスタ(データベースを格納する領域)を初期化する必要があり、それを実行していないためです。

メッセージにある通りinitdbを実行します。

 # service postgresql-9.3 initdb --encoding=UTF8 --no-locale
 Initializing database:                                     [  OK  ]

指定しているオプションの意味は以下です。データベース作成先ディレクトリ(デフォルト:/var/lib/pgsql/9.3/data)等もここで指定できます。各オプションに関しては必ずしもここで指定する必要がないものもありますので、環境に合わせて指定してください。

• --encoding: データベースのデフォルトの文字エンコーディングを設定するオプション。ここでは文字エンコーディングにUTF-8を指定している。
• --no-localeは、ロケールを使用しないことを設定するオプション。localeでは文字列処理やメッセージ等を変更できる。--no-localeは--locale=Cと同じことを指し、C ロケール以外を設定すると性能へ影響する可能性もある。

ロケール(--locale)とエンコーディング(--encoding)は同じ値を設定する必要がありますが、encoding=SQL_ASCIIとする場合、またはlocale=C(--no-locale)とする場合は例外です。

これでPostgreSQLを使用できる状態となりました。
再度、起動処理を実行してみます。

# service postgresql-9.3 start
Starting postgresql-9.3 service:                           [  OK  ]

各プロセスが起動していることが分かります。

# ps auxf | grep postgre | grep -v grep
postgres 21428  0.0  0.7 224856 13840 ?        S    16:48   0:00 /usr/pgsql-9.3/bin/postmaster -p 5432 -D /var/lib/pgsql/9.3/data
postgres 21430  0.0  0.0  80480  1180 ?        Ss   16:48   0:00  \_ postgres: logger process
postgres 21432  0.0  0.0 224856  1432 ?        Ss   16:48   0:00  \_ postgres: checkpointer process
postgres 21433  0.0  0.1 224856  2268 ?        Ss   16:48   0:00  \_ postgres: writer process
postgres 21434  0.0  0.0 224856  1412 ?        Ss   16:48   0:00  \_ postgres: wal writer process
postgres 21435  0.0  0.1 225716  2616 ?        Ss   16:48   0:00  \_ postgres: autovacuum launcher process
postgres 21436  0.0  0.0  80612  1488 ?        Ss   16:48   0:00  \_ postgres: stats collector process

では、接続してみます。初期ではPostgreSQL側に"postgres"という名前のユーザ、"postgres"という名前のデータベースがありますのでそれに接続してみます、

# psql -U postgres -d postgres
psql: FATAL:  Peer authentication failed for user "postgres"

接続できませんでした。これはPostgreSQLのクライアント認証設定が影響しています。

上記の接続はローカルからの接続だったため、-hでホストを指定しなかったので、Unixドメインソケット経由の通信となります。
設定ファイルを見ると、Unixドメインソケット経由での接続時の認証方式はデフォルトではpeerとなっており、OSユーザと接続先DBのユーザと一致していなければ接続できません。
上記の接続の仕方ですと、OS上でpostgresユーザになっていると接続先データベースのユーザと一致しますので接続できます。RPMパッケージをインストールした際に自動的にOS上にpostgresユーザが作成されます。

# cat /var/lib/pgsql/9.3/data/pg_hba.conf
…
# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             all             ::1/128                 ident
…

この状態も手間なので、ローカルの全てのユーザがUnixドメインソケット経由で任意のデータベースに接続することを許可しておきます。
セキュリティを考えるとtrustでは無くmd5などにした方が良いかと思いますが、ここでは考慮しません。

# vim /var/lib/pgsql/9.3/data/pg_hba.conf
…
# "local" is for Unix domain socket connections only
local   all             all                                     trust  # <- 変更
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             all             ::1/128                 ident
…

設定変更後、PostgreSQLを再起動します。

# service postgresql-9.3 restart
Stopping postgresql-9.3 service:                           [  OK  ]
Starting postgresql-9.3 service:                           [  OK  ]

再度接続を試します。

# psql -U postgres -d postgres
psql (9.3.0)
Type "help" for help.

postgres=#

接続できました。
接続を終了するには、\qコマンドを実行します。

以上が、インストールからデータベースへ接続するまでの手順です。
ここでは細かいところまで記載していませんが、引き続き設定を行っていくにあたって、実行ファイルやライブラリへのPATH指定が.bashrcへ必要になったりなど追加の設定が必要になる知れません。

おわりに

ここではPostgreSQL 9.3をインストールしてからデータベースへ接続するまでの基本的な手順を記載しました。
PostgreSQL 9.3ではマテリアライズドビューや１秒以内での高速フェイルオーバー機能、レプリケーション機能改善など、大規模なシステム環境向けの機能追加や耐障害性の強化等がなされているようで、これからもさらに使われていく機会は増えていきそうです。

はじめに

2013年9月30日にFreeBSD 9.2-RELEASEがリリースされました。ZFSやDTraceといった注目の機能が強化されているようです。

• FreeBSD 9.2-RELEASE Announcement

早速、さくらのVPSで使っているFreeBSD 9.1-RELEASEをFreeBSD 9.2-RELEASEへアップグレードしましたので、その際の手順を記載しておきます。

FreeBSD 9.1-RELEASEからFreeBSD 9.2-RELEASEへのアップグレード

アップグレード(マイナーバージョンアップ)は公式マニュアルに記載されている手順を元に実施します。

• 18.2. FreeBSD Update

環境

環境は以下の通りです。

アップグレード

アップグレードを実施します。まず、rootにスイッチします。

$ su -

freebsd-updateコマンドを実行して、更新内容を取得します。-rオプションで9.2-RELEASEを指定し、upgradeオプションを付けます。
更新されるファイルに対して、何度か"Does this look reasonable (y/n)?(これは妥当ですか？)といったことを聞かれるので"y"と入力します。

# freebsd-update -r 9.2-RELEASE upgrade
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching public key from update4.freebsd.org... done.
Fetching metadata signature for 9.1-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata files... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic src/src world/base

The following components of FreeBSD do not seem to be installed:
world/doc world/games world/lib32

Does this look reasonable (y/n)? y
…
…
…
/usr/src/usr.sbin/zzz/zzz.8
/usr/src/usr.sbin/zzz/zzz.sh
/var/db/mergemaster.mtree
/var/named/etc/namedb/master/empty.db
/var/named/etc/namedb/master/localhost-forward.db
/var/named/etc/namedb/master/localhost-reverse.db
/var/named/etc/namedb/named.conf
/var/named/etc/namedb/named.root
/var/yp/Makefile.dist
To install the downloaded upgrades, run "/usr/sbin/freebsd-update install".

上記"freebsd-update"実行後の最後のメッセージにある通りに、"freebsd-update install"を実行し、修正ファイルを反映(ディスクへ書き込み)します。

# freebsd-update install
Installing updates...
Kernel updates have been installed.  Please reboot and run
"/usr/sbin/freebsd-update install" again to finish installing updates.

"freebsd-update install"実行時の最後のメッセージにある通りに、システムの再起動を実施し、起動後再度"freebsd-update install"を実行して古いライブラリ等を削除します。

#  shutdown -r now
Shutdown NOW!
shutdown: [pid 35368]
root@hostname:/root #
*** FINAL System shutdown message from xxxxx@hostname.sakura.ne.jp ***

System going down IMMEDIATELY

# freebsd-update install
Installing updates... done.

マイナーバージョンアップですので、portsの再構築等は必要ありません。これでアップグレードは終了です。

おわりに

ZFS環境だったのでそれが影響して問題が発生しないか心配しましたが、処理に時間がかかっただけで特に問題なく進みました。
記事と関係ないですが、jailを試してみたい…

はじめに

Railsの勉強のため、簡単なRSSリーダーを作ってみて、その中で利用しているFeed取得・解析用のRubyライブラリ"Feedzirra"というものについて、基本的な使い方等を簡単なメモとして記載しておきます。

• pauldix/feedzirra - GitHub

feedzirra

Feed取得・解析用のRubyライブラリです。
詳しい説明はREADMEを読んでいただくのが早いと思います。使い方のサンプルなども載ってます。

• feedzirra/README.md at master · pauldix/feedzirra · GitHub

環境

実行環境は以下です。

インストール

gemコマンドでインストールできます。

$ gem search feedzirra

サンプルプログラム

試しに実行して、いくつかのデータを取得してみます。
FeedzirraはFeedのURLを解析するため、逐一対象WebサイトのFeedのURLを自分で調べるのは手間なので、Nokogiriを利用してWebサイトのURLからそのWebサイトのFeedのURLを取得して、それを解析するようにします。

記事のデータ取得に関しては、Webサイト側で配信されている順に配列で取得されます。
ニュースサイト等は必ずしも公開時間順になっている訳ではないようで、収集データを時系列で管理する場合は取得後に並び変える必要がありました(以下では特に記載してません)。

#!/usr/bin/env ruby

require 'open-uri'
require 'nokogiri'
require 'rss'
require 'feedzirra'


### 引数で受けとったWEBサイトのURLをnokogiriで解析してFeedのURLを取得
filename = ARGV[0]
doc = Nokogiri::HTML(open(filename),nil,'utf-8')
doc.css('link').each do |link|

  if link['type'] == 'application/rss+xml'&& link['rel'] == 'alternate'
    href = link['href']
    @feed_url = URI.join(filename, href)

  elsif link['type'] == 'application/atom+xml'&& link['rel'] == 'alternate'
    href = link['href']
    @feed_url = URI.join(filename, href)

  end
end

### FeedのURLをFeedzirraで取得・解析
feed = Feedzirra::Feed.fetch_and_parse "#{@feed_url}"

### データ取得例
### 対象サイトのURL取得
p "url: #{feed.url}"
### 対象サイトのFeed用URL取得
p "feed_url: #{feed.feed_url}"
### 対象サイトの最終更新日取得
p "last_modified: #{feed.last_modified}"

### 全記事を取得(配列で取得される)
p "ALL articles: #{feed.entries[0]}"
### 最初の記事の公開日を取得
p "The first article 'title': #{feed.entries[0].title}"
### 2番目の記事の公開日を取得
p "The second article 'published': #{feed.entries[1].published}"

実行

本ブログを対象に実行してみました。

$ ruby feedzirra-test.rb http://kanjuku-tomato.blogspot.com

実行結果

"url: http://kanjuku-tomato.blogspot.com/"
"feed_url: http://kanjuku-tomato.blogspot.com/feeds/posts/default?alt=rss"
"last_modified: 2013-11-17 13:55:23 +0900"
"ALL articles: [#＜Feedzirra::Parser::RSSEntry:0x007fb4d607c910 @entry_id=\"tag:blogger.com,1999:blog-522146242299075566.post-5854226855805152372\", @published=2013-10-05 10:51:00 UTC, @categories=[\"FreeBSD\", \"さくらのVPS\"], @title=\"FreeBSD 9.1-RELEASEをFreeBSD 9.2-RELEASEへアップグレード\", @summary=\"<
...(略)...
致します。 \", @url=\"http://kanjuku-tomato.blogspot.com/2013/01/blog-post.html\", @author=\"noreply@blogger.com (dshim)\">]"
"The first article 'title': FreeBSD 9.1-RELEASEをFreeBSD 9.2-RELEASEへアップグレード"
"The second article 'published': 2013-09-15 08:52:00 UTC"

おわりに

Feed取得用のRuny Gemは他にも以下のようなものがあるようです。

• aasmith / feed-normalizer
• arttu / feed_parser

どのような違いがあるのか使って比較してないのでわかりませんが、現状ではFeedzirraはGithubリポジトリ上の更新も頻繁に行われているようなので、Feedzirraを使ってみてます。取得したデータをDBに格納するようにして、RailsでFeed Readerを作ってます。

参考

• Rails + Heroku で俺専用RSSリーダー作った ::ハブろぐ
• Rails3.2でRSSリーダーを作る その2(完) | i78s.me
• Rails4でfeedzillaを試してみた
• Railsアプリケーションを作ってみる。feedzirra – RSS取得編 | ネクスト株式会社

はじめに

2013/11/21にRHEL 6.5がリリースされ、コンテナ型の仮想化ソフトウェア「Docker」への対応が発表されました。
以下リンク先の情報の通り、完全に「Docker」がサポートされた訳ではないため、利用するには外部リポジトリからDockerのパッケージを追加する必要があります。

• Red Hat、RHEL 6.5 をリリース ― PTP、プライベート認証局、コンテナ型仮想化技術「Docker」

なお、Dockerも2013/11/26にバージョン0.7がリリースされ、主要Linuxディストリビューションへの対応が発表されました。その中にはRHELも含まれています。

• Docker 0.7 runs on all Linux distributions – and 6 other major features | Docker Blog

RHEL6.5に追従して、先日(2013/12/1)、RHELのクローンとなるCentOSのバージョン6.5がリリースされたので、CentOS 6.5の環境にDockerをインストールしてみました。以下に記載します。

• CentOS 6.5 Release Notes

Dockerのインストールと動作確認

環境

インストール環境は以下です。

DockerのRPMパッケージインストール

Dockerの公式ドキュメントやDocker社(旧dotCloud社)の公式ブログの情報を元にインストールを行います。

• Requirements and Installation on Red Hat Enterprise Linux / CentOS - Docker Documentation
• Docker 0.7 & [RedHat | CentOS] 6.5 | CloudCounselor

インストールはrootユーザで行います。rootユーザにスイッチします。

$ su -
パスワード:

DockerのRPMパッケージはCentOS標準リポジトリには存在せず、EPELリポジトリにあります。
EPELリポジトリがない場合はEPELリポジトリのパッケージをインストールします。

# rpm -ihv http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

Dockerのパッケージをインストールします。lxc(Linux Containers)などが依存パッケージとしてインストールされます。

# yum install docker-io

Dockerのサービスを起動します。

# /etc/init.d/docker start
Starting cgconfig service:                                 [  OK  ]
Starting docker:                                    [  OK  ]

Dockerのインストールはこれで完了です。

CentOS6のコンテナ作成

CentOS6のコンテナを作成してみます。

Docker社のGIthubからCentOSのImage作成用のスクリプトを取得します。
現在はmkimage-centos.shからmkimage-rinse.shになっていますので過去のコミットログからmkimage-centos.shを取得します。

# cd /tmp

# wget https://github.com/dotcloud/docker/blob/8afb0abbee0ff135a5314d7078285378b8f49c93/contrib/mkimage-centos.sh

取得したスクリプトに実行権を付与して、実行します。
必要なパッケージが取得され、ファイルシステムのアーカイブ(ここではcentos-64.tar.xz)が作成されます。

# chmod 775 mkimage-centos.sh

# ./mkimage-centos.sh

# ls
centos-64.tar.xz

ファイルシステムのアーカイブをDockerのリポジトリへインポートします。"centos6_x86_64"の部分は好きな名前を指定します。

# cat centos-64.tar.xz | docker import - centos6_x86_64
f4f3b9b79842a9b3f7e0e1ea7ade3d2d0e4af6d0597165bffedbb99798c9fd09

リポジトリへインポートされた情報を確認します。

# docker images -notrunc
REPOSITORY          TAG                 IMAGE ID                                                           CREATED             SIZE
centos6_x86_64      latest              f4f3b9b79842a9b3f7e0e1ea7ade3d2d0e4af6d0597165bffedbb99798c9fd09   6 hours ago         300.2 MB (virtual 300.2 MB)

先ほどインポートしたアーカイブのイメージを元に、コンテナを起動します。
-tオプションの後ろにコンテナ作成に利用したいリポジトリ名:タグ名を指定します。タグ名は省略可能です。ここでは上記で登録した"centos6_x86_64(:latest)"を指定しています。 /bin/bashを指定して、コンテナのbashを起動しコンテナを操作します。この場合、-iオプションを付けてインタラクティブ(対話)モードにする必要があります。
※dockerでは基本的に1つのコンテナ起動時に指定した1つのプロセスを実行するような形になるようです。

# docker run -i -t centos6_x86_64:latest /bin/bash
bash-4.1#

bash-4.1# uname -a
Linux 82a772e0e0de 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

exitを実行すると、コンテナのbashが終了します。

bash-4.1# exit

基本動作確認

まだ分からない部分が多いのですが、マニュアルを見ながらいくつか触ってみました。

• Command Line Interface - Docker Documentation

dockerコマンドのオプションは以下です。

# docker help
Usage: docker [OPTIONS] COMMAND [arg...]
 -H=[unix:///var/run/docker.sock]: tcp://host:port to bind/connect to or unix://path/to/socket to use

A self-sufficient runtime for linux containers.

Commands:
    attach    Attach to a running container
    build     Build a container from a Dockerfile
    commit    Create a new image from a container's changes
    cp        Copy files/folders from the containers filesystem to the host path
    diff      Inspect changes on a container's filesystem
    events    Get real time events from the server
    export    Stream the contents of a container as a tar archive
    history   Show the history of an image
    images    List images
    import    Create a new filesystem image from the contents of a tarball
    info      Display system-wide information
    insert    Insert a file in an image
    inspect   Return low-level information on a container
    kill      Kill a running container
    load      Load an image from a tar archive
    login     Register or Login to the docker registry server
    logs      Fetch the logs of a container
    port      Lookup the public-facing port which is NAT-ed to PRIVATE_PORT
    ps        List containers
    pull      Pull an image or a repository from the docker registry server
    push      Push an image or a repository to the docker registry server
    restart   Restart a running container
    rm        Remove one or more containers
    rmi       Remove one or more images
    run       Run a command in a new container
    save      Save an image to a tar archive
    search    Search for an image in the docker index
    start     Start a stopped container
    stop      Stop a running container
    tag       Tag an image into a repository
    top       Lookup the running processes of a container
    version   Show the docker version information
    wait      Block until a container stops, then print its exit code

コンテナの一覧表示(docker ps オプション)

docker psコマンドの-aオプションでコンテナの一覧を表示してみます。/bin/bashがExit 0となっているので正常に終了していることを示しています。

# docker ps -a
CONTAINER ID        IMAGE                   COMMAND             CREATED             STATUS              PORTS               NAMES
82a772e0e0de        centos6_x86_64:latest   /bin/bash           4 hours ago         Exit 0                                  clever_davinci

コンテナの起動(docker start コンテナID)

docker startコマンドで起動したいコンテナを指定して、コンテナを起動します。

# docker start 82a772e0e0de
82a772e0e0de

コンテナのステータスがUPになりました。

# docker ps -a
CONTAINER ID        IMAGE                   COMMAND             CREATED             STATUS              PORTS               NAMES
82a772e0e0de        centos6_x86_64:latest   /bin/bash           4 hours ago         Up 2 seconds                            clever_davinci

コンテナへの接続( docker attach コンテナID)

コンテナへattach(接続)してみます。bashが起動します。

# docker attach 82a772e0e0de
bash-4.1#

exitを入力すると終了します。

bash-4.1# exit

起動したままコンテナをdettachするにはCtrl-p + Ctrl-qを入力します。

bash-4.1# #
#

コンテナの停止(docker stop コンテナID)

docker stopコマンドで停止したいコンテナを指定して、コンテナを停止します。

# docker stop 82a772e0e0de
82a772e0e0de

コンテナの設定情報表示(docker inspect コンテナID)

docker inspectでコンテナの設定情報を表示できます。

# docker inspect 82a772e0e0de
[{
"ID": "82a772e0e0de28e69855223ea2695c8cd3309a7abaa856cfebc1b2272124ea7b",
"Created": "2013-12-08T10:17:05.541604445Z",
"Path": "/bin/bash",
"Args": [],
"Config": {
"Hostname": "82a772e0e0de",
"Domainname": "",
"User": "",
"Memory": 0,
"MemorySwap": 0,
"CpuShares": 0,
"AttachStdin": true,
"AttachStdout": true,
"AttachStderr": true,
"PortSpecs": null,
"ExposedPorts": {},
"Tty": true,
"OpenStdin": true,
"StdinOnce": true,
"Env": null,
"Cmd": [
"/bin/bash"
        ],
"Dns": null,
"Image": "centos6_x86_64",
"Volumes": {},
"VolumesFrom": "",
"WorkingDir": "",
"Entrypoint": null,
"NetworkDisabled": false
    },
"State": {
"Running": false,
"Pid": 0,
"ExitCode": 137,
"StartedAt": "2013-12-08T15:10:27.897931338Z",
"FinishedAt": "2013-12-08T17:03:44.120620099Z",
"Ghost": false
    },
"Image": "f4f3b9b79842a9b3f7e0e1ea7ade3d2d0e4af6d0597165bffedbb99798c9fd09",
"NetworkSettings": {
"IPAddress": "",
"IPPrefixLen": 0,
"Gateway": "",
"Bridge": "",
"PortMapping": null,
"Ports": null
    },
"SysInitPath": "/var/lib/docker/init/dockerinit-0.7.0",
"ResolvConfPath": "/etc/resolv.conf",
"HostnamePath": "/var/lib/docker/containers/82a772e0e0de28e69855223ea2695c8cd3309a7abaa856cfebc1b2272124ea7b/hostname",
"HostsPath": "/var/lib/docker/containers/82a772e0e0de28e69855223ea2695c8cd3309a7abaa856cfebc1b2272124ea7b/hosts",
"Name": "/clever_davinci",
"Driver": "devicemapper",
"Volumes": {},
"VolumesRW": {}
}]#

コンテナイメージのコミット(docker commit コンテナID リポジトリ名)

登録しているコンテナに変更を加えた後は、その情報をリポジトリにコミットすることができます。
新規コンテナ作成時にそのリポジトリを指定して作成することで、同一環境を簡単に作成することができます。

ID:82a772e0e0deのコンテナにパッケージを追加して試してみます。
dockerにattachします。

# docker attach 82a772e0e0de
bash-4.1#

bash-4.1# rpm -qa | wc -l
125

baseパッケージをインストールしてみます。

bash-4.1# yum groupinstall base

パッケージ数を確認します。

bash-4.1# rpm -qa | wc -l
363

コンテナを終了します。

bash-4.1# exit

baseパッケージをインストールしたコンテナIDを指定して、install/baseという名前でリポジトリへcommitします。

# docker commit 82a772e0e0de install/base

リポジトリにinstall/baseというイメージが登録されています。

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
install/base        latest              68512dfeb565        3 hours ago         430.5 MB (virtual 730.7 MB)
centos6_x86_64      latest              f4f3b9b79842        6 hours ago         300.2 MB (virtual 300.2 MB)

新しくコンテナを作成する際に-tオプションでinstall/baseを指定すると、baseパッケージがインストールされたCentOS6を起動できます。

# docker run -i -t install/base /bin/bash
bash-4.1#

パッケージ数が先ほど作成したものと一致しています。

bash-4.1# rpm -qa | wc -l
363

コンテナの一覧を見ると新しく作成されたコンテナが表示されています。

# docker ps -a
CONTAINER ID        IMAGE                   COMMAND             CREATED             STATUS              PORTS               NAMES
933b3258c5ba        install/base:latest     /bin/bash           18 seconds ago      Exit 0                                  compassionate_thompson
82a772e0e0de        centos6_x86_64:latest   /bin/bash           5 hours ago         Up 43 minutes                           clever_davinci

コンテナの削除(docker rm コンテナID)

コンテナを削除したい場合はdocker rmで削除したいコンテナIDを指定すると削除できます。

# docker rm 933b3258c5ba

# docker ps -a
CONTAINER ID        IMAGE                   COMMAND             CREATED             STATUS              PORTS               NAMES
82a772e0e0de        centos6_x86_64:latest   /bin/bash           5 hours ago         Up 43 minutes                           clever_davinci

リポジトリの削除(docker rmi イメージID)

リポジトリの削除はdocker rmiで削除したいイメージIDを指定します。

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
install/base        latest              68512dfeb565        3 hours ago         430.5 MB (virtual 730.7 MB)
centos6_x86_64      latest              f4f3b9b79842        6 hours ago         300.2 MB (virtual 300.2 MB)

# docker rmi 68512dfeb565

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
centos6_x86_64      latest              f4f3b9b79842        6 hours ago         300.2 MB (virtual 300.2 MB)

dockerのレジストリからイメージの取得(docker pull イメージ名)

今回、最初はスクリプトを使ってファイルシステムのアーカイブからイメージを作成しましたが、Dockerの公式レジストリ(https://index.docker.io/)にもコンテナのイメージがあり、取得して利用することができます。

ubuntuのイメージを取得してみます。

# docker pull ubuntu
Pulling repository ubuntu
8dbd9e392a96: Download complete
b750fe79269d: Download complete
27cf78414709: Download complete

一覧が以下のようになってます。

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
centos6_x86_64      latest              f4f3b9b79842        8 hours ago         300.2 MB (virtual 300.2 MB)
ubuntu              12.04               8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)
ubuntu              latest              8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)
ubuntu              precise             8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)
ubuntu              12.10               b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)
ubuntu              quantal             b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)

Ubuntu 12.10を起動する場合は以下のようにします。

# docker run -i -t ubuntu:12.10 /bin/bash
root@4c7067de37e9:/#

root@4c7067de37e9:/# cat /etc/issue
Ubuntu 12.10 \n \l

また、自分でやってはいませんが、自身で作成したイメージを公式レジストリ(https://index.docker.io/)に登録することもできるようです。あらかじめサイト上でアカウントを作っておき、 docker loginした後にdocker pushすると登録でき、外部のどこからでも作成したリポジトリを参照することができるようになるようです。

おわりに

CentOS6.5へDockerをインストールして、コンテナの作成や簡単な動作を確認してみました。仮想マシンの作成は割と容易にでき、起動も一瞬なので手軽に使えるイメージでした。
コンテナ型仮想化ということでSolarisコンテナ(Zone)のようなイメージを持ってましたがそれよりはライトな感じで、仮想OS環境をガリガリ使うというよりは、特定用途の環境をあらかじめ作っておき必要に応じてサクッと起動して使うような感じなんですね。 (例えばApacheの環境を作っておき、docker run -p 10080:80 -d http(<-仮名称(Apacheがインストールされたコンテナイメージ名))"とかで手軽にApache環境を起動できるようにしておくような)
どのような使い方をするのが良いのかはまだわかりませんが、あらかじめ特定の環境を作成してそのコンテナイメージを登録しておき、必要なときに起動してテスト、不要となったら削除するといったような形でCIの仕組みに取り入れたりできそうなイメージでした。

はじめに

2014/1/20 FreeBSD 10-RELEASEが公開されました。10系の初リリースです。

• FreeBSD 10.0-RELEASE Announcement

さくらのVPSで使っているFreeBSD 9.2-RELEASEを10.0-RELEASEへアップグレードしてみましたので、その際に実施した手順を記載します。

FreeBSD 9.2-RELEASEを10.0-RELEASEへアップグレード

公式マニュアルの手順を元に、アップデートを実施します。

• 18.2. FreeBSD Update

ただし、利用しているFreeBSDのパッチレベルによってはportupgradeコマンドの不具合でアップグレード処理を実行できませんのでパッチを適用する必要があります。

• FreeBSD-EN-13:04.freebsd-update.asc
• FreeBSD-EN-13:05.freebsd-update.asc

また、FreeBSD 10.0-RELEASEからデフォルトのバイナリパッケージ管理ツールが変更になったことで、メジャーバージョンアップ後のソフトウェアの更新が従来通りのやり方ではうまくいきませんでした。この点については以下に記載しているやり方が正しいのかわかりません。

実行環境

実行環境は以下となります。

freebsd-updateの個別パッチの適用

セキュリティパッチの当たっていないFreeBSD 9.2-RELEASE-p0を利用しており、freebsd-updateコマンドに不具合があり、freebsd-updateコマンド実行時に以下のエラーが出てアップデートを実行できませんでした。

The update metadata is correctly signed, but failed an integrity check.
Cowardly refusing to proceed any further.

そのため、上記のErrata Noteの内容を参考にfreebsd-updateコマンドにパッチをあてます。
なお、該当の不具合が修正されているセキュリティパッチの適用されたFreeBSDであれば、この手順は不要です。

作業は全てrootで実施しますので、rootにスイッチします。

$ su -

FreeBSD-EN-13:04のパッチ適用

FreeBSD-EN-13:04のパッチを適用します。

パッチファイル設置用のディレクトリを作成します。

# mkdir /tmp/FreeBSD-EN-13:04

作業用ディレクトリに移動します。

# cd /tmp/FreeBSD-EN-13:04

パッチファイルをダウンロードします。

# fetch http://security.FreeBSD.org/patches/EN-13:04/freebsd-update.patch

以下の通りにダウロードされます。

fetch: http://security.FreeBSD.org/patches/EN-13:04/freebsd-update.patch: size of remote file is not known
freebsd-update.patch                                  2754  B 3756 kBps 00m00s

gpgコマンド(GnuPG)がある場合はPGPシグネチャファイルをダウンロードします。

# fetch http://security.FreeBSD.org/patches/EN-13:04/freebsd-update.patch.asc

以下の通りにダウロードされます。

fetch: http://security.FreeBSD.org/patches/EN-13:04/freebsd-update.patch.asc: size of remote file is not known
freebsd-update.patch.asc                               801  B 1245 kBps 00m00s

gpgコマンド(GnuPG)がある場合はPGP署名を確認します。なければ飛ばしても構いません。

# gpg --verify freebsd-update.patch.asc

/usr/srcディレクトリに移動してます。

# cd /usr/src

ダウンロードしたパッチファイルを使って修正差分を適用します。

# patch < /tmp/FreeBSD-EN-13:04/freebsd-update.patch

以下の通りにパッチが適用されます。

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: usr.sbin/freebsd-update/freebsd-update.sh
|===================================================================
|--- usr.sbin/freebsd-update/freebsd-update.sh
|+++ usr.sbin/freebsd-update/freebsd-update.sh
--------------------------
Patching file usr.sbin/freebsd-update/freebsd-update.sh using Plan A...
Hunk #1 succeeded at 1200.
Hunk #2 succeeded at 2814.
Hunk #3 succeeded at 2852.
Hunk #4 succeeded at 2876.
done

/usr/src/usr.sbin/freebsd-updateディレクトリに移動します。

# cd /usr/src/usr.sbin/freebsd-update

freebsd-updateコマンドのリビルドを実施します。

# make install -DWITHOUT_MAN

install -o root  -g wheel -m 555  freebsd-update.sh  /usr/sbin/freebsd-update

FreeBSD-EN-13:05のパッチ適用

FreeBSD-EN-13:05のパッチを適用します。

パッチファイル設置用のディレクトリを作成します。

# mkdir /tmp/FreeBSD-EN-13:05

作業用ディレクトリに移動してます。

# cd /tmp/FreeBSD-EN-13:05

パッチファイルをダウンロードします。

# fetch http://security.FreeBSD.org/patches/EN-13:05/freebsd-update.patch

以下の通りにダウロードされます。

fetch: http://security.FreeBSD.org/patches/EN-13:05/freebsd-update.patch: size of remote file is not known
freebsd-update.patch                                   653  B 1521 kBps 00m00s

gpgコマンド(GunPG)がある場合はPGPシグネチャファイルをダウンロードします。

# fetch http://security.FreeBSD.org/patches/EN-13:05/freebsd-update.patch.asc

以下の通りにダウロードされます。

fetch: http://security.FreeBSD.org/patches/EN-13:05/freebsd-update.patch.asc: size of remote file is not known
freebsd-update.patch.asc                               801  B 3007 kBps 00m00s

gpgコマンド(GunPG)コマンドがある場合はPGP署名を確認します。なければ飛ばしても構いません。

# gpg --verify freebsd-update.patch.asc

/usr/srcディレクトリに移動します。

# cd /usr/src

ダウンロードしたパッチファイルを使って修正差分を適用します。

# patch < /tmp/FreeBSD-EN-13:05/freebsd-update.patch

以下の通りにパッチが適用されます。

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: usr.sbin/freebsd-update/freebsd-update.sh
|===================================================================
|--- usr.sbin/freebsd-update/freebsd-update.sh  (revision 257878)
|+++ usr.sbin/freebsd-update/freebsd-update.sh  (revision 257879)
--------------------------
Patching file usr.sbin/freebsd-update/freebsd-update.sh using Plan A...
Reversed (or previously applied) patch detected!  Assume -R? [y] y
Hunk #1 succeeded at 2884.
done

/usr/src/usr.sbin/freebsd-updateディレクトリに移動します。

# cd /usr/src/usr.sbin/freebsd-update

freebsd-updateコマンドのリビルドを実施します。

# make install -DWITHOUT_MAN

install -o root  -g wheel -m 555  freebsd-update.sh  /usr/sbin/freebsd-update

FreeBSDのメジャーバージョンアップ

freebsd-updateコマンドを使ってFreeBSD 10.0-RELEASEへのメジャーバージョンアップを実施します。

更新ファイルのダウンロード

10.0-RELEASEへアップデートするために必要なファイルを取得します。

# /usr/sbin/freebsd-update -r 10.0-RELEASE upgrade

更新対象となるファイルに対して、Does this look reasonable (y/n)?(変更に問題ないか？)といったことを聞かれるのでy(yes)と入力します。

Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 9.2-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic src/src world/base

The following components of FreeBSD do not seem to be installed:
world/doc world/games world/lib32

Does this look reasonable (y/n)? y

Fetching metadata signature for 10.0-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Fetching files from 9.2-RELEASE for merging... done.
Preparing to download files... done.
Fetching 38043 patches.....10....20....30....40....50....60....70....80....90....100....110....120....130....140....150....160....170....180....190....200....210....220....230....240....250....260..
･･･
･･･
･･･
....36060....36070....36080....36090....36100....36110....36120....36130....36140....36150....36160....36170....36180....36190....36200....36210....36220....36230....36240....36250....36260....36270....36280....36290....36300....36310....36320....36330....36340....36350....36360....36370....36380....36390....36400....36410....36420....36430....36440....36450.. done.
Applying patches... done.
Fetching 9673 files...
Attempting to automatically merge changes in files... done.

変更対象の設定ファイルが表示されます。同様にDoes this look reasonable (y/n)?(変更に問題ないか？)といったことを聞かれるのでy(yes)と入力します。

he following changes, which occurred between FreeBSD 9.2-RELEASE and
FreeBSD 10.0-RELEASE have been merged into /etc/group:
--- current version
+++ new version
@@ -1,6 +1,6 @@
-# $FreeBSD: release/9.2.0/etc/group 218046 2011-01-28 22:28:12Z pjd $
+# $FreeBSD: release/10.0.0/etc/group 256366 2013-10-12 06:08:18Z rpaulo $
 #
 wheel:*:0:root,shimizu,vps,zabbix
 daemon:*:1:
 kmem:*:2:
 sys:*:3:
@@ -16,10 +16,11 @@
 sshd:*:22:
 smmsp:*:25:
 mailnull:*:26:
 guest:*:31:
 bind:*:53:
+unbound:*:59:
 proxy:*:62:
 authpf:*:63:
 _pflogd:*:64:
 _dhcp:*:65:
 uucp:*:66:
Does this look reasonable (y/n)? y
･･･
･･･
･･･
The following changes, which occurred between FreeBSD 9.2-RELEASE and
FreeBSD 10.0-RELEASE have been merged into /etc/ssh/sshd_config:
--- current version
+++ new version
@@ -1,7 +1,7 @@
-#      $OpenBSD: sshd_config,v 1.89 2013/02/06 00:20:42 dtucker Exp $
-#      $FreeBSD: release/9.2.0/crypto/openssh/sshd_config 252339 2013-06-28 09:55:00Z des $
+#      $OpenBSD: sshd_config,v 1.90 2013/05/16 04:09:14 dtucker Exp $
+#      $FreeBSD: release/10.0.0/crypto/openssh/sshd_config 258343 2013-11-19 11:47:30Z des $

 # This is the sshd server system-wide configuration file.  See
 # sshd_config(5) for more information.

 # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
@@ -31,10 +31,13 @@

 # Lifetime and size of ephemeral version 1 server key
 #KeyRegenerationInterval 1h
 #ServerKeyBits 1024

+# Ciphers and keying
+#RekeyLimit default none
+
 # Logging
 # obsoletes QuietMode and FascistLogging
 #SyslogFacility AUTH
 #LogLevel INFO

@@ -114,11 +117,11 @@
 #UseDNS yes
 #PidFile /var/run/sshd.pid
 #MaxStartups 10:30:100
 #PermitTunnel no
 #ChrootDirectory none
-#VersionAddendum FreeBSD-20130515
+#VersionAddendum FreeBSD-20131111

 # no default banner path
 #Banner none

 # override default of no subsystems
Does this look reasonable (y/n)? y

The following files are affected by updates, but no changes have
been downloaded because the files have been modified locally:
/.cshrc
/root/.cshrc

10.0-RELEASEへのアップデートに伴って削除されるファイル一覧が表示されます。

The following files will be removed as part of updating to 10.0-RELEASE-p0:
/boot/kernel/atadisk.ko
/boot/kernel/atadisk.ko.symbols
/boot/kernel/atapicam.ko
/boot/kernel/atapicam.ko.symbols
/boot/kernel/atapicd.ko
/boot/kernel/atapicd.ko.symbols
/boot/kernel/atapifd.ko
/boot/kernel/atapifd.ko.symbols
/boot/kernel/atapist.ko
/boot/kernel/atapist.ko.symbols
/boot/kernel/ataraid.ko
/boot/kernel/ataraid.ko.symbols
/boot/kernel/coda.ko
･･･
･･･
･･･
/usr/src/usr.sbin/zic/Makefile.inc
/usr/src/usr.sbin/zic/README
/usr/src/usr.sbin/zic/zdump/Makefile
/usr/src/usr.sbin/zic/zic/Makefile
/usr/src/usr.sbin/zzz/Makefile
/usr/src/usr.sbin/zzz/zzz.8
/usr/src/usr.sbin/zzz/zzz.sh
/var/cache
/var/db/mergemaster.mtree
/var/empty
/var/yp/Makefile.dist
To install the downloaded upgrades, run "/usr/sbin/freebsd-update install".

カーネル/カーネルモジュール更新

更新ファイルはまだ反映されていないので、上記freebsd-updateコマンド実行後の最後のメッセージにある通りに、freebsd-update installコマンドを実行します。

# /usr/sbin/freebsd-update install

更新が反映(ディスクへ書き込み)されます。

Installing updates...
Kernel updates have been installed.  Please reboot and run
"/usr/sbin/freebsd-update install" again to finish installing updates.

上記メッセージに表示されているとおり、OS再起動を実施すると新しいカーネル(10.0-RELEASE)で起動するはずです。

# shutdown -r now

起動後、rootへスイッチします。

# su -

OSバージョンが10.0-RELEASEとなっていることを確認します。

# uname -r
10.0-RELEASE

古いライブラリ/ファイル類の削除

再びfreebsd-updateコマンドを実行します。

# /usr/sbin/freebsd-update install

古い共有ライブラリとオブジェクトファイルを削除されます。

Installing updates...
Completing this upgrade requires removing old shared object files.
Please rebuild all installed 3rd party software (e.g., programs
installed from the ports tree) and then run "/usr/sbin/freebsd-update install"
again to finish installing updates.

ZFSファイルシステムとストレージプールの更新

利用可能なZFSファイルシステムとストレージプールのバージョンはFreeBSDのバージョンによって異なります。
FreeBSDのアップグレードによってZFSファイルシステムとストレージプールのバージョンはアップグレードされますが、現在動作しているZFSファイルシステムとストレージプールは古いバージョンのままで動作し続けますので、最新バージョンの機能を利用できるように、現在動作しているZFSファイルシステムとストレージプールに対して以下のコマンドを実行してアップグレードを実行します。
※9.2-RELEASEと10.0-RELEASEでZFSファイルシステムとストレージプールのバージョンに違いはありませんが追加機能等が反映されているかわかりませんので念のため実行しています。

# zpool upgrade -a

# zfs upgrade -a

パッケージの更新

最後にパッケージの更新を実施します。

まず、最新portsを取得し、/usr以下へ展開します。

既存portsを移動させます。

# mv /usr/ports /usr/ports.bak

最新portsを取得します。

# wget http://ftp.jaist.ac.jp/pub/FreeBSD/ports/ports/ports.tar.gz -P /tmp

/usr以下へ展開します。

# tar -zxvf /tmp/ports.tar.gz -C /usr/

これまではportmasterコマンドを実行すればアップデートできてましたが、FreeBSD 10.0-RELEASEでこれを実行してもアップデートされませんでした。

# portmaster -af

FreeBSD 10.0-RELEASEからはデフォルトのパッケージ管理システムが従来のpkg_*からpkgngへと変更になったためかと思い、pkgngを利用するためには従来のパッケージ管理データベースをpkgng形式のフォーマットへ変換する必要する必要があるとのことでしたので、pkgng形式への変更を試みました。

pkgng

pkgngはFreeBSD 10.0-RELEASE以降デフォルトとなるパッケージ管理システムです。

• 5.5. pkgng によるバイナリ package の管理
• Official FreeBSD Binary Packages now available for pkgng

pkgコマンドがインストールされていない場合、pkgコマンドを実行するとブートストラップユーティリティによって自動でインストール処理が実行されます(FreeBSD 9.1 以降)。

# pkg

pkgng形式を利用する以前からインストールされているパッケージ/アプリケーションがある場合はpkg2ngコマンドを実行してフォーマットを変更するようにメッセージが出ます。

The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg please wait
Installing pkg-1.2.5... done
If you are upgrading from the old package format, first run:

  $ pkg2ng
･･･

pkg2ngコマンドを実行し、パッケージ管理データベースを新しいフォーマットへ変換します。

# pkg2ng

pkg2ngコマンド実行後、/var/db/pkgディレクトリにpkgngのSQLiteデータベースが作成されます。

# ls -lt /var/db/pkg | head -n 5
total 43802
-rw-r--r--    1 root  wheel   8911872  1月 22 10:42 local.sqlite
drwxr-xr-x    2 root  wheel         3  1月 22 01:02 gettext-0.18.3.1
drwxr-xr-x    2 root  wheel         3  1月 22 01:02 gmake-3.82_1
drwxr-xr-x    2 root  wheel         3  1月 22 01:02 libxml2-2.8.0_3

pkg infoコマンドを実行すると、pkgng形式になったパッケージ一覧が表示されます。

# pkg info

最新のバイナリパッケージへアップデートします。

# pkg upgrade -f

ここで、パッケージの依存関係でconflictが発生したりするので、適宜パッケージを削除/インストールして調整しなければならないと思います。
また、細かいコンパイルオプションが必要なものはportsからインストールし直す必要があります。

依存関係が解決できたら、再度最新のバイナリパッケージへアップデートを試みます。

# pkg upgrade -f

おわりに

以上で、FreeBSD 9.2-RELEASEから10.0-RELEASEへの更新が完了しました。
個人的には新しいパッケージ管理システムpkgngがportsやpkg_*コマンドより手軽な感じが良いなと思いました。
パッケージソフトウェアのアップデートのやり方が上記のような形で正しいのかはわかっていませんが、問題なく動作しているようです。 10-RELEASEのインストーラからインストール時にファイルシステムでZFSを選択できるようになったのも嬉しいです。

参考

• FreeBSD 10.0-RELEASE登場 | マイナビニュース
• 「FreeBSD 10.0-RELEASE」公開、ClangがデフォルトコンパイラになりHyper-V対応も強化 | SourceForge.JP Magazine
• 間もなく登場! FreeBSD 10.0、IT技術者なら知っておくべき11の新機能 (1) 高速圧縮アルゴリズム、圧縮キャッシュ | マイナビニュース 変更する
• 2013年11月5日　次世代パッケージ管理システムpkg(8)，バイナリパッケージ提供開始：FreeBSD Daily Topics｜gihyo.jp … 技術評論社
• FreeBSD Daily Topics：2012年8月8日　次世代パッケージ管理システムpkgの使い方：従来のパッケージからの移行方法｜gihyo.jp … 技術評論社
• FreeBSDのコレ知ってる？（3）：次世代パッケージ管理システム、pkg(8) (1/3) - ＠IT

はじめに

Ruby on Rails勉強し始めたころにOfficial Blog: A second spring of cleaningでGoogle Readerが終了するとの告知を受けて、とりあえずRuby on Railsを使ってフィードリーダーアプリを作ってみようと思い、やってみました。
まだ不完全ですが･･･。

• daish0/readerd · GitHub

やってみたこととか

基盤系

アプリの設置先にはさくらのVPS SSD メモリ2Gを使いました。AWSとかも使ってみたいですがどこまでやれるかわからなかったのでコストを考えて一旦断念しました。OSにはCentOS6を使い、WEBサーバソフトウェアはNginx、Unicornを、データベースにはPostgreSQL 9.3を使いました。PostgreSQLは最初9.2でやってましたが途中で9.3が出たのでアップデートしました。でも別に9.3特有の機能とかは使ってません。

Rails4 アプリ作成

アプリに関しては、すでに同じようなことをやられている方も当然いらっしゃったので、そういった方のブログ記事やgithubにソースを公開されている方のソースを参考にさせていただきました。
Railsに関してはお作法からわからなかったので苦労しました。というか未だにどういう書き方が良いのかなどちゃんと理解できてないです。何かとあるとコントローラで処理させようとしてしまうのでモデルやビューをうまく使い分けるとかActiveRecordの扱い方とか。
とりあえず、前述のようないろいろな方のソースコードを拝見してそれをローカルに取得して少し変更してはそのときの動作を確認してというのを繰り返したり、Railsプロジェクトを何度か立ち上げて写経したり適当に簡単なプログラムを作ったりして感じを覚えていきました。
プログラマブルな思考についても引き続き勉強していきます。

使ってみたGem

Unicorn: Rack HTTP server for Unix and fast clients

最近主流のRack(RubyとRubyアプリケーション/フレームワーク間のインターフェース)対応httpサーバ。

devise

Railsの認証ライブラリの定番。ログイン機能を簡単に実装できます。

pauldix/feedzirra - GitHub

フィードの情報を取得するライブラリ。似たようなライブラリは他にもありましたが、開発が今でも行われているようなのでこれを使わせていただきました。フィードの新規登録時や定期更新時にこのライブラリ経由で情報を取得しています。
ただ、Nokogiriで解析して取得したフィードのURLをfeedzirraに渡しているので、Nokogiriの解析結果から実際のフィードURLが取得できない場合はエラーになってしまいます。他のアプリケーションだとどうやって処理しているのかもう少し調べてみようと思ってます。

Nokogiri

FeedzirraはFeedのURLしか解析できないっぽかったのですが毎回FeedのURLを調べるのが手間だったので、対象サイトのURLからFeedのURLを取得するためにNokogiriを使ってみました。

seyhunak/twitter-bootstrap-rails - GitHub

米ツイッターが開発・提供しているフロントエンドツールのRailsライブラリ。レスポンシブにも対応してデザインの調整が結構楽になります。

javan/whenever - GitHub

Crontab管理ライブラリ。これを使ってフィードデータ取得用のrakeタスクをcrontabに登録して管理してます。

rails/strong_parameters · GitHub

mass_assignment脆弱性を解決するためのライブラリ。従来はモデル側でフィルタリングの制御をしていたけど、Rails4からはこれを使ってコントローラ側で制御するのが標準になる模様。

newrelic/rpm · GitHub

NewRelicでRailsアプリケーションのパフォーマンスをモニタリングするためのGem。

おわりに

自分用のアプリケーションをとりあえずRails4で作ってみました。とりあえず既読管理とか実装したい。

もっと勉強して次は人に使ってもらえるアプリケーションを作ってみたいなぁ。

参考

• Rails + Heroku で俺専用RSSリーダー作った ::ハブろぐ
• Rails3アプリケーション開発で良く使うgemまとめ
• twitter bootstrap railsを使ったら職が見つかり彼女も出来て背も3センチ伸びました。 - ppworks blog
• Wheneverは導入が超簡単なcorntab管理ライブラリGemです！[Rails] - 酒と泪とRubyとRailsと
• Rails4.0に含まれる strong_parameters について - willnet.in
• Ruby - ツールを使いたいだけの人のための bundler 入門 (例: vagrant + veewee) - Qiita [キータ]
• 「Ruby on Railsで簡単で素早くWebアプリを開発する」 第４回 Active Recordの入力チェック機能
• [Rials3]Rails3 + ActiveRecord で正しくtimezoneを設定する - Future Journal 〜未来志向で行こう〜
• rails 4 concern 便利 - 鳩舎
• 翻訳 ふとっちょのRails modelをconcernsでダイエットしよう | ntcncp.net

はじめに

tmuxを真剣に使い始めて1ヶ月程度ですが、tmuxについて基本的な機能の使い方をまとめてみようと思います。
類似の記事は既にたくさんありますが、とりあえず最低限覚えておくと良さそうな機能について整理してみます。

tmuxとは

tmuxは端末多重化ソフトウェアです。"てぃーまっくす"と読まれます。
Unix/Linux系OSを利用されている方であれば端末を利用した作業はほぼ必須かと思いますが、そのような場合にtmuxを利用できれば、1つのターミナルで操作しているシェルから実行したtmux上で複数の仮想端末を操作できるため、ターミナルを複数開くことなく複数のサーバへログインしたり、それぞれの仮想端末で別々のプログラムを実行できるようになるため、より効率的に作業が行えます。

具体的には以下のような形です。

tmuxがない場合

• ssh接続するたびに端末が開かれる
• 画面のカオス化
• 回線が切れる
• 実行中の処理が途切れてゲームオーバー
• sshクライアント実行中の端末が停止
• Windowsだとブルースクリーンになって実行中の処理が (ry

tmuxを使うことによるメリット

• 1つの端末で複数の擬似端末を起動可能
• 複数の端末を立ち上げずに、tmux上の擬似端末を切り替えてオペレーション可能
• 起動した仮想端末を画面分割して使用可能
• 他のファイルを参照したりログ出力を参照しながらオペレーション可能
• 起動した仮想端末上でコピペが可能
• マウスを使わず、tmux内でキーボードのみでのコピペが可能
• 起動した仮想端末のデタッチ(切り離し)/アタッチ(接続)が可能
• tmux実行端末とのネットワークが切れても問題なく、異なる環境から同じtmuxセッションへ接続可能

こんなに散らばっていた複数のターミナル画面ですが…

こんな風に1つのターミナル画面にまとめることができます。

tmux利用のイメージ図

利用イメージ図としては以下のような感じです。
ssh先の踏み台サーバ上でtmuxを起動して各サーバ群にssh接続します。私はウィンドウ毎に接続先サーバを分ける等して使ってます。tmuxセッションが残っていれば、自端末と踏み台サーバ間の通信は切れても問題ありません。

tmuxの構成要素

ここで、tmuxの構成要素について簡単に記載します。

設定ファイル

~/.tmux.confに設定を記述します。新規セッション作成時に読み込まれます。
最初は存在しませんので、デフォルトの設定をカスタマイズするような場合に自分で作成する必要があります。
CentOS6であればtmuxインストール後に/usr/share/doc/tmux-1.6/examples/以下に設定ファイルのサンプルが設置されますので参考にすると良いかもしれません。

tmuxのプロセス構成

tmuxはサーバ/クライアント構成となります。

• tmuxサーバ(セッション)
• tmux起動時に生成される、tmuxセッションを管理しているプロセス
• tmuxクライアント(pty/仮想端末)
• tmuxセッションへ接続(アタッチ)しているプロセス(pty)

画面構成要素

• セッション(Session)
• tmuxに管理される仮想端末全体を指す
• 各セッションは1つ以上のウィンドウを持つ
• ウィンドウ(Window)
• tmuxセッション内に開かれている1つの仮想端末の画面全体を指す
• ウィンドウは1つ以上のペインを持つ
• ペイン(Pane)
• 分割されたウィンドウの単位を指す
• ペインそれぞれが独立した擬似端末となる

実際の画面を元に示すと、青い枠がペイン、緑の枠がウィンドウ、青と緑を合わせてセッションを指します。

tmuxを使ってみる

文章での説明だとよくわからない部分も多いかもしれませんので、実際にtmuxを使ってみます。

tmuxのインストール

tmuxをインストールしてみます。
最新バージョン1.8のソースコードをダウンロードしてインストールすることもできますが、各OSのパッケージ管理ツールを利用してインストールするのが簡単です。

RHEL系LinuxであればEPELリポジトリにパッケージが存在しますのでyumでパッケージをインストールできます。

# yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/tmux-1.6-3.el6.x86_64.rpm

OS Xであればhomebrewからインストールできます。

# brew install tmux

以下ではMac OS X 10.7のiTermからCentOS 6.5のサーバへログインし、CentOS 6.5で起動したtmux 1.6で動作確認した内容を記載します。

tmuxの基本操作

起動中(アタッチしている)のtmuxを操作するには、多くの場合tmuxの制御を行うことを示すためのプレフィックスキーCtrl-b(デフォルト設定値)を入力し、それに続いて実行したい操作に対応するコマンドキーを入力する形でtmuxの内部コマンドを実行することになります。
どのキーがどの操作に対応しているかは Ctrl-b + ?を入力することで表示できます。

tmuxの起動

tmuxを起動してセッションを開始します。起動には以下のコマンドを実行します。

% tmux

または、

% tmux new-session

これでtmuxセッションが作成され、セッションにアタッチした状態になります。以下のような画面になります。

セッションの確認

ここで、起動しているtmuxのセッションについて確認してみます。前述の通り、tmuxにはtmux全体を管理しているセッションと、セッションに接続しているクライアントの2種類があります。

現在起動中のセッションを確認するにはtmux list-sessionsまたは tmux lsを実行します。左側の数字がセッション番号になります。以下の例ではセッション番号が0となっていることが分かります。

% tmux list-sessions
0: 1 windows (created Tue Feb 11 21:43:00 2014) [193x36] (attached)

現在起動中のセッションに接続されているクライアントを確認するにはtmux list-clientまたは tmux lscを実行します。

% tmux list-client
/dev/pts/1: 0 [37x193 xterm] (utf8)

セッションのデタッチ

セッションをデタッチするにはCtrl-b + dまたは Ctrl-b + : detach-clientを実行します。なお、回線が切断された時には自動でデタッチされます。
仮想端末が終了し、以下の出力とともに元の端末に戻ります。

[detached]
%

デタッチによって、tmuxセッションで実行中の処理を継続させたままクライアントを終了できます。再度そのセッションへアタッチすることで作業の続きを行うことができます。

セッションのアタッチ

アタッチするにはtmuxを起動するには tmux attachを実行します。attachの文字を全て入力せずとも tmux a等でもいけます。
複数のtmuxセッションを起動している場合は、-t [target-session]オプションで接続したいセッションを指定することができます。セッション番号は前述の tmux list-sessionsで参照することができます。
なお，ひとつのセッションに複数のクライアントをアタッチすることも可能です。-dを指定すると、そのセッションにアタッチしている他のクライアントはデタッチされます。

% tmux attach -t 0

セッションの削除

tmux kill-sessionで現在起動中のセッションを削除できます。-t [target-session]オプションを指定することで削除したいセッションを指定することができますが、指定しない場合は直近でアタッチしていたセッションが削除されます。

% tmux kill-session

全てのセッションを削除するには tmux kill-serverを実行します。

% tmux kill-server

ウィンドウの操作

新規ウィンドウ作成

セッションにアタッチした状態でCtrl-b + cまたは :new-windowを入力することで新規ウィンドウを作成できます。

画面下に0:zsh-に続いて 1:zsh*と表示されますが、これがそれぞれウィンドウとなります。現在選択されているウィンドウには *と表示されており、それ以外のウィンドウには -と表示されます。ウィンドウ名は Ctrl-b + :rename-window [window name]で指定できます。

ウィンドウの切り替え

Ctrl-b + [ウィンドウ番号]でウィンドウを切り替えることができます。
また、Ctrl-b + nで上の番号のウィンドウへ、Ctrl-b + pで下の番号のウィンドウへ切り替えることができます。 上記の画面上でCtrl-b + 0と入力すると、ウィンドウ番号0の画面が表示されます。

ウィンドウ一覧の表示

Ctrl-b + wで現在作成されているウィンドウの一覧が表示されます。
↑で ↓でウィンドウを選択して Enterキーで対象ウィンドウを表示させることもできます。

ウィンドウの削除

Ctrl-b + &と入力することで作成したウィンドウを削除できます。Confirm 'kill-window'? (y/n)というメッセージが出力されますので、yと入力するとウィンドウが削除されます。

ペインの操作

水平分割

Ctrl-b + "でウィンドウを水平に分割できます。これで以下のような画面構成になり、2つのペインが作成されます。

垂直分割

Ctrl-b + $でウィンドウを垂直に分割できます。これで以下のような画面構成になり、3つ目のペインが作成されます。

ペイン間の移動

ペイン間の移動は Ctrl-b + oで行います。
また、Ctrl-b + qまたは Ctrl-b + :display-panesで以下のようにペインのインジケータ(番号)を表示させることができ、Ctrl-b + q + インジケータ番号で指定したペインへ移動することもできます。
インジケータが表示される時間はデフォルトだと少々短いですが、Ctrl-b + :display-panes-time [time]で変更できます。単位はミリ秒なので、表示時間を1秒にしたい場合は1000と指定します。

以下ではインジケータ番号2のペインが選択されている状態ですが、Ctrl-b + qでインジケータ番号が表示されている間に 0を入力します。

インジケータ番号0のペインが選択されます。

ペイン分割解除

Ctrl-b + xでペイン分割を解除できます。

インジケータ番号0のペインが選択されている状態でCtrl-b + xを入力すると、画面下のステータスバーに kill-pane 0? (y/n)と表示されます。

画面下のステータスバーの kill-pane 0? (y/n)に対して yを入力するとインジケータ番号0のペインが削除され、以下のような画面になります。

他にも様々な機能がありますが、とりあえず上記あたりは最低限覚えておくべき項目かと思います。

おわりに

tmuxの使い方について基本的な部分をまとめてみました。
最初は使いづらい部分も多いかと思いますが、慣れると多少効率的に作業ができるようになると思います。
記載した機能以外にもコピー&ペーストやペインのリサイズなどの多くの機能があります。また、設定ファイルを利用してカスタマイズすることもできますので、賢者の設定ファイルを参考にいろいろ触ってみると良いかと思います。