Let’s Encryptに変更

深い理由はないけどStartSSLからLet’s Encryptに変更
とりあえず動いているからOKだけどハマッタ^^;;

Let’s Encryptとは

Mozilla、アカマイ、シスコ、Facebookがサポートする認証局です。
無料でTLSを取得出来る事が出来るサービスです。
StartSSLとほぼ一緒ですがコマンドから申請ができるのが大きく違います。

2016 03 08 15 41 12

まだPublic βですが個人用blogだから問題ないしということで証明書が切れる前に入れ替えます。

スクリプト準備

GitHubで公開されているのでそちらからcloneします
Amazon Linuxだとはまります。
CentOS 7系なら問題無くそのスクリプトで走ります。

Let’s Encrypt Client on Amazon Linux – No module named _cffi_backendを参考に私は下記の通りやりました。

cd ~/git
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
git checkout amazonlinux
git pull

スクリプト実行

Apacheとかだったらスムーズに行くかもしれないけどh2oなのでってググったら
Using H2O with Let’s Encryptなんてページが!!!
作者がやり方を公開してくれている!!!有り難い。
この通りに素直にやっていく

./letsencrypt-auto certonly –webroot \
–webroot-path $DOCROOT \
–email $EMAIL \
–domain $HOST1

私は環境変数ではなく素直に埋め込みました^^;;

そしたら

IMPORTANT NOTES:
– Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/www.barasu.org/fullchain.pem. Your cert will
expire on 2016-06-06. To obtain a new version of the certificate in
the future, simply run Let’s Encrypt again.
– If you like Let’s Encrypt, please consider supporting our work by:

Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

コマンドラインからだけで証明書も取れるのはかなり便利。

でも、2016年6月6日に切れるのね・・・これはこれで面倒だな・・・
切れる前に対応しないと・・・

h2o設定変更

設定変更はcertificate-fileとkey-fileの両方を書き換えるだけ
これでh2oを再起動します。 “Let’s Encryptに変更” の続きを読む

AWSにnaveでnode.js環境を構築してみる

C言語より高速なJavaScriptによるバイナリ操作が話題を読んでまとめると

  • JavaScriptは Cよりも速くできるよ。
  • その為には、実行エンジン(V8)がすぐ消化できるようなコードを書くべし。

とうい風に私は感じたので・・・これからはJavaScriptの時代が来るの?

やってみないとわからないのでEC2上で構築してみた。 “AWSにnaveでnode.js環境を構築してみる” の続きを読む

無くならないことになっている

6/20に発生した大規模障害に関するお詫びとお知らせには驚いた。

障害発生以来、弊社ならびに外部専門業者を交え、データ復旧を試み続けて参りました。しかしながら、極めて遺憾ではございますが、データ復旧を行うことは不可能と判断いたしました。

不可能って・・・
私はファーストサーバ使ってないので被害はなかったですが、この障害がAWSだった日には・・・

ユーザだったらふざけるなぼけ!!!と言いたいけどエンジニアの端くれだから可能性はゼロではないのは知っているし・・・
ストレージは吹っ飛ばないことになっているというようなシステム多い気がします。

基本なんだけど「バックアップはちゃんと取る」に限るよね。

「ファイルサーバのバックアップをテープで取りましょう」なんて今はなかなかいえないよなぁ。
火事とか地震とかでのレイヤー0の障害ではテープだけではカバーしきれないし “無くならないことになっている” の続きを読む

Moshを利用してみる

近頃はやりのMosh: the mobile shellをインストールしてみた
MoshとはSSHに比べてレスポンスがいいと言われています。
SSHで困っているか?と言われると困っていないんだけど入れてみる。

Mac側

brew install mobile-shell

brew search mosh とかすると出てきますがそれは罠です!!!
mobile-shellを入れましょう。

EC2側(Amazon Linux AMI release 2012.03)
環境の準備

sudo yum -y install git autoconf automake gcc gcc-c++ make
sudo yum -y –enablerepo=epel install boost-devel zlib-devel ncurses-devel protobuf-devel

ソースをgitより持ってくる

git clone git://github.com/keithw/mosh.git

