第5章　EC2起動時の自動設定（user-data・AMI）

EC2インスタンスを起動するたびに手作業で初期設定を行うのは非効率です。user-dataとcloud-init、そしてAMI（Amazon Machine Image）を使った自動化・標準化の考え方を扱います。

user-dataとcloud-init

EC2インスタンスの起動時には、シェルスクリプトやcloud-config形式のテキストを「user-data」として渡すことができます。これを実行する仕組みが、多くのLinuxディストリビューションに標準搭載されているcloud-initというソフトウェアです。user-dataは既定では、インスタンスの初回起動時に1度だけ実行されます。実行結果のログは/var/log/cloud-init-output.logで確認できるため、意図通りに動かなかった場合はまずこのログを確認します。

# user-dataとして渡すシェルスクリプトの例
#!/bin/bash
apt update
apt install -y nginx
systemctl enable --now nginx

AMI（Amazon Machine Image）という「ひな形」

AMIは、必要なソフトウェアや設定をあらかじめ仕込んだサーバーの状態を、ひな形として保存したものです。以前の運用フェーズ別の課題でも扱った「ゴールデンイメージ」の考え方に近く、AMIとuser-dataを組み合わせることで、複数台のサーバーを同じ状態で素早く起動できるようになります。

user-dataスクリプトを書くときの注意点

user-dataとして渡すシェルスクリプトは、通常の運用スクリプトと同じく、何度実行しても同じ結果になるべき等性（idempotency）を意識して書くことが望ましいとされます。たとえば、すでにインストール済みのパッケージを再度インストールしようとしてもエラーにならないようにする、設定ファイルを追記する場合は重複して追記されないようにする、といった配慮です。また、user-dataの内容には平文でログに残ってよい情報だけを含めるべきで、パスワードやAPIキーのような機密情報を直接埋め込むのは避け、IAMロールやAWS Systems Manager Parameter Storeのような専用の仕組みを使うのが基本です。

AMIの更新と世代管理

AMIは一度作ったら終わりではなく、OSのセキュリティパッチやミドルウェアのバージョンアップにあわせて定期的に更新するのが実務での基本です。新しいAMIを作成した際は、古いAMIをすぐに削除せず、しばらく世代を残しておくことで、新しいAMIに問題が見つかった場合にすぐ前のバージョンへ切り戻せるようにしておく運用がよく取られます。

AMIの作成自体は、動いているインスタンスからコンソール操作で作ることもできますが、毎回手作業で行うと「どのインスタンスから作ったAMIか」「どんな手順で構築したか」が曖昧になりがちです。そこで、あらかじめ定義した手順（ベースAMIの指定、インストールするパッケージ、実行するスクリプトなど）に沿ってAMIの作成そのものを自動化するEC2 Image Builderというサービスも用意されています。手作業でのAMI更新をなくし、毎回同じ手順で再現性のあるAMIを作れるようにする点で、これも一種のInfrastructure as Codeの実践といえます。

user-dataの実行状況をインスタンス内部から調べる

ログファイルを直接読む以外にも、cloud-init自身が持つcloud-init statusというコマンドで、初期化処理が完了しているか、エラーが発生していないかを一目で確認できます。--longオプションを付けると、各処理ステージの詳細な状況まで表示されます。

$ cloud-init status --long
status: done
boot_status_code: enabled-by-generator
detail:
DataSourceEc2 Local (metadata service)

user-dataの内容そのものを後から確認したい場合は、/var/lib/cloud/instance/user-data.txtに、起動時に渡されたスクリプトの内容がそのまま保存されています。「そもそもどんなuser-dataが渡されたのか分からない」という状況になったときに、このファイルを確認する習慣をつけておくと調査がスムーズです。

この章のまとめ

user-dataはEC2起動時にcloud-initが実行する初期設定用のスクリプトであること、その実行ログは/var/log/cloud-init-output.logで確認できること、user-dataを書く際はべき等性と機密情報の扱いに注意が必要なこと、そしてAMIというひな形と組み合わせることでサーバー構築を標準化・自動化できることを押さえました。次章では、複数のインスタンスのログやメトリクスを集約するCloudWatchを扱います。