2014-04-02

退職しませんでした

Life

こんにちは＠oko_changです。
昨日は私の誕生日だったのですが、たくさんのお祝いのコメントを頂き本当にありがとうございます！

毎年この時期はTwitterなどで退職しましたブログや入社しましたブログなどが賑わいます。
そんな私も最近までこっそり転職活動をしていたのですが、最終的に退職しないという決断をしました。
当初転職活動を始めたのは、今までと違った形でインフラエンジニアとして働いてみたいなと思った事がきっかけとなり、この点を転職先に求めていました。
その後、3月中旬くらいに別チーム（サービス開発をしているチーム）の同僚と送別会がてら飲んでるときに、彼のチームで働くというお誘いを受けました。
この提案は考えもしませんでしたし、私がもともと想像していたプランとは少し違いしましたが、自分にとっては良い経験になりそうだし、面白いチャレンジに思えたので、退職しないことを選びました。
退職しないという決断が正しいのかはまだ分かりませんが、この決断を正しくすることは自分にかかっていると思うので、これからしっかり正しい決断に育てていきたいと思います。

転職活動を始めてから、勉強会やコミュニティで知り合った方からのアドバイスを頂いたりしたのは大きな助けとなりました。
また、実際に転職先として考えていた企業で働くエンジニアの方にお話を頂く機会もあり、とても刺激を受けました。
退職の意思を伝えたときに応援してくれた方、引き留めてくれた方、ありがとうございます。

直接お礼をさせていただきたい方がいっぱいいますが、まずはこの場を借りてお礼をさせて頂きます。
これからもよろしくお願いします。

2014-03-24

ELBのConnection Drainingの動作をテストする

AWS awscli AWS CLI Tools

こんにちは＠oko_changです。
先日、ELBののConnection Draining機能がリリースされました。
Connection Drainingの機能については、こちらのブログに参考にして、動作テストはこちらのブログに記載されているように大きなダミーファイルを使えば良さそうです。

環境

リリースノートを見るとAWS CLIはConnection Drainingに対応しているようです。
1.3.2より前のバージョンをご使用の方はsudo pip install --upgrade awscliをして下さい。

AWS CLI 1.3.2
Amazon ElasticLoadBalancing CLI version 1.0.34.0 (API 2012-06-01)

テスト環境の作成

まず最初にテスト用のELBを作成します。

$ aws elb create-load-balancer \
--load-balancer-name okochang-elb \
--listeners Protocol=http,LoadBalancerPort=80,InstanceProtocol=http,InstancePort=80 \
--subnets subnet-28f4fd4a \
--security-groups sg-d1e3fcbd \
--region ap-northeast-1

$ aws elb configure-health-check \
--load-balancer-name okochang-elb \
--health-check Target="HTTP:80/index.html",Interval=30,Timeout=15,UnhealthyThreshold=5,HealthyThreshold=5 \
--region ap-northeast-1

次にテスト用EC2インスタンスを作成し、ELBの分散対象に加えます。

$ aws ec2 run-instances \
--image-id ami-b5c0b1b4 \
--security-group-ids sg-b72d31db \
--instance-type t1.micro \
--subnet-id subnet-28f4fd4a \
--private-ip-address 10.0.10.10 \
--key-name okochang-key \
--associate-public-ip-addres \
--region ap-northeast-1

$ aws elb register-instances-with-load-balancer \
--load-balancer-name okochang-elb \
--instances i-3a1f443d \
--region ap-northeast-1

テスト用EC2インスタンスにはWebサーバを構築して、ダミーファイルを作成しておきます。

# dd if=/dev/zero of=tempfile bs=10M count=50

動作確認

Connection Draining有効時

ELBは現在、作成するとデフォルトでConnection Drainingが有効になっています。
先ほどのリリースノートにあるとおりConnection Drainingには対応されているはずですが、describe-load-balancer-attributesを実行してもレスポンスは返ってきませんでした。

$ aws elb describe-load-balancer-attributes --load-balancer-name okochang-elb --region ap-northeast-1
{
    "LoadBalancerAttributes": {
        "CrossZoneLoadBalancing": {
            "Enabled": false
        }, 
        "AccessLog": {
            "Enabled": false
        }
    }
}

