スキップしてメイン コンテンツに移動

いつもAWS Management Consoleでやってる作業をAWS Command Line Interfaceでやってみる

今日はAWS Command Line Interface User Guide (Version 1.0.0)を読んで勉強したので、いつもAWS Management Consoleからやってる作業をCLIからやってみた。



インストール
$ sudo easy_install awscli

セットアップ

IAM Role for EC2でPowerUsers設定してるからAccess KeyとSecret Access Keyは設定しない。
$ aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]: us-west-2
Default output format [None]: json
Outputはjson、table、textが使える。違いはこんな感じ。tableめっちゃかっこいい。
$ aws ec2 describe-volumes --output json
{
    "Volumes": [
        {
            "AvailabilityZone": "us-west-2c",
            "Attachments": [
                {
                    "AttachTime": "2013-11-20T04:49:04.000Z",
                    "InstanceId": "i-e71117d3",
                    "VolumeId": "vol-806f02d6",
                    "State": "attached",
                    "DeleteOnTermination": true,
                    "Device": "/dev/sda1"
                }
            ],
            "VolumeType": "standard",
            "VolumeId": "vol-806f02d6",
            "State": "in-use",
            "SnapshotId": "snap-68c27457",
            "CreateTime": "2013-11-20T04:49:04.000Z",
            "Size": 8
        }
    ]
}
$ aws ec2 describe-volumes --output table
---------------------------------------------------------------------------------------------------------------------
|                                                  DescribeVolumes                                                  |
+-------------------------------------------------------------------------------------------------------------------+
||                                                     Volumes                                                     ||
|+------------------+---------------------------+-------+----------------+---------+----------------+--------------+|
|| AvailabilityZone |        CreateTime         | Size  |  SnapshotId    |  State  |   VolumeId     | VolumeType   ||
|+------------------+---------------------------+-------+----------------+---------+----------------+--------------+|
||  us-west-2c      |  2013-11-20T04:49:04.000Z |  8    |  snap-68c27457 |  in-use |  vol-806f02d6  |  standard    ||
|+------------------+---------------------------+-------+----------------+---------+----------------+--------------+|
|||                                                  Attachments                                                  |||
||+---------------------------+------------------------+-------------+--------------+------------+----------------+||
|||        AttachTime         |  DeleteOnTermination   |   Device    | InstanceId   |   State    |   VolumeId     |||
||+---------------------------+------------------------+-------------+--------------+------------+----------------+||
|||  2013-11-20T04:49:04.000Z |  True                  |  /dev/sda1  |  i-e71117d3  |  attached  |  vol-806f02d6  |||
||+---------------------------+------------------------+-------------+--------------+------------+----------------+||
$ aws ec2 describe-volumes --output text
VOLUMES us-west-2c      2013-11-20T04:49:04.000Z        8       snap-68c27457   in-use  vol-806f02d6    standard
ATTACHMENTS     2013-11-20T04:49:04.000Z        True    /dev/sda1       i-e71117d3      attached        vol-806f02d6

設定ファイルは~/.aws/configに作成される。
$ cat ./.aws/config 
[default]
output = json
region = us-west-2

設定は複数保持することが出来、--profileで切り替えられる。別の設定を追加してみる。
$ aws configure --profile table
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]: us-west-2
Default output format [None]: table
$ cat ./.aws/config
[default]
output = json
region = us-west-2
[profile table]
output = table
region = us-west-2

ヘルプ
末尾にhelpを付けることでhelpが表示される。
トップレベルでのhelp。サブコマンドが列挙される。
$ aws help
各サブコマンドに対するヘルプ。例えばec2。
aws ec2 help
サブコマンドの実行コマンドに対するヘルプ。
$ aws ec2 describe-volumes help
やること

こんな感じ。



VPCを作る
まずはVPCを作る。CIDRは10.0.0.0/16を指定。
$ aws ec2 create-vpc --cidr-block 10.0.0.0/16
{
    "Vpc": {
        "InstanceTenancy": "default",
        "State": "pending",
        "VpcId": "vpc-c92822ab",
        "CidrBlock": "10.0.0.0/16",
        "DhcpOptionsId": "dopt-3bdbbf50"
    }
}

Subnetを作る

Public SubnetとPrivate Subnetの二つのSubnetを作る。AZの指定が出来るので、二重化の観点だと意味が無いけど別々にしてみた。
$ aws ec2 create-subnet --vpc-id vpc-c92822ab --cidr-block 10.0.1.0/24 --availability-zone us-west-2a
{
    "Subnet": {
        "VpcId": "vpc-c92822ab",
        "CidrBlock": "10.0.1.0/24",
        "State": "pending",
        "AvailabilityZone": "us-west-2a",
        "SubnetId": "subnet-5694be22",
        "AvailableIpAddressCount": 251
    }
}
$ aws ec2 create-subnet --vpc-id vpc-c92822ab --cidr-block 10.0.2.0/24 --availability-zone us-west-2b
{
    "Subnet": {
        "VpcId": "vpc-c92822ab",
        "CidrBlock": "10.0.2.0/24",
        "State": "pending",
        "AvailabilityZone": "us-west-2b",
        "SubnetId": "subnet-9d858eff",
        "AvailableIpAddressCount": 251
    }
}

