AWS CloudShellでAWS CLIの基本を学ぶ ~EC2編~

記事タイトルとURLをコピーする

技術2課の松田です。こんにちは。

本記事は以下の記事の続編になりますので、よろしければご一読頂けますと幸いです。

blog.serverworks.co.jp

なお前回の記事同様にAWS CLI(以下、CLI)をお手軽に触ってみよう!という趣旨になります。今回はEC2インスタンスを作成しますが、前回同様CLIリファレンスを読むコツもご紹介しますので、そちらにも目を向けて頂けますと幸いです。

構成図

簡単ですが構成図を記載しておきます。ちなみにEC2へのログイン経路は特に用意しないので、その点はご了承ください。

環境準備

前回同様に、CLIの実行環境にはAWS CloudShell(以下、CloudShell)を起動します。もし起動方法が分からない場合は前記事をどうぞ。

CLIでEC2インスタンスを作る

では早速、EC2を起動するコマンドを組み立てていきましょう。

コマンドを組み立てる

前記事でご紹介した通り、以下の考え方でコマンドを組み立てていきます。

  • commandsubcommandparametersの順で決める
  • commandはサービス名を頼りに探す
  • subcommandはコマンド名のルール(create-xxxxdescribe-xxxx)を頼りに探す
  • parametersは必須のものと設定したいものを探す

まずはcommandですが、EC2インスタンスを作成するのでそのままec2でOKです。
続いてsubcommandですが、ここはrun-instancesとなります。昔の名残なのか分かりませんが、create-xxxxでもlaunch-xxxxでもないので注意しましょう。

最後にparametersを決めます。必須のものはありませんね。

では以下の設定でインスタンスを起動するために必要なパラメータだけ指定しましょう。

  • OS: Amazon Linux 2
  • インスタンスタイプ: t3.nano
  • ストレージ:EBS(gp3)で8GiB
  • セキュリティグループ: デフォルトセキュリティグループを使用
  • 配置するサブネット: 前回作ったやつ

ひとつずつ見ていきます

OSを指定する

OSはAMIによって決定されます。AMIを指定するパラメータは--image-idで、書式は以下となります。

--image-id (string)
The ID of the AMI. An AMI ID is required to launch an instance and must be specified here or in a launch template.

肝心なAMIのIDはというと、以下のコマンドを叩くことで確認できます。

aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2

返ってきたami-0521a4a0a1329ff86というのがAMIのIDですね。

ぶっちゃけコンソールから確認したほうが楽ですが、CloudFormationなんかを使う際には有用なテクニックになりますので覚えておくといいかもしれません。コマンドについての詳細は以下をご参照ください。

aws.amazon.com

インスタンスタイプを指定する

インスタンスタイプを指定するパラメータはそのまま--instance-typeです。

--instance-type (string)
The instance type. For more information, see Instance types in the Amazon EC2 User Guide .
Default: m1.small
Possible values:
a1.medium
a1.large
...
t3.nano
...

今回はt3.nanoを指定します。

ストレージを指定する

EBSのボリュームタイプgp3で、サイズは8GiBとします。ストレージの指定には--block-device-mappingsを使用するのですが、--instance-typeなどと違って複数の値をjson形式で渡す必要があります。つまり--block-device-mappingsに以下のような値を渡す、ということです。

[
  {
    "DeviceName": "string",
    "VirtualName": "string",
    "Ebs": {
      "DeleteOnTermination": true|false,
      "Iops": integer,
      "SnapshotId": "string",
      "VolumeSize": integer,
      "VolumeType": "standard"|"io1"|"io2"|"gp2"|"sc1"|"st1"|"gp3",
      "KmsKeyId": "string",
      "Throughput": integer,
      "OutpostArn": "string",
      "Encrypted": true|false
    },
    "NoDevice": "string"
  }
  ...
]

