クラウドインフラ構築記

先日AWSモバイル/IoTサービス徹底攻略！！～Developers.IO Meetup番外編～に参加しました。

センサーからOpenBlock BX1 →SORACOM Air →AWS IoT→DynamoDBまで登録する流れをハンズオンで体験できました。

• SIMの挿入取り出しがしずらい。OpenBlock BX1ではナノサイズではなく、フルサイズで
• OpenBlock BX1の時刻は同期しておかないとログ収集がうまくいかない
• root証明書等スペースがあるファイルだとAWS IoTの設定ができない

Raspberry Pi2 等でも同様な仕組みは作成できると思われるが、Open Block BX1は、AWS Mobile SDK/3Gモジュール/WebUIが組み込まれており、事前準備がかなり省けることが実感。

AWS IoTの設定ですが、ハンズオン時はManagement Consoleで行いましたが、CLIでもできます。以下CLIでのAWS IoTの設定になります。

Thingの登録

aws iot create-thing --thing-name bx1

登録されたThingsを確認します。1度作成したthing名を削除して再登録しても登録自体はエラーは出ませんが、list-things、Management Consoleで確認しても登録されません。

この件、先ほど確認したところ、削除したThingで再登録できるようになっていました。

aws iot list-things

aws iot describe-thing --thing-name bx1-demo --region ap-northeast-1

証明書、秘密鍵、公開鍵を作成します。証明書は後からでも取得可能ですが、秘密鍵、公開鍵は作成時しか取得できないので、保存は忘れずに。

aws iot create-keys-and-certificate --set-as-active > cert.json

cat cert.json | jq .keyPair.PublicKey -r > thing-public-key.pem

cat cert.json | jq .keyPair.PrivateKey -r > private-key.pemm

証明書上位方は下記より取得できます。

aws iot​ describe-certificate --certificate-id "your-certificate-id" --output text --query certificateDescription.certificatePem > cert.pem

root証明書をダウンロードしておきます。

wget https://www.symantec.com/content/en/us/enterprise/verisign/roots/VeriSign-Class%203-Public-Primary-Certification-Authority-G5.pem -O rootCA.pem

IoTポリシを作成します。

 vi policy.json

{
 "Version": "2012-10-17", 
 "Statement": [{
 "Effect": "Allow",
 "Action":["iot:*"],
 "Resource": ["*"]
 }]
}

aws iot create-policy --policy-name awsiot-handon-policy --policy-document file://policy.json

作成したポリシは以下で確認できます。

aws  iot get-policy --policy-name awsiot-handon-policy --region ap-northeast-1

先ほど作成されたポリシを証明書と紐付けます。

aws  iot attach-principal-policy --principal "certificateArn" --policy-name "awsiot-handon-policy"

Thingsも証明書に紐付けます。

aws iot attach-thing-principal --thing-name "bx1-demo" --principal "certificateArn"

certificateArnには、下記で確認することができます。

aws --profile target1 iot list-thing-principals --thing-name  bx1-demo --region ap-northeast-1

AWS IoTからどんなアクションを行うかRuleで設定します。
Rule設定用のjsonテンプレートから作成するのが一番いいかと思われます。下記はDynamoDBと連携する例にはなりますが、Kinesis、Firehose、S3、SQS、SNSなどとも連携が可能です。

aws  iot create-topic-rule --generate-cli-skeleton

vi rule.json

{
 "ruleName": "IoTHandsonRule2",
 "topicRulePayload": {
 "sql": "SELECT * FROM 'handson/device01'",
 "description": "",
 "actions": [
 {
 "dynamoDB": {
 "tableName": "IoTHandsonRawData",
 "roleArn" : "arn:aws:iam::XXXXXXXXXXXX:role/aws_iot_dynamoDB",
 "hashKeyField": "sensor",
 "hashKeyValue": "${topic(2)}",
 "rangeKeyField": "timestamp",
 "rangeKeyValue": "${timestamp()}"
 }
 }
 ],
 "ruleDisabled": false
 }
}

aws  iot create-topic-rule --cli-input-json file://rule.json

作成したRulesを確認します。

aws --profile target1 iot list-topic-rules --region ap-northeast-1

AWS IoTのEnd Pointは下記で確認することができます。

aws  target1 iot describe-endpoint --region ap-northeast-1

先日のAWSモバイル/IoTサービス徹底攻略！！IoTハンズオンの際は、AWS IoTのエンドポイントとして、data.iot.ap-northeast-1.amazonaws.comで行いましたが、nslookupで確認したところ、同じ送信先IPアドレスになっていますので、どちらを使ってもいけると思われます。

秘密鍵、公開鍵、証明書の削除は現時点では、Management Consoleから行えないので（Deactiveは可能）、削除する場合は、CLIで行う必要があります。

先日のJAWS-UGアーキテクチャー専門支部#2に議論参加側で参加してきました。

Blue-Green deployment パターン(EC2)実装編の叩き台

Blue-Green deploymentとしては、ELBによるもの、DNSによるもの実装としては2つある。

Opsworks、ElasticBeanstalkは、DNSベース。

Blue-Green Deploymentとは異なりますが、Rolling Updateの方法も。過去Rolling Updateの記事を参考までに。

今回は、Ec2のBlue-Green deploymentの話でしたが、Docker、No EC2の場合もあり、幅広くなりそう。

Lambda ＋　API Gateway

受け付ける元がIoTデバイスの場合、100%の許容は必要ないのでは。Kinesisとかバッファリングできるので、少々のダウンとか許容できる

API Gatewayのベストプラスティス

Deploy APIで、ステージング環境（Stage）を作成できるので、Stage→ProductionでAPI GatewayのDeployment管理はできる、ただ、Lambda等組み合わせるので、こちらも考慮する必要があるか。Inheit from Stageで/(production)にoverrideも。

API Gatewayはプロトコル変換が可能。Lambdaを使うと待機リソースが不要。

CodeDeply

デプロイ方式の議論から

• AMI
• userdata (cloud-init)
• Chef/Ansible

Enterpriseの現場では、一番のAMIデプロイが多い。事実、tomcat、Apache等ミドルを入れ込んだ数種類のAMIを用意して、用途に合わせたサーバーを構築するケースもあります。AutoScalingの際、userdataがLaunch Configurationに組み込まれているので、userdata scriptで修正が生じた場合、Launch Configurationから作り直さなければならない。今後のアップデートを期待したい。

メリット

• WebUI
• AutoScaling時の自動適用

デメリット

• ソースが、S3、githubのみ。
  • gitlab等プライベートリポジトリへは未対応。
•  Internetへのアクセスが必要
  • S3のみに限定されているVPC Endpointの他のCodeCommit、DynamoDB等へ対応が待たれる。

CodeDepolyは開発環境で使うのいい？

DynamoDB Streams、Lambdaを使ったアーキテクチャーをまとめていければと思います。

次回はEc2を前提としないクラウドネイティブなCDP  10/15になります。