近いうちに AWS CLIコマンドで生成されるファイルは ~/.aws/config から ~/.aws/credentials に統合されるというお話

Route53 を DSL で管理する Roadworker は便利だからよく使っていたのですが、 AWS CLI 生成した ~/.aws/config を読み込んでくれなくてちょっと不便だなって思っていたのですが、 Roadworker で ~/.aws/config 読み込まないのはなんで?って質問したら

Want to read from AWS credentials from awscli generated config file · Issue #6 · winebarrel/roadworker

どうやら AWS SDK では ~/.aws/credentials を読み込むのが最近のトレンドのようだったのです。

A New and Standardized Way to Manage Credentials in the AWS SDKs – AWS Security Blog

確かに aws cli のドキュメント調べたらまずはじめに ~/.aws/credentials がないか調べますって書いてあって、だがしかし、 aws configure コマンドは ~/.aws/config ファイルを生成して、なんでかなあって不思議に思ってたんですよね。

Configuring the AWS Command Line Interface – AWS Command Line Interface

親切にも指定したクレデンシャルファイルを読み込むオプションをつけて実装してくださいました。
フィードバック速い!

で、肝心の AWS CLI に質問したら即効で答え返ってきました。
もうその議論はなされていてレビュー通ったらマージされて、リリースされるよって教えてくれました。
僕のすごいへたくそな英語にも親切に答えてくれる。
それなりに通じてるんだろうか・・・。あなたがチュキだからーみたいな感じになってないといいな。

aws configure may have to generate ~/.aws/credentials instead ~/.aws/config · Issue #918 · aws/aws-cli

楽しみだなあ。
issue を登録するだけで contribution graph に色が塗られるのは気持ちいいけど、コード的なコミットもしたいなあ。

いかにも貢献していますって感じでかっこいいじゃないですか。

ちなみに今の AWS CLI のバージョンは 1.4.4 です。
リリースされたらアップグレードしましょう。

pip install --upgrade awscli

あと、Roadworker はとってもオススメです。もっと Star ついてもいいと思う。
僕の尊敬している伊藤直也さんも使ってるので最高です。
いつか直也さんみたいなすごいエンジニアになりたい。

以上、半分以上僕の日記帳でした。

Vagrant AWS Provider を使ってみた

まずはダミーの box イメージをインポートする。

vagrant box add dummy https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box

そして次のような Vagrantfile を書く。
前提条件は以下。

  • IAMで予めEC2にアクセスを制限したユーザのクレデンシャルを払いだしておくこと
  • 使用するキーペアの名前は vagrant
  • 起動するインスタンスタイプは t2.micro (デフォルトだと m3.medium で起動してしまう)
  • Vagrant 用のセキュリティグループを定義してそれを使用
  • 東京リージョンを指定(ap-northeast-1)
  • 起動する AMI は Amazon Linux AMI 2014.03.2 (HVM) (ami-29dc9228)
  • SSH ユーザ名は ec2-user
  • 対応する秘密鍵の場所を指定する。
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
config.vm.box = "dummy"
config.vm.provider :aws do |aws, override|
aws.access_key_id = ""
aws.secret_access_key = ""
aws.keypair_name = "vagrant"
aws.instance_type = "t2.micro"
aws.security_groups = [ "vagrant" ]
aws.region = "ap-northeast-1"
# Amazon Linux AMI 2014.03.2 (HVM)
aws.ami = "ami-29dc9228"
override.ssh.username = "ec2-user"
override.ssh.private_key_path = "~/.ssh/aws-ec2-vagrant.pem"
end
end

そして

vagrant up --provider=aws

以下の様なエラーが出るが、ここでは気にしない。

==> default: Rsyncing folder: /Users/wnoguchi/Documents/tmp/vagrant-ec2/ => /vagrant
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
mkdir -p '/vagrant'
Stdout from the command:
Stderr from the command:
sudo: sorry, you must have a tty to run sudo

IPアドレス知らなくてもSSHできる。

vagrant ssh

グローバルIPが知りたければインスタンスメタデータcurl で取得する。

[ec2-user@ip-172-31-25-90 ~]$ curl -w "\n" http://169.254.169.254/latest/meta-data/public-hostname
ec2-54-64-60-151.ap-northeast-1.compute.amazonaws.com
[ec2-user@ip-172-31-25-90 ~]$ curl -w "\n" http://169.254.169.254/latest/meta-data/public-ipv4
54.64.60.151