というわけで以下はElastic Load Balancing API Toolsを使って動作確認をしています。
先ほど作成したELBのConnection Drainingが有効になっている事が確認出来ます。

$ elb-describe-lb-attributes okochang-elb --region ap-northeast-1 --headers
CROSS_ZONE_LOADBALANCING  CROSSZONE_LOADBALANCING_ENABLED
CROSS_ZONE_LOADBALANCING  false
ACCESS_LOG  ACCESSLOG_ENABLED
ACCESS_LOG  false            
CONNECTION_DRAINING  CONNECTION_DRAINING_ENABLED  CONNECTION_DRAINING_TIMEOUT
CONNECTION_DRAINING  false                        300

以下のようにすると秒数を変更したりできます。

$ elb-modify-lb-attributes okochang-elb --connection-draining "enabled=true, timeout=1800" --region ap-northeast-1 --headers
CONNECTION_DRAINING  CONNECTION_DRAINING_ENABLED  CONNECTION_DRAINING_TIMEOUT
CONNECTION_DRAINING  true                         1800

それではテスト用のダミーファイルをダウンロードします。

$ curl -OL http://okochang-elb-625610288.ap-northeast-1.elb.amazonaws.com/tempfile

ダウンロード途中に以下のようにELBからインスタンスを外してみます。

$ elb-deregister-instances-from-lb okochang-elb --instances i-3a1f443d --region ap-northeast-1 --headers

elb-describe-instance-healthを実行してみると、STATEがInServiceで、DESCRIPTIONがInstance deregistration currently in progress.となっており、ELBから指定された秒数外れるのを待っている状態である事が分かります。

$ elb-describe-instance-health okochang-elb
INSTANCE_ID  INSTANCE_ID  STATE      DESCRIPTION                                     REASON-CODE
INSTANCE_ID  i-3a1f443d   InService  Instance deregistration currently in progress.  N/A

その後、きちんとダウンロードも無事に完了しました。

$ curl -OL http://okochang-elb-625610288.ap-northeast-1.elb.amazonaws.com/tempfile
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  500M  100  500M    0     0  2640k      0  0:03:13  0:03:13 --:--:-- 2974k

Connection Draining無効時

次はConnection Drainingを無効にしてテストします。

$ elb-modify-lb-attributes okochang-elb --connection-draining "enabled=false" --region ap-northeast-1 --headers
CONNECTION_DRAINING  CONNECTION_DRAINING_ENABLED  CONNECTION_DRAINING_TIMEOUT
CONNECTION_DRAINING  false                        300

以下のようにしっかりと無効になってる事を確認しておきます。

$ elb-describe-lb-attributes okochang-elb --region ap-northeast-1 --headers
CROSS_ZONE_LOADBALANCING  CROSSZONE_LOADBALANCING_ENABLED
CROSS_ZONE_LOADBALANCING  false
ACCESS_LOG  ACCESSLOG_ENABLED
ACCESS_LOG  false            
CONNECTION_DRAINING  CONNECTION_DRAINING_ENABLED  CONNECTION_DRAINING_TIMEOUT
CONNECTION_DRAINING  false                        1800

先ほど外したインスタンスをELBに戻しておきます。

$ elb-register-instances-with-lb okochang-elb --instances i-3a1f443d --region ap-northeast-1 --headers
INSTANCE_ID  INSTANCE_ID
INSTANCE_ID  i-3a1f443d

再度テスト用のダミーファイルをダウンロードします。

$ curl -OL http://okochang-elb-625610288.ap-northeast-1.elb.amazonaws.com/tempfile

先ほどと同様にインスタンスをELBから外します。

$ elb-deregister-instances-from-lb okochang-elb --instances i-3a1f443d --region ap-northeast-1 --headers
No instances currently registered to LoadBalancer

今度はすぐにELBから外れました。

$ elb-describe-instance-health okochang-elb
No instances currently registered to LoadBalancer

Connection Drainingを無効時はダウンロードが失敗しました。

$ curl -OL http://okochang-elb-625610288.ap-northeast-1.elb.amazonaws.com/tempfile
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 67  500M   67  337M    0     0  2739k      0  0:03:06  0:02:06  0:01:00 2821k
curl: (18) transfer closed with 170663064 bytes remaining to read

