EBS ボリュームにアプリケーションファイルを保存する

はじめに

レポートアプリケーションには、レポートファイル用の独立したディスクが必要です。Amazon EBS ボリュームを作成して EC2 インスタンスにアタッチし、ファイルシステムをフォーマットしてマウントした後、そのボリュームからレポートを提供します。その後、アンマウントとデタッチを行い、作成したリソースを削除します。

EC2 の起動と SSH の基本を理解していることが前提です。各ラボは新しい環境で始まり、専用のアプリケーションイメージ、ネットワーク、キーペアが用意されています。

認定試験との関連

このラボでは EC2 ワークロード向けのブロックストレージの選択を練習し、AWS Certified Cloud Practitioner CLF-C02 ドメイン 3 の目標にあるタスク 3.6 のストレージ概念を学びます。

ストレージサーバーを起動する

このステップでは、アプリケーションインスタンスを起動し、そのアベイラビリティーゾーンを確認します。

作業ディレクトリで、用意されたリソース ID を読み込みます。

cd /home/labex/project

source launch.env

storage-server という名前のインスタンスを 1 台起動します。イメージにはレポートアプリケーションが含まれており、ここではそのデータボリュームを用意します。

aws ec2 \
  run-instances \
  --image-id "$AMI_ID" \
  --instance-type t3.micro \
  --subnet-id "$SUBNET_ID" \
  --security-group-ids "$SECURITY_GROUP_ID" \
  --key-name report-key \
  --count 1 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=storage-server}]'

名前タグからインスタンス ID を取得します。

INSTANCE_ID=$(aws ec2 \
  describe-instances \
  --filters Name=tag:Name,Values=storage-server \
  --query 'Reservations[0].Instances[0].InstanceId' \
  --output text)

インスタンスが実行状態になるまで待ちます。

aws ec2 \
  wait instance-running \
  --instance-ids "$INSTANCE_ID"

アベイラビリティーゾーンは、リージョン内の独立した場所です。EBS ボリュームは同じアベイラビリティーゾーンのインスタンスにアタッチします。ゾーンを推測せず、インスタンスの情報から取得します。

AVAILABILITY_ZONE=$(aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[0].Instances[0].Placement.AvailabilityZone' \
  --output text)

状態とゾーンを確認します。

aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name,Zone:Placement.AvailabilityZone}'

running を確認します。AWS View を開き、Refresh resources をクリックして storage-server を選択し、Check application をクリックします。ストレージを追加する前に HTTP 200 を確認してください。

データボリュームを作成してアタッチする

このステップでは、独立した EBS データボリュームを作成し、実行中のサーバーにアタッチします。

Amazon EBS は EC2 用のブロックストレージを提供します。ボリュームはディスクに相当するリソースで、ファイルシステムはそのディスク上のファイルを整理します。ボリュームをアタッチするとブロックデバイスが利用可能になりますが、ファイルシステムは作成されません。EBS ボリュームガイドでは、アタッチとデータの永続性について説明しています。

小さな空の汎用 SSD ボリュームを作成します。gp3 はボリュームタイプ、--size 1 は 1 GiB の容量を指定し、ゾーン変数はインスタンスと同じゾーンに配置します。後の操作で使うため ID を保存します。

VOLUME_ID=$(aws ec2 \
  create-volume \
  --availability-zone "$AVAILABILITY_ZONE" \
  --size 1 \
  --volume-type gp3 \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=report-data}]' \
  --query 'VolumeId' \
  --output text)

新しいボリュームが利用可能になるまで待ちます。

aws ec2 \
  wait volume-available \
  --volume-ids "$VOLUME_ID"

API のデバイス名 /dev/sdf を使ってアタッチします。

aws ec2 \
  attach-volume \
  --volume-id "$VOLUME_ID" \
  --instance-id "$INSTANCE_ID" \
  --device /dev/sdf

アタッチが完了するまで待ちます。

aws ec2 \
  wait volume-in-use \
  --volume-ids "$VOLUME_ID"

ボリュームとアタッチ情報を確認します。

aws ec2 \
  describe-volumes \
  --volume-ids "$VOLUME_ID" \
  --query 'Volumes[].{Volume:VolumeId,State:State,Zone:AvailabilityZone,Size:Size,Type:VolumeType,Attachments:Attachments}'

in-use、サイズ 1、タイプ gp3、自分のインスタンスへのアタッチを確認します。AWS View を更新し、ボリュームの行を確認してください。ルートボリュームは新しいデータボリュームとは別です。

ボリュームをマウントしてレポートを提供する

