aws

nullpopoponginxのパフォーマンスチューニングを行っているときに、例えばファイルディスクリプタのサイズなどを確認したい場合、nginxユーザにsuしてulimitコマンドを実行したいことがある。

ユーザのシェルを変更する場合、usermodコマンドで-sをつけて恒久的に変更するやり方はググると多数出てくるが、/sbin/nologinなどに戻すのを忘れると悲惨なセキュリティホールになってしまうし、そもそも/etc/passwdなどの認証系のファイルって怖くて弄りたくない。

一時的にユーザのシェルを変更してコマンドを実行する場合は、こうすると便利だ。

[ec2-user@ip-10-0-64-140 ~]$ sudo su -
[root@ip-10-0-64-140 ~]# su - nginx --shell=/bin/bash --command="ulimit -a"
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 55430
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 20000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 2048
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

このように、一度rootになってからsuコマンドの引数に「--shell」と「--command」のオプションを与えてあげればよい。

[amazonjs asin="4774145017" locale="JP" title="プロのための Linuxシステム構築・運用技術 (Software Design plus)"]

nullpopopoAmazon EC2の /etc/hosts は通常 localhost のエントリしかない。eth0のアドレスに対して自分自身からアクセスさせたい場合など、vimでhostsのエントリを書いたりしてもよいのだが、 www.example.com などの1つのFQDNを複数台でクラスタ化するときなどは面倒だしオペミスするのもつまらない。そこで、EC2インスタンスのhostsを簡単に書き換えるシェルスクリプトを作ってみた。

#!/bin/bash
LANG=C
HOSTSFILE=/etc/hosts
T_DIR=${HOME}/tmp
E_DIR=${HOME}/etc
TMP=$(basename $0).$$
MASTER=${T_DIR}/tmp_${TMP}_hosts.master
UNAME=${T_DIR}/tmp_${TMP}_hosts.uname
H_FILE=${E_DIR}/hosts

[ ! -d ${T_DIR} ] && mkdir -p ${T_DIR}
[ ! -d ${E_DIR} ] && mkdir -p ${E_DIR}

case $1 in
  [[:alnum:]]*)
    if [ 0 = $(uname -n | egrep '(^ip-[[:digit:]-]?)' > /dev/null 2>&1 ; echo $?) ];
      then
        cat ${HOSTSFILE} | grep ^127.0.0.1 > ${MASTER}
        uname -n | sed -e 's/-/./g;s/ip.//g' | 
        awk --assign FQDN=$1 '{print $1,"t"FQDN}' > ${UNAME}
        cat ${MASTER} > ${H_FILE}
        cat ${UNAME} >> ${H_FILE}
        sudo chown root. ${H_FILE}
        sudo mv ${H_FILE} /etc/
        rm -f ${MASTER} ${UNAME}
    fi
    ;;
  *)
    ;;
esac

引数にFQDNを与えてあげれば、 /etc/hosts のエントリに追加してくれる。こいつをPATHの通ったどこかに置いておいてAMI化しておけば、楽ちんなことこの上ない。

[amazonjs asin="4822211967" locale="JP" title="Amazon Web Services クラウドデザインパターン 設計ガイド"]

みなさんこんにちは。(っ´∀`)っ ゃーこと濱田です。前回、AWSでWordPressを冗長構成で構築してみましたが、フロントエンドを冗長化していませんでしたので、今回はフロントエンドも冗長化してみたいと思います。

■ ざっくりとした構成

coara-web

上記の図のとおり、クライアントからのアクセスはElastic Load Balancer ( ELB ) からEC2インスタンスに振り分けられます。DBはMulti-AZ DeploymentをYesにして構築しています。今回、新しく登場したのが真ん中の青いバケツ、S3 ( Scalable Storage in the Cloud ) になります。これはELB配下にあるすべてのインスタンスから画像をアップロードします。

…続きを読む

みなさんこんにちは。すっかりAWSのとりこ (っ´∀`)っ ゃーでございます。今日はAWSのRDS(Managed Relational Database Service)にMySQLのデータベースを作成し、EC2にインストールしたWordPressから接続してみたので、その手順をまとめてみました。接続イメージとしては、WEBサーバの背後にDBサーバがあるような感じです。

■ Why use RDS?

RDSはセットアップが簡単で、しかも「Multi-AZ」設定を行うだけで耐障害性の高いDBサーバを構築することができます。セットアップがどれだけ簡単かは、以下に示す手順のように、ブラウザの数クリックだけで作業できることでおわかりいただけると思います。

■ What's Multi-AZ?

Multi-AZとは、異なるAvailability Zone間でレプリケーション環境を構築してくれる仕組みです。これを設定することで、ゾーンAにマスター、ゾーンBにスレーブのDBができ、同期レプリケーションを行ってくれます。ゾーンA障害時には数分でゾーンBに切り替わります。なので、Multi-AZを使ってこそ単一障害点(SPOF)が無くなるというRDSの真価を発揮すると言えましょう。

※ 本来はEC2側も複数用意してELBの配下に置いてこそですが、今回は省略します

それでは作業してみましょう。

…続きを読む