概要
OpsWorks にゼロからスタックを建てる機会があったので取ったメモです。
インスタンスに直接 SSH ログインを行う、開発環境を構築してみました。
用語
新しい用語だらけなので軽く整理します。
詳細については以下を読むと良さそうです。
スタック
スタックはインスタンスやボリュームを一塊にした単位です。コンポーネントの集合と捉えれば良いと思います。
スタックは AWS OpsWorks の主要なコンポーネントです。スタックは基本的には、共通の目的を持ち、論理的にまとめて管理される Amazon EC2 インスタンス、Amazon EBS ボリューム、Elastic IP アドレスなどの AWS リソースのコンテナーです。スタックにより、ユーザーはこれらのリソースをグループで管理することができます。
Layer
コンポーネントの一塊です。コンポーネントごとの設計図を持ちます。
コンポーネントごとの Chef のクックブックはこの単位で追加できます。
全てのインスタンスへ適用したい Chef クックブックがある場合はスタックのカスタムクックブックへ追加します。
Layer って縦に重ねるイメージで、確かにそれぞれのコンポーネントは縦に積まれてると考えられるけど、個人的にコンポーネントは縦横無尽にスタック上に配置されてる印象を受けたので、しっくり来ませんでした。
1 つ以上の Layer を追加することにより、スタックのコンポーネントを定義します。Layer とは要するに設計図であり、アプリケーションの構築やデータベースサーバーのホストといった特定の目的のために、Amazon EC2 インスタンスのセットを設定する方法を指定します。
スタックの構築
基本的には新しいスタックの作成 - OpsWorksに書いてあるとおりです。
基本ほぼデフォルトを設定していました。
悩んだ設定だけメモしていきます。
悩んだ設定
- Default subnet
- Default root device type
- Default SSH key
- Default IAM Instance Profile
- Hostname theme
Default subnet
各サブネットは 1 つのアベイラビリティーゾーンに関連付けられているため、アベイラビリティーゾーンの選択と同値かと思います。
アベイラビリティゾーンについては以下の資料を参照してください。
Default root device type
EBS backed か Instance store を選択できます。データの存続期間が大きく異なりますので、インスタンスストアの存続期間を参考に選べば良いかと思います。
Instance store だと、インスタンスが停止してもデータは失われてしまうそうです。
両者の違いについては以下に詳しく書いてあります。
Default SSH key
デフォルト値は none で、おそらくこの状態だとスタック上のインスタンスに ssh ログインが不可能となります。
ここで設定した SSH key は、設定を上書きしない限りこのスタック上の全てのインスタンスで有効になります。
Default IAM Instance Profile
特にアプリケーションの権限周りの設定が準備されていないのであれば、デフォルトの New IAM Instance Profile のままで良さそうです。
EC2 インスタンスで実行されるアプリが必要とするアクセス許可を指定する場合（たとえば、アプリケーションが Amazon S3 バケットにアクセスする場合）は、適切なアクセス許可を持つ既存のインスタンスプロファイル（ロール）を選択する必要があります。
Hostname theme
各インスタンスのデフォルトのホスト名を生成するために使用される文字列らしいですが、どう決めてよいかわからず悩みました。要はなんでも良さそうです。たぶん。
悩んだ末、なんとなく美味しそうなので Fruits にしておきました。
Layer の追加
Rails の開発環境を作成したかったため、Rails App Server を追加してみました。
基本的にはOpsWorks Layer の作成方法とOpsWorks Layer の設定の編集を読めばわかるようになっていました。
1箇所だけ設定で悩んだので、それについてのメモです。
悩んだ設定
- Public IP / Elastic IP
Public IP / Elastic IP
Layer のインスタンスにデフォルトで Public IP / Elastic IP を付与するかどうかの設定です。
端的に言うと、どちらも付与可能な Gloabl IP を自動で割り当てる機能です。
今回は自動的に Global IP を割り当てる必要は無いため、どちらも OFF にしました。
Instances の追加
Rails App Server にインスタンスを追加します。
基本資料はLayer へのインスタンスの追加です。
また、時間ベースおよび負荷ベースのインスタンスで負荷を管理するという資料にもある通り、手動操作でないインスタンスを作成することも可能です。
今回は特定のインスタンスへ EIP 割り当て、各ユーザーが SSH ログイン実現できるようにしたかっため、そちらの設定も行いました。
EIP 割り当て
EC2 で EIP を allocate し、その EIP をスタックに関連付け、それを書くインスタンスに割り当てることが可能です。
AWS OpsWorks～EIPを使って固定IPで起動しよう～を参考に設定しました。
SSH ログイン
各ユーザ (AIM) で SSH ログインを可能にするには以下の手順が必要でした。
- インスタンス (root) のキーペアの登録
- ユーザのパブリック SSH キーの登録
- のユーザアクセス許可の管理
インスタンス (root) のキーペアの登録
まずは独自のキーペアを Amazon EC2 にインポートするに従い、キーペアを EC2 へインポートしました。
インポートしたキーペアをインスタンスへと紐付けます。
スタック内の全てのインスタンスで共通のキーを使いたかったため、Default SSH key も設定しておきました。
ユーザのパブリック SSH キーの登録
次に、IAM ユーザーのパブリック SSH キーの登録に従い、各ユーザのパブリック SSH キーを設定します。
ユーザアクセス許可の管理
AWS OpsWorks のユーザーアクセス許可の管理に従い、各ユーザのアクセス許可の設定をします。
権限を与えたいユーザを追加し、権限の設定をすれば完了です。
起動そして SSH
インスタンスを起動……そして$ ssh -i ~/.ssh/[your-keyfile] necojackarc@INSTANCE-DNS……入れた！入れましたー！！
また、設定変えた後はexecute_recipesが走り、インスタンスを起動した状態でも、ユーザの追加と権限付与を行えばすぐに SSH で入れるようになります。素晴らしい。
まとめ
今回は以下の作業を行いました。
- スタックの作製
- Layer の作成
- キーペアの登録
- インスタンスの作成
- EIP の allocate と紐付け
- ユーザの追加と権限付与
AWSdocumentation がかなり丁寧でわかりやすかったにも関わらず、知らない知識が多すぎて時間がかかってしまいました。
慣れるとサクサクと作業が進めれそうな、良い感じの使いやすさになっていたと思います。
次は VPC へセキュリティグループやホスト名の設定を行ってみたいと思います。