あとは nginx 入れるなりなんなりして実験して、用が済んだら

vagrant halt

か潔く

vagrant destroy -f

References

  1. mitchellh/vagrant-aws
  2. インスタンスメタデータとユーザーデータ – Amazon Elastic Compute Cloud

AWSで2段階認証(MFA)を構成する(Android版: Google Authenticator使用)

AWSアカウントはGoogleアカウント、Amazonアカウントに次いで大事なアカウントです。
2段階認証、多要素認証、MFA(Multi-Factor Authentication)等々呼ばれ方は様々ですが、
AWSアカウントにも2段階認証を設定することができます。
AWSではMFA(Multi-Factor Authentication, 多要素認証)と呼ばれています。
今回はこれを設定します。

2段階認証を実行するプロセスにはSMSによるメッセージングもできるのですが、
ドコモとかだと海外からのSMSの受信制限とかがかかっていたりして、これを解除しないとうまく受け取れないことがあります。
最初GitHubから2段階認証のワンタイムパスワードを何度やってもSMSで受け取れなくて国コードが間違ってるんじゃないかとか、
先頭の0を取らないといけないじゃないかとか、GitHubのバグなんじゃないかと思いました。

ここではAndroidアプリのGoogle Authenticator(Google認証システム)を使用します。
Google AuthenticatorはGoogleの二段階認証にしか使えないのかと思っていたのですが、
他の2段階認証を採用しているシステムでも使えるようです。
便利ですねー。

MFAの設定を有効にする

  • Management Consoleにログイン後、右上のメニューから[Security Credentials]を選択します。

f:id:wnoguchi0727:20140812213056p:plain

  • あなたがアクセスしようとしているページはAWSアカウントのセキュリティクレデンシャルのページで、
    AWSアカウントのセキュリティクレデンシャルはAWSリソースへの無制限アクセスを提供するものだから
    AWSのベストプラクティスにならってIAMで制限されたユーザを作成してやったほうがいいよーと
    警告が表示されるので[Continue to Security Credentials]をクリックして先に進みます。

f:id:wnoguchi0727:20140812213051p:plain

  • 次に[Your Security Credentials]セクション内の[Multi-Factor Authentication(MFA)]を開いて
    [Activate MFA]ボタンをクリックします。

f:id:wnoguchi0727:20140812213054p:plain

  • [A virtual MFA device]を選択します。

f:id:wnoguchi0727:20140812213044p:plain

  • 要するに、Google Authenticatorを入れてねと書いてあります。

f:id:wnoguchi0727:20140812213045p:plain

  • QRコードが表示されました。
    この段階ではGoogle Authenticatorがインストール済みの前提で話を進めます。
    さらに厳重に認証コードを2連続で入力を促されます。
    そんなことできたんだ・・・。

f:id:wnoguchi0727:20140812213046p:plain

Google Authenticatorを起動する

さて、このQRコードを読み取るためにGoogle Authenticatorを起動します。
こんなアイコンのやつですね。

f:id:wnoguchi0727:20140812213053p:plain

  • [アカウントを設定]をタップします。

f:id:wnoguchi0727:20140812213052p:plain

f:id:wnoguchi0727:20140812213055p:plain

  • AWSアカウントのワンタイムパスワードを生成するところが現れたのがわかると思います。
    右側の円グラフのゲージがこの認証コードの有効な期間なので2回、この認証コードををさっきの認証コード入力欄に入力して[Next Step]をクリックします。

f:id:wnoguchi0727:20140812213050p:plain

  • これで2段階認証を行うためのGoogle AuthenticatorとAWSアカウントが紐付けられました。

f:id:wnoguchi0727:20140812213047p:plain

f:id:wnoguchi0727:20140812213048p:plain

実際にログインしてみる

実際に2段階認証が有効になったかサインアウトしてもう一度ログインしてみます。

  • ログインID、パスワードを入力します。

f:id:wnoguchi0727:20140812213057p:plain

  • 認証コードを求められるようになりました。
    ここでGoogle Authenticatorで生成される認証コードを期限内に入力してログインします。

f:id:wnoguchi0727:20140812213049p:plain

これでAWSアカウントに2段階認証を設定することができました。

デバイスが壊れた、紛失してログインできなくなってしまったら

GitHubやQiita等はリカバリコードが用意されていますが、AWSの場合は直接問合せする必要があるようです。
要注意。

Amazon Route53にレジストラとしての機能がついたのでさっそく使ってみた

