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
hiboma さんに口頭で質問をして、自分の考えを整理できました！
2つ大きな思い込みをしていたみたいです。

* 必ず `vagrant up` 一回で provisioning が成功しないといけない
* 依存関係の流れを上からではなく、下から考えていた

前者だと、将来的に resouse の編集や追加すると依存関係の流れが乱れだろうなぁと思っていたのですが、複数 回してもいいなら、不確かであるかもわからない修正に備えて、無駄に冗長なコードにするよりも、現状で一番バランスのいい状態 (完璧ではいけど最小限の流れだけ用意する) にする方が望ましいんですね。
将来手を加えることに引っ張られすぎていました。

後者の考え方だと「そのリソースに必要なものをすべて require しないと！」という発想になってしまうのですが、上から芋づる式？に流れを組み立てていけば、リソース済みの内容がどんどん増えていきますね。

---

@tacahillo

なるほどです！
まだクラスやモジュールを使えていないので、そのような疑問も少しは解消していきそうですね！
トレードオフというお話もあったのですが、確かに書くのも面倒くさいし、完璧だとしても時間を書けて読みづらくするよりは、最低限を保証しにいったほうがよさそうです。

だいぶ納得できたので、そのように修正したいと思います！！ありがとうございました〜！