まとめ

無事に期待する動作を確認出来ました。
ELB配下のインスタンスをメンテナンスするときなど、運用時に助かる機能なので重宝しますね。
どうやらすでに作成されているELBはConnection Drainingは無効になってるみたいなのでタイミングを見て有効にしておきたいですね。

その後

AWS CLIでConnection Drainingが使えないなーと悩んでいたら＠j3tm0t0さんから以下のようにアドバイス頂きました。

@oko_chang --debug するとレスポンスにはちゃんと返ってるようですね。このあたりに足してあげると出ると思われます。 https://t.co/r9FeLqtOjv
— moto (@j3tm0t0) 2014, 3月 23

@oko_chang https://t.co/iRmOcu3aEN を site-packages/botocore/data/aws/elb/ に置いたら、出るようになると思います。
— moto (@j3tm0t0) 2014, 3月 23

debugオプションをつけてレスポンスが返ってくることと、その後Connection Drainingの情報が取得出来ました！
＠j3tm0t0さんありがとうとうございます！

$ aws elb describe-load-balancer-attributes --load-balancer-name okochang-elb --region ap-northeast-1
{
    "LoadBalancerAttributes": {
        "ConnectionDraining": {
            "Enabled": false, 
            "Timeout": 1800
        }, 
        "CrossZoneLoadBalancing": {
            "Enabled": false
        }, 
        "AccessLog": {
            "Enabled": false
        }
    }
}

参考リンク

2014-03-22

VPC内のELBが使用しているローカルIPアドレスをEC2インスタンス起動時に指定してみる実験

AWS

こんにちは＠oko_changです。
VPC内でELBを使用する場合、ELBは指定されたサブネット内のローカルIPアドレスを使用します。
なんとなく気になったので、ELBがローカルIPアドレスを使用した後にそのアドレスを指定してEC2インスタンスを起動した場合の動作を確認してみました。

環境

aws-cli 1.3.2

確認手順

※VPCとVPCサブネットは事前に作成しておきます。
まず最初に、VPC内でELBを作成します。

$ aws elb create-load-balancer \
--load-balancer-name okochang-elb \
--listeners Protocol=http,LoadBalancerPort=80,InstanceProtocol=http,InstancePort=80 \
--subnets subnet-28f4fd4a \
--security-groups sg-d1e3fcbd \
--region ap-northeast-1

ELBのヘルスチェックを設定します。

$ aws elb configure-health-check \
--load-balancer-name okochang-elb \
--health-check Target="HTTP:80/index.html",Interval=30,Timeout=15,UnhealthyThreshold=5,HealthyThreshold=5

負荷分散対象のEC2インスタンスを起動します。

$ aws ec2 run-instances \
--image-id ami-b5c0b1b4 \
--security-group-ids sg-b72d31db \
--instance-type t1.micro \
--subnet-id subnet-28f4fd4a \
--private-ip-address 10.0.10.10 \
--key-name okochang-key \
--associate-public-ip-addres

ELBに起動したEC2インスタンスを分散対象として設定します。

$ aws elb register-instances-with-load-balancer \
--load-balancer-name okochang-elb \
--instances i-3ebce539

負荷分散対象のEC2インスタンスにWebサーバをインストールし、ELB（10.0.10.17）からアクセスされていることを確認します。

# yum install httpd -y
# vi /etc/httpd/conf/httpd.conf 
# echo "Hello World" > /var/www/html/index.html
# httpd -t
# chkconfig httpd on
# service httpd start
# tail -f /var/log/httpd/access_log 
2014-03-21 23:31:46 JST 340 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0]
2014-03-21 23:32:16 JST 348 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0]
2014-03-21 23:32:46 JST 340 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0]
2014-03-21 23:33:16 JST 338 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0]
2014-03-21 23:33:46 JST 326 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0]
2014-03-21 23:34:16 JST 352 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0]
2014-03-21 23:34:46 JST 324 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0]
2014-03-21 23:35:16 JST 338 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0]
2014-03-21 23:35:46 JST 322 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0]
2014-03-21 23:36:16 JST 350 10.0.10.17 - [GET /index.html HTTP/1.1] 200 12 [-] [ELB-HealthChecker/1.0]