帰ってきて何の気なしにAmazonからのメールをぼーっとみてると
「あーはいはい、またなんか機能追加したのね」ってそのまま即効でアーカイブしそうになったけど、

(2014-08-09追記 日本語ブログエントリ出てました)

Domain Name Registration

You can now purchase a new domain name or transfer the management of your existing domain name to Route 53. When you purchase new domains via Route 53, the service will automatically configure a Hosted Zone for each domain and ensure the privacy of your WHOIS record at no additional charge. In addition, you benefit from AWS‘s consolidated billing to manage your domain name expenses alongside all of your other AWS resources.

この文章見てもしかしてRoute53にレジストラとしての機能が実装されたのか?

って半信半疑で少しぐぐってみたけど日本語の情報全然ないから僕の英語力がおかしいのかと思ったんだけど、
ちょっと試してみました。

上の文章を要約すると

  1. Amazon Route53 でドメインのお買い物ができるようになりました(レジストラになりました)。
  2. ドメインの転送もできます。
  3. Route53 で購入したドメインは自動的に Hosted Zone が構成されます。
  4. 何もしなくてもWHOISレコードからプライバシーが保護されます。
  5. 支払いはAWSの他のサービスの利用料金と統合して請求されます。

ものは試しなのでやってみました

ドメイン買ってみる

  • Route53のダッシュボードでDomainsを選択

f:id:wnoguchi0727:20140802020330p:plain

foo-bar-blah.com はもう僕がお名前.comで取得しちゃっているので買えません。
foo-bar-blah.jp ドメインは $100 だそうです。ぼったくり価格w

f:id:wnoguchi0727:20140802020333p:plain

今回は foo-bar-blah.net を取得することにしました。
Continue をクリック。

f:id:wnoguchi0727:20140802020332p:plain

技術者情報を入力します。
WHOISで個人情報が大公開されないようにするために Privacy Protection を Yes とするのがポイント。

f:id:wnoguchi0727:20140802024714p:plain

最終的な確認画面。規約に同意したらチェックして購入を確定する。

f:id:wnoguchi0727:20140802020335p:plain

ドメインの登録リクエストが正常に送信されたことが確認できる。

f:id:wnoguchi0727:20140802020336p:plain

ダッシュボードに戻ってみると Domain Registration in Progress となっており、登録中であることがわかる。

f:id:wnoguchi0727:20140802020337p:plain

しばらくすると Domains のメニューで選択した時の一覧に先ほど購入したドメインがリストアップされた。

f:id:wnoguchi0727:20140802020339p:plain

Hosted Zoneも自動的に構成されており、すぐに A レコード等を追加して使いはじめることができるようになっていた。

f:id:wnoguchi0727:20140802023645p:plain

すごいな・・・。

ドメイン移管してみる

お名前.comで取得したちょうど期限が切れそうなドメインが合ったのでRoute53に転送しました。

まずは Transfer Domain をクリックする。

f:id:wnoguchi0727:20140802020338p:plain

移管したいドメインを検索する。
今回はもうすぐ有効期限が切れそうなドメイン cloud-clipboard.com を選択した。

f:id:wnoguchi0727:20140802020340p:plain

AuthCode 等を入力して確定。

f:id:wnoguchi0727:20140802020341p:plain

これで移管の申請は完了。

f:id:wnoguchi0727:20140802020342p:plain

たぶんもう少ししたら結果出ると思う(2014/08/01深夜)。

Domain transfer in progress となり、ドメイン移管の手続きが始まったようです(2014/08/02朝)。

f:id:wnoguchi0727:20140802085611p:plain

Geographic Routing with Geo DNS の項についてはよくわかりませんでしたが、
負荷分散的な話でしょうか。誰か教えてください。。。

Lower Prices for DNS Queries では 8/1 から Route53 へのクエリ問合せが20%安くなったよって言ってるんでしょうか。

うーん、英語は難しいですね。

awscliでec2インスタンスを操作する

よく忘れるので基本的な操作方法のまとめ。

インスタンスの操作

インスタンスを作成

  • AMI IDを調べてメモる
  • 立ち上げたいインスタンス
  • インスタンスタイプ: 現状t2.microが最小(2014/7/8現在)
  • 使用するキーペア
  • 適用するセキュリティグループ
% aws ec2 run-instances --image-id ami-29dc9228 --count 1 --instance-type t2.micro --key-name default --security-groups hoge | jq '.'

AZを指定する

--placement AvailabilityZone=ap-northeast-1a をつけてやればいい。