コンパイル

cd mosh
./autogen.sh
./configure
make
sudo make install

Security Security Groupsの変更
UDPの60000 – 61000は開けましょう。
開けないとはまります^^;;

Amazon Linuxでmoshをそのまま実行した。

Macからつないでみる。

mosh hoge.ap-northeast-1.compute.amazonaws.com

2012 05 07 01

普通につながった。
これで終了^^;;

SSHよりレスポンスが良いと言われていますが体感はできませんでした。
たぶんTokyo Regionだからかな。
US EASTやSão Pauloあたりだとだいぶ違いがわかるのだろうなぁ。

そのままMacBook Airの蓋を閉めてSleepしても復帰時にちゃんと接続し直すらしい
コレは便利だと思う。実際はテストしていないからテストしてみます。

SSHに変わるところまでいくのかな?
Windows版のクライアントが出たら広がるような気がする。
Prompt App
カテゴリ: ユーティリティ
価格: ¥700

が対応してくれたらかなりうれしいんだけどなぁ

追記
-i や -l を効かそうとすると下記のコマンドを入力

mosh –ssh=”ssh -i .ssh/key” ec2-user@hoge.ap-northeast-1.compute.amazonaws.com

Auto Scalingで起動するAMI変更手順

新規のLaunch configを作成する。

$ as-create-launch-config AS20120101 –image-id ami-xxxx –instance-type t1.micro –region ap-northeast-1 –group “xxx-YYY” –key xxxx-key

Launchの確認

$ as-describe-launch-configs –region ap-northeast-1
LAUNCH-CONFIG AS201201 ami-yyyy t1.micro
LAUNCH-CONFIG AS20120101 ami-xxxx t1.micro

Scaling GroupのUpdate

$ as-update-auto-scaling-group WP-AS –launch-configuration AS20120101 –region ap-northeast-1

Scaling Groupの確認

$ as-describe-auto-scaling-groups –region ap-northeast-1
AUTO-SCALING-GROUP WP-AS AS20120101 ap-northeast-1b,ap-northeast-1a barasuLB 1 3 1
INSTANCE i-0517c605 ap-northeast-1b InService Healthy

古いLaunchの削除

$ as-delete-launch-config AS201201 –region ap-northeast-1
Are you sure you want to delete this launch configuration? [Ny]

削除後Launchの確認

$ as-describe-launch-configs –region ap-northeast-1
LAUNCH-CONFIG AS20120101 ami-22a81e23 t1.micro

これでAuto Scalingで起動するAMIの変更が完了です。

nginx設定変更

今まではaccess.logの表示がELBからのaccessと言うことでRemote_AddressはELBのIP(Private IP)になっていました。
10.x.x.x これだとさっぱりわかんねー

10.150.126.145 – – [25/Jan/2012:08:43:11 +0900] “GET /wp-content/plugins/wptouch/themes/default/style.css HTTP/1.1” 200 47051 “https://www.barasu.org/pc/windows/2877.html” “Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3” “xxx.xxx.xxx.xxx, 10.156.115.4”

確かにaccess.logにReal IPも埋め込まれいるけどいろいろ面倒だよねぇ。
WordPress上のコメントでは

ELBはX-Forwarded-Forのサポートをしているということでnginx側で設定変更を行ってみた。

参考URLは[Amazon][ELB][EC2][Nginx] ELBとNignxを利用した場合の注意点と解決策

nginxはyumで入れたので–with-http_realip_module付きでコンパイルされているか確認

nginx -Vで一覧表示されます。

nginx version: nginx/0.8.54
built by gcc 4.4.5 20110214 (Red Hat 4.4.5-6) (GCC)
TLS SNI support enabled
(略) –with-http_ssl_module –with-http_realip_module –with-http_addition_module (略)’

もともと–with-http_realip_moduleがついていたので設定だけの書き換えでOK

/etc/nginx/nginx.confに下記2行を追加

set_real_ip_from 10.0.0.0/8;
real_ip_header X-FORWARDED-FOR;