ELBが使用しているIPアドレスと同じIPを指定して起動します。
やはりIPアドレスが使用中になって起動出来ませんね。

$ aws ec2 run-instances \
--image-id ami-b5c0b1b4 \
--security-group-ids sg-b72d31db \
--instance-type t1.micro \
--subnet-id subnet-28f4fd4a \
--private-ip-address 10.0.10.17 \
--key-name okochang-key \
--associate-public-ip-addres

A client error (InvalidIPAddress.InUse) occurred when calling the RunInstances operation: Address 10.0.10.17 is in use.

ちなみにELBが使用しているネットワークインターフェースの情報も以下のようにdescribe-network-intaerfacesで確認する事が出来ます。

$ aws ec2 describe-network-interfaces --filters Name=description,Values="ELB okochang-elb"

感想

VPC内のローカルIPアドレスを意識しない運用をしている場合は特に問題にならないと思いますが、ローカルIPアドレスに何かしら意味を持たせている場合は注意しておいた方が良いかもしれません。

2014-03-21

FluentdからElasticsearchに転送してKibanaで可視化する

CentOS Fluentd Kibana Elasticsearch

こんにちは＠oko_changです。
前回はFluentdについて記載しましたが、今回はFluentdからElasticsearchにログを転送してKibanaで可視化するまでをまとめておきたいと思います。

環境概要

前回の環境にElasticsearchとKibanaを追加するイメージです。

CentOS6.5

f:id:okochang:20140322183510p:plain

Elasticsearchのセットアップ

インストールは公式にあるようにYumのリポジトリを追加して簡単に出来ます。
javaが必要なので、それもインストールしておきます。

# rpm --import http://packages.elasticsearch.org/GPG-KEY-elasticsearch
# cat >> /etc/yum.repos.d/elasticsearch.repo <<'EOF'
[elasticsearch-1.0]
name=Elasticsearch repository for 1.0.x packages
baseurl=http://packages.elasticsearch.org/elasticsearch/1.0/centos
gpgcheck=1
gpgkey=http://packages.elasticsearch.org/GPG-KEY-elasticsearch
enabled=1
EOF
# yum install elasticsearch java-1.7.0-openjdk

インストールが終わったら起動して、動作確認してみます。

# chkconfig elasticsearch on
# service elasticsearch start
# curl -X GET http://localhost:9200/
{
  "status" : 200,
  "name" : "Knickknack",
  "version" : {
    "number" : "1.0.1",
    "build_hash" : "5c03844e1978e5cc924dab2a423dc63ce881c42b",
    "build_timestamp" : "2014-02-25T15:52:53Z",
    "build_snapshot" : false,
    "lucene_version" : "4.6"
  },
  "tagline" : "You Know, for Search"
}

Kibanaのセットアップ

Kibanaもセットアップは簡単です。
公式ページから圧縮ファイルをダウンロードして、任意のディレクトリに配置します。
KibanaはJavascriptで動作しており、アクセスされるブラウザからElasticsearchがListenしているポートに接続出来る必要があります。
ちょっとその構成が気持ち悪いので、今回はconfig.js内のelasticsearch:の設定を以下のようにし、Apacheのリバースプロキシ経由でアクセスするようにしたいと思います。
※Apacheの設定は後述。

# useradd kibana
# passwd kibana
# chmod +x /home/kibana
# su - kibana
$ curl -LO https://download.elasticsearch.org/kibana/kibana/kibana-3.0.0milestone5.tar.gz
$ tar zxvf kibana-3.0.0milestone5.tar.gz 
$ ln -s /home/kibana/kibana-3.0.0milestone5 ./kibana
$ vi /home/kibana/kibana/config.js 
$ grep okochang /home/kibana/kibana/config.js 
    elasticsearch: "http://kibana.okochang.com/es/",
# exit

Apache

Apacheは、以下のように名前ベースのVirtualHostを設定しています。
さらにElasticsearchへの接続用に/es/をリバースプロキシ構成にしています。
必要に応じてDigest認証の設定も追加します。