aws ec2 run-instances --image-id ami-29dc9228 --count 1 --instance-type t2.micro --key-name default --security-groups web --placement AvailabilityZone=ap-northeast-1a | jq '.'

DeleteOnTerminationを避ける

今ではほとんどEBSから起動されるEC2インスタンスがほとんどだが、このままでは DeleteOnTermination=true となってしまっているので、インスタンスをterminateするとインスタンスに紐付けられているボリューム自体も削除されてしまう。

これを避けたいなら

% aws ec2 run-instances --image-id ami-29dc9228 --count 1 --instance-type t2.micro --key-name default --security-groups hoge \
--block-device-mappings "[{\"DeviceName\": \"/dev/xvda\",\"Ebs\":{\"DeleteOnTermination\": \"false\"}}]" | jq '.'

としなければならない。面倒だが。

既に作成されたインスタンスについて DeleteOnTermination=true としたい場合は

% aws ec2 modify-instance-attribute --instance-id i-dfff36d1 --block-device-mappings "[{\"DeviceName\": \"/dev/xvda\",\"Ebs\":{\"DeleteOnTermination\": \"false\"}}]" | jq '.'

とすればいい。

インスタンスを起動

% aws ec2 start-instances --instance-ids i-xxxxxxxx | jq '.'

インスタンスを停止

% aws ec2 stop-instances --instance-ids i-xxxxxxxx | jq '.'          

停まったかどうか確認。

% aws ec2 describe-instances --instance-ids i-xxxxxxxx | jq -r '.Reservations [] .Instances [] .State .Name'
stopped

インスタンスを削除(terminate)

% aws ec2 terminate-instances --instance-ids i-xxxxxxxx | jq '.'

jqで欲しい値をとってくる

インスタンスID

% aws ec2 describe-instances | jq -r '.Reservations [] .Instances [] .InstanceId'
i-xxxxxxxx

グローバルIPアドレス

% aws ec2 describe-instances | jq -r '.Reservations [] .Instances [] .PublicIpAddress'
xxx.xxx.xxx.xxx

PublicDNS名

% aws ec2 describe-instances | jq -r '.Reservations [] .Instances [] .PublicDnsName'
ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com

SSHで接続するとき

単なる覚え書き。

ssh ec2-user@xxx.xxx.xxx.xxx -i ~/.ssh/foobar.pem

References

  1. run-instances — AWS CLI 1.3.21 documentation
  2. start-instances — AWS CLI 1.3.21 documentation
  3. stop-instances — AWS CLI 1.3.21 documentation
  4. terminate-instances — AWS CLI 1.3.21 documentation
  5. describe-instances — AWS CLI 1.3.21 documentation

awscliでt1.microインスタンスをたちあげようとしたら怒られたでござる

t1.microインスタンスawscliから立ち上げようとAMI ID調べて立ち上げようとしたら失敗した。

% aws ec2 run-instances --image-id ami-29dc9228 --count 1 --instance-type t1.micro --key-name default --security-groups hoge | jq '.'
A client error (InvalidParameterCombination) occurred: Non-Windows instances with a virtualization type of 'hvm' are currently not supported for this instance type.

このインスタンスタイプはサポートしてないぞゴルァ!と怒られてしまいました。
しかたなくManagement Consoleからどんなタイプが選べるのか確認してみると t2.micro というインスタンスタイプが・・・。
「無料枠に最適!」って書いてあったのでこれで立ち上げてみました。

% aws ec2 run-instances --image-id ami-29dc9228 --count 1 --instance-type t2.micro --key-name default --security-groups hoge | jq '.'
{
"Instances": [
{
(snip)
}
],
"Groups": [],
"ReservationId": "r-ffffaaaa",
"OwnerId": "ffffffffffff"
}

うーん、今度からはt1.microインスタンスじゃなくてt2.microインスタンスっていう新しい最小のインスタンスタイプが追加された?変更された?みたいだ。
発表は2014/7/1とタイムリー。
T2インスタンスにはCPUクレジットという概念が追加されたみたい。
バーストするけど、クレジット消費してしまっても極端には性能は落ちませんよってことかな?

References

  1. dogmap.jp を t1.micro から t2.micro に変更してみました | dogmap.jp
  2. Amazon Web Services ブログ: 【AWS発表】バースト可能な性能を持つ新しい低コストEC2インスタンス

awscliでセキュリティグループを定義する

