class: center, middle
# 検証環境の作り方

やました

---

# 話すこと

1. 検証サーバの立て方
2. 検証の仕方

Docker,ansible,vagrant...etcの最近話題の話はしないです＞＜；

---

# 1. 検証サーバの立て方

既に動いているサーバがある場合

本番環境に近い環境でテストしたい  
=> 総合テスト、負荷テスト以外も本番に近い環境でテストしたい  
=> どうやって検証サーバ作るか？

---

class: center, middle

# 答え
# コピーする

---

sshでrootとれれるならそのままコピーすればおｋ  
CPUのアーキテクチャ合わせて  
ファイル全部コピーすりゃだいたい動く

# 不要なファイル外して全ファイルコピー
    cat <<EOF > exc.txt
    - /sys/*
    - /proc/*
    - /mnt/*
    - /dev/*
    - /tmp/*
    EOF
    rsync -avz --numeric-ids --delete --exclude-from=exc.txt root@example.com:/ /mnt/
    
    # grubとかfstabとか直す
    cd /mnt
    mount -t proc proc proc/
    mount -t sysfs sys sys/
    mount -o bind /dev dev/
    chroot /mnt
    vi /etc/fstab
    vi /etc/network/interfaces
    vi /etc/udev/rules.d/70-persistent-net.rules
    update-grub
    grub-install /dev/vda

---

- まずコピーを検討しましょう
    - 構築方法思い出すより手っ取り早い場合が多い
- EC2だからスナップショットが、Dockerイメージが、Vagrantイメージが（略
    - 本番と同じならそちらをお使い下さい
- 構築手順(ansible,chefのコード)があっても違うものができるかも？
    - `yum install java-1.7.0-openjdk.x86_64`でどのバージョンが入る？
        - tomcatのconfがこうなってた白目`JAVA_HOME="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/"`
    - 本当に構築手順通りにやって本番環境と同じになる？
        - 本番で変更した内容がすべて手順に反映されてる？

---

- 構築手順通りにやって問題がないと分かっているならそちらでもおｋ
    - 全コピーした場合のコストと比較する
    - 常に全コピーが良いとは限らない(railsのテストだけならローカルに手順通り作るとか)

---

- ○○が起動しない
    - カーネルなら起動パラメータ、モジュール周り見る
    - `.pid`,`.lock`ファイル等
    - mysqlファイルシステムがぶっ壊れた⇒ [Google : mysql リカバリ](https://www.google.co.jp/#q=mysql+%E3%83%AA%E3%82%AB%E3%83%90%E3%83%AA)
        - ファイル全コピーのあとdumpデータだけは別にもってくるとか
    - エラーメッセージをよく見ること
- 本番稼動中にコピーしたらサーバが重くなってあｑｗせｄｒｆｔｇｙふじこ
    - 影響ないようなコピーを考える
        - `rsync --rsync-path="ionice -c3 nice -n 19 rsync"`
        - `rsync --bwlimit=1.5m`
    - バックアップ(メンテ)のタイミングでやる

---

# 2. 検証の仕方

そんなこんなで検証環境ができた

![94602404267](http://36.media.tumblr.com/808f93504602113d57e7131fdf538d5c/tumblr_na8aotCVST1riy4fno1_400.png)

よく分からないからとりあえず押してみるお
![94602976412](http://36.media.tumblr.com/bbabe1ccd061a6bd2efab03d3ead0c7c/tumblr_na8b0pF6t11riy4fno1_250.png)

---

![94603394897](http://36.media.tumblr.com/933be70cfe1caf15fdd8f9991cc0fdaa/tumblr_na8b9bhkIq1riy4fno1_500.png)

---

# よく分からないボタンを押すとどうなる？

よく分からないアプリ＝自分で仕様を把握してない  
(他社から引き継いだアプリ、他人が作ったアプリ等々)

+ 意図しないファイルを潰すかもしれない
+ 外部サービスと連携してよからぬことが起きるかも・・・・
    + S3のファイルを上書き
    + 決済サービスと連携しちゃう
    + メールサービスと連携してメールを飛ばしちゃう

---

# 影響しない環境で立てる

手っ取り早くやるなら
デフォルトゲートウェイを抜く

`ip route del default`

⇒すくなくともパケットを外に飛ばせなくなる

---

# GWにするサーバを用意する

お勧めはゲートウェイにするサーバを用意して  
ここでヤバイ通信を止める

設定は検証サーバのデフォルトGWをそちらに向けるだけ

通信
     検証サーバ  ---->   GWサーバ  
                          ↑
                          ここでやばそうな通信を止める観察する

---

# GWサーバの設定

- iptables
    - パケット制御
    - どこに接続しようとしているか見る
- unbound
    - 名前解決要求を見る
    - 一時的に別のIPに接続させる
- postfix
    - 送信したメールを見る

---

## iptables

# メール送信を止める
    iptables -A FORWARD -p tcp --dport 25  -j REJECT
    # 10.0.10.152からGWを越えようとするパケットは拒否するがログに残す
    iptables -A FORWARD -s 10.0.10.152 -j LOG --log-prefix iptables --log-level=info
    iptables -A FORWARD -s 10.0.10.152 -j REJECT

こんな感じのログがsyslogに出る  
下記例だと587ポートに接続をしようとしているのが分る

iptablesIN=br0 OUT=br0 PHYSIN=vnet0 MAC=00:00:00:00:00:00:00:00:00:00:00:00:00:00 SRC=10.0.10.152 DST=183.79.135.206 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=33720 DF PROTO=TCP SPT=39678 DPT=587 WINDOW=14600 RES=0x00 SYN URGP=0

---

## unbound

キャッシュDNSサーバも立てると検証時にどの名前解決をしたかわかるので便利

unbound.conf

verbosity: 2

google.co.jpの名前解決をした例

unbound: [1152:0] info: resolving google.co.jp. A IN

---

## postfix

main.cf

virtual_alias_maps = regexp:/etc/postfix/aliases.reg

/etc/postfix/aliases.reg

/^(.+)@.+$/ yamasita@localhost

全メールアドレスをyamasita@localhostへ配送させる  
⇒あて先がなんであれ検証サーバが送信したメールを見れる

---
# GWサーバの設定

+ これで完璧じゃないけどやらないよりずっと良い
+ 自分では把握してるつもりでもうっかりはある
+ そのうちGWサーバの設定をansibleにして公開するよ(多分)

---

# まとめ

+ 検証環境はコピーで作れないか検討する
    - 全コピーなら難しくないよ

+ 検証する場合は外部に影響しない環境で
    - GWサーバは一度作ってしまえば大抵使いまわせる