このステップでは、空のデータボリュームを初期化し、アプリケーションがレポートを読み取れるようにします。

インスタンスの現在のパブリックアドレスを取得します。

PUBLIC_IP=$(aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[0].Instances[0].PublicIpAddress' \
  --output text)

用意された SSH 設定で接続します。

ssh -F ssh_config ubuntu@"$PUBLIC_IP"

インスタンス内で、新しくアタッチしたデバイスを確認します。このラボでの Linux 名は /dev/xvdf です。デバイス名は API のアタッチ名と異なる場合があります。他の EC2 イメージでは NVMe 名が使われることもあるため、操作前にディスクを特定してください。公式の Linux ボリューム準備ガイドでは、この違いを説明しています。

lsblk -f /dev/xvdf

デバイスにファイルシステムタイプがないことを確認します。新しく作成した空のデータボリュームにのみ ext4 ファイルシステムを作成してください。既存のデータがあるボリュームをフォーマットすると、そのデータが消去されます。

sudo mkfs.ext4 /dev/xvdf

マウントポイントは、ファイルシステムにアクセスするためのディレクトリです。レポートアプリケーション用に用意されたディレクトリに、新しいファイルシステムをマウントします。

sudo mount /dev/xvdf /srv/reports

ソースデバイス、ファイルシステム、マウントポイントを確認します。

findmnt /srv/reports

/dev/xvdf、ext4、/srv/reports を確認します。架空のデータを使った CSV レポートを作成します。sudo tee は管理者が所有するファイルシステムに書き込み、区切り文字を引用符で囲んだヒアドキュメントは 2 行をそのまま保持します。

sudo tee /srv/reports/report.csv <<'CSV'
period,total
Q1,320
CSV

ファイルを読み戻します。

cat /srv/reports/report.csv

LabEx ターミナルに戻ります。

exit

AWS View で storage-server を選択し、Read volume report をクリックします。HTTP 200 と CSV のテキスト period,total、Q1,320 を確認します。この応答は、アプリケーションがマウントされたボリューム上のファイルを読み取れることを示します。

このラボのマウントは手動です。再起動しても手動のマウントは自動復元されません。本番環境では通常、設定をテストした後に /etc/fstab にファイルシステム UUID を設定します。

アンマウント、デタッチ、削除を行う

このステップでは、決められた順序でデータボリュームとアプリケーションインスタンスを削除します。

まずアプリケーションインスタンスに再接続します。

ssh -F ssh_config ubuntu@"$PUBLIC_IP"

ディスクをデタッチする前にファイルシステムをアンマウントします。これによりファイルシステムへのアクセスを止め、保留中の書き込みを反映します。

sudo umount /srv/reports

マウントされていないことを確認します。

findmnt /srv/reports

マウントされていないディレクトリでは findmnt は出力を表示せず、ゼロ以外の終了ステータスを返します。ここでは正常な結果です。LabEx ターミナルに戻ります。

exit

自分のデータボリュームだけをデタッチします。

aws ec2 \
  detach-volume \
  --volume-id "$VOLUME_ID" \
  --instance-id "$INSTANCE_ID" \
  --device /dev/sdf

ボリュームが再び利用可能になるまで待ちます。

aws ec2 \
  wait volume-available \
  --volume-ids "$VOLUME_ID"

デタッチしたボリュームを削除します。データは完全に削除されるため、本番用ボリュームを削除する前には重要なファイルやバックアップを保存してください。

aws ec2 \
  delete-volume \
  --volume-id "$VOLUME_ID"

アプリケーションインスタンスを終了します。

aws ec2 \
  terminate-instances \
  --instance-ids "$INSTANCE_ID"

終了を待ちます。

aws ec2 \
  wait instance-terminated \
  --instance-ids "$INSTANCE_ID"

インスタンスの最終状態を確認します。

aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'

terminated を確認してから、残っているボリュームを一覧表示します。

aws ec2 \
  describe-volumes \
  --query 'Volumes[].{Volume:VolumeId,State:State}'

[] が期待されます。データボリュームは明示的に削除され、このインスタンスのルートボリュームは終了時に削除されました。AWS View を更新し、サーバーが実行中の対象ではなく、ボリューム一覧が空であることを確認します。用意されたネットワークとキーペアはそのまま残します。

まとめ

EC2 インスタンスと同じアベイラビリティーゾーンに EBS データボリュームを作成してアタッチし、空のファイルシステムをフォーマットしてアプリケーション用にマウントしました。実際のレポート応答を確認した後、ボリュームをアンマウント、デタッチ、削除し、最後にサーバーを終了しました。