Internet Gatewayを作る

Public Subnetは外部からのアクセスを可能にしたいのでInternet Gatewayを作る。
$ aws ec2 create-internet-gateway
{
    "InternetGateway": {
        "Tags": [],
        "InternetGatewayId": "igw-1f878c7d",
        "Attachments": []
    }
}
作成したInternet GatewayはVPCにAttachしてやる必要がある。
$ aws ec2 attach-internet-gateway --internet-gateway-id igw-1f878c7d --vpc-id vpc-c92822ab
{
    "return": "true"
}

Route Tablesを作る

Route Tablesも二つ作る。一つはPublic Subnet用。
$ aws ec2 create-route-table --vpc-id vpc-c92822ab
{
    "RouteTable": {
        "Associations": [],
        "RouteTableId": "rtb-b9cec4db",
        "VpcId": "vpc-c92822ab",
        "PropagatingVgws": [],
        "Tags": [],
        "Routes": [
            {
                "GatewayId": "local",
                "DestinationCidrBlock": "10.0.0.0/16",
                "State": "active"
            }
        ]
    }
}
Public Subnet用のRoute TableはでInternet GatewayをDefault Gatewayとする。
$ aws ec2 create-route --route-table-id rtb-b9cec4db --destination-cidr-block 0.0.0.0/0 --gateway-id igw-1f878c7d
{
    "return": "true"
}
Public Subnet用のRoute TableをPublic Subnetに紐つける。
$ aws ec2 associate-route-table --subnet-id subnet-5694be22 --route-table-id rtb-b9cec4db
{
    "AssociationId": "rtbassoc-50f2f832"
}

もう一つはPrivate Subnet用。これはDefault Gatewayを持たず、VPCのCIDRにしか経路を持たない。
$ aws ec2 create-route-table --vpc-id vpc-c92822ab
{
    "RouteTable": {
        "Associations": [],
        "RouteTableId": "rtb-9acec4f8",
        "VpcId": "vpc-c92822ab",
        "PropagatingVgws": [],
        "Tags": [],
        "Routes": [
            {
                "GatewayId": "local",
                "DestinationCidrBlock": "10.0.0.0/16",
                "State": "active"
            }
        ]
    }
}
Private Subnet用のRoute TableをPrivate Subnetに紐つける。
$ aws ec2 associate-route-table --subnet-id subnet-9d858eff --route-table-id rtb-9acec4f8
{
    "AssociationId": "rtbassoc-51f2f833"
}
Security Groupを作る

EC2をLaunchする前にSecurityGroupを作成しておく。
$ aws ec2 create-security-group --group-name EC2s --description EC2s --vpc-id vpc-c92822ab
{
    "return": "true",
    "GroupId": "sg-46a3b424"
}
このSecurityGruopではInboundのSSH(Source IPはany)を許可する。
$ aws ec2 authorize-security-group-ingress --group-id sg-46a3b424 --protocol tcp --port 22 --cidr 0.0.0.0/0
{
    "return": "true"
}
EC2を作る

