POSIX準拠なシェルスクリプトだけでAWSを操りたい!〜POSIX原理主義でクラウドも侵略〜

  • 6
    Like
  • 0
    Comment

この記事は、POSIX原理主義とシェルショッカー日本支部に感化されちゃって、なんとか実践しようとしている、なんちゃって雑魚戦闘員がお送りします。POSIX原理主義でもクラウドを侵略できますよ、というお話です。これで、POSIX原理主義がますます強力になれるんじゃないかと勝手に思っています。

まずコマンドの紹介から、

axs - UNIX哲学を守ったつもりのsimpleなawsコマンド

A simple 'aws' command 'axs' written in POSIX sh. axs(access) to aws(amazon web services) with posixism.

このコマンドは、AmazonWebServicesにアクセスし、数々のwebサービスを利用したり、アプリを構築したりするために作られた、POSIX原理主義に基づく、なんちゃってawsコマンドです。aws cliは使用しておらず。シェルスクリプトのみでAWS version4署名を生成しています。

https://github.com/BRAVEMAN-L-BRID/axs

作った経緯

AWS APIツールは「いつでも、どこでも、すぐ」使えるわけではない。

バージョン依存や環境依存の大きい、AWS APIツールはいつでもどこでもすぐに使えるわけではありません。それに加えて、SDKやCLIも、それらをインストールできない環境だと、そもそも役に立ちません。意外なこと使えない環境を目にする機会も多いです。

しかしながら、環境やバージョンアップに悩まされずにAWSのサービスを利用したい、というニーズも時にはあるのではないでしょうか?
浅くネットサーフィンした限りでは、そのように認識しています。

このaxsコマンドは、そのニーズに応えるために作りました。

POSIX shに準拠しているつもりなので、Windows, Mac, Linuxなどで、それこそコピーしてくるだけで「いつでも、どこでも、すぐ」動きます。

大量のオプション、引数からの解放

作った経緯2です。awsコマンドの大量の引数やオプション、サービスごとに異なる数々のサブコマンドにヘキヘキした覚えはありませんか?私はあります。
あれはUNIX哲学を守っていません。コマンドとクラウドへ渡すパラメーターがぐちゃぐちゃに混ざったシェルスクリプトを書くのは、もう、こりごりです。

このコマンドでは、その煩わしさから解放されます(嘘、かもしれません)。また、UNIX哲学を守ったつもりで、RESTfulの概念も大事にしています。直感的な操作が可能かもしれません。

スクリプトを使った自動化も楽になる可能性があります。

使い方

ダウンロードしたら、このリポジトリの/binディレクトリにPATHを通してください。

0. 準備

~/.aws/credentialsファイルに以下のようにアクセスキーIDとシークレットアクセスキーを記述してください。パーミッションには気を付けてください。

[default]
aws_access_key_id = hogehoge
aws_secret_access_key = mogemoge

1. 基本

使い方は簡単です。設定ファイル(データ形式は後述)をaxsコマンドで読み込むだけです。

例えば、catコマンドを使って

$cat config_file | axs

とできますし、もしくは、引数に設定ファイルを置くだけです

$axs config_file

2. 設定ファイルのデータ形式について

AWSはREST APIを用いています。そこで、今回は、正しいのかどうかは横に置いておいて、HTTPにちなんだデータ形式の設定ファイルを記述します。

以下のような形式をとることにしました。

METHOD URI                    (←リクエストライン)
Key Value                   (←キーバリュー形式に分解したクエリ)
key Value                   (←キーバリュー形式に分解したクエリ)
Key Value                     (←キーバリュー形式に分解したクエリ)
Host: ec2.ap-northeast-1.amazonaws.com  (←必須ヘッダー)
Content-Type: application/hoghoge     (←場合によっては必須のヘッダー)
X-Amz-moge: hogehogehoge                (←設定などの追加のヘッダー)

(bodyの部分コンテンツの中身)
xmlとかjsonとかバイナリデータ         (←コンテンツの中身)

基本的に、Host,Content-Typeヘッダのみが必須だと考えてもらっていいです。

AWS APIを利用するので、body部には、基本的にxmlやjsonを記述します。

ただし、場合によっては画像ファイルや音声ファイルなどのバイナリデータをアップロードしなければならない時もあります。また、xml,jsonが長く煩雑な時は、リクエストライン、クエリ、ヘッダまでの部分とbody部を分離したいと思う時もあるでしょう。

そのような時に、axsコマンドの-fオプションを使います。

3. -fオプション

body部を分離して別ファイル(body.txtなど)にしてaxsコマンドを使う場合には以下のようにします。
※ここではヒアドキュメントを使用しています。

