CONTENTS
EC2でのサーバー構築手順
構築前の約束事
構築を始める前に。。。
インフラ技術者の約束ごと。
・ファイルを変更するときは、バックアップをとってから！
EC2にログイン
sudo su -l
rootアカウントのパスワード変更
$ sudo su -l $ passwd
ローカルタイム変更
$ ll /etc/localtime* $ cp -rp /etc/localtime /etc/localtime.org && cp -rp /usr/share/zoneinfo/Japan /etc/localtime $ ll /etc/localtime*
———————————————————————-
時間が日本時間になっているのを確認
———————————————————————-
$ date
yum updateなどでglibcパッケージが更新されるとJSTからUTCにまた戻るので、防止設定
# ll /etc/sysconfig/clock* # cp -rp /etc/sysconfig/clock /etc/sysconfig/clock.org && vi /etc/sysconfig/clock ZONE="UTC" UTC=true
を以下に変更
ZONE="Asia/Tokyo" UTC=false
# ll /etc/sysconfig/clock*
NTP設定
時刻同期の設定
・うるう年のうるう秒対策
・時刻の後戻り防止
のためにやっておきましょう。
簡単に言うと
stepモード・・・時刻にずれが生じたら、正しい時刻に一気にあわせる
slewモード・・・時刻にずれが生じたら、徐々にあわせる
ポイントはNTPサーバよりも自分の時計が進んでしまったとき。
slewは自分の時計の進み方を遅くして、NTPサーバにあわせる。
stepは一気にあわせるので、サーバは過去の時刻に戻ってしまう。
過去の時刻に戻るとDB不整合を招くことがあるので、DBサーバはslewを強く推奨します。
NTPサーバとの距離が遠くて、時刻のずれが大きくなるような環境では
slewモードは足並みが揃うまでにかかる時間が大きいです。
が、それが問題になってslewが選択できないほど時刻のずれが大きいようならば
NTPサーバを立てるとか必要かと思います。
うるう年のうるう秒については
step・・・同じ時刻を2回刻む。
slew・・・NTPサーバが1秒進むので、徐々に追いつく
という挙動になるので、slewにしておこうということです。
同じ時刻を2回刻んだが為に、障害が発生して各地でOSが落ちまくるという悲劇が
過去のうるう年にありました。
バグフィックス済みのカーネルであれば、stepモードでも問題ないですが
slewにしておけばバグフィックス済みのカーネルになっているか、確認する手間も省けます。
時刻同期をstepモードからslewモードに変更する
# ps -ef | grep ntp | grep -v grep && echo "---" && ll /etc/sysconfig/ntpd* && echo "---" && cp -rp /etc/sysconfig/ntpd /etc/sysconfig/ntpd.org && ll /etc/sysconfig/ntpd* ntp 2385 1 0 18:20 ? 00:00:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g ←まだ-gオプションのみ --- -rw-r--r-- 1 root root 45 Feb 6 10:09 /etc/sysconfig/ntpd -rw-r--r-- 1 root root 111 Feb 6 10:09 /etc/sysconfig/ntpdate --- -rw-r--r-- 1 root root 45 Feb 6 10:09 /etc/sysconfig/ntpd ←オリジナルファイル -rw-r--r-- 1 root root 111 Feb 6 10:09 /etc/sysconfig/ntpdate -rw-r--r-- 1 root root 45 Feb 6 10:09 /etc/sysconfig/ntpd.org ←オリジナルのコピー。バックアップとして保存 # vi /etc/sysconfig/ntpd - OPTIONS="-g" + OPTIONS="-g -x"
-xオプションを追記して保存
# ntpq -p # service ntpd restart # ps -ef | grep ntp # ntpq -p
*がついたエントリがあること
再起動後は*がつくまでは少しかかる
ユーザ作成
1.グループ作成
$ groupadd -g グループID グループ名
-g・・・グループID。省略すると既存グループIDの連番。でもOS自動作成のシステムグループと分けるために
桁数も多くしたIDを指定しておいた方がお得。
★OSがバージョンアップされると、ユーザやグループが追加されることは多いです。
ユーザやグループを作成するときにIDを小さい番号にしてしまうと、新規追加されたシステムユーザ・グループと重複してしまって
データ移行するときに面倒な手間が発生していまいます。
3桁、4桁を使用するのがオススメです。
2.ユーザ作成
$ useradd -u ユーザID -g グループ名 -d ホームディレクトリ -m -s /bin/bash -c "コメント" ユーザ名
オプションは
-u・・・ユーザID省略可。省略すると既存グループIDの連番。。省略すると既存ユーザIDの連番。グループIDと同じで指定した方がいい。
-g・・・グループ名もしくはグループID。どちらで指定もOK
-d・・・ホームディレクトリ。省略可。省略すると/home/ユーザ名になる。
-m・・・ホームディレクトリが存在しなかったら作成する。
-s・・・ユーザのシェルスクリプト。省略するとシステムデフォルトになる。AWS Linuxは/bin/bash
-c・・・コメント。省略可。省略すると空欄になる。
3.2で作成したユーザのパスワード変更
$ passwd ユーザ名
プロンプト変更
プロンプトとは、、、
sshログインしたら、白点滅でコマンド入力を待ってくれている箇所にある「$」、(rootユーザだったら「#」)
の前に表示されている文字列。
EC2だったら
[ec2-user@ip-10-0-2-240 ~]$ [root@ip-10-0-1-240 ~]#
の
[ec2-user@ip-10-0-2-240 ~]
と
[root@ip-10-0-1-240 ~]
の部分。
ここを変更します。
これ、超重要です。
単に便利だからとか、実用的だからではなく、事故を防ぐために必須なんです。
shutdownとか、rmとか、、、アプリ停止コマンドとか。プロンプトで何のサーバか判断できないところに打つのは怖くないですか？？
★自分がどのサーバでコマンドを打とうとしているのか、ぱっと見で判断できるかどうか可視性を高めることは、事故を減らす為に非常に重要です。
root@hogehoge(WEB-HON)
root@hogetest（db-dev)
というように、大文字/小文字で差をつけたりして
本番か開発か、WEBかDBか、環境や用途がわかるものがオススメです。
ユーザプロファイルの「PS1」がプロンプト変数。
# ll /etc/bashrc* # cp -rp /etc/bashrc /etc/bashrc.org && vi /etc/bashrc ---------------------------------------------------------------------- ここから35行目あたり # Turn on checkwinsize shopt -s checkwinsize # change by prophet ←追加 # [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@\h \W]\\$ " ←コメントアウト [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@\h(サーバ用途) \W]\\$ " ←追加 # You might want to have e.g. tty in prompt (e.g. more virtual machines) ----------------------------------------------------------------------
変更確認はスイッチユーザか再ログインする
# sudo su -l
swap作成
swapファイルをメモリにあわせて作成する
メモリと同等～2倍くらいがよい。
マイクロインスタンスなら1GBで。
サイズはbs(ブロックサイズ)×count(数)。下記なら1M×1024=１GBのファイルができる。
dd if=/dev/zero of=/usr/local/swapfile bs=1M count=1024
nanoだったらメモリ500MBなので、スワップ500MBで。
dd if=/dev/zero of=/usr/local/swapfile bs=4k count=128000
作成したファイルをswap用にフォーマット
mkswap /usr/local/swapfile
swapon -aでエラーにならないようにパーミッション変更しておく
chmod 0600 /usr/local/swapfile
/usr/local/swapfileをswapとして有効化
swapon /usr/local/swapfile
swap設定状態を確認
swapon -s
OS起動時自動マウント設定
cp -rp /etc/fstab /etc/fstab.org vi /etc/fstab
下記を追加
# Add by 名前とか会社名とか /usr/local/swapfile swap swap defaults 0 0
システムファイルを変更する場合、デフォルト設定ではないことがわかるように
# Add by XXX のようにコメントを入れるようにしています。
変更前のファイルと比較すればわかることなのですが、
パラメータなんかは、チューニングしていった変更履歴がわかるように変更箇所をコピーして1行追加し、変更前はコメントアウトして残しておいたりわかりやすいように残しておきます。
◇自動swap有効化確認
いったん有効化したswapを無効にして、
/etc/fstabに記載した内容が妥当であることを確認します。
swapon/swapoffコマンド
-aオプションで/etc/fstabに記載しているスワップを全部有効化/無効化する
swapon -s Filename Type Size Used Priority /usr/local/swapfile file 2097148 8820 -1 ※サイズは作成したファイルによって異なる いったん無効にする swapoff /usr/local/swapfile swapoff -aでもOK swapon -s ※何も出力されない swapon -a swapon -s Filename Type Size Used Priority /usr/local/swapfile file 2097148 8820 -1
ftpインストール
ftpはデザイナーや外部パートナーの依頼があるときのみ、行うようにします。
通常は不要なポートやサービスを立ち上げないために、
SFTPなどを使用するようにします。
$ yum install vsftpd
———————————————————————-
設定ファイル書き換え（IPは適宜書き換え、セキュリティグループで穴をあける）
———————————————————————-
$ cp -rp /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf.org && vi /etc/vsftpd/vsftpd.conf
# 末尾に以下を追記
---------------------------------------------------------------------- pasv_enable=YES pasv_addr_resolve=YES pasv_min_port=60001 pasv_max_port=60100 pasv_address=EC2のpublicDNSを記入 ----------------------------------------------------------------------
# 起動
$ service vsftpd status $ service vsftpd start $ service vsftpd status
# OS起動時の自動起動設定
$ chkconfig --list vsftpd
# 全てoffとなっていること確認
$ chkconfig vsftpd on $ chkconfig --list vsftpd
# runレベル2～5がonになっていること確認
———————————————————————-
無効にする場合は
$ chkconfig vsftpd off
停止する場合は
$ service vsftpd status $ service vsftpd stop $ service vsftpd status
———————————————————————-
以上！
この辺りをベースで設定しておけば、AWS EC2で再起動がかかったりしても開発者が余計な調査などを行なわなくて済むようになりますね。
これらを行なう前は、データの反映時間がずれたり、バッチ処理が正常に発動しなかったりと、サーバー再起動後の確認点が多かった気がします。
デザイン＋開発＋インフラ構築がセットになって、はじめて良いアプリケーションが提供できるかな〜と考えています！
