ImageBuilderでカスタムAMIを作成
はじめに
昔、IaCの先駆けといいますか、PapetやChefを使用したことがあります。
その後、Ansibleが主流となった経緯を体験してきました。
PapetやChefでは自動構築する処理を書くのですが、それを「レシピ」と呼んでいました。
Ansibleではプレイブックと呼ぶようになったので、しばらく「レシピ」という言葉は聞かなくなりました。
今回、AWSでもAnsibleのようなIaCサービス、ImageBuilderを使用する必要があり、事前検証を行いました。
ここで久々に「レシピ」という言葉に出会ったのですが、Chefの頃のレシピとは少々位置づけが違っているように感じ、ImageBuilderの理解に時間がかかってしまいました。
最終的にはこのImageBuilderの検証で行った手順をTerraform化し、マネジメントコンソールから設定するのではなく、IaC(Terraform)でIaC(imageBuilder)を構成することも検討予定ですが、まずはImageBuilderとはどのようなサービスなのか、どんなものが作成されるのか、こちらを検証してみることにしました。
どこから手を付ける？
ImageBuilderへアクセスするとこのような画面が表示されます。
「イメージパイプラインを作成する」というボタンが目立ちますが、闇雲に試してみたところ、ここからスタートするのは少々難しいと感じました。
ではどこから構築するか。
イメージパイプラインはイメージレシピと、イメージレシピを構成するコンポーネントが必要になることがわかりました。
下から攻める、まずはコンポーネントから用意していくことにしました。
コンポーネント
コンポーネントはその名の通り、どのようなコンポーネントをどのように準備するのかを記載します。
今回はAMIにZabbix AgentとSplunkをインストールした状態で作成したいので、Zabbix Agent用とSplunk用の2つのコンポーネントを作成します。
「コンポーネントを作成する」をクリックします。
コンポーネントの各パラメータですが、以下のように指定しました。
タイプ＝ビルド
互換性のあるOSバージョン＝Amazon Linux 2
コンポーネント名＝ZabbixAgent
コンポーネントのバージョン＝1.0.0
実際の処理はこの下にある、「定義ドキュメント」に記載します。
どのように書くべきか、まずは記述イメージを沸かせるために、「例を使用する」をクリックしてみます。
AWSが用意しているサンプルが表示されます。
このサンプルを見つつ、自分がどのような処理でコンポーネント(今回はZabbixAgent)をインストールするのかを記述します。
(以下、さらっと書いていますが、何度も何度も試行錯誤して出来上がった定義ドキュメントです)
同様の手順で、Splunk用のコンポーネントも作成しておきます。
イメージレシピ
次に、どのコンポーネントを使用するのかを定義するイメージレシポを作成します。
「イメージレシピを作成」をクリックします。
イメージレシピの基本的な情報となる名前とバージョンを指定します。
ベースとなるイメージを指定します。
今回はAmazon Linux 2を使用します。
Amazon Linux 2をどのような状態で使用するのかを指定できます。
常に最新の状態のAIMを使用したい場合もあるでしょうが、以下のように、バージョンを指定しておくことも可能です。
業務で使用する場合は常に最新のものというよりは、動作検証のとれた、確実に動くバージョンを使用したい場合もあると思いますので、そういう場合にとても役に立つ設定だと思います。
インスタンスの設定は今回は利用しませんでしたので未指定で進めます。
(SSMエージェントの削除は指定しても良かったかもしれません)
作業ディレクトリも特に理由がなければ変更せずこのままで進めます。
次に、肝となるコンポーネントの指定です。
ここで、AWSが用意しているコンポーネントや、事前に作成したコンポーネントを選択します。
選択肢から、「ユーザ所有」を選択します。
すると、事前に作成したコンポーネントが表示されるので、カスタムAMIにどのコンポーネントをインストールするのかを指定します。
今回はZabbixAgentとSplunkHFを選択します。
テストコンポーネントも同様にAWSが用意されたコンポーネントなどが選択可能です。
今回はテストコンポーネントは使用しませんので、コンポーネントの選択は行わずに進めます。
ストレージボリューム、タグについても必要に応じて設定します。
設定が終わったら、最後に「レシピを作成する」をクリックします。
イメージパイプライン
コンポーネント、イメージレシピの準備ができましたので、いよいよイメージパイプラインを作成します。
イメージパイプライン名を入力し、
ビルドスケジュールは今回は検証のため「手動」とし、
必要に応じてタグを入力し、「次へ」をクリックします。
イメージレシピの指定になりますが、事前に作成してあるので、「既存のレシピを使用する」を選択します。
ここで新しいレシピを作成することも可能です。
ImageBuilderに慣れていればここから作成したほうが楽かもしれません。
事前に作成しておいたイメージレシピを選択します。
すると、画面には、選択したイメージレシピの情報が表示されます。
先程設定したように、ZabbixAgentとSplunkHFの2つのコンポーネントが含まれていることがわかります。
内容を確認し、「次へ」をクリックします。
インフラストラクチャ設定では今回は便宜上、「サービスデフォルトを使用」とします。
なお、このインフラストラクチャ設定は後ほど変更します。
ディストリビューション設定もデフォルトのまま進めます。
以上の設定の内容を最後に確認し、「パイプラインを作成する」をクリックします。
インフラストラクチャ設定の変更
作成したイメージパイプラインですが、このままでは実行時にエラーになる箇所と、少々カスタマイズしたほうが良い箇所がありますので、そちらを変更します。
IAMロールの変更
この変更は、どのようなコンポーネントを定義しているのかに左右されます。
今回の検証ではZabbixAgentで必要な媒体はインターネットから取得しています。
SplunkHFは特定のバージョンを利用したいこともあり、S3バケット内に媒体を保管しておき、コンポーネント内でS3から媒体を取得する処理にしています。
このイメージパイプラインのインフラストラクチャ設定で定義されているIAMロールはS3へのアクセス権限が不足していますので、このまま実行するとエラーになります。
インフラストラクチャの「編集」をクリックし、IAMロールの下にある、「新しいロールを作成する」をクリックします。
ロール名の検索欄に「EC2」と入力すると、現在インフラストラクチャ設定で使用されている「EC2InstanceProfileForImageBuilder」が現れますので、ロール名をクリックします。
このロールにS3のアクセスポリシーをアタッチします。
余計な権限は与えないのがAWSのポリシー。
今回はS3バケットから情報が取り出せれば良いので、「AmazonS3ReadOnlyAccess」を選択します。
これでS3へのアクセス権限が付与されました。
インスタンスタイプの変更
イメージパイプラインのインフラストラクチャ設定に戻ります。
ここにある、インスタンスタイプが未指定の状態です。
このままでも問題はないのですが実際に実行すると4xlargeなど、高スペックのインスタンスが使用されます。
パイプラインの実行が終われば自動的にインスタンスは終了するのでそこまで費用にこだわらなくてもよいのかもしれませんが、少しでも費用を抑えるために、低スペックのインスタンスを指定しておきます。
動作確認
以上で基本的なImageBuilderの設定が終わりました。
実際に実行し、カスタムAMIが作成されるか確認してみます。
今回のイメージパイプラインは手動で設定していますので、イメージパイプラインを画面から実行します。
しばらく時間がかかりますが、エラーがなければ出力イメージのステータスが「使用可能」になります。
あとは、完成したこのAMIを使用して、EC2インスタンスを起動するだけです。
実際に起動したEC2インスタンスを確認すると、ZabbixAgentが起動していますし、S3から取得したSplunkHFの媒体も/tmpに存在しています。
おわりに
ImageBuilderの構成の理解に少々時間がかかりました。
あとはコンポーネントの中身。
こちらは何度か試行錯誤しながら形にしていくことになりますので、こちらも少々時間がかかります。
それでも、一度カスタムAMIが完成してしまえば、あとは安定して同じ状態のAMIを使用してEC2のインスタンスやコンテナを起動することができます。
これまで、ChefやAnsibleで自動構築を経験してきましたが、AWSでも同じようなことができるということを実際に経験することができました。
Ansible等に触れたことがある方であれば理解は早いと思います。
AnsibleのRoleのように、コンポーネントを分割して構成する構成が良いです。
コンポーネントをバージョンアップしたのであれば、それに付随してイメージレシピもどのバージョンのコンポーネントを使用するのかを設定変更すれう必要がありますが、関係のないコンポーネントに影響が及ぶことにはなりません。
例えば、SplunkHFのコンポーネントを修正し、バージョンを「1.0.1」に変更した場合、イメージレシピ内のコンポーネントのバージョン指定も変更する必要があります。
修正したコンポーネントはイメージレシピンはすべてバージョン管理されて保存されているため、いつでも過去のバージョンを使用してカスタムAMIを作成することもできます。
一度使い方を理解してしまえば、かなり面白いサービスだなと感じることができました。
これはImageBuilderにだけ言える話ではなく、AWSの他のサービスについても同じようなことが言えると思います。
サービス数が多いのですべてを検証してみることはできませんが、今後も積極的に検証し理解を深めていき、有志とも情報を共有して行きたいと感じた、今回の検証でした。