$cat<<END | axs -f moon.jpg
PUT /image.jpg
Host: Bucket.s3.amazonaws.com (東京リージョンの場合はbucket.s3-ap-northeast-1.amazonaws.com)
Content-Type: image/jpeg
END

*この例では、ローカルのmoon.jpgという画像ファイルをs3のBucketバケットにimage.jpgという名前で保存しています。

4. -qオプション

 これはAPIアクセス後に返ってくる、レスポンスのレスポンスヘッダーを表示するかいなかを決定するオプションです。
 デフォルトではレスポンスヘッダを表示します。AWSのREST APIがヘッダ情報をよく扱うので、汎用性を高めるためにそうのようにしてあります。

例えば、以下のような違いになります。

$cat config_file | axs 

HTTP 200  OK
hoge: hogehoge
hage: hagehoge
hoga: hogレスポンスヘッダー

<xml ......>
<DescribeInstances>...........</...>
.......

-qオプションを利用した場合は、レスポンスヘッダが省略されxmlやjsonやバイナリが直に帰ってきます。ですので、パイプでつないで加工したりするのに便利です。


cat config_file | axs -q > polly.mp3
               (pollyに喋ってもらう)


cat config_file | axs -q | parsrx.sh(POSIX原理主義製xmlパーサー)
               (xmlが返ってくる)


cat config_file | axs -q | parsrj.sh(POSIX原理主義製jsonパーサー)
               (jsonが返ってくる)

TIPS

  • 設定ファイルの書き方は、AWS API referenceなどを参照してください。設定ファイルの記述はクエリ部分以外はHTTPと同じです。
    深く悩まずに記述できることでしょう。

  • Content-Lengthヘッダ,x-amz-content-shaナンチャラヘッダ,Autorizationヘッダは自動生成されるので、考慮する必要はありません。

  • 私も仲間に加えてもらった秘密結社シェルショッカー日本支部のPOSIX原理主義製の他コマンドと相性がいいです。
    これを機に秘密結社シェルショッカー日本支部よりダウンロードしてくることをお勧めします。
    中でもmojihameコマンドとの相性は抜群です。https://github.com/ShellShoccar-jpn/installer

例えば、クエリAPIとmojihameコマンド

テンプレファイルを用意します、template

GET /
QUERY
%1 %2
QUERY
Version 2016-11-15
Host: ec2.ap-northeast-1.amazonaws.com
Content-Type: application/x-www-form-urlencoded

設定の用意、config.txt

Action Hogehoge
AAAAA dededed
hogemoge ahahaha

いざアクセス

cat config.txt | mojihame -lQUERY template - | axs -q | parsrx.sh | 加工

素晴らしいparsrsのコマンドを用いれば、無駄に多くのコマンドを用いずにレスポンスの解析もできます

ちなみに

cat config.txt | mojihame -lQUERY template -

までの結果だけ抜き出すと以下のようになっています。

GET /
Action Hogehoge
AAAAA dededed
hogemoge ahahaha
Version 2016-11-15
Host: ec2.ap-northeast-1.amazonaws.com
Content-Type: application/x-www-form-urlencoded

実際にAWSにaxs(アクセス)してみよう!

以下の内容ではシェルショッカー日本支部の開発しているコマンドを多く使うかもしれません。mojihameコマンドとParsrsは必須です。また、記述の簡略化のために、ヒアドキュメントを多用します。

S3にアクセスして、東京リージョンで静的webサイトのホスティングをしてみよう!

0.好きな名前のbucketをおく(PUTする)

cat <<END | axs
PUT /
Host: BucketName.s3-ap-northeast-1.amazonaws.com
Content-Type: application/xml

<CreateBucketConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> 
  <LocationConstraint>ap-northeast-1</LocationConstraint> 
</CreateBucketConfiguration >
END

1.bucketの中に公開するオブジェクトindex.htmlをおく(PUTする)

公開するものなので、誰でも読み込み可能にするために、設定として追加のヘッダx-amz-acl: public-readを付与しています。

cat <<-END | axs -f index.html     (←ローカルファイル)
PUT /index.html
Host: BucketName.s3-ap-northeast-1.amazonaws.com
Content-Type: text/html
x-amz-acl: public-read
END

2.bucketの中に公開するオブジェクトerror.htmlをおく(PUTする)

これは、エラーページ用のhtmlです。

cat <<END | axs -f error.html
PUT /Error.html 
Host: BucketName.s3-ap-northeast-1.amazonaws.com
Content-Type: text/html
x-amz-acl: public-read
END