# yum install httpd
# htdigest -c /etc/httpd/conf/htdigest "Required authentication" okochang
# vi /etc/httpd/conf.d/vhosts.conf
# cat /etc/httpd/conf.d/vhosts.conf 
NameVirtualHost *:80
<VirtualHost *:80>
    DocumentRoot /home/kibana/kibana
    ServerName kibana.okochang.com
    ProxyPass /es/ http://localhost:9200/
    ProxyPassReverse /es/ http://localhost:9200/
    CustomLog logs/access_log custom
    ErrorLog logs/error_log
    Options FollowSymLinks
    <Location />
        AuthType Digest
        AuthName "Required authentication"
        AuthUserFile /etc/httpd/conf/htdigest
        require valid-user
        Satisfy any
        Order deny,allow
        Deny from all
        Allow from 127.0.0.1
    </Location>
</VirtualHost>
# httpd -t
# chkconfig httpd on
# service httpd start

ブラウザからKibanaにアクセス

以下のように管理画面のトップページが表示されます。
f:id:okochang:20140320012023p:plain

fluent-plugin-elasticsearch

最後に転送元のサーバでfluent-plugin-elasticsearchをインストールして、Elasticsearchに転送する設定をします。
※以下は前回設定行った設定に追記しております。

# sudo yum install gcc gcc-c++ libcurl-devel
# /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-elasticsearch --no-ri --no-rdoc
# vi /etc/td-agent/td-agent.conf
# cat /etc/td-agent/td-agent.conf
## Input
<source>
  type tail
  path /var/log/httpd/access_log 
  format /^(?<date>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2} \w{3}) (?<processing_time>[^ ]*) (?<remote>[^ ]*) (?<user>[^ ]*) \[(?<method>.*)\] (?<status>[^ ]*) (?<size>[^ ]*) \[(?<referer>[^ ]*)\] \[(?<agent>.*)\]/
  pos_file /var/log/td-agent/tmp/apache.access.log.pos
  tag apache.access
</source>

## Output
<match apache.access>
  type copy
  <store>
    type file
    path /var/log/td-agent/apache.access
    time_slice_format %Y%m%d
    time_format %Y%m%dT%H%M%S%z 
  </store>
  <store>
    type forward
    send_timeout 60s
    recover_wait 10s
    heartbeat_interval 1s
    <server>
      name fluentd.okochang.com
      host 10.0.1.200
      port 24224
    </server>
  </store>
  <store>
    type elasticsearch
    host 10.0.1.200
    port 9200
    type_name access_log
    logstash_format true
    logstash_prefix apache_access
    logstash_dateformat %Y%m
    flush_interval 10s
  </store>
</match>

動作確認

管理画面トップのSample Dashboardにアクセスすると、以下のようにWebサーバのアクセスログがたまっていることが分かります。
f:id:okochang:20140320012035p:plain

追記（2014年3月22日）

Elasticsearchのsは小文字が正解です。

Sは小文字！
— Jun Ohtani (@johtani) 2014, 3月 22

ご指摘ありがとうございます、修正しました！

感想

セットアップは思ったよりも簡単ですね。
管理が画面もカッコイイし、色々なログをElasticsearchに保存して可視化したくなります。

参考リンク

2014-03-17

FluetndでApacheのアクセスログを集約する

こんにちは＠oko_changです。
すでに色々な方がまとめていますが、やっぱり自分なりにブログにまとめたほうが覚えやすいので今回はfluentdについて書きます。

Fluentdとは？

こちらを見るのがやはり早いですかね。

環境

どちらもCentOS 6.5を使用しています。
今回はFluentdを使ってローカルのファイルに保存しつつ、転送先にも保存するまで確認します。
f:id:okochang:20140320100028p:plain

転送元環境

インストール前

Fluentdについては色々な方がブログとかでもまとめているので、そちらを参考になりますが、公式ドキュメントもとても充実していました。
ここにFluentdをインストール前にするべき事が記載されていますので、設定します。
※limits.confとsysctl.confにそれぞれ追記する

# vi /etc/security/limits.conf
root soft nofile 65536
root hard nofile 65536
* soft nofile 65536
* hard nofile 65536

# vi /etc/sysctl.conf
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 10240    65535

# reboot

Apacheの設定