set_real_ip_from ではEBLのIPレンジを書きます。面倒なので10.0.0.0/8にしました。
real_ip_header X-FORWARDED-FOR; にはReal IPのHTTPヘッダーフィールドを書きます。

これでnginxのサービス再起動を行って終了

これでaccess.logにもちゃんとRemote_AddressはGlobal IPが表示されます。

yyy.yyy.yyy.yyy – – [25/Jan/2012:13:05:11 +0900] “GET /wp-content/plugins/jquery-colorbox/themes/theme1/images/border.png HTTP/1.1” 200 112 “https://www.barasu.org/diary/7115.html” “Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3” “yyy.yyy.yyy.yyy”

Auto Scalingで遊んでみる。

Auto Scalingとは

お客様が定義する条件に応じて、Amazon EC2 の能力を、自動的に縮小・拡張することができます。

拡張よりも縮小が自動でできることがありがたい。

Auto Scalingの設定はAmazon Management ConsoleからGUIで設定することが現在できませんのでツールの用意を行います。

brewで下記コマンドを投入したらOK

$ brew install auto-scaling

viva brew!!!ってな感じです。

Auto Scalingの流れは下記のようになってます。

Amazon EC2/S3/EBS クラウドコンピューティングによる仮想サーバ構築

のP.60 AutoScalingの設定に詳しく書かれています。

  1. スケールアウト時に起動するAMIを指定
  2. インスタンスの最小・最大数、ゾーンを指定する「グループ」を設定
  3. スケールアウトを実行するトリガとなるしきい値を設定

まず、スケールアウト時に起動するAMIを指定

as-create-launch-config Launch設定名 –image-id AMIID –instance-type インスタンスのタイプ –group セキュリティグループ –key キーペア名 で設定します。

下記の設定は AMI(ami-xxxxxx)をMicro Instanceで東京Regionにて起動する設定。

$ as-create-launch-config AS201201 –image-id ami-xxxxxx –instance-type t1.micro –region ap-northeast-1 –group “XXXXXXX” –key XXXXXX-key

「OK-Created launch config」というメッセージが表示されます。

launch configが正しく設定されたかは下記コマンドで表示させます。

$ as-describe-launch-configs –region ap-northeast-1
LAUNCH-CONFIG AS201201 ami-xxxxxx t1.micro

Launch名が表示されたら正しく設定されています。

続いて「インスタンスの最小・最大数、ゾーンを指定する「グループ」を設定」を行います。

as-create-auto-scaling-group AutoScalingグループ名 –launch-configuration Launch設定名 –availability-zones 配置したいAvailabilityZode名 –load-balancers ロードバランサー名 –max-size 最大起動インスタンス数 –min-size 最小起動インスタンス数 –region 起動するRegion

$ as-create-auto-scaling-group WP-AS –launch-configuration AS201201 –availability-zones=ap-northeast-1a,ap-northeast-1b –load-balancers barasuLB –max-size 3 –min-size 1 –region ap-northeast-1

Auto Scaling Groupが正しく設定されたかは下記コマンドを入力します。

$ as-describe-auto-scaling-groups –region ap-northeast-1
AUTO-SCALING-GROUP WP-AS AS201201 ap-northeast-1b,ap-northeast-1a barasuLB 1 3 1
INSTANCE i-0fff2e0f ap-northeast-1a InService Healthy AS201201

Auto Scaling Groupが設定された瞬間に min-sizeが1以上であればその数自動的に登録したAMIが起動します。起動後にLoadBalancer配下に自動的に入ります。

min-seize が1以上であれば障害発生してサーバ(instance)が落ちても自動的に別のサーバが起動しLoadBalancer配下に入りることになります。単純に落ちないシステムが簡単に構築可能*^o^*

ここまでの処理は落ちたら起動するというAuto Scalingの設定でした。
次にスケールアウトを実行するトリガとなるしきい値を設定します。

今回はCPU使用率が平均65%が5分間続いたら自動的にScalingするように設定します。
拡張(+1)するポリシーを設定します。

$ as-put-scaling-policy UP-Policy –auto-scaling-group WP-AS –adjustment=1 –type ChangeInCapacity –cooldown 300 –region ap-northeast-1