3.bucketの中に公開するオブジェクトimage.jpgをおいて(PUTする)、やっぱり消す(DELETE)

index.htmlに載せる画像をbucketにputしましたが、気に入らなかったのでやっぱりDELETEすることにしました。

cat <<END | axs -f moon.jpg
PUT /image.jpg
Host: BucketName.s3-ap-northeast-1.amazonaws.com
Content-Type: text/html
x-amz-acl: public-read
END

やっぱり気に入らないので消す

cat <<END | axs
DELETE /image.jpg
Host: BucketName.s3-ap-northeast-1.amazonaws.com
END

4.バケットをウェブサイト用に修正する(PUTする)

s3を静的webサイトとして活用します。

s3のwebサイトホスティングでは、ルーティングルールを使用して、特定のHTTPエラーコードをチェックする条件を指定できます。ルールを追加すれば、リクエストエラーが発生した場合、リクエストを再ルーティングしたりできます。つまりwebサイトの機能を持たせることができるのです。

たとえば、リクエストエラーを処理し、別のホストにルーティングしてみましょう。次のルーティングルールは、HTTPエラー404のイベントでEC2インスタンスにリダイレクトします。

ExamplePage.htmlページをリクエストしてHTTP 404エラーが発生したとします。すると、そのリクエストは、指定されたEC2インスタンスのreport-404/testPage.htmlに再ルーティングされます。ルーティングルールが存在しない状態で、HTTPエラーが発生した場合には、Error.htmlを返します。

cat <<END | axs
PUT /
website
Host: BucketName.s3-ap-northeast-1.amazonaws.com
Content-Type: application/xml

<WebsiteConfiguration xmlns='http://s3.amazonaws.com/doc/2006-03-01/'>
  <IndexDocument>
    <Suffix>index.html</Suffix>
  </IndexDocument>
  <ErrorDocument>
    <Key>Error.html</Key>
  </ErrorDocument>

  <RoutingRules>
    <RoutingRule>
    <Condition>
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals >
    </Condition>
    <Redirect>
      <HostName>ec2-11-22-333-44.compute-1.amazonaws.com</HostName>
      <ReplaceKeyPrefixWith>report-404/</ReplaceKeyPrefixWith>
    </Redirect>
    </RoutingRule>
  </RoutingRules>
</WebsiteConfiguration>

5.TIPS:独自ドメインで静的webサイトを公開する場合

上記までの設定を用いて、s3で静的webサイトのホスティングを行うと、webサイトの公開アドレスは、AWS側で決定されたendpoitとなります。例えばs3-website.s3.amazonaws.comのようなものです。

しかし、自分のドメインでwebサイトを公開したいと思う時もあるでしょう。

その場合は、バケット名を独自ドメイン名にして、Route53で設定してあげれば可能です。

例えば、あなたの所得したドメインがwebsite.comだった場合。バケット名をwebsite.comにします。あとは、Route53で設定してあげると、website.comでwebサイトを公開できます。

6.TIPS:独自ドメインのバケットを用いるときの注意

独自ドメインでサイトを公開しない通常の時は、以下のようにホストヘッダにバケットの名前を含めることができます。そしてこちらの方がレファレンス的には正しいです。

cat <<END | axs
PUT /
website
Host: BucketName.s3-ap-northeast-1.amazonaws.com
END

なおこの場合のwebサイトのアドレス以下のようになります。

http://BucketName.s3-website-ap-northeast-1.amazonaws.com

しかし、独自ドメインをバケット名に使用し、ホストヘッダに含める場合は、axsコマンドでは、エンドポイントの名前解決ができません。したがってドメイン名のバケットを作る場合には、ターゲットuriにバケット名を含めます。

cat <<END | axs -f index.html
PUT /website.com/index.html
Host: s3.amazonaws.com
Contetnt-Type: text/html
END

この操作では、us-east-1リージョンにあるwebsite.comバケットに、index.htmlをPUTしています。なおAWS APIで用いるendpointについては、レファレンスを参照してください。サービスとリージョンごとに形式が異なる場合が多いです。
http://docs.aws.amazon.com/ja_jp/general/latest/gr/rande.html

7.TIPS:ヒアドキュメントで記述した内容を設定ファイルに残したい

そんな時はteeコマンドを使います 。ヒアドキュメントに記述した内容がconfig_fileに保存されます。

cat <<END | tee config_file | axs
GET /
Host: s3.amazonaws.com
END

Amazon Pollyにアクセスして音読させてみよう!

Amazon Pollyはテキストの音声変換サービスです。誰でも非常に簡単に利用できるサービスで、AWSの中でも敷居は低いです。とりあえずやってみましょう。何かのアプリ開発に役に立つかもしれません。