今回はテスト用のログファイルとしてApacheのアクセスログを使用します。
テスト環境のアクセスログのフォーマットは以下のように変更してあります。
また、td-agent（Fluentd安定版の配布パッケージ）にアクセス出来るようにログディレクトリの権限を修正します。

# grep "custom" /etc/httpd/conf/httpd.conf 
LogFormat "%{%Y-%m-%d %T %Z}t %D %a %u [%r] %s %b [%{Referer}i] [%{User-Agent}i]" custom
CustomLog logs/access_log custom
# chmod 755 /var/log/httpd

td-agentのインストール、設定

次にtd-agentをインストールします。
公式ドキュメントに記載してあるようにインストールスクリプトを使って簡単に導入が可能です。

# curl -L http://toolbelt.treasuredata.com/sh/install-redhat.sh | sh

設定方法も公式ドキュメントのconfig-file、input-plugin、output-pluginをひと通り読むと分かりやすかったです。
Apacheデフォルトのログ形式であればテンプレートがあるみたいですが、今回は少しカスタマイズしているため、正規表現のチェックをこちらでやりました。
また、自分のローカルと別のFluetndサーバに転送するため、以下のような設定をしています。

# vi /etc/td-agent/td-agent.conf
## Input
<source>
  type tail
  path /var/log/httpd/access_log 
  format /^(?<date>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2} \w{3}) (?<processing_time>[^ ]*) (?<remote>[^ ]*) (?<user>[^ ]*) \[(?<method>.*)\] (?<status>[^ ]*) (?<size>[^ ]*) \[(?<referer>[^ ]*)\] \[(?<agent>.*)\]/
  pos_file /var/log/td-agent/tmp/apache.access.log.pos
  tag apache.access
</source>

## Output
<match apache.access>
  type copy
  <store>
    type file
    path /var/log/td-agent/apache.access
    time_slice_format %Y%m%d
    time_format %Y%m%dT%H%M%S%z 
  </store>
  <store>
    type forward
    send_timeout 60s
    recover_wait 10s
    heartbeat_interval 1s
    <server>
      name fluentd.okochang.com
      host 10.0.1.200
      port 24224
    </server>
  </store>
</match>

上記で設定したディレクトリなどを作成して、自動起動の設定をしたらデーモンを起動します。

# mkdir /var/log/td-agent/tmp
# chown td-agent.td-agent /var/log/td-agent/tmp
# chkconfig td-agent on
# service td-agent start

転送先環境

転送元環境と同じようにインストール前の作業をしたら、td-agentを同じくインストールします。
td-agent.confは以下のように設定しました。

# curl -L http://toolbelt.treasuredata.com/sh/install-redhat.sh | sh
# vi /etc/td-agent/td-agent.conf
<source>
  type forward
  port 24224
  bind 0.0.0.0
</source>

<match apache.access>
  type file
  path /var/log/fluentd/all_access.log
  time_slice_format %Y%m%d
  time_format %Y%m%dT%H%M%S%z
</match>

さらに必要なディレクトリを作成し、自動起動の設定をしたら起動します。

# mkdir /var/log/fluentd
# chown td-agent.td-agent /var/log/fluentd/
# chkconfig td-agent on
# service td-agent start

動作確認

以下のようにログが出力されました。

転送元のログファイル

# tail -f /var/log/td-agent/apache.access.20140317.b4f4bb855c8fbaa5a 
20140317T094432+0900	apache.access	{"date":"2014-03-17 09:44:32 JST","processing_time":"372","remote":"202.215.74.59","user":"-","method":"GET / HTTP/1.1","status":"304","size":"-","referer":"-","agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:27.0) Gecko/20100101 Firefox/27.0"}

転送先のログファイル

# tail -f /var/log/fluentd/all_access.log.20140317.b4f4bb675d4776d09
20140317T094432+0900	apache.access	{"date":"2014-03-17 09:44:32 JST","processing_time":"372","remote":"202.215.74.59","user":"-","method":"GET / HTTP/1.1","status":"304","size":"-","referer":"-","agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:27.0) Gecko/20100101 Firefox/27.0"}

まとめ

fluetndは色々な方がブログにそれちらも参考になるけど、やっぱり公式のドキュメント読むとさらに理解が深まりますね。