同様に縮小(-1)するポリシーは下記のように設定

$ as-put-scaling-policy Down-Policy –auto-scaling-group WP-AS –adjustment=-1 –type ChangeInCapacity –cooldown 300 –region ap-northeast-1

確認

$ as-describe-policies –region ap-northeast-1
SCALING-POLICY WP-AS Down-Policy -1 ChangeInCapacity 300 arn:aws:autoscaling:ap-northeast-1:426070445735:scalingPolicy:ab0f1b93-97dd-4c30-9fcd-ed4d097bd809:autoScalingGroupName/WP-AS:policyName/Down-Policy
SCALING-POLICY WP-AS UP-Policy 1 ChangeInCapacity 300 arn:aws:autoscaling:ap-northeast-1:426070445735:scalingPolicy:5b3db0e2-7fe0-4f4a-bea1-fae8bbcd76cf:autoScalingGroupName/WP-AS:policyName/UP-Policy

そのポリシーをキックするにはCloudWatchを利用します。
AWS Management ConsoleのCloudWatchタブを選択してCreateAlarmを押下します。

Viewingは「EC2: Aggregated by Auto Scaling Group」を選択します。

作成したAuto Scaling Groupの「CPU Utilization」を選択し「Continue」を押下します。

Name:は適当に決めます。CPU負荷が65%続いたらなので CPU_Average_65とかにしておきます。
This alarm will enter the ALARM state when CPUUtilization isで>= 65 for 5に設定。

Take actionを「Auto Scaling Policy」Auto Scaling Groupを設定したグループを選びPolicyをAddするPolicyを設定します。

「Add Action」を押下して完了です。

参考URL
Amazon WebserviceのAuto Scalingの設定について

CPU負荷を与えてAuto Scalingが動くことを確認する。
CPU負荷を与えてしばらくしたらInstanceが起動したことを確認。
LoadBalancerの下にもちゃんと入っている。

負荷が下がるとAuto Scaling Groupに含まれるInstanceが「terminated」になる。

CPU負荷が上昇した時には自動的にAuto ScalingによりInstanceが増えることを確認
CPU負荷が低下したときにもちゃんとterminatedしてくれる。これで余分なお金がかからなくて済む^^;;
しばらくこれで運用してみます。

東京リージョンへ移行

新年あけましておめでとうございます。
本年もよろしくお願いいたします。

新年早々「Your Amazon EC2 Reserved Instances are expiring」なんてメールが届いていた。
リザーブドインスタンス購入したのは去年の1月だったなー
もう1年なんだ。
Reserved Instancesが切れるタイミングでSingapore RegionからTokyo Regionに移動させてみる。
面倒だから最小構成で再構築
EC2 × 1
RDS×1
をさくっと作って再構築。
最小構成だからmemcachedとnginxは後回しにする^^;;
最小構成なのでLoad Balancersも今回は入れない。

Tokyo Region と Singapore Regionの速度差の確認
さくらに置いてあるサーバにpingで確認
東京Region ⇨ さくらサーバ

100 packets transmitted, 100 received, 0% packet loss, time 99155ms
rtt min/avg/max/mdev = 8.197/14.258/101.905/14.368 ms

シンガポールRegion ⇨ さくらサーバ

100 packets transmitted, 100 received, 0% packet loss, time 99230ms
rtt min/avg/max/mdev = 79.252/87.623/198.597/18.117 ms

さすが東京Region。
速いねー5倍ぐらい近くなっている!!!
ヨーロッパからだとわからないけどこのblogはほとんど国内からのアクセスなのでこれでいいや。

めんどくさかったのはあまりなかったけど
Elastic IPsを取り直したことかなぁ
/var/log/httpd/access-log に見たこともない箇所へのアクセスが・・・
前使っていた人が利用していたところへのアクセスなんだろうけど404が大量に出たので気持ち悪くて取り直したぐらいかなぁ

DNSもRoute53だったのでへぐったら元に戻すのもすぐだし^^;;
しばらくはシンガポールと東京で運用して何かあったら切り戻すかんじかなぁ〜