Amazon lexで音声チャットボットを作成してみた

天気の良い週末にやることがなく、昼の12時ごろ、趣味の長時間歯磨きをしながらtechCrunchを見ていたら、amazonのlexの記事が乗っていた。

http://jp.techcrunch.com/2017/04/21/20170420amazon-lex-the-technology-behind-alexa-opens-up-to-developers/

Amazonの仮想アシスタントAlexaを支えているテクノロジーであるAmazon Lexが、今朝(米国時間20日)のロイターの記事によれば、プレビュー段階を終了したということだ。

↓↓↓
https://aws.amazon.com/jp/lex/

Amazon Lex は、音声やテキストを使用した会話型インターフェイスをさまざまなアプリケーションに構築するためのサービスです。
Lex では、自動音声認識 (ASR) という音声をテキストに変換するための高度な深層学習機能と、
テキストの意図を理解するための自然言語理解 (NLU) を利用できます。
これにより、非常に魅力的なサービスと生き生きとした音声対話を実現するアプリケーションを構築できます。
Amazon Lex を使うと、すべての開発者が Amazon Alexa に採用されている深層学習技術と同じ技術を利用し、
自然言語での高度な対話ボット (チャットボット) を短時間で簡単に構築できるようになります。

このページにある動画は去年の11月末のものだ。
その頃、某ゲームの開発と並行して走る運営の現場の両方が修羅場で、毎日トラブルと戦っていた。さらにトラブルは現場だけとは限らず、外野がキナ臭くなり、モヒカンと肩パッドの荒くれ供から平和を守るために北斗百烈拳を繰り出していた。明日を見失って、CV千葉繁になっていた記憶がうっすらとある。
当然re:InventのKeynoteなど見る暇はなかった。

Try a sample

まずはこちらのページでサンプルを作ってみる。
https://console.aws.amazon.com/lex/home?region=us-east-1#bot-create:

cb-1.png
BookTripをクリック。

cb-2.png

IAM:自動的に作ってくれるんはありがたい。念のため後でデタッチされた権限を見ることにするけどな。
Child-Directed?:子供専用ではないからNo。

Createを押しやす。


マイクを許可しますかのプロンプトが出るので、許可にする。
このmacには内臓マイクがないので、iPhoneのヘッドホンを繋いでおく。

cb-3.png

しかしこの後、何をどうしたらいいのか、説明がないからさっぱりわからない。。。。。。
困った。

tutorialの動画をみながらもう一度sample chat botをつくる

AWS Lex Demo Tutorial (Jan 2017)
https://www.youtube.com/watch?v=7uG9cuxNo5k
「花の注文をするチャットボット」を10分くらいで作る様子。

4ヶ月ほど前に親切な人が投稿してくれたチュートリアル動画で、
やさしい英語をえらんで説明してくれているが、
英語のききとりがやっとの自分はYoutobeの字幕機能で補いながらみた。
この通りやってみると、なんとなくわかる。

なおこの動画の中では、まだ「Channels」がFacebookしかないが、
3ヶ月後の現在は、3つに増えている。

  • Facebook
  • Twilio SMS ←増えた
  • Slack ←増えた

花屋のサンプルをそのまま真似して、以下のように作ってみた。

name:OrderFlowersSitopp
Description:Bot to order flowers on the behalf of a user
Output voice:Joey

cb-8.png