また、AWSのフルマネージドサービスなので利用者がインフラ構成やコーディングについて心配する必要は微塵もありません。東京リージョンでは利用できないので注意してください。

なお、ここではmojihameコマンドを使います

1.テンプレートファイル speech.templateを用意します。

お馴染みのHTTP形式の設定ファイルのテンプレです。使い回しが可能なので、メンテナンス効率は上がるかもしれません。aws cliのようにパラメータとコマンドをごちゃまぜにしたスクリプトを書く必要がなくなります。

POST /v1/speech
Host: polly.us-east-1.amazonaws.com
Content-Type: application/json

{
  "OutputFormat": "mp3",
  "Text": "%1",
  "VoiceId": "Mizuki"
}

2.pollyにアクセスしておしゃべりしよう!

ここまできたら簡単、あとはAmazon Pollyにアクセスしておしゃべりするだけです。

$echo "こんにちはQiita" | mojihame polly.template - | axs -q > result.mp3

ちなみにaxsコマンドの前までを抜き出すと以下のようになっています。

POST /v1/speech
Host: polly.us-east-1.amazonaws.com
Content-Type: application/json

{
  "OutputFormat": "mp3",
  "Text": "こんにちはQiita",
  "VoiceId": "Mizuki"
}

3.長文の小説もPollyに喋ってもらうことができます。

「小説家になろう」というサイトから小説をもらってきて、pollyに音読させましょう。pollyには文字数制限がありますので、何文字かに区切ってリクエストを出し、返ってきたレスポンスを対象ファイルに上書きしていきましょう。

下記のcurl先のurlのncode下の番号は小説とページによって異なります。

$curl http://ncode.syosetu.com/txtdownload/dlstart/ncode/XXXXXXXX/ | 
tr -d '\n' | 
sed 's/.\{250\}/&@/g' | 
tr '@' '\n' | 
while read LINE; do 
echo $LINE | mojihame polly - | axs -q ; 
done >> polly.mp3

EC2にアクセスしてインスタンスを立ててみよう!

このセクションではmojihameコマンドとparsrx.shを使います。

0.テンプレートファイルec2.templateの用意

以下のファイルはmojihameコマンドで使います。

GET /
QUERY
%1 %2
QUERY
Version 2016-11-15
Host: ec2.ap-northeast-1.amazonaws.com
Content-Type: x-www-form-urlencoded

1.VPCを作ろう

cat <<END                       | 
Action CreateVpc
CidrBlock 10.0.0.0/16
END
mojihame -lQUERY ec2.template - | 
axs -q                          |
parsrx.sh                       | 
grep 'vpcId'                    | 
awk '{print $2}'

(結果としてvpcIdが表示されます)

ヒアドキュメントではなく、config_file1に設定項目であるAction CreateVpcとCidrBlock 10.0.0.0/16を記述したとしたら以下のようになワンライナーになります。

 cat config_file1 | mojihame -lQUERY ec2.template - | axs -q | parser.sh | grep 'vpcId' | awk '{print $2}'

2.puclic-subnetを作ろう

作成したvpcにinternet gatewayをアタッチし、パブリックサブネットを作成します。以下省略

3.ec2インスタンスを立てよう

作成したpublic-subnet内にec2インスタンスを作成します。以下省略

今回は面倒臭かったので色々省略しましたが、1、2、3の流れは全て簡潔で似通っています。次回があれば、AWS上に3-tierアーキテクチャを構成する完全自動化スクリプトを組んでみたいと思います。もちろんaxsコマンドを使って。

Amazon Rekognitionにアクセスして画像解析してみよう!

Amazon Rekognitionは、深層学習により、画像解析を行なってくれるAWSのフルマネージドサービスです。ユーザーがコーディングの心配をすることなく、簡単にすぐに、どこでも利用することができます。非常に利便性が高く、将来必要不可欠になるであろうサービスの一つです。

1.S3にバケットを配置して、顔を含んだjpeg画像を置いてみる

リージョンはusを選択してください。他リージョンではまだサービスを開始していません。

  • バケットを作る
cat <<END | axs
PUT /
Host: s3-to-rekognition.s3.amazonaws.com
END
  • 画像ファイルを配置する
cat <<END | axs -f my-face.jpg
PUT /my-face.jpg
Host: s3-to-rekognition.s3.amazonaws.com
Content-Type: image/jpeg
END

2.Rekognitionで画像解析して、要素を抽出してみる

これにはDetectLabels APIを使用します。