参考リンク

2014-03-15

mod_evasiveはEPELからインストール出来るみたい

CentOS

こんにちは＠oko_changです。
mod_evasiveはDos/DDos/brute forceアタックに有効なApacheモジュールですが、EPELから簡単にインストール出来るようなので備忘録としてまとめておきます。

環境

CentOS 6.5
Apache 2.2.15

導入手順

EPELリポジトリの追加

# rpm http://ftp.riken.jp/Linux/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm

mod_evasiveのインストール

# yum --enablerepo=epel install mod_evasive

ロックファイルを配置するディレクトリを作成します。

# mkdir /var/lock/mod_evasive
# chown apache.apache /var/lock/mod_evasive

少し変えてるけど設定ファイルはデフォルトだとだいたいこんな感じです。

# cat /etc/httpd/conf.d/mod_evasive.conf 
LoadModule evasive20_module modules/mod_evasive20.so

<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        2
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10
    DOSLogDir           "/var/lock/mod_evasive"
    #DOSWhitelist   127.0.0.1
</IfModule>

Apacheを再起動して有効化

# service httpd restart

テスト

テスト用のスクリプトで動作確認ができます。

# perl /usr/share/doc/mod_evasive-1.10.1/test.pl 
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden

感想

ソースインストールでも簡単だけど、EPELからインストール出来るとさらに簡単なので良い。

2014-03-13

Vagrant、Chef Soloでの環境構築からserverspecでのテストまでをJenkinsでビルド

Chef CentOS serverspec Jenkins Vagrant

こんにちは＠oko_changです。
今回の内容は前回の続きになっており、Packer、Vagrant、Chef Soloでの環境構築からserverspecまでのテストをJenkinsでビルドをしてみたいと思います。

環境準備

OSXにJenkinsをインストールする。

$ brew install jenkins

Jenkinsの設定ファイルをカスタマイズする（-Dfile.encoding=utf-8を追加）。

$ vi /usr/local/opt/jenkins/homebrew.mxcl.jenkins.plist

Jenkinsをlaunchctlで自動起動するため、以下のように実行する。

$ ln -sfv /usr/local/opt/jenkins/*.plist ~/Library/LaunchAgents
$ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist

localhostに接続すると無事にJenkinsにアクセスが出来る。

http://localhost:8080/

Jenkinsの設定

Jenkinsのプラグイン管理画面からGit Pluginをインストールする（インストール後再起動）。
f:id:okochang:20140313011840p:plain
新規ジョブ作成からジョブ名を指定してフリースタイル・プロジェクトのビルドにチェックしてOKをクリック。
f:id:okochang:20140313011857p:plain
リポジトリにてGitを選択し、SSHの設定、ビルド時に実行するシェルスクリプトを書いておきます。
f:id:okochang:20140313011908p:plain
f:id:okochang:20140314011417p:plain
今回書いたシェルスクリプトは以下のとおりです。

#!/bin/bash
source ~/.bash_profile
rvm use 2.1.0 
vagrant up --provider aws 
vagrant ssh-config --host=serverci.okochang.com > vagrant-ssh.conf
sed -i -e "1d" vagrant-ssh.conf
bundle exec knife solo bootstrap serverci.okochang.com -F vagrant-ssh.conf 
bundle exec rake ci:setup:rspec spec
rm vagrant-ssh.conf
vagrant destroy --force serverci.okochang.com

ジョブが登録されたらビルドを実行して、成功したら動作確認完了。
f:id:okochang:20140314011432p:plain

感想

自分できちっとまとめたので、少し理解が深まったかな。

参考リンク

http://d.hatena.ne.jp/naoya/20130520/1369054828
http://d.hatena.ne.jp/idesaku/20110730/1311997411
http://qiita.com/makoto_kw/items/cbe93d4ebbc35f3b43fd
http://qiita.com/skinoshita/items/6862b4a6726fc3b24944
http://dev.classmethod.jp/smartphone/iphone/jenkins-cocoapods/
http://megadreams14.com/?p=27
http://qiita.com/h7kayama/items/318618c1863e866457cb
https://groups.google.com/forum/#!topic/vagrant-up/ExFet5jMomU