このへんは手でやったほうが早い気がしないでもない。
CloudFormationとかだといろいろよろしくやってくれるんだろうか。
まだその辺の境地にも達してないけど・・・。

セキュリティグループの作成

% aws ec2 create-security-group --group-name web --description "Web server role security group."
{
"return": "true",
"GroupId": "sg-ffffffff"
}

Inbound方向の規則を定義する

ping(ICMP)応答

aws ec2 authorize-security-group-ingress --group-name web --protocol icmp --port -1 --cidr "0.0.0.0/0" | jq '.'
{
"return": "true"
}

SSH

% aws ec2 authorize-security-group-ingress --group-name web --protocol tcp --port 22 --cidr "0.0.0.0/0" | jq '.'
{
"return": "true"
}

HTTP

% aws ec2 authorize-security-group-ingress --group-name web --protocol tcp --port 80 --cidr "0.0.0.0/0" | jq '.'
{
"return": "true"
}

Outbound方向

Outbound(authorize-security-group-egress)方向はデフォルトで全通過。

まとめると

aws ec2 create-security-group --group-name web --description "Web server role security group." | jq '.'
aws ec2 authorize-security-group-ingress --group-name web --protocol icmp --port -1 --cidr "0.0.0.0/0" | jq '.'
aws ec2 authorize-security-group-ingress --group-name web --protocol tcp --port 22 --cidr "0.0.0.0/0" | jq '.'
aws ec2 authorize-security-group-ingress --group-name web --protocol tcp --port 80 --cidr "0.0.0.0/0" | jq '.'

逆の操作

セキュリティグループに対して以下の様な操作を行うと22番ポートが封じられるのでSSH不能になる。
CIDRまできちんと記述しないといけないので注意。

aws ec2 revoke-security-group-ingress --group-name web --protocol tcp --port 22 --cidr "0.0.0.0/0" | jq '.'

ただし、ICMP規則を削除するときは

aws ec2 revoke-security-group-ingress --group-name web --protocol icmp --port -1 --cidr "0.0.0.0/0" | jq '.'

に関してはいったんpingを止めないとpingをずっと受け入れ続けてしまうみたいなので、いったん Ctrl+C でとめてからもう一回pingを打ってみると通らなくなることが確認できる。

References

  1. authorize-security-group-ingress — AWS CLI 1.3.21 documentation
  2. authorize-security-group-egress — AWS CLI 1.3.21 documentation

awscliでキーペア(鍵ペア)を生成する

意外と簡単。あとは jq で見せ方を工夫すればOK。
ここではVagrantのinsecure private keyをダミーとして使用。

% aws ec2 create-key-pair --key-name default | jq -r '.KeyMaterial' | tee ~/.ssh/aws-ec2-default.pem && chmod 600 ~/.ssh/aws-ec2-default.pem
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzI
w+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9HZyN1Q9qgCgzUFtdOKLv6IedplqoP
kcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIFo9D8HfdOV0IAdx4O7PtixWKn5y2
hMNG0zQPyUecp4pzC6kivAIhyfHilFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NO
Td0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcW
yLbIbEgE98OHlnVYCzRdK8jlqm8tehUc9c9WhQIBIwKCAQEA4iqWPJXtzZA68mKd
ELs4jJsdyky+ewdZeNds5tjcnHU5zUYE25K+ffJED9qUWICcLZDc81TGWjHyAqD1
Bw7XpgUwFgeUJwUlzQurAv+/ySnxiwuaGJfhFM1CaQHzfXphgVml+fZUvnJUTvzf
TK2Lg6EdbUE9TarUlBf/xPfuEhMSlIE5keb/Zz3/LUlRg8yDqz5w+QWVJ4utnKnK
iqwZN0mwpwU7YSyJhlT4YV1F3n4YjLswM5wJs2oqm0jssQu/BT0tyEXNDYBLEF4A
sClaWuSJ2kjq7KhrrYXzagqhnSei9ODYFShJu8UWVec3Ihb5ZXlzO6vdNQ1J9Xsf
4m+2ywKBgQD6qFxx/Rv9CNN96l/4rb14HKirC2o/orApiHmHDsURs5rUKDx0f9iP
cXN7S1uePXuJRK/5hsubaOCx3Owd2u9gD6Oq0CsMkE4CUSiJcYrMANtx54cGH7Rk
EjFZxK8xAv1ldELEyxrFqkbE4BKd8QOt414qjvTGyAK+OLD3M2QdCQKBgQDtx8pN
CAxR7yhHbIWT1AH66+XWN8bXq7l3RO/ukeaci98JfkbkxURZhtxV/HHuvUhnPLdX
3TwygPBYZFNo4pzVEhzWoTtnEtrFueKxyc3+LjZpuo+mBlQ6ORtfgkr9gBVphXZG
YEzkCD3lVdl8L4cw9BVpKrJCs1c5taGjDgdInQKBgHm/fVvv96bJxc9x1tffXAcj
3OVdUN0UgXNCSaf/3A/phbeBQe9xS+3mpc4r6qvx+iy69mNBeNZ0xOitIjpjBo2+
dBEjSBwLk5q5tJqHmy/jKMJL4n9ROlx93XS+njxgibTvU6Fp9w+NOFD/HvxB3Tcz
6+jJF85D5BNAG3DBMKBjAoGBAOAxZvgsKN+JuENXsST7F89Tck2iTcQIT8g5rwWC
P9Vt74yboe2kDT531w8+egz7nAmRBKNM751U/95P9t88EDacDI/Z2OwnuFQHCPDF
llYOUI+SpLJ6/vURRbHSnnn8a/XG+nzedGH5JGqEJNQsz+xT2axM0/W/CRknmGaJ
kda/AoGANWrLCz708y7VYgAtW2Uf1DPOIYMdvo6fxIB5i9ZfISgcJ/bbCUkFrhoH
+vq/5CIWxCPp0f85R4qxxQ5ihxJ0YDQT9Jpx4TMss4PSavPaBH3RXow5Ohe+bYoQ
NE5OgEXk2wVfZczCZpigBKbKZHNYcelXtTt/nP3rsCuGcM4h53s=
-----END RSA PRIVATE KEY-----

