provisioning で利用した shell script を manifest に書き換える

### ops研修/ manifest
@tacahilo @kitak @keokent @hiboma

shell script で書いた provisioning のファイルを manifest で再現するPRです。
今回は書き換えることが目的なので、クラスやモジュールは使用しないようです。
適宜 push していきますので、完成までしばらくお待ちください！
後日、レビューのほどよろしくお願いします！

主に、以下の点で指摘をいただけたらとてもありがたいです。

* コーディングスタイル
* manifest に関する tips

### ToDo
- [x] 7ec6185：必要な Package を追加
- [x] d7a9c25：Package と Exec の初期値を追加
- [x] c9936d7：iptables と mysqld のOS起動時のふるまいを設定
- [x] 8dea2c6：source の機能を使って、gemrc と bash_profile を作成
- [x] df8a848：Ruby 関連のインストール (バージョンは 2.1.5)
- [x] 21e435d：Rails アプリケーションを clone する
- [x] d518127：bundler をインストールして、Gem をアプリケーションのローカルに保存 
- [x] a42b649：DB (本番環境のみ MySQL) を作成
- [x] b07061b：Assets:precompile を実行

### 細かい作業の流れ (TDD)
1. shell scriptを参考に、テスト項目の括りで一個ずつ manifest に記述する
2. puppet apply (vagrant provision) を実行
3. serverspec のテストを実行
4. 問題なければ commit、push
5. はじめにもどる

### source
* shell script：https://github.com/ryoma123/centos6-sampleapp/blob/master/shell/build-rails.sh
そもそもの話，requireを多用すると依存関係が複雑化するので避けたほうがいいんだよね．

リソースAはリソースBとリソースCをrequireしており，リソースBはリソースCとリソースDをrequireしており，リソースCはリソースDをrequireしており，...みたいになると混乱するし，ちょっとの変更でmanifestsが壊れる可能性がある．
それなら以下のように指定しておけば，リソースの実行順序は保証されるよね．

- リソースAはリソースBをrequire
- リソースBはリソースCをrequire
- リソースCはリソースDをrequire

多分，本来的には @ryoma123 の考え方であってるかもしれない（require＝必要ってことだしね）んだけど，実用には向かないかなーという感じ．
書くのが面倒くさいし，一箇所を変更した時の影響範囲が大きくなるしね．


ちなみに，実運用ではclassを使って分離することで，requireの数を減らしてる．
`Class['A'] -> Class['B']`みたいに順番を指定できるので．1枚のmanifestsがfatになってきたら別ファイルに分けてしまうかな．