DetectLabelsは、入力として提供される画像(JPEGまたはPNG)内における実世界の要素を検出して、ラベルを付与します。花、木、テーブルなどのオブジェクトは当然含まれ、さらには、結婚式、卒業、誕生日パーティーのようなイベントシーン、風景、夕方、自然などの概念までが含まれます。

結果は整形されていないjsonで帰ってきます。これでは読み取りづらいので、ヘッダ情報を排して、jsonパーサーにかけてしまいます。もちろん、POSIX原理主義jsonパーサーparsrj.shを使って。

cat <<END | axs -q | parsj.sh
POST /
Host: rekognition.us-east-1.amazonaws.com
X-Amz-Target: RekognitionService.DetectLabels
Content-Type: application/x-amz-json-1.1

{
   "Image":{
      "S3Object":{
         "Bucket":"s3-to-rekognition",
         "Name":"my-face.jpg"
      }
   }
}
END

私の顔画像をアップロードして解析した結果は以下のようになりました。

$.Labels[0].Confidence 99.2739486694336
$.Labels[0].Name Human
$.Labels[1].Confidence 99.27888488769531
$.Labels[1].Name People
$.Labels[2].Confidence 99.27890014648438
$.Labels[2].Name Person
$.Labels[3].Confidence 82.6961669921875
$.Labels[3].Name Dimples
$.Labels[4].Confidence 82.6961669921875
$.Labels[4].Name Face
$.Labels[5].Confidence 82.6961669921875
$.Labels[5].Name Smile
$.Labels[6].Confidence 54.255836486816406
$.Labels[6].Name Selfie
$.Labels[7].Confidence 50.784881591796875
$.Labels[7].Name Female
$.Labels[8].Confidence 50.784881591796875
$.Labels[8].Name Girl
$.Labels[9].Confidence 50.784881591796875
$.Labels[9].Name Woman
$.Labels[10].Confidence 50.74814987182617
$.Labels[10].Name Glasses
$.Labels[11].Confidence 50.74814987182617
$.Labels[11].Name Goggles

多分、私は二重で目が大きいので上のような結果になってしまったのだと思います。サングラスとか眼鏡の可能性が指摘されてます。ちなみに顔アップの自撮り写真をあげたのですが、それも認識されているようですね。えくぼとスマイルまで認識されています。rekognitionには女顔として認識されたようでした。

以上のようにかなり詳しく要素を検出してくれます。別の例ではテーブルクロスなども検出していました。他にもAmazon Rekognitionでは顔の判別や比較、リストができます。ですので、例えば、普段見ない顔を検出した時にアラートを送信するようなアプリケーションを作れば、自作警備システムなんかも作成できるかもしれませんね!東京オリンピックに備えて笑

まとめ

さて、これでクラウドの力を借りれば、POSIX原理主義でも、様々なアプリケーションを開発できることがわかりましたね!さらには、機械学習や深層学習の力を借りた強力なものまでも、比較的簡単にできちゃうことがわかったと思います!しかも環境やバージョンに悩まされることなしで!

わーい!POSIX原理主義シェルスクリプトは楽しいですね!

※ここまでの流れで、AWS自体がPOSIX原理主義と対極じゃんて声が聞こえてきそうですが、そこはあまり関係ありません。AWSは道具というよりサービスです。ほらAmazon Web Servicesって言います。それにフルマネージドなサービスを多く活用するようにすれば、バージョンアップによる不具合とは比較的無縁です。

ということで、私は、実は、POSIX原理主義は、クラウドととても相性がいいのではないかと勝手に思っています(素人考え)。

「必要なもの」POSIX準拠コマンドと交換可能性を担保したコマンド

  • openssl ver1.0.0以上
  • utconv (同梱、秘密結社シェルショッカー日本支部)
  • urlencode (同梱、秘密結社シェルショッカー日本支部)
  • cat
  • awk
  • sed
  • printf
  • echo
  • grep
  • curl
  • wget
  • eval

感想

意味がるのか知りません。あるかもしれないし、ないかもしれません。ただ楽しかったですとだけ付け加えておきます。

「シェルかっこいい、クラウドかっこいい」
→「なんか作りたい」
→「POSIX原理主義すげー」
→「POSIX原理主義でもクラウドwebサービスの力を借りたい!」
→「一番サービスが充実していそうなAWSを操りたい」
→「awsコマンド的なものをPOSIX原理主義で開発しよう!」
という動機で始めました。作者は初Qiita,教育学部卒業したてのずぶの素人で数ヶ月前までIT系とは無縁でした。技術的な誤りを多分に含んでいる可能性があります。その時は指摘してくださると助かります。