ダブルクォーテーションを消すのには jq の -r オプションを使ってます。
teeコマンドは標準出力にもちゃんとできたこと見せたいから。

References

  1. create-key-pair — AWS CLI 1.3.21 documentation
  2. jqに痺れた … AWS CLIで演習など – OpenGroove
  3. teeコマンドの使い方 – Qiita
  4. vagrant/keys/vagrant at master · mitchellh/vagrant

awscliでキーペア(鍵ペア)を一括削除する

概要

AWSAPIの練習とシェルスクリプトの練習も兼ねてる。

AWS APIを叩く練習をしていてキーペアをいっぱい作っちゃいました。
こんな感じ。

% aws ec2 describe-key-pairs| jq -r '.KeyPairs [] .KeyName'
default
default2
default3
default4
default5
default6
default7
default8

ちなみにjqの -r オプションはダブルクォーテーションを消してくれるオプション。

これらのキーペアを消したい。

find+xargsを使う(失敗)

find+xargsの組合せに慣れてるから以下の様な感じにしたくなる。

aws ec2 describe-key-pairs | jq -r '.KeyPairs [] .KeyName' | xargs aws ec2 delete-key-pair --key-name
Unknown options: default3, default4, default5, default6, default7, default8, default2

でもエラー。xargsのmanページをよく見てみる。

Man page of XARGS

xargs は標準入力から読み込んだ一連の項目をその後ろに 追加していく (訳注: 作成されたコマンドラインが、
コマンドライン長の上限を 越える場合や、オプションによる特別な指定がある場合は、入力を適宜分割して、
command を複数回実行することになる)。標準入力における空行は無視する。

そういえば

find | xargs rm

find | xargs grep hoge

は引数に複数のエントリをもたせられた気がする・・・。

1個ずつ削除したいのでこれは使えない。

while+readを組み合わせる(成功)

aws ec2 describe-key-pairs | jq -r '.KeyPairs [] .KeyName' | while read key; do
aws ec2 delete-key-pair --key-name $key
done

これならどうだ。

% aws ec2 describe-key-pairs | jq -r '.KeyPairs [] .KeyName' | while read key; do
pipe pipe while> aws ec2 delete-key-pair --key-name $key
pipe pipe while> done
{
"return": "true"
}
{
"return": "true"
}
{
"return": "true"
}
{
"return": "true"
}
{
"return": "true"
}
{
"return": "true"
}
{
"return": "true"
}
{
"return": "true"
}

あっ、うまくいった。
やったきもちいいいいい。

References

  1. jq
  2. jqに痺れた … AWS CLIで演習など – OpenGroove
  3. jqコマンドを使ってみた – mknkisk report
  4. Bash – パイプ出力を現在のシェル上のwhileに喰わせる上手いやり方 – Qiita