ただしコマンドの中に直接jsonを埋め込むのは無理なので、ファイル読み込みを利用します。つまり↑のjsonをebs.jsonとか名前を付けて保存しておき、コマンド実行時にはebs.jsonのパスを指定する、みたいな感じですね。

ではリファレンスを読みながらjsonファイルを作成しましょう。ここのjsonの組み立て方は--parametersと同じ要領でだいたいOKです。必須パラメータと任意パラメータの区別がないので、設定したいパラメータだけ選んで値を入れていく感じですね。ただコマンド実行してみると「このパラメータも入れて!」ってエラーが返ってきたりするので、そのあたりはトライ&エラーで直していくことになるかと思います。

今回は以下の内容で作成しました。ファイル名はなんでもいいのですが、CloudShell上にebs.jsonとして保存しておきます。こうしておけば、コマンド実行時に--block-device-mappings file://ebs.jsonとすることで、--block-device-mappingsにjsonを渡してあげられます。

[
    {
        "DeviceName": "/dev/xvda",
        "Ebs": {
            "DeleteOnTermination": true,
            "VolumeSize": 8,
            "VolumeType": "gp3"
        }
    }
]

以下、簡単に解説します(※VolumeSizeVolumeTypeは名前のままなので割愛)。

  • DeviceName
    • EBSボリュームのデバイス名。
    • ルートボリュームのデバイス名として予約されている/dev/xvdaを指定すると、このjsonがルートボリュームのパラメータとなる。
    • OSや仮想化タイプによりルート用の予約名は異なる。詳細はこちら
  • DeleteOnTermination
    • EC2削除時にEBSごと削除するかを決める。trueにしておくとEC2と一緒に消えてくれる。

セキュリティグループを指定する

セキュリティグループの指定には、セキュリティグループIDで指定する--security-group-idsまたはセキュリティグループ名で指定する--security-groupsを使用します。ただし今回アタッチするのはデフォルトセキュリティグループのため、コマンドで指定する必要はありません(アタッチするセキュリティグループを指定しなければ、デフォルトセキュリティグループがアタッチされる)。

Default: Amazon EC2 uses the default security group.

配置するサブネットを指定する

配置するサブネットは--subnet-idで指定します。前の記事で作成したサブネットのIDが必要になりますが、以下のコマンドで取得することができます(コンソールでも見れますがせっかくなので)。

aws ec2 describe-subnets --filters "Name=cidr-block,Values=192.168.0.0/28"

ということで、ここではSubnetIdとして返ってきているsubnet-0e12b8cb3d096421bを渡せばOKですね。

コマンドを実行する

以上を踏まえると、実行コマンドは以下の様になります。

aws ec2 run-instances --image-id ami-0521a4a0a1329ff86 --instance-type t3.nano --block-device-mappings file://ebs.json --subnet-id subnet-0e12b8cb3d096421b

これを実行して、以下の様にワーっと値が返って来れば成功です。

さいごに

今回はCLIでEC2インスタンスを起動してみました。コンソールだとウィザード形式でなんとなく起動できますが、CLIだとかなり大変です。逆にCLIに慣れるためにはうってつけのサービスとも言えますので、あえてコンソールではなくCLIで...というのもよいかと思います。

興味のある方は、今回の内容を発展させて、EC2にログインすることを目指す...というのもよいかもしれません。今更ですが、今回記事にした手順では「EC2インスタンスをとにかく起動する」ことにフォーカスしていたため、ログインのことが一切考慮されていません。ログイン可能なインスタンスを起動しようとすると、キーペアやセキュリティグループ、インターネットゲートウェイやルートテーブルなどたくさん設定しなければならず大変ですが、達成する頃にはCLIの基本はマスターできるのではないかと思います。

最後までお読みいただきありがとうございました。本記事がどなたかのお役に立てば幸いです。

松田 渓(記事一覧)

2021年10月入社。所属はクラウドインテグレーション2部技術2課。