DevOps Professional対策 Opsworks編

2週間後に、aws認定のDevOps Professionalを受ける予定です。
ただ、ぜんぜん自信ない。
assosiate受けた時も思ったけど、opsworksとかelasticbeenstalkとか言われてもいまいちピンとこない。
使ったことないからかな。
じゃあ、使ってみましょう。
そして記事でアウトプットしとけば整理しやすいかもね、という自分本位な記事でございます。
やってみて感想を書く程度です。

Opsworksとは？

AWS OpsWorks は、Chef や Puppet のマネージド型インスタンスを利用できるようになる構成管理サービスです。Chef や Puppet は、コードを使用してサーバーの構成を自動化できるようにするためのオートメーションプラットフォームです。OpsWorks では、Chef や Puppet を使用して、Amazon EC2 インスタンスやオンプレミスのコンピューティング環境でのサーバーの設定、デプロイ、管理を自動化できます。OpsWorks には、AWS Opsworks for Chef Automate、AWS OpsWorks for Puppet Enterprise、AWS OpsWorks Stacks の 3 つのバージョンがあります。

だそうでございます。
CloudFormationではダメなのかな？
ChefとPuppetがキーワードか。どっちも使ったことない。

Chefとは？

CHEFは、サーバーの環境構築、運用などを自動化するためのツールです。ローカル環境はもちろん、仮想環境、オンプレ、クラウドなどさまざまな環境でつかうことが可能です。

ひとつ「CHEF」においてユニークなポイントが。使われる用語として、料理に関するものが多く、初心者でも理解がしやすくなっています。たとえば、「Cookbook」「Recipe」「knife」などが、それらにあたります。用語について詳しく見ていきましょう。

Puppetとは？

Puppetは、「クライアント/サーバ構成」でサーバ構成を集中管理できる設定管理ツールです。「スタンドアロン構成」も可能です。UNIX系OS/Windowsをサポートしています。

ネットワーク設定、ユーザ/グループ作成、パッケージのインストール/アンインストール、設定ファイル/アプリケーションデータなどの配置、サービス起動設定/再起動処理、特定コマンド実行などの、構成管理として必要な処理を自動化します。

PuppetはRubyで実装されています。Puppetコマンド(各種操作の実行を行うフロントエンド機能)と、Rubyライブラリ(各種機能を実装)で構成されています。

構成情報を「マニフェスト」という設定ファイルに、Ruby型固有言語で定義します。Puppetコマンドで、そのマニフェストを実行することでサーバに反映されます。

実践

ふむ。Chefが自動構築でpuppetが運用よりな感じで、それのマネージドがOpsworksという感じですか。
試しにやってみます。

AWS OpsWorksハンズオン

この通りやってみました。

1. CloudFormationスタックの作成
2. http://opsworks-bootcamp-jp.s3.amazonaws.com/opsworks-handson-cf.template をテンプレートにする → 古すぎてRDS Mysqlの該当versionがなかったりしたのでローカルでMysqlのと編集してアップ
3. スタック名 opswork-hundon 、KeyNameはec2に登録されてるキーペア名
4. nextからのcreate
5. githubに適当な名前（opswork-hundon ）でレポジトリ作る。(最初、private repositoryにしてたけど、opsworkからのcloneに失敗したのでpublicに変更しました。privateで使うならSSHkey必要ですね）
6. ec2が一台できてるのでSSHログイン、sudo yum install git
7. default.rb作成からのgit push

mkdir -p ~/site-cookbooks/hello/recipes
vi ~/site-cookbooks/hello/recipes/default.rb

------------ default.rb start-------------------
file "/home/ec2-user/hello.txt" do
  action :create
end
------------ default.rb-------------------------------


## Git setup and push default.rb into GitHub
cd ~/site-cookbooks
git init
git add .
git commit -m "first commit"
git remote add origin https://github.com/xxxxxxxxxx/opsworks-handson.git 
git push -u origin master

8. Opsworks開き、add stack(Chef 11 Stackを選択してみました）
9. https://www.slideshare.net/AmazonWebServicesJapan/aws-opsworks の51ページのあたりからの内容を入力し、Add Stack
10. レイヤーを追加（Add layer）。PHP app serverで進める
11. PHP app serverにPublic IP割り当て
12. RDSレイヤーを追加。CloudFormationで作成したRDS,user:wpuser,pwd:wppassword
13. PHP app Serverにインスタンス追加。インスタンスは何でも良さそうだけど、instance storeに対応してないといけないらしく、m3.mediumにしました）
14. インスタンスを起動 (これけっこう時間かかる）
15. インスタンスにログイン
16. Chefレシピを起動したインスタンスに適用するのでStackを開いてRun command
17. Update custom cookbookを実行
18. Execute RecipesでHello Recipeを実行
19. インスタンス上にhello.txtができているのを確認
20. 次はインスタンスにwordpressをdeploy。基本、コンソール上で。
  1. wordpress レシピを作成
  2. レシピをgit push
  3. レシピをdeploy (またCustom cookbookのアップデートから)
21. AppをdeployするためにApps画面開く
22. wordpressのappを作成（https://github.com/WordPress/WordPress.git からdeployするっぽい）
23. stack->run commandでwp-cli::deployを実行する
24. インスタンスをブラウザで開いてみる

なるほど。できました。
このwordpressサイトを量産したければ、インスタンス作ってwordpressのdeployを繰り返せばいいわけか。
cliでもできるっぽい。
cloudformationで決め打ちしながらガツガツ作ってくよりは柔軟性あるのかな。
なんかで Elastic Beanstalk < Opsworks < cloudFormationっていう難易度の序列みた気がするけど、なんとなく理解できた。
作ってみるとけっこう視覚的にわかりやすい。

片付け

片付けは忘れないようにしないと。
「この請求何？」って事案が発生してしまうのでご注意。

• インスタンスの停止、削除
• App、レイヤー、スタックの順に削除
• Cloud Formationのスタックを削除

で、変なのは残らないはず。

来週はElastic Beanstalk触ってみよう。模擬試験もやっとかないと。ひとまず5割くらいは取りたい。

あれ？Puppetはどこいった？？

---

##追記

elastic beanstalkはこちらを参照しつつ軽くやってみる程度でいいかな。
記事にするほどの内容にはならなさそうです。

AWS再入門 AWS Elastic Beanstalk編

あとはこれに目を通しておく

AWS Black Belt Online Seminar 2017 AWS体験ハンズオン～Deploy with EB CLI編～