2013年3月5日火曜日

kuboxをSPDYに対応させました(nginx)

SPDY(スピーディー)は、Googleが提唱し、現在標準化作業が進められている通信プロトコルの一つ。

https://blog.kubox.info(警告がでます)

詳細はSPDYメモがよく纏められています。

NginxをSPDYに対応させる


NginxはSPDYに1.3以上でないと対応しおらず、現状1.3はDev向けなのでサービスでの利用は推奨されていません。
なのでこのサイトのSSLもいつおかしくなるかわかりません。。。
自己証明でも可能です。

Nginx1.3のDevはインストールページからダウンロード可能です。
Nginx ダウンロード

SPDYはSSLでの利用前提で開発されている(らしい)のでOpenSSL1以上が必須になっています。
http://www.openssl.org/source/

ヘッダーファイルが欲しいだけなので既存のOpenSSL0.9は消さなくても大丈夫です。
ダウンロードしたOpenSSLを適当なところで展開だけ済ませておいてください。今回は/usr/local/src配下に展開されたとします。

Nginx1.3にSPDYのパッチを当てます
nginx1.3# wget http://nginx.org/patches/spdy/patch.spdy.txt
nginx1.3# patch -p1 < patch.spdy.txt


Nginx1.3のconfigureオプションにsslとSPDYを追加します。
このサーバにはport80でこのBlogがNginxで動いているのでprefixでディレクトリを分けてます。
これでstableとdevを共存させることができます。

./configure \
--prefix=/usr/local/nginx-spdypatch-1.3.13 \
--with-openssl=/usr/local/src/openssl-1.0.1e \
--with-http_ssl_module \
--with-http_spdy_module \


nginx.confにSPDYの設定とSSLの設定を追記します。

server {
                listen 443 ssl spdy default_server;
                ssl_certificate /usr/local/nginx-spdypatch-1.3.13/crt/server.crt;
                ssl_certificate_key   /usr/local/nginx-spdypatch-1.3.13/crt/server.key;
                ssl on;
                ssl_session_timeout 5m;
                ssl_protocols SSLv2 SSLv3 TLSv1;
                ssl_ciphers HIGH:!aNULL:!MD5;
                ssl_prefer_server_ciphers on;

                spdy_max_concurrent_streams 100;
                spdy_streams_index_size     32;
                spdy_recv_timeout           30s;
                spdy_keepalive_timeout      3m;
                spdy_headers_comp           9;
....

}


別途initスクリプトを置くのはめんどくさいので手動で起動します。
/usr/local/nginx-spdypatch-1.3.13/sbin/nginx -c /usr/local/nginx-spdypatch-1.3.13/conf/nginx.conf


ブラウザがChromeであればエクステンションで確認できます。
SPDY indicator

URLにchrome://net-internals/#spdyを入力することでも確認できます。



SPDYの動作が確認できない場合はログには特にでないので、OpenSSLのバージョンnginxのconfigureオプションなどを確認してみてください。

2013年3月1日金曜日

Chef Practice :: 環境が異なっても同じレシピを使うパターン1 #opschef

dev、staging、productionとそれぞれの環境が異なる事が殆どです。

これらの環境ごとにCookbookやrecipeを分けるのも1つの方法ですが冗長になる運用コストが高いので可能な限り1つのrecipeにまとめれたほうがよいです。

Chef-serverを使うことでこの環境の差は比較的用意に乗り越えることができます。

environment


environmentでそれぞれの環境分作りノードを予め割り当てておきます。

recipe内からはnode.chef_environmentでenvironmentを取得できます。

if node.chef_environment =~ /staging|production/

else

end


environmentはchef-client実行時に"chef-client -E Production"と実行している場合は注意してください。
この場合Attributesのchef_environmentとして登録されます。

if node[:chef_environment] =~ /staging|production/

else

end


environmentとtemplates


templates利用する際はrecipe内でnode.chef_environmentを書くよりも環境ごとにtemplatesを準備します。


template "/etc/passwd" do
source "passwd." + node.chef_environment + "conf.erb"
end


attributesとenvironmentとtemplates



templatesを環境ごとにつくらずattributesにまとめる方法です。
ex)attributes/default.rb

default["passwd"]["open"] = [
"root:x:0:0:root:/root:/bin/bash",
"bin:x:1:1:bin:/bin:/sbin/nologin",
"daemon:x:2:2:daemon:/sbin:/sbin/nologin",
...


ex)recipes/default.rb


template "/etc/passwd" do
mode 00644
source "/etc/passwd.erb"
if node[:chef_environment] =~ /staging|production/

else

end
end