Buildをするとtest Botでtext入力できるようになる。
Sample Utterancesの1個めをコピペして、
I would like to pick up flowers
と記入してエンターしてみるとすぐ答えが返ってきた。ほうほう。
cb-7.png
あっ、これもうできちゃったのか。早いなぁ。(΄◉◞౪◟◉`)

音声入力してみる

AWSのLexのコンソールに行く
https://console.aws.amazon.com/lex/home?region=us-east-1#bots:

さっき作った「name:OrderFlowersSitopp」を選ぶcb-15.png

右側にチャットボットのタブが現れるので、
入力欄のマイク部分をクリックする。そうすると音声入力モードになった。

cb-13.png


Macに繋いだiPhone用のヘッドフォンのマイクのあたりに話しかけると、テキスト化して、チャットにしてくれます。

上の例だと、私の発音が悪いので、rosesがlosesとかclosesになっている。ひどい(笑)
しかもボットはそのまま「Ok your closes will be ready 」と予約終了してしまった。
いったいなんの花が届くのか。。笑

もちろん、これはサンプルだから何も届かないけど、
ちゃんとカスタムスロットに無いものはエラーにしないと、そのまま注文を受け取ったことになってしまうから、
注意が必要ということで。

sampleを作ってわかったこと

  • サンプルの3種類は以下の通り。主たる目的はこういうものなのかな。

    • 旅行の予約
    • 花屋のオーダー
    • 歯医者の予約

考えられる用途

  • 保険の見積もり
  • 通販サイトのパスワード忘れた
  • 美容院の予約
  • ゲームの進行不具合の通報
  • ゲームのチート疑惑の通報
  • ゲーム掲示板の炎上の通報
  • ゲームの..いかん、つい仕事が

これがFacebookのお店のページに備わってたら、確かに気楽に呼び出しやすい。
でも受け取る側はどうなんだろう? botが応答して解決しない場合もあるだろうし、ちゃんと過去の履歴を呼び出せるのかな?

大変そうな点

Sample UtterancesとSlot typesの用意が大変そう。

Sample Utterancesとは、ユーザーがこういったらこの部分をパラメタとして受け取るという設定。花屋の予約sampleでは2個しかなかったけど、こんなんで済むはずがない。

  • I would like to pick up flowers
  • I would like to order some flowers

様々な言い方を網羅しておかないと、「おっしゃることがわかりません」を連発するポンコツbotになってしまう。
(参考動画 Virgin Flight – Saturday Night Live

Slot typesは、ユーザーの返答の中から受け付けるキーワードの種類で、花屋の予約sampleでは花の種類3つが該当する。だがこんな少なくて済むはずがない。3種類しか売ってない花屋っていうのだったら別だけど。
– roses
– lilies
– tulips

Sample utterancesもSlot TypesもAlexa Skillsにも同様の設定項目があり、これらをいかにきめ細かに定義できるかでbotの優秀さが決まると思う。

まとめ

  • AWSのlexを使ってchatbotが作れる。
  • 連携先は、Facebook、Twilio SMS、slackが選べる。ただし音声入力は、声の入力装置があるプラットフォームじゃないとダメ。(Twilioは電話と連携してるから、これが候補か。)
  • Utterancesとslot typesをちゃんと定義しないと、ポンコツbotになってしまう。人工知能というより人工無能。これはAlexa skillsも同じ。
  • しゃべった言葉を分解してテキストにするところが人工知能。ここはブラックボックス。
  • サンプルでは必要なかったが、ちゃんとbotを作るときにはLambda関数も書く必要がある。(http://docs.aws.amazon.com/ja_jp/lex/latest/dg/getting-started-ex2.html)
  • botの会話ログを見るのってどうするんだろ?

以上!

続きを読む

AWS X-RayでLambda→Athenaのアクセスを可視化してみた

以前こんなものを作りましたが、これをAWS X-Rayで可視化してみたら、何がわかるのか、実験してみました。

Amazon AthenaをAWS Lambdaから操作できるようにしてみた

AWS X-Ray デーモンの実行

AWS X-Ray SDK は、AWS X-Ray に Trace データを直接送信しないらしいので、送付用のEC2インスタンスを作成します。ユーザデータとして以下を登録してインスタンスを生成するだけなので、簡単です。

#!/bin/bash
curl https://s3.dualstack.us-east-1.amazonaws.com/aws-xray-assets.us-east-1/xray-daemon/aws-xray-daemon-2.x.rpm -o /home/ec2-user/xray.rpm
yum install -y /home/ec2-user/xray.rpm

システムログにxrayのインストールログが出力されていたのでOKでしょう。

Examining /home/ec2-user/xray.rpm: xray-2.0.0-1.x86_64
Marking /home/ec2-user/xray.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package xray.x86_64 0:2.0.0-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package         Arch              Version               Repository        Size
================================================================================
Installing:
 xray            x86_64            2.0.0-1               /xray            6.6 M

Transaction Summary
================================================================================
Install  1 Package

Total size: 6.6 M
Installed size: 6.6 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : xray-2.0.0-1.x86_64                                          1/1 
xray start/running, process 2576
  Verifying  : xray-2.0.0-1.x86_64                                          1/1 

Installed:
  xray.x86_64 0:2.0.0-1                                                         

Complete!

Lambdaアプリ側の準備

今回Javaアプリケーションを動かすわけですが、LambdaアプリケーションをX-Rayで監視したい場合は、Lambdaアプリケーションの「設定」タブの中で以下のチェックボックスをONにするだけで良いようです。

スクリーンショット 2017-04-23 22.21.44.png

参考:http://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-services.html

またX-Rayを操作するための権限をIAMで設定する必要もあります。今回は試験的な運用だったため「AWSXrayFullAccess」をつけてしまいましたが、実際の運用に合わせてこの辺りは慎重に選びたいですね。

アプリを起動して可視化してみる

ここまでできれば、普通にLambdaアプリを動かしてみてX-Rayでどのように見えるのか確認ができます。今回Lambdaアプリケーションには以下のJSONをインプットとして与えるようにしました。以前の記事でサンプルとしてAthenaのテーブルからデータを取得するようにした際の入力値です。

{
  "region": "us-east-1",
  "s3Path": "s3://ishida-athena-staging-dir/",
  "sql": "SELECT elbname, requestip,  requestport, backendip, backendport, requestprocessingtime, backendprocessingtime, timestamp FROM sampledb.elb_logs order by timestamp desc limit 10",
  "columnListStr": "elbname, requestip,  requestport, backendip, backendport, requestprocessingtime, backendprocessingtime,  timestamp"
}

実行後1分ほど待つと、以下のような表示がX-Rayで確認できました。無事可視化ができたようです。

スクリーンショット 2017-04-23 22.56.40.png

X-Rayの中身を確認してみる

表示されたService Mapの右側のオブジェクトをクリックすると以下のような表示がされました。
スクリーンショット 2017-04-23 22.56.51.png

それぞれの処理にどの程度時間がかかってレスポンスとして何を返しているのかが一覧でわかります。
表示されているIDをクリックすると、そのTraceの詳細が確認できました。

スクリーンショット 2017-04-23 22.56.58.png

これをみる限り、Lambdaアプリの初期化に230ms程度、実際のAthena接続部分に約3秒程度かかっている、という風にみればいいんですかね。この処理全体としては4.6秒かかっているので、実際にAthenaにアクセスするため以外に1.5秒ほどは時間が取られている、と理解すればいいんでしょうか。この辺はもっと勉強が必要だ(^^;

ちなみにエラーが出ている場合は、その例外の中身も確認することができるようです。

まとめ

それぞれの処理がどの程度時間にかかっていて、さらに呼び出し関係までこれほど簡単にセットアップしつつ可視化ができるのは強力ですね。これからMicroservicesなどで分散して処理をさせることが当たり前になることを考えると、必須の技術と言えると思います。Springで言えばZipkinとSleuthをAWS上で実現しているような感じですね。

続きを読む

Amazon Lex でサンプルbotを試した

Amazon Lex

Lexがついに一般公開されました。
Alexa Voice Serviceで色々と頑張らなくても手軽にAlexaを使えそうです。

サンプルbotのモデル

公式ドキュメントのExercise2を通して、Lexの使い方を学んでいきたいと思います。

Pizza Ordering Bot

早速作っていきましょう。
※Lexはus-east-1(バージニア北部)のみで利用可能です。

1. lambda関数の用意

1-1: IAMロールの作成

マネジメントコンソールからIAMを選択し、サイドバーのロールから新しいロールの作成に進みましょう。
ロールタイプはAWSサービスロールのlambdaを選んでください。
ポリシーのアタッチ画面で検索窓に lex と入力し、
AmazonLexRunBotsOnlyを選択してロールを作成します。

スクリーンショット 2017-04-23 9.31.06.png

1-2: 関数の作成

ここを参考に作れば問題ないです。

ざっくり言うと lambda→ブランク関数→Node.js v4.3 を選択し、ドキュメントのコードをそのまま貼り付ければ問題ないです。
ロールについては、既存のロールを選択より先程作成したものをアタッチしてください。

2. Lex botの作成

コンソールの LexBotsCreate からbotを作成します。
名前は適当に(e.g. PizzaOrderingBot)、好きな声を選んで、Session timeout は5分で。Child-DirectedNo で大丈夫です。

3. SlotTypeとIntentの設定

3-1: Slotの追加

EditorタブのサイドバーからSlot typesにある+ボタンより新しいスロットを追加。
今回は以下のように追加します

  • Crusts というslotを作成し、valueに thickthin
  • Sizes というslotを作成し、valueに small, medium, large
  • PizzaKind というslotを作成し、valueに cheeseveg

※↓ではPizzaSizeになってますが、SizesでもPizzaSizeでも好きな名前をつけてください
スクリーンショット 2017-04-23 8.58.28.png

※ Slotとは

Alexaの質問に対して答えるべき単語のまとまり、といった感じです。
(Alexaが回答として期待している単語のまとまりと言うべきか。)
主要な都市や日時、空港や俳優などAmazonが用意しているものも利用可能です。
Amazonが用意したBuilt-in SlotはAMAZON.xxxで定義されており、インストールなどの必要もありません。

3-2: Intentの追加

EditorタブのサイドバーからIntentにある+ボタン、Create New Intentより作成しましょう。

3-2-1: Sample utterancesの編集

ここに入れた文章でAlexaに呼びかけると、反応して処理を開始します。
以下のような文章を追加します。

  • I want to order pizza please
  • I want to order a pizza
  • I want to order a {pizzaKind} pizza
  • I want to order a {size} {pizzaKind} pizza
  • I want a {size} {crust} crust {pizzaKind} pizza
  • Can I get a pizza please
  • Can I get a {pizzaKind} pizza
  • Can I get a {size} {pizzaKind} pizza
3-2-2: Slotsの編集

作成したslotを追加していきます。
Nameで登録した名前は、上のutterancesの文章や、lambdaの処理で利用する際のkeyとなります。
Slot typeは先程作成したものを選択、PromptにはAlexaから投げられる質問を入れます。
また、Requiredにはすべてチェックを入れましょう。

※ Promptの例
– pizzaKind: Do you want a cheese or veg pizza?
– size: What size pizza?
– crust: Thick or thin crust?

スクリーンショット 2017-04-23 9.37.54.png

3-3: その他設定

FulfillmentでAWS Lambda functionを選択し、先程作ったlambda関数を選択します。
Lambda initialization and validationConfirmation promptはとりあえずそのまま空白で問題ありません。

※ Intentとは

utterancesに追加した文章で我々が呼びかけるとAlexaが質問を投げかけてくるので、それに対してslotに入ってる単語で回答。また、promptでAlexaは別の質問を行いデータをさらに集める。それらのデータを用いてAlexaが回答、またはlambdaに処理が投げられる。
このような一連の流れをIntentとしてまとめています。

4. テスト

早速テストしましょう。画面上部の Build ボタンよりビルド完了後、画面右下のチャット欄からチェックできます。

スクリーンショット 2017-04-23 9.49.23.png

ビルド後はIntentが保存されて編集できなくなるのですが、画面上部でversionをLatestに変更すると再び編集が可能になります。

スクリーンショット 2017-04-23 9.37.39.png

5. おつかれさまでした😌

lambda関数の動きについては触れていませんが、今後何か書くかもしれません。
あとは音声入力などについても調べたいと思います。
(Alexa Voice ServiceのSkill Kitに追加できないのかしら…)

続きを読む

[AWS] Terraform で EFS 作って、EC2 起動時にマウントさせておく

Terraform を使うと、EFS を作成して EC2 にマウントさせておくなんてことが簡単にできます。
Autoscaling 環境で Web ドキュメントルートを共有したい時とかに便利なんで、みんな使えばいいと思うよ。
なお、この記事の想定読者は AWS はダッシュボードからポチポチしてインスタンス立てたりしてるけど、そろそろインフラをコードで管理したいな。Terraform とか便利そうだねー使ってみたいねーって人です。
てわけで、単純に EC2 立ち上げても面白くないので EFS をマウントさせてみました。

そもそも、Terraform ってなんだ?って人は、以下のページとか参考になると思います。
Terraform簡易チュートリアル on AWS

実際の設定

Terraform は、特定のディレクトリ下にある拡張子が .tf なファイルを全部読み込んでいい感じにリソースを起動してくれます。なので、機能別に .tf 作成していってみましょう。

メイン設定

まず、メインの設定を作成。
プロバイダーとか、設定ファイル内で使用する変数とか設定していってみましょうか。

main.tf
# 今回のプロジェクト名
variable "project" {}
variable "domain" {}

# AWS リソースを起動するリージョンとかの情報
variable "region" { default = "us-west-2" }
variable "azs" {
    default {
        "a" = "us-west-2a"
        "b" = "us-west-2b"
        "c" = "us-west-2c"
    }
}

# AMI ID (Amazon Linux)
variable "ami" { 
    default {
        "us-west-2" = "ami-8ca83fec"
    }
}

# EC2 接続用の SSH 鍵の公開鍵
variable "ssh_public_key" {}

provider "aws" {
    region = "${var.region}"
}

variable で設定した値は tf ファイル内で ${var.region} のようにして参照可能です。
また、terraform の各種コマンドを実行する際に以下のようにパラメータとして変数を渡して上書きすることもできます。

$ terraform plan \
  -var 'project=example' \
  -var 'domain=example.com'

同じディレクトリ内に terraform.tfvars というファイルがあれば、それを読み込んで値が上書きされたりします。この辺の詳細は以下を参照してください。
Input Variables – Terraform by HashiCorp

provider "aws" は、aws を使いますよって宣言です。
以下のように アクセスキーを書いておくこともできますが、それやるとうっかり github とかに公開した時とかに切ない目にあうのでやめたほうが吉でしょう。

provider "aws" {
    access_key = "__ACCESS_KEY__"
    secret_key = "__SECRET_KEY__"
    region = "us-west-2"
}

環境変数 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY を読み込んでいい感じでやってくれるので、僕は direnv 使って作業ディレクトリ内で環境変数を変更することで対応してます。
(もちろん、この場合でも .gitignore.envrc を含めておいて間違って公開しないようにしないと切ない目にあうので注意)

VPC の作成

こんな感じの .tf ファイルで VPC と subnet が作成できます。

vpc.tf
## VPC
resource "aws_vpc" "app" {
    cidr_block           = "172.31.0.0/16"
    enable_dns_hostnames = true
    enable_dns_support   = true
    instance_tenancy     = "default"

    tags {
        "Name" = "${var.project}"
    }
}

## Subnet
resource "aws_subnet" "a" {
    vpc_id                  = "${aws_vpc.app.id}"
    cidr_block              = "172.31.0.0/20"
    availability_zone       = "${lookup(var.azs,"a")}"
    map_public_ip_on_launch = true

    tags {
        "Name" = "${var.project}-subnet-a"
    }
}

resource "aws_subnet" "b" {
    vpc_id                  = "${aws_vpc.app.id}"
    cidr_block              = "172.31.16.0/20"
    availability_zone       = "${lookup(var.azs,"b")}"
    map_public_ip_on_launch = true

    tags {
        "Name" = "${var.project}-subnet-b"
    }
}

resource "aws_subnet" "c" {
    vpc_id                  = "${aws_vpc.app.id}"
    cidr_block              = "172.31.32.0/20"
    availability_zone       = "${lookup(var.azs,"c")}"
    map_public_ip_on_launch = true

    tags {
        "Name" = "${var.project}-subnet-c"
    }
}

resource "aws_subnet" の中に ${aws_vpc.app.id} ってのが出てきましたね。
Terraform の中では、管理下にあるリソースの情報を他のリソースの設定でも参照することが可能です。
各リソースで使用できる値が異なってくるので、その辺は公式ドキュメント読みましょう。
例えば aws_vpc で使用できる値は aws_vpc を参照すればわかります。

また、${lookup(var.azs,"a")} ってのも出てきましたね。
これは Terraform の組み込み関数です、lookup は配列の中からキーをもとに値を探す関数です。
詳しくは Built-in Functions を読んでください。

ついでに Internet Gateway と Route Table も設定しておきましょう。

route-table.tf
## Internet Gateway
resource "aws_internet_gateway" "igw" {
    vpc_id = "${aws_vpc.app.id}"
}

## Route Table
resource "aws_route_table" "rtb" {
    vpc_id     = "${aws_vpc.app.id}"
    route {
        cidr_block = "0.0.0.0/0"
        gateway_id = "${aws_internet_gateway.igw.id}"
    }
}

resource "aws_route_table_association" "route_a" {
    subnet_id = "${aws_subnet.a.id}"
    route_table_id = "${aws_route_table.rtb.id}"
}

resource "aws_route_table_association" "route_b" {
    subnet_id = "${aws_subnet.b.id}"
    route_table_id = "${aws_route_table.rtb.id}"
}

resource "aws_route_table_association" "route_c" {
    subnet_id = "${aws_subnet.c.id}"
    route_table_id = "${aws_route_table.rtb.id}"
}

IAM ロールの作成

次に EC2 に割り当てるための IAM ロールを作ってみましょう。
ポリシーは、AWS が用意している AmazonEC2RoleforDataPipelineRole と、EC2 から CloudwatchLogs にログを送信するためのカスタムポリシーを作ってアタッチしてみます。

iam-role.tf
## For EC2 instance Role
resource "aws_iam_role" "instance_role" {
    name               = "instance_role"
    path               = "/"
    assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

## AmazonEC2RoleforDataPipelineRole
resource "aws_iam_role_policy_attachment" "data-pipeline" {
    role       = "${aws_iam_role.instance_role.name}"
    policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforDataPipelineRole"
}

## PutCloudwatchLogs
resource "aws_iam_policy" "put-cloudwatch-logs" {
    name        = "AmazonEC2PutCloudwatchLogs"
    description = ""
    policy      = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "put-cloudwatch-logs" {
    role       = "${aws_iam_role.instance_role.name}"
    policy_arn = "${aws_iam_policy.put-cloudwatch-logs.arn}"
}

aws_iam_roleassume_role_policy のところと、aws_iam_policypolicy のところでヒアドキュメントが出てきましたね。
こんな風に複数行にわたるインラインポリシーはヒアドキュメントで記述することが可能です。
また、以下のように別ファイルにしておいて読み込ませることも可能です。
管理しやすい方でやってください。

iam-role.tf
resource "aws_iam_role" "instance_role" {
    name               = "instance_role"
    path               = "/"
    assume_role_policy = "${file("data/instance_role_assume_policy.json")}"
}
data/instance_role_assume_policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

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

EC2 から EFS へのアクセスは 2049 番ポートを介して行われるので、EFS が所属するセキュリティグループに穴を開けないといけません。
EC2 は 80, 443, 22 を解放してみます。

security-group.tf
## For EC2
resource "aws_security_group" "ec2" {
    name        = "${var.project}-EC2"
    description = "for ${var.project} EC2"
    vpc_id      = "${aws_vpc.app.id}"

    ingress = [
        {
            from_port       = 80
            to_port         = 80
            protocol        = "tcp"
            cidr_blocks     = ["0.0.0.0/0"]
        },
        {
            from_port       = 443
            to_port         = 443
            protocol        = "tcp"
            cidr_blocks     = ["0.0.0.0/0"]
        },
        {
            from_port       = 22
            to_port         = 22
            protocol        = "tcp"
            cidr_blocks     = ["0.0.0.0/0"]
        }
    ]

    egress {
        from_port       = 0
        to_port         = 0
        protocol        = "-1"
        cidr_blocks     = ["0.0.0.0/0"]
    }
}

## For EFS
resource "aws_security_group" "efs" {
    name        = "${var.project}-EFS"
    description = "for ${var.project} EFS"
    vpc_id      = "${aws_vpc.app.id}"

    ingress {
        from_port       = 2049
        to_port         = 2049
        protocol        = "tcp"
        security_groups = ["${aws_security_group.ec2.id}"]
    }

    egress {
        from_port       = 0
        to_port         = 0
        protocol        = "-1"
        cidr_blocks     = ["0.0.0.0/0"]
    }
}

EFS の作成

こんな感じで EFS が作成できます。
各サブネットごとにマウントターゲットを作成して、そいつをセキュリティグループに所属させる形ですね。

efs.tf
resource "aws_efs_file_system" "app" {
  tags {
        "Name" = "${var.domain}"
  }
}

resource "aws_efs_mount_target" "app-a" {
  file_system_id  = "${aws_efs_file_system.app.id}"
  subnet_id       = "${aws_subnet.a.id}"
  security_groups = ["${aws_security_group.efs.id}"]
}

resource "aws_efs_mount_target" "app-b" {
  file_system_id = "${aws_efs_file_system.app.id}"
  subnet_id      = "${aws_subnet.b.id}"
  security_groups = ["${aws_security_group.efs.id}"]
}

resource "aws_efs_mount_target" "app-c" {
  file_system_id = "${aws_efs_file_system.app.id}"
  subnet_id      = "${aws_subnet.c.id}"
  security_groups = ["${aws_security_group.efs.id}"]
}

EC2 の作成

さて、いよいよ EC2 です。
ここでは、user-data を使って、初回ローンチ時に EFS をマウントさせてしまいます。
さらにマウントした EFS 内に html/ ってディレクトリを作成して、そいつを /var/www/html にシンボリックリンクしてみましょうか。
と言っても、こんな感じで大丈夫です。

ec2.tf
## IAM Instance Profile
resource "aws_iam_instance_profile" "instance_role" {
    name = "instance_role"
    role = "${aws_iam_role.instance_role.name}"
}

## SSH Key
resource "aws_key_pair" "deployer" {
  key_name   = "${var.project}"
  public_key = "${var.ssh_public_key}"
}

## EC2
resource "aws_instance" "app" {
    ami                         = "${lookup(var.ami,var.region)}"
    availability_zone           = "${aws_subnet.a.availability_zone}"
    ebs_optimized               = false
    instance_type               = "t2.micro"
    monitoring                  = true
    key_name                    = "${aws_key_pair.deployer.key_name}"
    subnet_id                   = "${aws_subnet.a.id}"
    vpc_security_group_ids      = ["${aws_security_group.ec2.id}"]
    associate_public_ip_address = true
    source_dest_check           = true
    iam_instance_profile        = "${aws_iam_instance_profile.instance_role.id}"
    disable_api_termination     = false

    user_data                   = <<USERDATA
#!/bin/bash
az="${aws_subnet.a.availability_zone}"
efs_region="${var.region}"
efs_id="${aws_efs_file_system.app.id}"
efs_mount_target="${aws_efs_mount_target.app-a.dns_name}:/"
efs_mount_point="/mnt/efs/$${efs_id}/$${az}"
web_doc_root="/var/www/html"

# EFS Mount
/usr/bin/yum -y install nfs-utils || /usr/bin/yum -y update nfs-utils
if [ ! -d $${efs_mount_point} ]; then
  mkdir -p $${efs_mount_point}
fi
cp -pi /etc/fstab /etc/fstab.$(date "+%Y%m%d")
echo "$${efs_mount_target}    $${efs_mount_point}   nfs4    defaults" | tee -a /etc/fstab
mount $${efs_mount_point}

# create Web document root
if [ -d $${web_doc_root} ]; then
  rm -rf $${web_doc_root}
fi
if [ ! -d $${efs_mount_point}/html ]; then
  mkdir $${efs_mount_point}/html
  chown ec2-user:ec2-user $${efs_mount_point}/html
fi
ln -s $${efs_mount_point}/html $${web_doc_root}
chown -h ec2-user:ec2-user $${web_doc_root}
USERDATA

    root_block_device {
        volume_type           = "gp2"
        volume_size           = 10
        delete_on_termination = true
    }

    tags {
        "Name"          = "${var.domain}"
    }
}

user_data は長めのシェルスクリプトなので、可読性が悪いから ${file("data/user_data.sh")} とかってやって別ファイルで管理したいですよね。
でも待ってください、ヒアドキュメントでやってるのは理由があるのです。

ヒアドキュメントで書くと、user_data 用のシェルスクリプトの中で Terraform の変数が使えます。
マウントするには EFS の ID とか、マウントターゲットの dns_name とか必要になってきますが、それを作成前に知らなくてもこのように書いておけるのです。便利ですね。
その代わり、user_data 用のシェルスクリプト内でローカルな環境変数を使いたい場合は $${efs_mount_point} のように書いてあげてくださいね。

ざっと、こんな感じです。
慣れちゃえば、tf ファイルを使い回しできるので便利ですよ。
また、すでに作成済みの AWS リソースを Terraform 管理下に置きたい場合は

$ terraform import aws_instance.app ${instance_id}

のようにして管理下に置くことができます。
管理されているリソースは terraform.tfstate というファイルに書き込まれます。
さらに別プロダクトになるのですが Terraforming と言うツールを使用すると、既存の AWS リソースから Terraform 用の tf ファイルを作成したり、terraform.tfstate を作成したりもできるので便利です。
Terraforming については、Terraforming で既存のインフラを Terraform 管理下におく を参考にしてください。

実際にリソース作成してみる

tf ファイル書いたら

$ terraform plan

で、設定ファイルに誤りがないか?既存のリソースへの影響はどの程度あるのかが確認できます。
実際に反映させたい時は

$ terraform apply

で、おっけ。

では、良い Terraform を!

続きを読む

RDSをAnsibleで管理する

はじめに

AnsibleにはAWSのリソースを操作できるモジュールが豊富に用意されています。

今回は、RDSをAnsibleで管理してみます。
RDSインスタンスを作成するためには、

  • サブネットグループ
  • パラメータグループ

が必要になるので、一気通貫で作成できるようにします。

やること

  • サブネットグループ作成
  • パラメータグループ作成
  • RDSインスタンス作成

ポイント

サブネットグループを作成するためにサブネットIDが、RDSインスタンスを作成するためにセキュリティグループIDがそれぞれ必要となりますが、IDをAnsibleのYAMLに書きたくないので、それぞれ名前からIDを取得する実装とします。

前提

  • AWS関連のモジュール実行にはbotoが必要です。
  • credential情報は環境変数かaws configureでセットしてある必要があります。
  • ec2_group_factsが必要です。

下記リソースを前提に進めます。

  • VPC

    • AnsibleVPC
  • サブネット
    • private-a
    • private-c
  • セキュリティグループ
    • db_server

sample

以下のようなRDSインスタンスを作成します。

  • サブネットグループ

    • private

      • private-a(AZ-a)
      • private-c(AZ-c)
  • パラメータグループ
    • mysql57-sample
  • RDSインスタンス
    • sample-db

      • セキュリティグループ

        • db_server
      • サブネットグループ
        • private
      • パラメータグループ
        • mysql57-sample

ディレクトリ構成

ディレクトリ構成
site.yml
roles/
|--rds/
|  |--tasks/
|  |  |--main.yml
hosts/aws    #inventory
host_vars/
|--localhost.yml

inventory

AWSリソース関連モジュールはすべてlocalhostで実行するので、下記のようなインベントリファイルを用意します。

hosts/aws
[aws]
localhost

vars

こんな感じに変数を定義します。今回はhost_varsで定義しました。
RDSインスタンスのパスワードをそのまま記載していますが、実際はansible-vaultで暗号化したファイルなどに記載してください。

host_vars/localhost.yml
---
my_vars:
  aws:
    common:
      region: ap-northeast-1
    vpc:
      name: AnsibleVPC    # ターゲットのVPC名
    rds:
      subnet_group:
        - name: private
          description: 'private subnet group'
          subnets:
            - private-a #サブネット名
            - private-c #サブネット名
      param_group:
        - name: mysql57-sample
          description: 'MySql5.7 sample'
          engine: mysql5.7
          params:
            character_set_database: utf8
            character_set_server: utf8
      instance:
        - name: sample-db
          db_engine: MySQL
          engine_version: 5.7.16
          multi_zone: no
          zone: a
          size: 5
          instance_type: db.t2.micro
          parameter_group: mysql57-sample
          subnet_group: private
          security_group:
            - db-server #セキュリティグループ名
          username: mysql_admin
          password: mysql_admin
          tags:
            Role: sample-db

Role

まずVPCを特定するためにidが必要ですが、こちらと同様、VPC名でidを取得します。

後続タスクで必要となる、サブネットIDとセキュリティグループIDを取得し、それぞれ名前からIDを参照するためにディクショナリを生成します。

roles/vpc/tasks/main.yml
---
- name: vpc_id取得
  ec2_vpc_net_facts:
    region: "{{ my_vars.aws.common.region }}"
    filters:
      "tag:Name": "{{ my_vars.aws.vpc.name }}"
  register: vpc_net_fact

- name: subnet id取得
  ec2_vpc_subnet_facts:
    region: "{{ my_vars.aws.common.region }}"
    filters:
      vpc_id: "{{ vpc_net_fact.vpcs[0].id }}"
      "tag:Name": "{{ item.1 }}"
  with_subelements:
    - "{{ my_vars.aws.rds.subnet_group }}"
    - subnets
  register: subnet_fact
  when: my_vars.aws.rds.subnet_group is defined

- name: subnet dict作成
  set_fact:
    subnets_dict: >-
      {%- set dict = {} -%}
      {%- set inc = 0 -%}
      {%- set subnet_group_cnt = my_vars.aws.rds.subnet_group|length -%}
      {%- for i in range(subnet_group_cnt) -%}
      {%-   set list = [] -%}
      {%-   for j in range(my_vars.aws.rds.subnet_group[i].subnets|length) -%}
      {%-     set _ = list.append(subnet_fact.results[inc+j].subnets[0].id) -%}
      {%-   endfor -%}
      {%-   set _ = dict.update({my_vars.aws.rds.subnet_group[i].name: list}) -%}
      {%-   set inc = inc + subnet_group_cnt -%}
      {%- endfor -%}
      {{ dict }}
  when: my_vars.aws.rds.subnet_group is defined

- name: securitygroup id取得
  ec2_group_facts:
    region: "{{ my_vars.aws.common.region }}"
    filters:
      vpc_id: "{{ vpc_net_fact.vpcs[0].id }}"
      group_name: "{{ item.1 }}"
  with_subelements:
    - "{{ my_vars.aws.rds.instance }}"
    - security_group
  register: sg_fact
  when: my_vars.aws.rds.instance is defined

- name: securitygroup dict作成
  set_fact:
    sg_dict: >-
      {%- set dict = {} -%}
      {%- for i in range(sg_fact.results|length) -%}
      {%-   set _ = dict.update({sg_fact.results[i].security_groups[0].group_name: sg_fact.results[i].security_groups[0].group_id}) -%}
      {%- endfor -%}
      {{ dict }}
  when: my_vars.aws.rds.instance is defined

- name: RDS subnet-group作成
  rds_subnet_group:
    state: present
    name: "{{ item.name }}"
    description: "{{ item.description }}"
    region: "{{ my_vars.aws.common.region }}"
    subnets: >-
      {%- set subnetname = item.name -%}
      {%- set list = subnets_dict[item.name] -%}
      {{ list }}
  with_items: "{{ my_vars.aws.rds.subnet_group }}"
  register: rds_subnet_group

- debug: var=rds_subnet_group

- name: RDS パラメータグループ作成
  rds_param_group:
    state: present
    name: "{{ item.name }}"
    description: "{{ item.description }}"
    region: "{{ my_vars.aws.common.region }}"
    engine: "{{ item.engine }}"
    params: "{{ item.params }}"
  with_items: "{{ my_vars.aws.rds.param_group }}"
  register: rds_param_group
  when: my_vars.aws.rds.param_group is defined

- debug: var=rds_param_group

- name: RDS インスタンス作成
  rds:
    command: create
    instance_name: "{{ item.name }}"
    db_engine: "{{ item.db_engine }}"
    engine_version: "{{ item.engine_version }}"
    region: "{{ my_vars.aws.common.region }}"
    multi_zone: "{{ item.multi_zone }}"
    zone: "{{ my_vars.aws.common.region }}{{ item.zone }}"
    size: "{{ item.size }}"
    instance_type: "{{ item.instance_type }}"
    parameter_group: "{{ item.parameter_group }}"
    subnet: "{{ item.subnet_group }}"
    vpc_security_groups: >-
      {%- set list = [] -%}
      {%- for i in range(item.security_group|length) -%}
      {%-   set _ = list.append(sg_dict[item.security_group[i]]) -%}
      {%- endfor -%}
      {{ list }}
    username: "{{ item.username }}"
    password: "{{ item.password }}"
  with_items: "{{ my_vars.aws.rds.instance }}"
  register: rds_instance
  when: my_vars.aws.rds.instance is defined

- debug: var=rds_instance

site.yml

site.yml
---
- name: rds
  hosts: localhost
  connection: local
  roles:
    - role: rds

実行

Command
$ ansible-playbook -i hosts/aws -l localhost site.yml

注意

Ansibleのrdsモジュールにはなぜかストレージタイプを指定するためのオプションがなく、作成されたインスタンスのストレージはマグネティックになってしまいますので適宜変更してください。

まとめ

RDSは、関連リソースを合わせて作成する必要がありますが、Ansibleで自動化できると楽です。
また、今回のplaybookはインスタンスの変更には対応していません。

参考になれば幸いです。

参考

続きを読む

AWSIoT ラージデータアップロードパターン実装

AWSIoT ラージデータアップロードパターン実装

このBlackbeltセミナー の「ラージデータアップデートパターン」を実装しようと思ったら、未熟ゆえに結構色々詰まったので、やりかたをまとめときます。

image

AWSIoT Thing作成

このへんは普通に作るだけなので、適当に流します。

デバイス名はdevice00, 以下のようなPolicyを作成し、attachしておきます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Connect",
      "Resource": [
        "arn:aws:iot:ap-northeast-1:[YOUR_ACCOUNT_ID]:client/device00"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "iot:Publish",
      "Resource": "arn:aws:iot:ap-northeast-1:[YOUR_ACCOUNT_ID]:topic/device00/token/req"
    },
    {
      "Effect": "Allow",
      "Action": "iot:Subscribe",
      "Resource": "arn:aws:iot:ap-northeast-1:[YOUR_ACCOUNT_ID]:topicfilter/device00/token/res"
    },
    {
      "Effect": "Allow",
      "Action": "iot:Receive",
      "Resource": "arn:aws:iot:ap-northeast-1:[YOUR_ACCOUNT_ID]:topic/device00/token/res"
    }
  ]
}

また、証明書のダウンロードもおこなっておきます。

IAMロールの設定

この後、LambdaでToken発行処理とデバイスからのS3へのアップロード処理を作成するのですが、
関数作成時に該当処理の実行権限をもつIAMロールが必要になるので、先に作っておきます。

S3アップロード処理ロール

デバイスに渡すSTSに許可する権限を付与したロールを”s3-role”として定義します。
ここでは、任意バケット以下にPutObjectのみをおこなえる権限を与えておきます。

実際には、バケット以下のデバイス名のフォルダにのみアップロード可能にする予定ですが、それは
STS発行時にロール権限を制限する形で加えるので、ここではバケット以下への書き込み権限を与えます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": [
                "arn:aws:s3:::[YOUR_BACKET_NAME]/*"
            ]
        }
    ]
}

STS発行処理ロール

“s3-role”のロール権限を付与したSTSを作成するLambda関数に与えるロール権限を
“create-token”ロールとして作成します。

Lambda関数を実行するので、既存ポリシーのアタッチで”AWSLambdaBasicExecutionRole”を付与します。

また、作成したSTSをAWSIoTの機能でPublishするので、そのための権限も付与します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Action": [
                "iot:Publish"
            ],
            "Resource": [
                "arn:aws:iot:ap-northeast-1:[YOUR_ACCOUNT_ID]:topic/device00/token/res"
            ]
        }
    ]
}

そして、STSにs3-roleの権限を付与するための権限も追加します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::[YOUR_ACCOUNT_ID]:role/s3-role"
        }
    ]
}

さらに、s3-role側でcreate-tokenロールを信頼しAssumeRoleを許可する旨の設定をおこなう必要があります。

s3-roleの設定画面で「信頼関係」タブを選択し、「信頼関係の編集」をおこなってエディタで
JSONの”Statement”要素の配列に以下を追加します。

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::[YOUR_ACCOUNT_ID]:role/create-token"
  },
  "Action": "sts:AssumeRole"
}

STS作成とデバイスへのトークン送信処理

STSを発行し、AWSIoT経由で指定のTopicにTokenをpublishするLambda処理を作成します。

今回はスライドの構成にしたがってTopic経由のpublishにしましたが、STSを使った通信が頻繁に
発生することが想定される場合は、Lambdaをスケジュール起動にしてDeviceShadowを用い定期的に
Pushで通知するほうがいいかもしれません。

import boto3
import json

def lambda_handler(event, context):

    sts = boto3.client('sts')
    iotData = boto3.client('iot-data')

    thingName=event['name']

    token = sts.assume_role(
        RoleArn="arn:aws:iam::[YOUR_ACCOUNT_ID]:role/s3-role",
        RoleSessionName=thingName,
        Policy=json.dumps({
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Sid": "",
                    "Effect": "Allow",
                    "Action": [
                        "s3:PutObject"
                    ],
                    "Resource": [
                        "arn:aws:s3:::large-data-upload-pattern/"+thingName+"/*"
                    ]
                }
            ]
        })
    )

    iotData.publish(
        topic=thingName+'/token/res',
        qos=1,
        payload=json.dumps({
            "AccessKeyId": token['Credentials']['AccessKeyId'],
            "SecretAccessKey": token['Credentials']['SecretAccessKey'],
            "SessionToken": token['Credentials']['SessionToken']
        })
    )

eventオブジェクトのメンバー’name’からデバイス名を取得していますが、ここにデバイス名をセットするための
設定は次項でおこないます。

AWSIoTでSTS発行リクエストを受ける

AWSIoTで”*/token/req”のTopicにトークン発行リクエストがpublishされたら、上記のLambdaを起動する
Ruleを作成します。

“Rule query statement” が以下になるように設定し、ActionにはLambda起動を選択して先述の
関数を指定してください。

SELECT topic(1) AS name FROM '+/token/req'

ここまでの設定で、AWSIoTコンソールの”Test”から、”device00/token/req”にメッセージ(空でよい)を
送信するとTokenが”device00/token/res”にpublishされることが確認できます。

あとは動作確認です。

STSを取得してみる

下記サンプルスクリプトを実行すると、”device00/token/req”にトークン発行リクエストを送信し、
“device00/token/res”からトークンを取得して標準出力に表示します。

from AWSIoTPythonSDK.MQTTLib import AWSIoTMQTTClient
import json
import time

def cb(client, userdata, message):
    print("got message")
    print(message.payload)

host="[IOT_ENDPOINT_DOMAIN]"
rootCAPath = "[ROOT_CA_FILE_PATH]"
certificatePath = "[CERTIFICATE_FILE_PATH]"
privateKeyPath = "[PRIVATE_KEY_FILE_PATH]"

myAWSIoTMQTTClient = None
myAWSIoTMQTTClient = AWSIoTMQTTClient("device00")
myAWSIoTMQTTClient.configureEndpoint(host, 8883)
myAWSIoTMQTTClient.configureCredentials(rootCAPath, privateKeyPath, certificatePath)

myAWSIoTMQTTClient.configureAutoReconnectBackoffTime(1, 32, 20)
myAWSIoTMQTTClient.configureOfflinePublishQueueing(-1)
myAWSIoTMQTTClient.configureDrainingFrequency(2)
myAWSIoTMQTTClient.configureConnectDisconnectTimeout(10)
myAWSIoTMQTTClient.configureMQTTOperationTimeout(5)

myAWSIoTMQTTClient.connect()
myAWSIoTMQTTClient.subscribe("device00/token/res", 1, cb)

time.sleep(2)

myAWSIoTMQTTClient.publish("device00/token/req", json.dumps({}), 1)

while True:
    time.sleep(5)

S3へのアップロード

取得したトークンを用いて、下記サンプルスクリプトで適当にS3にアップロードしてみます。

import boto3

AWS_S3_BUCKET_NAME = '[YOUR_BACKET_NAME]'

s3 = boto3.resource(
    's3',
    aws_access_key_id="[ACCESS_KEY]",
    aws_secret_access_key="[SECRET_KEY]",
    aws_session_token="[SESSION_TOKEN]"
)
bucket = s3.Bucket(AWS_S3_BUCKET_NAME)

obj = bucket.Object("device00/hogehoge")

response = obj.put(
    Body="hogehogehogehoge".encode('utf-8'),
    ContentEncoding='utf-8',
    ContentType='text/plane'
)

まとめ

まとめてみると大したことではないのですが、AssumeRoleとか権限まわりで色々詰まってよくわかんなくなるので大変でした。

続きを読む

[JAWS-UG CLI] CodeBuild: #5 プロジェクトの削除

前提条件

CodeBuildへの権限

CodeBuildに対してフル権限があること。

AWS CLIのバージョン

以下のバージョンで動作確認済

  • AWS CLI 1.11.57
コマンド
aws --version

結果(例):

  aws-cli/1.11.70 Python/2.7.12 Linux/4.4.11-23.53.amzn1.x86_64 botocore/1.5.33

バージョンが古い場合は最新版に更新しましょう。

コマンド
sudo -H pip install -U awscli

0. 準備

まず変数の確認をします。

変数の確認
cat << ETX

        AWS_DEFAULT_PROFILE: (0.1) ${AWS_DEFAULT_PROFILE}
        AWS_DEFAULT_REGION:  (0.2) ${AWS_DEFAULT_REGION}

ETX

結果(例):

  AWS_DEFAULT_PROFILE: (0.1) <CodeBuildにフル権限のあるプロファイル>
  AWS_DEFAULT_REGION:  (0.2) ap-northeast-1

変数が入っていない、適切でない場合は、それぞれの手順番号について作業を
行います。

0.1. プロファイルの指定

プロファイルの一覧を確認します。

コマンド
cat ~/.aws/credentials 
       | grep '[' 
       | sed 's/[//g' | sed 's/]//g'

結果(例):

  iamFull-prjz-mbpr13
  <CodeBuildにフル権限のあるプロファイル>
変数の設定
export AWS_DEFAULT_PROFILE='<CodeBuildにフル権限のあるプロファイル>'

0.2. リージョンの指定

変数の設定
export AWS_DEFAULT_REGION='ap-northeast-1'

最終確認

変数の確認
cat << ETX

        AWS_DEFAULT_PROFILE: (0.1) ${AWS_DEFAULT_PROFILE}
        AWS_DEFAULT_REGION:  (0.2) ${AWS_DEFAULT_REGION}

ETX

結果(例):

  AWS_DEFAULT_PROFILE: (0.1) <CodeBuildにフル権限のあるプロファイル>
  AWS_DEFAULT_REGION:  (0.2) ap-northeast-1

1. 事前作業

1.1. プロジェクト名の指定

変数の設定
CODEB_PROJECT_NAME='codebuild-demo-java-20170417'
変数の設定
ARRAY_CODEB_PROJECT_NAMES="${CODEB_PROJECT_NAME}" 
        && echo ${ARRAY_CODEB_PROJECT_NAMES}
コマンド
aws codebuild batch-get-projects 
        --names "${ARRAY_CODEB_PROJECT_NAMES}"

結果(例):

  {
      "projectsNotFound": [],
      "projects": [
          {
              "name": "codebuild-demo-java-20170417",
              "serviceRole": "arn:aws:iam::XXXXXXXXXXXX:role/hoge",
              "tags": [],
              "artifacts": {
                  "namespaceType": "NONE",
                  "packaging": "NONE",
                  "type": "S3 ",
                  "location": "artifact-20170417-XXXXXXXXXXXX",
                  "name": "codebuild-demo-java-20170417"
              },
              "lastModified": 14xxxxxxxx.000,
              "timeoutInMinutes": 60,
              "created": 14xxxxxxxx.000,
              "environment": {
                  "computeType": "BUILD_GENERAL1_SMALL",
                  "image": "aws/codebuild/java:openjdk-8",
                  "type": "LINUX_CONTAINER",
                  "environmentVariables": []
              },
              "source": {
                  "type": "S3",
                  "location": "src-20170417-XXXXXXXXXXXX/MessageUtil.zip"
              },
              "encryptionKey": "arn:aws:kms:ap-northeast-1:XXXXXXXXXXXX:alias/aws/s3",
              "arn": "arn:aws:codebuild:ap-northeast-1:XXXXXXXXXXXX:project/codebuild-demo-java-20170417",
              "description": "codebuild demo (java)"
          }
      ]
  }

2. プロジェクトの削除

変数の確認
cat << ETX

        CODEB_PROJECT_NAME: ${CODEB_PROJECT_NAME}

ETX
コマンド
aws codebuild delete-project 
        --name ${CODEB_PROJECT_NAME}

結果(例):

  (戻り値なし)

3. 事後作業

同名のプロジェクトの不存在確認します。

コマンド
aws codebuild batch-get-projects 
        --names "${ARRAY_CODEB_PROJECT_NAMES}"

結果(例):

  {
    "projectsNotFound": [
      "codebuild-demo-java-20170417"
    ],
    "projects": []
  }

完了

続きを読む

[JAWS-UG CLI] CodeBuild: #2 プロジェクトの作成

前提条件

CodeBuildへの権限

CodeBuildに対してフル権限があること。

AWS CLIのバージョン

以下のバージョンで動作確認済

  • AWS CLI 1.11.57
コマンド
aws --version

結果(例):

  aws-cli/1.11.70 Python/2.7.12 Linux/4.4.11-23.53.amzn1.x86_64 botocore/1.5.33

バージョンが古い場合は最新版に更新しましょう。

コマンド
sudo -H pip install -U awscli

0. 準備

まず変数の確認をします。

変数の確認
cat << ETX

        AWS_DEFAULT_PROFILE: (0.1) ${AWS_DEFAULT_PROFILE}
        AWS_DEFAULT_REGION:  (0.2) ${AWS_DEFAULT_REGION}
        FILE_ZIP             (0.3) ${FILE_ZIP}
        IAM_ROLE_ARN        (0.4) ${IAM_ROLE_ARN}

ETX

結果(例):

  AWS_DEFAULT_PROFILE: (0.1) <CodeBuildにフル権限のあるプロファイル>
  AWS_DEFAULT_REGION:  (0.2) ap-northeast-1
  FILE_ZIP             (0.3) MessageUtil.zip
  IAM_ROLE_ARN         (0.4) arn:aws:iam::XXXXXXXXXXXX:role/CodeBuildServiceRole

変数が入っていない、適切でない場合は、それぞれの手順番号について作業を
行います。

0.1. プロファイルの指定

プロファイルの一覧を確認します。

コマンド
cat ~/.aws/credentials 
       | grep '[' 
       | sed 's/[//g' | sed 's/]//g'

結果(例):

  iamFull-prjz-mbpr13
  <CodeBuildにフル権限のあるプロファイル>
変数の設定
export AWS_DEFAULT_PROFILE='<CodeBuildにフル権限のあるプロファイル>'

0.2. リージョンの指定

変数の設定
export AWS_DEFAULT_REGION='ap-northeast-1'

0.3. ソースコードZIPファイルの指定

変数の設定
FILE_ZIP='MessageUtil.zip'
コマンド
aws s3 ls s3://${S3_BUCKET_SOURCE}/${FILE_ZIP}

0.4. IAMロールの指定

変数の設定
IAM_ROLE_NAME='CodeBuildServiceRole'
コマンド
IAM_ROLE_ARN=$( 
        aws iam get-role 
          --role-name ${IAM_ROLE_NAME} 
          --query 'Role.Arn' 
          --output text 
) 
        && echo ${IAM_ROLE_ARN}

結果(例):

  arn:aws:iam::XXXXXXXXXXXX:role/CodeBuildServiceRole

最終確認

変数の確認
cat << ETX

        AWS_DEFAULT_PROFILE: (0.1) ${AWS_DEFAULT_PROFILE}
        AWS_DEFAULT_REGION:  (0.2) ${AWS_DEFAULT_REGION}
        FILE_ZIP             (0.3) ${FILE_ZIP}
        IAM_ROLE_NAME        (0.4) ${IAM_ROLE_NAME}

ETX

結果(例):

  AWS_DEFAULT_PROFILE: (0.1) <CodeBuildにフル権限のあるプロファイル>
  AWS_DEFAULT_REGION:  (0.2) ap-northeast-1
  FILE_ZIP             (0.3) MessageUtil.zip
  IAM_ROLE_NAME        (0.4) CodeBuildServiceRole

1. 事前作業

1.1. プロジェクト名の指定

変数の設定
CODEB_PROJECT_NAME='codebuild-demo-java-20170417'

同名のプロジェクトの不存在確認します。

変数の設定
ARRAY_CODEB_PROJECT_NAMES="${CODEB_PROJECT_NAME}" 
        && echo ${ARRAY_CODEB_PROJECT_NAMES}

同名のプロジェクトの不存在確認します。

コマンド
aws codebuild batch-get-projects 
        --names "${ARRAY_CODEB_PROJECT_NAMES}"

結果(例):

  {
    "projectsNotFound": [
      "codebuild-demo-java-20170417"
    ],
    "projects": []
  }

1.2. プロジェクトの説明の指定

変数の設定
CODEB_PROJECT_DESC='codebuild demo (java)'

1.3. ソースコードタイプの指定

変数の設定
CODEB_SOURCE_TYPE='S3'

1.4. ソースコード用S3バケットの指定

変数の設定
S3_BUCKET_SOURCE=$( 
        aws s3 ls 
          | grep "source-${AWS_DEFAULT_REGION}" 
          | cut -d ' ' -f3 
) 
        && echo ${S3_BUCKET_SOURCE}

結果(例):

  source-ap-northeast-1-XXXXXXXXXXXX

1.5. source

変数の確認
cat << ETX

        CODEB_SOURCE_TYPE: ${CODEB_SOURCE_TYPE}
        S3_BUCKET_SOURCE:  ${S3_BUCKET_SOURCE}
        FILE_ZIP:          ${FILE_ZIP}

ETX
変数の設定
CODEB_PROJECT_SOURCE="type=${CODEB_SOURCE_TYPE},location=${S3_BUCKET_SOURCE}/${FILE_ZIP}" 
        && echo ${CODEB_PROJECT_SOURCE}

結果(例):

  type=S3,location=source-ap-northeast-1-XXXXXXXXXXXX/MessageUtil.zip

1.6. アーティファクトタイプの指定

変数の設定
CODEB_ARTIFACTS_TYPE='S3'

1.7. アーティファクト用S3バケットの指定

変数の設定
S3_BUCKET_ARTIFACTS=$( 
        aws s3 ls 
          | grep "artifact-${AWS_DEFAULT_REGION}" 
          | cut -d ' ' -f3 
) 
        && echo ${S3_BUCKET_ARTIFACTS}

結果(例):

  artifact-ap-northeast-1-XXXXXXXXXXXX

1.8. artifacts

変数の確認
cat << ETX

        CODEB_ARTIFACTS_TYPE: ${CODEB_ARTIFACTS_TYPE}
        S3_BUCKET_ARTIFACTS:  ${S3_BUCKET_ARTIFACTS}

ETX
変数の設定
CODEB_PROJECT_ARTIFACTS="type=${CODEB_ARTIFACTS_TYPE},location=${S3_BUCKET_ARTIFACTS}" 
        && echo ${CODEB_PROJECT_ARTIFACTS}

結果(例):

  type=S3,location=artifact-ap-northeast-1-XXXXXXXXXXXX

1.9. 環境タイプの指定

変数の設定
CODEB_ENV_TYPE='LINUX_CONTAINER'

1.10. 環境イメージの指定

注釈: http://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref.html

変数の設定
CODEB_ENV_IMAGE='aws/codebuild/java:openjdk-8'

1.11. 環境コンピュートタイプの指定

変数の設定
CODEB_ENV_COMPUTE_TYPE='BUILD_GENERAL1_SMALL'

1.12. environment

変数の確認
cat << ETX

        CODEB_ENV_TYPE:         ${CODEB_ENV_TYPE}
        CODEB_ENV_IMAGE:        ${CODEB_ENV_IMAGE}
        CODEB_ENV_COMPUTE_TYPE: ${CODEB_ENV_COMPUTE_TYPE}

ETX
変数の設定
CODEB_PROJECT_ENVIRONMENT="type=${CODEB_ENV_TYPE},image=${CODEB_ENV_IMAGE},computeType=${CODEB_ENV_COMPUTE_TYPE}" 
        && echo ${CODEB_PROJECT_ENVIRONMENT}

結果(例):

  type=LINUX_CONTAINER,image=aws/codebuild/java:openjdk-8,computeType=BUILD_GENERAL1_SMALL

2. プロジェクトの作成

変数の確認
cat << ETX

        CODEB_PROJECT_NAME:        ${CODEB_PROJECT_NAME}
        CODEB_PROJECT_DESC:        ${CODEB_PROJECT_DESC}
        CODEB_PROJECT_SOURCE:      ${CODEB_PROJECT_SOURCE}
        CODEB_PROJECT_ARTIFACTS:   ${CODEB_PROJECT_ARTIFACTS}
        CODEB_PROJECT_ENVIRONMENT: ${CODEB_PROJECT_ENVIRONMENT}
        IAM_ROLE_ARN:              ${IAM_ROLE_ARN}

ETX
コマンド
aws codebuild create-project 
        --name ${CODEB_PROJECT_NAME} 
        --description "${CODEB_PROJECT_DESC}" 
        --source ${CODEB_PROJECT_SOURCE} 
        --artifacts ${CODEB_PROJECT_ARTIFACTS} 
        --environment ${CODEB_PROJECT_ENVIRONMENT} 
        --service-role ${IAM_ROLE_ARN}

結果(例):

  {
    "project": {
      "name": "codebuild-demo-java-20170417",
      "serviceRole": "arn:aws:iam::XXXXXXXXXXXX:role/CodeBuildServiceRole",
      "created": 14xxxxxxxx.000,
      "source": {
          "type": "S3",
          "location": "source-ap-northeast-1-XXXXXXXXXXXX/MessageUtil.zip"
      },
      "artifacts": {
          "namespaceType": "NONE",
          "packaging": "NONE",
          "type": "S3",
          "location": "artifact-ap-northeast-1-XXXXXXXXXXXX",
          "name": "codebuild-demo-java-20170417"
      },
      "lastModified": 14xxxxxxxx.000,
      "timeoutInMinutes": 60,
      "environment": {
          "computeType": "BUILD_GENERAL1_SMALL",
          "image": "aws/codebuild/java:openjdk-8",
          "type": "LINUX_CONTAINER",
          "environmentVariables": []
      },
      "encryptionKey": "arn:aws:kms:ap-northeast-1:XXXXXXXXXXXX:alias/aws/s3",
      "arn": "arn:aws:codebuild:ap-northeast-1:XXXXXXXXXXXX:project/codebuild-demo-java-20170417"
      "description": "codebuild demo (java)"
    }
  }

3. 事後作業

コマンド
aws codebuild batch-get-projects 
        --names "${ARRAY_CODEB_PROJECT_NAMES}"

結果(例):

  {
      "projectsNotFound": [],
      "projects": [
          {
              "name": "codebuild-demo-java-20170417",
              "serviceRole": "arn:aws:iam::XXXXXXXXXXXX:role/CodeBuildServiceRole",
              "tags": [],
              "artifacts": {
                  "namespaceType": "NONE",
                  "packaging": "NONE",
                  "type": "S3 ",
                  "location": "artifact-ap-northeast-1-XXXXXXXXXXXX",
                  "name": "codebuild-demo-java-20170417"
              },
              "lastModified": 14xxxxxxxx.000,
              "timeoutInMinutes": 60,
              "created": 14xxxxxxxx.000,
              "environment": {
                  "computeType": "BUILD_GENERAL1_SMALL",
                  "image": "aws/codebuild/java:openjdk-8",
                  "type": "LINUX_CONTAINER",
                  "environmentVariables": []
              },
              "source": {
                  "type": "S3",
                  "location": "source-ap-northeast-1-XXXXXXXXXXXX/MessageUtil.zip"
              },
              "encryptionKey": "arn:aws:kms:ap-northeast-1:XXXXXXXXXXXX:alias/aws/s3",
              "arn": "arn:aws:codebuild:ap-northeast-1:XXXXXXXXXXXX:project/codebuild-demo-java-20170417",
              "description": "codebuild demo (java)"
          }
      ]
  }

完了

続きを読む