それではEC2のLaunchをする。Public Subnetを指定する。
$ aws ec2 run-instances --image-id ami-be1c848e --count 1 --instance-type t1.micro --key-name mykey --security-group-ids sg-46a3b424 --subnet-id subnet-5694be22
{
    "OwnerId": "8XXXXXXXXXXX",
    "ReservationId": "r-ba0b018e",
    "Groups": [],
    "Instances": [
        {
            "Monitoring": {
                "State": "disabled"
            },
            "PublicDnsName": null,
            "KernelId": "aki-fc8f11cc",
            "State": {
                "Code": 0,
                "Name": "pending"
            },
            "EbsOptimized": false,
            "LaunchTime": "2013-11-20T06:15:54.000Z",
            "PrivateIpAddress": "10.0.1.152",
            "ProductCodes": [],
            "VpcId": "vpc-c92822ab",
            "StateTransitionReason": null,
            "InstanceId": "i-d6a907e2",
            "ImageId": "ami-be1c848e",
            "PrivateDnsName": "ip-10-0-1-152.us-west-2.compute.internal",
            "KeyName": "mykey",
            "SecurityGroups": [
                {
                    "GroupName": "EC2s",
                    "GroupId": "sg-46a3b424"
                }
            ],
            "ClientToken": null,
            "SubnetId": "subnet-5694be22",
            "InstanceType": "t1.micro",
            "NetworkInterfaces": [
                {
                    "Status": "in-use",
                    "SourceDestCheck": true,
                    "VpcId": "vpc-c92822ab",
                    "Description": null,
                    "NetworkInterfaceId": "eni-44457930",
                    "PrivateIpAddresses": [
                        {
                            "Primary": true,
                            "PrivateIpAddress": "10.0.1.152"
                        }
                    ],
                    "Attachment": {
                        "Status": "attaching",
                        "DeviceIndex": 0,
                        "DeleteOnTermination": true,
                        "AttachmentId": "eni-attach-9f49d9ab",
                        "AttachTime": "2013-11-20T06:15:54.000Z"
                    },
                    "Groups": [
                        {
                            "GroupName": "EC2s",
                            "GroupId": "sg-46a3b424"
                        }
                    ],
                    "SubnetId": "subnet-5694be22",
                    "OwnerId": "865720186868",
                    "PrivateIpAddress": "10.0.1.152"
                }
            ],
            "SourceDestCheck": true,
            "Placement": {
                "Tenancy": "default",
                "GroupName": null,
                "AvailabilityZone": "us-west-2a"
            },
            "Hypervisor": "xen",
            "BlockDeviceMappings": [],
            "Architecture": "x86_64",
            "StateReason": {
                "Message": "pending",
                "Code": "pending"
            },
            "RootDeviceName": "/dev/sda1",
            "VirtualizationType": "paravirtual",
            "RootDeviceType": "ebs",
            "AmiLaunchIndex": 0
        }
    ]
}
同様にPrivate Subnetを指定してEC2を立てる。結果は省略。
$ aws ec2 run-instances --image-id ami-be1c848e --count 1 --instance-type t1.micro --key-name mykey --security-group-ids sg-46a3b424 --subnet-id subnet-9d858eff

まとめ

AWS Command Line Interfaceは豊富なコマンド/サブコマンドが用意されているので、Management Consoleでやってることはほぼ全部やれてしまう。
すごくhelpが充実しているので簡単に使える。こういった部分に力が入ってるのはホントAWSのすごさだなぁと思う。



Amazon Web Services クラウドデザインパターン実装ガイドAmazon Web Services クラウドデザインパターン実装ガイド
大澤 文孝,玉川 憲,片山 暁雄,鈴木 宏康

日経BP社
売り上げランキング : 79039

Amazonで詳しく見る by AZlink

コメント

このブログの人気の投稿

リモートワークは仕組みじゃなくて文化です

ここ最近、コロナウイルス関連の報道が数多くあるが、その中でも多くの企業がリモートワークを推奨するという記事やプレスリリースが注目を浴びている。それ自体はもちろん大変望ましい。不要な対面での接点を減らすことで感染リスクを抑えることが出来るし、通勤ラッシュや首都圏への経済集中も抑制出来るからだ。 だがちょっと待ってほしい。リモートワークというのは社員が在宅で働くことだけを指すのではない。 社員が在宅で働いても出社時と同じパフォーマンスが出ること をリモートワークというのだ。だからこの記事のタイトルで「リモートワークは仕組みじゃなくて文化です」と書いた。 弊社がリモートワークを導入したのは2011年の東日本大震災がきっかけだけれど、9年経った今、どのようにリモートワークを運用して、そしてパフォーマンスを維持しているかを共有したいと思う。以下のことが文化として根付けば、その会社のメンバーはリモートワークでもオフィスでも同じようなパフォーマンスが発揮出来るはずだ。 1.勤怠を厳密に管理しない え、だってダルくないすか。管理するの。何時に働き始めて何時に働き終わったかなんて関係ないっしょ。大事なのは働いた結果のアウトプットであり、働いた時間なんか問題じゃない。 2.休憩も厳密に管理しない え、だってダルくないすか。管理するの。何時に休憩し始め(ry 3.工数を厳密に管理しない え、だ(ry 4.目に見えるアウトプットを意識する 当然のことながら、仕事は結果が全てであり、結果が出なければどこで何時間働いたって意味がない。そして結果というのは目に見えなければ意味がない。 だからこそ、アウトプットを出すこと、アウトプットを評価することに徹底的にこだわる。それはドキュメントかもしれないし、お客様やパートナーとコミュニケーションするためのメールかもしれないし、社内の改善活動かもしれないし、メンバーへのフォローかもしれないし、ブログかもしれないし、Slackでの発言かもしれない。 とにかく目に見えないものは周りも認められない。目に見えるアウトプットしか評価されないし、そのために徹底的にアウトプットするんだ、という意識を社内でしっかりと作ることが重要。 5.コミュニケーションコストを意識する どんなに頑張っても、オンラインのコミ

これで完璧!本当に役立つテレワークマナー

コロナ禍によってテレワークを導入する企業が増えた昨今、皆様いかがお過ごしでしょうか。僕は4連休明けでダルかったので有給を取得し妻とデートしてきました。イェーイ。 さて、 弊社 も今年2月以降は全社員完全テレワークに移行しました。弊社は2011年からテレワークを導入し各自が自由に活用していたため、特に大きな問題も無くテレワーク体制に移行したのですが、全社員完全テレワークは初めての状況であり、幾つかの課題が発生しました。特に、その状況下でも新しく入社する社員がいますので、これまで社内で培ってきた暗黙の了解が共有出来ないことは大きな課題でした。 ということで、本記事では、弊社のテレワークマナーについてご紹介したいと思います。皆さんのご参考になれば幸いです。 業務の開始と終了はチャットで宣言する これはオフィス出社時でもテレワークでも変わらないのですが、業務開始時と業務終了時にはSlackで宣言しています。弊社ではこれを開店/閉店と呼んでいます。 気をつけて頂きたいのは、これは 報告ではなく共有である ということです。業務開始と業務終了を共有しておくことで、同僚が相談したり依頼をしたりできる時間を把握出来ます。この共有をしておかないと、業務開始前や業務終了後にMentionがバンバン飛んで来るかもしれません。もちろん飛んできたからって怒るメンバーはいないのですが、お互いちょっとした気遣いが出来るように、自分が働いている時間は共有しておくと良いでしょう。 これは休憩時間も同様です。昼休みにのんびりゲームしているときにスマホがブーブー鳴っていたら気が散るかもしれません。休憩開始と終了をSlackで宣言することでゆっくり休憩することが出来ます。休憩中は Display name の後ろに「休憩中」等と付けておくのも良いでしょう。 マイクとスピーカーはPC内蔵のものを使わない PCの性能は以前と比べて格段に上がっていますが、残念ながらマイクとスピーカーはそうではありません。マイクについては音質は向上しているものの、指向性が無いために周囲の音を拾ってしまいます。そしてPC操作時には、どうしても打鍵音がダイレクトに響いてしまいます。またスピーカーは、まぁ正直全く駄目です。音楽を聞くのにさえ向いていないのに、音声のやり取りなんか出来るわけがない。 マイクとスピーカーは必ず別に用意しましょ

ネガティブなフィードバックをする時に意識したい7つのこと

僕は現在は取締役兼事業本部長という立ち位置でお仕事させて頂いてますが、元々はエンジニアで、かつピープルマネージメントを15年以上しておりました。僕がマネジメントしたメンバーは合算すると200人以上になります。正直に言えば、楽しいことはたくさんあったけれど、もちろん辛いことも多々経験していまして、特にメンバーに対してネガティブなフィードバックをすることは大きな苦しみの一つです。 最近、自分の部署の若いマネージャーから、ネガティブなフィードバックを上手に行うことが難しく課題に感じている、という声があったので、僕の経験をまとめてみました。 ポジティブなフィードバックをセットにして伝える どんな人にとっても、悪い話を聞くことは楽しい経験ではありません。悪い話だけを聞き続けると、不愉快な感情が理性を覆い隠してしまいます。しかしフィードバックとは叱ることではなく、どのように改善していくかを議論するためのきっかけであり、感情的になることはマイナスに働きます。ネガティブなフィードバックを伝える時は、ポジティブなフィードバックをセットに、出来れば先に伝えます。良い点がない人はいません(そんな人は採用していないはずです)から、必ず褒めるポイント、褒めるべきアウトプットがあるはずです。ポジティブなフィードバックをセットすることで、相手の感情のバランスを取ることが出来ます。 ネガティブな内容を責めるのではなく事実として伝える 上述の通り、フィードバックの目的は叱責ではなく改善なので、「なんで出来ないんだ」とか「どうして出来なかったんだ」ではなく、事実としてのネガティブな現状を正確に伝えることが重要です。例えそれが叱責に値する内容であったとしても、どちらか一方が感情的になると必ずもう片方も感情的になるので、冷静に正しく事実のみを伝えます。 期待値を提示する ネガティブなフィードバックには、必ずあるべき姿、こちらが期待していた姿があるはずなので、それを伝えます。その際には一方的に伝えるのではなく、こちらの期待値を根拠と併せて伝え、その上で一緒にその期待値の妥当性を議論します。この期待値のすり合わせをしないと、メンバー本人の振り返りも生まれず、改善のためのアクションも「言われたからやる」だけになってしまいます。 なぜネガティブな結果になったのかをヒアリングする 人それぞれ様々な事情や環境がある