LoRaWANとSORACOMFunnelのAWSIoTアダプタを使ってDynamoDBにデータを書き込む

はじめに

つい先日、SORACOMFunnelがAWSIoTに対応したというニュースを耳にしました
ちょうど仕事の関係でSORACOMのシールドが届いたし、会社にLoRaWANのPublicGWもあることだし・・・
ということでちょいと触ってみた
SORACOM公式ブログにも手順が書いてありましたが、ちょっと躓いたところがあったりしたので、まとめてみました

やりたいこと

  1. LoRaデバイスからLoRaゲートウェイを通ってAWSIoTにセンサーデータを投げる
  2. AWSIoTが受け取ったデータを加工するためのLambdaファンクションをキックする
  3. Lambdaがデータを加工してDynamoDBに格納する

SORACOM Funnelって?

SORACOM Funnel(以下、Funnel) は、デバイスからのデータを特定のクラウドサービスに直接転送するクラウドリソースアダプターです。
Funnel でサポートされるクラウドサービスと、そのサービスの接続先のリソースを指定するだけで、データを指定のリソースにインプット
することができます。

http://soracom.jp/services/funnel/より抜粋
要するに、デバイスからAWSなどのクラウド上に閉域網でデータを送信することができるサービス(合ってるかな・・・)

AWSIoTって?

AWS IoT によって、さまざまなデバイスを AWS の各種 Services や他のデバイスに接続し、データと通信を保護し、
デバイスデータに対する処理やアクションを実行することが可能になります。
アプリケーションからは、デバイスがオフラインの状態でもデバイスとのやり取りが可能です。

https://aws.amazon.com/jp/iot-platform/how-it-works/より抜粋
うーん、なるほどわからん。とりあえず使ってみよう

デバイス側の設定

同じ部署の電気系強いお方が気づいたらセッティングしていただいていましたので割愛
この時点でSORACOM Harvestにてデータが送信されているのを確認できている状態

AWSIoTの設定

Funnelでデータを送信する先のAWSIoTを作成します

エンドポイントを控える

Funnelを設定する際に必要なAWSIoTのエンドポイントを控えておきます

AWSIoT_TOP.PNG

Ruleを作成する

左のサイドメニューから「Rule」を選択し、「Create a rule」をクリック

AWSIoT_Rule.PNG

「Name」と「Description」を入力する(Descriptionは任意)

AWSIoT_Rule_name.PNG

「Attribute」に「*」、「Topic filter」に「IoTDemo/#」を入力
「Using SQL version」は「2016-03-23」で問題なければそのままでOK

AWSIoT_Rule_massage.PNG

「Set one or more actions」の「add action」をクリック

AWSIoT_Rule_set_action.PNG

今回はLambdaでデコードする必要があるため「Invoke a Lambda function passing the message data」を選択

AWSIoT_Rule_select_lambda.PNG

「Configure action」を選択

AWSIoT_Rule_select_lambda_button.PNG

キックするLambda Functionを選択
今回は初めて作成するので、Lambdaが呼ばれたときのeventの中身をログに吐き出すLambdaを作成して、それをキックするようにします
※DynamoDBに格納する処理は後ほど実装

「Create a new resouce」をクリック。Lambdaのページに遷移します

AWSIoT_Rule_lambda_create.PNG

「Blank Function」を選択

Lambda_create.PNG

Lambdaのトリガーを設定
「IoTタイプ」は「カスタムIoTルール」を選択
「ルール名は」現在作成中のルール名
「SQLステートメント」は作成中の「Rule query statement」の中身をコピー
「次へ」をクリック

Lambda_trigger.PNG

「名前」はお好きなFunction名をつけてください
「ランタイム」は筆者の好みによりNode.jsです
コードには

exports.handler = (event, context, callback) => {
    console.log(event);
};

と書いておいてください。

Lambda_setting.PNG

あとは、DynamoDBの権限を持ったロールを選択(作成)して、ページ下部の「次へ」をクリックしてLambdaFunctionを作成してください

AWSIoTのページに戻って、先ほど作成したLambdaFunctionを選択し、「Add action」をクリック

AWSIoT_Rule_add_lambda.PNG

その後「create Rule」をクリックするとRuleが作成されます
これでAWSIoTのRule作成が完了です

SORACOM Funnelの設定

まず、SORACOMコンソールにログインし、再度メニューから「LoRaグループ」⇒「追加」をクリックします
ポップアップが出てきてグループ名を入力するように言ってくるので、任意のグループ名を入力しグループを作成します

作成したグループを選択し、設定画面に移動します

転送先サービス:AWS IoT
転送先URL:https:///rule内で作成したSQLTopicFilter/#{deviceId}
認証情報:AWSIoTの権限を持ったIAMアカウント情報で作成したもの
送信データ形式:無難にJSON

funnel_setting.PNG

※転送先URLにはプレースホルダーを作成することができます
  - SIMを利用する場合:{imsi}
  - LoRaデバイスを利用する場合:{deviceId}

これでFunnelの設定は完了です

Lambdaの実装

デバイスの電源を入れ、データが送信されるようになると、Lambdaが起動してeventの中身をログに吐き出していると思います
↓こんな感じ

2017-06-23T04:13:59.850Z 62014535-57ca-11e7-b4e4-9fbd147f2037 { 
  operatorId: '0123456789',
  timestamp: 1498191237793,
  destination: { 
    resourceUrl: 'https://xxxxxxxxx.iot.ap-northeast-1.amazonaws.com/xxxxxxx/#{deviceId}',
    service: 'aws-iot',
    provider: 'aws' 
  },
  credentialsId: 'iot-sys',
  payloads: { 
    date: '2017-06-23T04:13:54.276320',
    gatewayData: [ [Object] ],
    data: '7b2268223a36312e367d',
    deveui: '1234567890' 
  },
  sourceProtocol: 'lora',
  deviceId: '1234567890' 
}

センサーから送られてくるデータはevent[“payloads”][“data”]にHEX形式で格納されているので、取り出してデコードする必要があります。


const data = event["payloads"]["data"];
const decodeData = new Buffer(data, "hex").toString("utf8");

デコードすると「7b2268223a36312e367d」⇒「{“h”: 61.6}」のようなString型になります(これは一例)

Object型のほうが使い勝手がよいので、parseしてしまいましょう


const parseData = JSON.parse(decodeData); // {h : 61.6}

あとはDynamoDBにputで投げつけます

index.js
"use strict";

const AWS = require("aws-sdk");
const co = require("co");
const moment = require("moment-timezone");

const dynamodb = new AWS.DynamoDB.DocumentClient({
  region: "ap-northeast-1"
});

const dynamoPutData = require("./lib/dynamo_put_data");

exports.handler = (event, context, callback) => {
  // UTCなのでJSTに変換
  const date = event["payloads"]["date"];
  const time = moment(date).tz("Asia/Tokyo").format();
  // HEX形式をデコード
  const data = event["payloads"]["data"];
  const decodeData = new Buffer(data, "hex").toString("utf8");
  // Object型に変換
  const parseData = JSON.parse(decodeData);
  // deviceIdを取得
  const deviceId = event["deviceId"];

  // DynamoDBにPUTするItem
  const item = [{
    deviceId: deviceId,
    time: time,
    value: parseData
  }];

  co(function *() {
    yield dynamoPutData.putDynamoDB(dynamodb, item[0]);
  }).then(() => {
    console.log("success!")
  }).catch((err) => {
    console.log(err);
  });
};

dynamo_put_data.js
"use strict";

class dynamoPutData {
  /**
   * DynamoDBへのPUT処理
   * @param {DocumentClient} dynamoDB
   * @param item
   * @returns {Promise}
   */
  static putDynamoDB(dynamoDB, item) {
    const params = {
      TableName: "TABLE_NAME",
      Item: item
    };
    return dynamoDB.put(params).promise();
  }
}

module.exports = dynamoPutData;

dynamo_put_data.js中の”TABLE_NAME”にはデータを投げつけるテーブル名を書いてください
関数を外だしして複数ファイルがあるので、Lambdaにはソースコード一式をZIPに固めてアップする方法でデプロイを行います
データが送られてきてLambdaがキックされると、DynamoDBにデータが格納されていると思います

まとめ

日ごろからAWSのサービスを使っていましたが、AWSIoTを利用する機会がなくとてもいい経験になりました。
今回はデバイスからクラウドといった方向でしたが、AWSIoTを利用すればその逆方向も実現することができるらしいので、近々そういった実装もしてみたと思います

では!

続きを読む

CodeStarバンザイ!数クリックで始めるCI/CDパイプライン

CodeStarを使ってCI/CDパイプラインを構築してみたので、紹介します。

CodeStarとは?

AWSのマネージドサービスであるCodePipeline、CodeCommit、CodeBuild、CodeDeployを使ってCI/CDパイプライン+実行環境をさくっと構築してくれるサービスらしい。

https://aws.amazon.com/jp/codestar/

よしっ、動かしてみるぞ!!

1.プロジェクト作成

マネジメントコンソールからCodeStarを選び、「start a project」をポチッ。
するとプロジェクトのテンプレートを選択する画面が表示される。

カテゴリは、Web application、Web service、Alexa Skill、Static Websiteから、
言語は、Ruby、Node.js、Java、Python、PHP、HTML 5から、
実行環境は、Beanstalk、EC2、Lambdaから選択できる。
※もちろん存在しない組み合わせもあります。

今の時代っぽいWeb Application×Node.js×Lambdaなんてのも選択できるんですね。

うーん、ここはCodeBuildも使ってみたいし「Web Application×Java Spring×EC2」を選択。

使う1.png

そして、プロジェクト名を入力。インスタンスタイプを設定して。ポチッ、ポチッ。

使う2.png

。。。
はいっ、CI/CDパイプライン構築の作業はこれで終わり。

そして、待つこと10分。
CodePipeline、CodeCommit、CodeBuild、CodeDeployと、これを統合的に確認するためのダッシュボードがいい感じにできちゃいました。
もちろんjavaのwebアプリケーションも起動しています。

ダッシュボード

使う4修正.png

CodePipeline

使う8.png

CodeCommit

使う5.png

CodeBuild

使う6.png

CodeDeploy

使う7.png

デプロイされたjavaのwebアプリケーション

12.png

2.CI/CDパイプライン実行

ここからが本番。
gitへの接続情報をIAMで確認(ユーザ⇒認証情報⇒AWS CodeCommit の HTTPS Git 認証情報「生成」)し、code commit上のソースコードをcloneする。
するとこんなものが落ちてきます。

tree
.
├── README.md
├── appspec.yml
├── buildspec.yml
├── pom.xml
├── scripts
│   ├── install_dependencies
│   └── start_server
└── src
    └── main
        ├── java
        │   └── com
        │       └── aws
        │           └── codestar
        │               └── projecttemplates
        │                   ├── HelloWorldAppInitializer.java
        │                   ├── configuration
        │                   │   ├── ApplicationConfig.java
        │                   │   └── MvcConfig.java
        │                   └── controller
        │                       └── HelloWorldController.java
        ├── resources
        │   └── application.properties
        └── webapp
            ├── WEB-INF
            │   └── views
            │       └── index.jsp
            └── resources
                ├── gradients.css
                ├── set-background.js
                ├── styles.css
                └── tweet.svg

ふむふむ、なるほど。
ここは手っ取り早くCI/CDパイプラインを確認するため、index.jspをちょこっと修正。
そして、code commitにpush。
code commit上で、変更した内容も確認できます。

使う11.png
すると。。。

使う9.png

パイプラインが動き出したーーー
どうやら動きとしては、こんなことをやっているみたい。

  • Source : 新たしいコードがpushされると、code commitからソースコードを取得しS3に格納。
  • Build : S3からソースコードを取得しビルド。そしてビルドしたモジュールをS3に格納。
  • Application : S3に格納されたモジュールをEC2にデプロイ。

待つこと5分。デプロイまで成功。
そして、先程の画面を確認してみると。。。

使う10.png

変わった!
簡単!!

これを使えば

  • Java、Rubyなどメジャーな言語を利用したCI/CDパイプラインを爆速で構築できる。
  • Jenkinsから開放される。

がしかし。。

  • 東京リージョンにはまだ来ていない。
  • CodeStarというかcode commit側の問題になるが、pull requestが使えない。。

本番用のアプリケーション開発環境・実行環境として利用するのは、まだまだ難しいような気もしますが、
pocくらいであればこれで十分かもしれませんね。

続きを読む

Fresh Install bitnami redmine stack on AWS, then migrate old data and database from old instance.

Fresh Install bitnami redmine stack on AWS, then migrate old data and database from old instance.

目的: Redmine のバージョンアップ と HTTPS化

ですが、新環境の構築手順のみやっていただければ新規構築手順としても使えます。

  • 前回書いた記事から1年ちょっと経過しました。
  • bitnami redmine stack AMI のバージョンも以下のように変化しました。(2017/06/21 現在)
    • Old version 3.2.1
    • New version 3.3.3
  • 前回は GUI でぽちぽち作成しましたが、今回は AWS CLI を中心に進めます。
  • ついでに前回書いてなかった HTTPS化 についても簡単に追記します。
  • 以下の AWS の機能を利用します。
    • Route53: ドメイン名取得、名前解決(DNS)
    • ACM(Amazon Certificate Manager): 証明書発行
    • ELB(Elastic Load Balancer): 本来は複数インスタンスをバランシングする用途に使うものですが今回は EC2 インスタンス 1台 をぶら下げ、ACM で取得した証明書を配布し外部との HTTPS通信 のために利用します。

注意と免責

  • 無料枠でない部分は料金が発生します。
  • データの正常な移行を保証するものではありません。

前提

  • 現環境が正常に動作していること。
  • 新環境を同一リージョン、同一VPC、同一サブネット内に新たにたてます。
    • インスタンス間のデータ転送を SCP で簡易に行いたいと思います。
    • 適宜セキュリティグループを解放してください。
  • aws cli version
% aws --version
aws-cli/1.11.47 Python/2.7.12 Darwin/16.6.0 botocore/1.5.10

段取り

  • 大まかに以下の順序で進めます
  1. Version 3.3.3 の AMI を使って EC2 インスタンスを起動
  2. Version 3.2.1 のデータバックアップ
    • Bitnami Redmine Stack の停止
    • MySQL Dump 取得
  3. Version 3.3.3 へのデータ復元
    • Bitnami Redmine Stack の停止
    • MySQL Dump 復元
    • Bitnami Redmine Stack の開始
  4. 動作確認

参考資料

作業手順

1. Newer Bitnami redmine stack インスタンス作成

以下の条件で作成します。

  • Common conditions

    • AMI: ami-15f98503
    • Type: t2.micro
    • Public IP: あり
  • User defined conditions
    • Region: N.Virginia
    • Subnet: subnet-bd809696
    • Security Group: sg-5b5b8f2a
    • Keypair: aws-n.virginia-default001
    • IAM Role: ec2-001
    • EBS: 20GB

WEB GUI から作るも良し、AWS CLI から作るも良し
以下コマンド実行例

set-env
KEY_NAME=aws-nvirginia-default001.pem
echo $KEY_NAME
check-ami
aws ec2 describe-images \
    --filters "Name=image-id,Values=ami-15f98503"
check-ami-name
aws ec2 describe-images \
    --filters "Name=image-id,Values=ami-15f98503" \
    | jq ".Images[].Name" \
    | grep --color redmine-3.3.3
create-instance
aws ec2 run-instances \
    --image-id ami-15f98503 \
    --count 1 \
    --instance-type t2.micro \
    --key-name aws-n.virginia-default001 \
    --security-group-ids sg-5b5b8f2a \
    --subnet-id subnet-bd809696 \
    --block-device-mappings "[{\"DeviceName\":\"/dev/sda1\",\"Ebs\":{\"VolumeSize\":20,\"DeleteOnTermination\":false}}]" \
    --iam-instance-profile Name=ec2-001 \
    --associate-public-ip-address
set-env
INSTANCE_ID=i-0f8d079eef9e5aeba
echo $INSTANCE_ID
add-name-tag-to-instance
aws ec2 create-tags --resources $INSTANCE_ID \
    --tags Key=Name,Value=redmine-3.3.3

注意書きにもありますが以下に表示される MySQL Database の root パスワードは初期起動時にしか表示されません。
このときに保管しておくか MySQL のお作法にしたがって変更しておいても良いでしょう

check-instance-created
aws ec2 describe-instances --filter "Name=instance-id,Values=$INSTANCE_ID"
wait-running-state
aws ec2 describe-instances \
    --filter "Name=instance-id,Values=$INSTANCE_ID" \
    | jq '.Reservations[].Instances[].State["Name"]'
get-redmine-password
aws ec2 get-console-output \
    --instance-id $INSTANCE_ID \
    | grep "Setting Bitnami application password to"
get-publicip
aws ec2 describe-instances \
    --filter "Name=instance-id,Values=$INSTANCE_ID" \
    | jq '.Reservations[].Instances[].NetworkInterfaces[].Association'
set-env
PUBLIC_IP=54.243.10.66
echo $PUBLIC_IP
site-check
curl -I http://$PUBLIC_IP/
HTTP/1.1 200 OK
(snip)
ssh-connect
ssh -i .ssh/$KEY_NAME bitnami@$PUBLIC_IP
first-login
bitnami@new-version-host:~$ sudo apt-get update -y
bitnami@new-version-host:~$ sudo apt-get upgrade -y
bitnami@new-version-host:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
bitnami@new-version-host:~$ sudo ./stack/ctlscript.sh status
subversion already running
php-fpm already running
apache already running
mysql already running
bitnami@new-version-host:~$ sudo ./stack/ctlscript.sh help
usage: ./stack/ctlscript.sh help
       ./stack/ctlscript.sh (start|stop|restart|status)
       ./stack/ctlscript.sh (start|stop|restart|status) mysql
       ./stack/ctlscript.sh (start|stop|restart|status) php-fpm
       ./stack/ctlscript.sh (start|stop|restart|status) apache
       ./stack/ctlscript.sh (start|stop|restart|status) subversion

help       - this screen
start      - start the service(s)
stop       - stop  the service(s)
restart    - restart or start the service(s)
status     - show the status of the service(s)

2. 旧バージョンのバックアップ取得

login_to_oldversion
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-74-generic x86_64)
       ___ _ _                   _
      | _ |_) |_ _ _  __ _ _ __ (_)
      | _ \ |  _| ' \/ _` | '  \| |
      |___/_|\__|_|_|\__,_|_|_|_|_|

  *** Welcome to the Bitnami Redmine 3.2.0-1         ***
  *** Bitnami Wiki:   https://wiki.bitnami.com/      ***
  *** Bitnami Forums: https://community.bitnami.com/ ***
Last login: Sun May 29 07:33:45 2016 from xxx.xxx.xxx.xxx
bitnami@old-version-host:~$
check-status
bitnami@old-version-host:~$ sudo stack/ctlscript.sh status
subversion already running
php-fpm already running
apache already running
mysql already running
stop
bitnami@old-version-host:~$ sudo stack/ctlscript.sh stop
/opt/bitnami/subversion/scripts/ctl.sh : subversion stopped
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd stopped
/opt/bitnami/php/scripts/ctl.sh : php-fpm stopped
/opt/bitnami/mysql/scripts/ctl.sh : mysql stopped
start-mysql
bitnami@old-version-host:~$ sudo stack/ctlscript.sh start mysql
170621 10:04:34 mysqld_safe Logging to '/opt/bitnami/mysql/data/mysqld.log'.
170621 10:04:34 mysqld_safe Starting mysqld.bin daemon with databases from /opt/bitnami/mysql/data
/opt/bitnami/mysql/scripts/ctl.sh : mysql  started at port 3306
check-available-filesystem-space
bitnami@old-version-host:~$ df -h /
Filesystem                                              Size  Used Avail Use% Mounted on
/dev/disk/by-uuid/6cdd25df-8610-4f60-9fed-ec03ed643ceb  9.8G  2.7G  6.6G  29% /
load-env-setting
bitnami@old-version-host:~$ . stack/use_redmine
bitnami@old-version-host:~$ echo $BITNAMI_ROOT
/opt/bitnami
dump-mysql
bitnami@old-version-host:~$ mysqldump -u root -p bitnami_redmine > redmine_backup.sql
Enter password:
bitnami@old-version-host:~$ ls -ltrh
  • scp 準備

手元の作業PCから新Redmine環境へssh接続するときに使用した証明書(pem)ファイルを旧Redmine環境にも作成します。

  • 今回は作業PC上で cat で表示させておいて旧環境のコンソール上にコピペしました。
example
bitnami@old-version-host:~$ vi .ssh/aws-nvirginia-default001.pem
bitnami@old-version-host:~$ chmod 600 .ssh/aws-nvirginia-default001.pem
  • ファイル転送
file_transfer
bitnami@old-version-host:~$ scp -i .ssh/aws-nvirginia-default001.pem redmine_backup.sql <new-version-host-ipaddr>:~
  • 新バージョン側にファイルが届いているか確認
check-transfered-files
bitnami@new-version-host:~$ ls -alh redmine*

3. 新バージョンへの復元

stop-stack
bitnami@new-version-host:~$ sudo stack/ctlscript.sh status
subversion already running
php-fpm already running
apache already running
mysql already running

bitnami@new-version-host:~$ sudo stack/ctlscript.sh stop

/opt/bitnami/subversion/scripts/ctl.sh : subversion stopped
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd stopped
/opt/bitnami/php/scripts/ctl.sh : php-fpm stopped
/opt/bitnami/mysql/scripts/ctl.sh : mysql stopped
start-mysql
bitnami@new-version-host:~$ sudo stack/ctlscript.sh start mysql
initial-database
bitnami@new-version-host:~$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.6.35 MySQL Community Server (GPL)

(snip)

mysql> drop database bitnami_redmine;

mysql> create database bitnami_redmine;

mysql> grant all privileges on bitnami_redmine.* to 'bn_redmine'@'localhost' identified by 'DATAB
ASE_PASSWORD';

mysql> quit
restore-dumpfile
bitnami@new-version-host:~$ mysql -u root -p bitnami_redmine < redmine_backup.sql
Enter password:
bitnami@new-version-host:~$
edit-line-18
bitnami@new-version-host:~$ vi /opt/bitnami/apps/redmine/htdocs/config/database.yml

    18    password: "DATABASE_PASSWORD"
db-migrate
bitnami@new-version-host:~$ cd /opt/bitnami/apps/redmine/htdocs/
bitnami@new-version-host:/opt/bitnami/apps/redmine/htdocs$ ruby bin/rake db:migrate RAILS_ENV=production
bitnami@new-version-host:/opt/bitnami/apps/redmine/htdocs$ ruby bin/rake tmp:cache:clear
bitnami@new-version-host:/opt/bitnami/apps/redmine/htdocs$ ruby bin/rake tmp:sessions:clear
stack-restart
bitnami@new-version-host:/opt/bitnami/apps/redmine/htdocs$ cd
bitnami@new-version-host:~$ sudo stack/ctlscript.sh restart

bitnami@new-version-host:~$ exit
site-check
curl -I http://$PUBLIC_IP/
HTTP/1.1 200 OK
(snip)

ブラウザでも http://$PUBLIC_IP/ でアクセスして旧環境のユーザー名とパスワードでログイン出来ることを確認してください。

この時点で旧環境のインスタンスを停止させておいて良いでしょう。
いらないと判断した時に削除するなりしてください。

4. おまけ HTTPS化

  • 4-1. Route53 でドメイン名を取得してください

    • .net で 年額 11 USドル程度ですので実験用にひとつくらい維持しておくと便利
  • 4-2. Certificate Manager で証明書を取得します
    • コマンドでリクエストしてます
aws acm request-certificate --domain-name redmine.hogefuga.net
check-status-pending
aws acm describe-certificate \
    --certificate-arn "arn:aws:acm:us-east-1:942162428772:certificate/fdf099f9-ced7-4b97-a5dd-f85374d7d112" \
    | jq ".Certificate.Status"
"PENDING_VALIDATION"
  • 4-3. 承認する

    • ドメインに設定しているアドレスにメールが飛んできます
  • 4-4. ステータス確認
check-status-ISSUED
aws acm describe-certificate \
    --certificate-arn "arn:aws:acm:us-east-1:942162428772:certificate/fdf099f9-ced7-4b97-a5dd-f85374d7d112" \
    | jq ".Certificate.Status"
"ISSUED"
  • 4-5. Classic タイプの HTTPS ELB をつくる
example
aws elb create-load-balancer \
    --load-balancer-name redmine-elb1 \
    --listeners "Protocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTP,InstancePort=80,SSLCertificateId=arn:aws:acm:us-east-1:942162428772:certificate/fdf099f9-ced7-4b97-a5dd-f85374d7d112" \
    --availability-zones us-east-1a \
    --security-groups sg-3c90f343
  • 4-6. インスタンスをくっつける
example
aws elb register-instances-with-load-balancer \
    --load-balancer-name redmine-elb1 \
    --instances i-0f8d079eef9e5aeba
  • 4-7. State が InService になるまで待ちます
example
aws elb describe-instance-health \
    --load-balancer-name redmine-elb1
  • 4-8. DNS Name を確認する(4-10. で使います)
example
aws elb describe-load-balancers \
    --load-balancer-name redmine-elb1 \
  | jq ".LoadBalancerDescriptions[].DNSName"
  • 4-9. 今の設定を確認
example
aws route53 list-resource-record-sets \
    --hosted-zone-id Z3UG9LUEGNT0PE | jq .
  • 4-10. 投入用の JSON をつくる
example
vi change-resource-record-sets.json
example
{
  "Comment": "add CNAME for redmine.hogefuga.net",
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "redmine.hogefuga.net",
        "Type":"CNAME",
        "TTL": 300,
        "ResourceRecords": [
          {
            "Value": <DNSName>
          }
        ]
      }
    }
  ]
}

4-11. 設定投入

example
aws route53 change-resource-record-sets \
    --hosted-zone-id Z3UG9LUEGNT0PE \
    --change-batch file://change-resource-record-sets.json

4-12. 設定確認

example
aws route53 list-resource-record-sets \
    --hosted-zone-id Z3UG9LUEGNT0PE

4-13. ブラウザ確認

https://redmine.hogefuga.net

4-14. EC2 インスタンスのセキュリティグループ再設定

  • グローバルの TCP:80 削除
  • サブネット内の TCP:80 許可
check
aws ec2 describe-security-groups --group-ids sg-b7d983c8
change
aws ec2 modify-instance-attribute \
    --instance-id i-0f8d079eef9e5aeba \
    --groups sg-b7d983c8

4-15. 再度ブラウザからアクセス可能か確認

続きを読む

クラウドサーバーサービス(IaaS)の性能比較・CPU&メモリ&トランザクション編 ~sysbench~

1. 概要

 AWS,GCP,IDCFクラウドを対象に、sysbench を使ってCPU、メモリ、データベースのトランザクション処理のベンチマークを実行します。IDCFクラウドについては東日本リージョン2のluxと西日本リージョンのmonsteraを計測し、ゾーン間の違いがあるかも計測します。
(※ 東日本リージョンでも計測する予定でしたが、sysbenchの実行時にエラーが発生しため測定不能でした。エラーの内容は最後に掲載します。)

 OLTPテストの実行時には、実環境に近づけるためベンチマークを実行するサーバとデータベースサーバを分けてテストします。AWSとGCPはデータベースサービスを使用します。

計測対象 sysbenchサーバ DBサーバ (OLTP用)
Amazon Web Services (AWS) EC2 RDS
Google Cloud Platform (GCP) GCE Cloud SQL
IDCFクラウド (ゾーン:lux) 仮想マシン 仮想マシン
IDCFクラウド (ゾーン:monstera) 仮想マシン 仮想マシン

2. 条件

2.1 バージョン

OS/ミドルウェア バージョン
CentOS 7.3
MySQL 5.7
sysbench 1.0.5

2.2 環境

  • sysbenchサーバ
ゾーン スペック ディスクサイズ
AWS(EC2) ap-northeast-1 m4.large
(2vCPUメモリ8GB)
8GB
GCP(GCE) asia-northeast1-a n1-standard-2
(2vCPUメモリ7.5GB)
10GB
IDCF lux standard.M8
(2vCPUメモリ8GB)
15GB
IDCF monstera standard.M8
(2vCPUメモリ8GB)
15GB
  • DBサーバ(OLTP用)
ゾーン スペック ディスクサイズ
AWS(RDS) ap-northeast-1 db.t2.large
(2vCPUメモリ8GB)
100GB
GCP(Cloud SQL) asia-northeast1-a db-n1-standard-2
(2vCPUメモリ7.5GB)
100GB
IDCF lux standard.M8
(2vCPUメモリ8GB)
100GB
IDCF monstera standard.M8
(2vCPUメモリ8GB)
100GB

3. sysbenchのインストール

 EPEL レポジトリからsysbenchをインストールします。

$ yum install epel-release
$ yum install sysbench

4. cpuテスト

 sysbench のCPUテストでは、指定した最大探索数(デフォルトでは10000)以下の素数を数えるという処理を繰り返し行い、CPUの性能を計測します。

4.1 テスト内容

 スレッド数を 1 threads, 2 threads, 4 threadsと変更して計測してみます。

実行例)

sysbench cpu --threads=1 run > /tmp/sysbench_cpu_1.log
sysbench cpu --threads=2 run > /tmp/sysbench_cpu_2.log
sysbench cpu --threads=4 run > /tmp/sysbench_cpu_4.log

※ sysbench 1.0から構文が変更されています。本稿は1.0の構文で記述しています。

  • sysbench 0.5 : $ sysbench --test=<path> [options...] command
  • sysbench 1.0 : $ sysbench [<path>] [options...] [command]

4.2 計測結果

※ sysbench 1.0はデフォルトで合計実行時間が一定となっており、古いバージョンではデフォルトでイベントの合計数が一定となっているため、結果の比較方法が古いバージョンと異なります。

 実行時間はデフォルトで10秒固定となっていました。 以下は制限時間(10秒)内で処理したイベント数の比較です。

対象/スレッド数 1 2 4
AWS 8744 13927 14022
GCP 9014 15396 15441
IDCF(lux) 10046 20075 18107
IDCF(monstera) 10036 20055 17962

cpu2.PNG

  • スペックが2CPUなので、2スレッドで頭打ちになる結果となっています。
  • AWS < GCP < IDCF の順にCPUの性能がいい事がわかりました。
  • IDCFの東日本リージョンのluxと西日本リージョンのmonsteraは、ほぼ同じ結果となりました。

5. memoryテスト

 sysbench のメモリのベンチマークテストでは、メモリに対する連続した書き込みおよび読み出しを行い、--memory-total-size で指定されたサイズに達するまで繰り返します。
 オプションやデフォルト値は以下のようになっています。

sysbench memory help
sysbench 1.0.5 (using system LuaJIT 2.0.4)

memory options:
  --memory-block-size=SIZE    size of memory block for test [1K]
  --memory-total-size=SIZE    total size of data to transfer [100G]
  --memory-scope=STRING       memory access scope {global,local} [global]
  --memory-hugetlb[=on|off]   allocate memory from HugeTLB pool [off]
  --memory-oper=STRING        type of memory operations {read, write, none} [write]
  --memory-access-mode=STRING memory access mode {seq,rnd} [seq]

5.1 テスト内容

 今回はデフォルト値のまま実行します。

実行例)

sysbench memory run > /tmp/sysbench_memory_1_write_seq.log

5.2 計測結果

 1秒あたりのスループットの計測結果を示します。単位はMiB/secです。

AWS GCP IDCF(lux) IDCF(monstera)
1553.80 2668.44 4073.40 4039.96

memory3.PNG

  • AWS < GCP < IDCFの順に処理速度が速いことがわかりました。
  • IDCFの東日本リージョンのluxと西日本リージョンのmonsteraは、ほぼ同じ結果となりました。

6. OLTPテスト

 OLTPテストではデータベースへの読み書きを行って性能を測定します。

6.1データベースの準備

 AWSとGCPは、MySQLを選択してDBインスタンスを作成するだけなので、6.1.2 から実行します。

6.1.1 MySQLの準備(IDCFのみ)

 IDCFはデータベースサービスが無いので、ディスクの追加・マウント及びMySQlのデータディレクトリを追加ディスクに移動後、下記の手順でMySQLのインストール・起動・設定を行います。

6.1.1.1 インストール

 CentOS 7 はデフォルトではmariaDBが導入されるので、MySQL 公式の yum リポジトリを利用してYumリポジトリのインストールをします。

$ yum install https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm
$ yum install -y mysql-community-server
6.1.1.2 起動

 MySQL Server を起動します。

$ systemctl start mysqld.service
6.1.1.3 rootパスワード変更

 MySQL5.7ではroot の初期パスワードがMySQLのログファイルに出力されています。
 ログファイルから初期パスワードを取得します。

$ cat /var/log/mysqld.log | grep password | awk '{ print $NF }' | head -n 1

 mysql_secure_installationで新しい root パスワードを設定します。

6.1.1.4 my.cnf設定

 /etc/my.cnf の以下の値のみ変更しました。各値はRDSに合わせて設定しました。

innodb_buffer_pool_size = 6144M
max_connections = 648

6.1.2 測定用データベース作成

 OLTPテストを行うには、あらかじめデータベースにベンチマーク用のユーザーとデータベースを作成しておく必要があります。
デフォルトではデータベース名、ユーザ名ともに「sbtest」になので、以下のように作成しておきます。

$ mysql -u root -p
 :
 :
mysql> CREATE DATABASE sbtest;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON sbtest.* TO 'sbtest'@'***.***.***.***' IDENTIFIED BY '<パスワード>';
Query OK, 0 rows affected (0.00 sec)

mysql> select user,host from mysql.user;
+-----------+-----------------+
| user      | host            |
+-----------+-----------------+
| sbtest    | ***.***.***.*** |
| mysql.sys | localhost       |
| root      | localhost       |
+-----------+-----------------+

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
  • ***.***.***.*** の部分はSysBenchを実行するサーバのIPアドレス又はエンドポイントを指定します。
  • <パスワード>は、データベースのポリシーに合わせて適切な値に変更して実行してください。

6.2 テスト実行

6.2.1 測定用テーブルの作成

 テスト用のテーブルを作成し、テストデータを用意します。

sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua 
--db-driver=mysql 
--oltp-table-size=1000000 
--mysql-host=<DBサーバのIPアドレス又はエンドポイント名> 
--mysql-password=<パスワード> 
prepare

6.2.2 テスト内容

 スレッド数1, 2, 3, 4, 16, 200, 500 のそれぞれについて、Read OnlyとRead-Writeの2パターンを実行します。

  • Read Onlyの実行例)
sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua 
--oltp-table-size=1000000 
--db-driver=mysql 
--mysql-host=<DBサーバのIPアドレス or エンドポイント> 
--mysql-db=sbtest 
--mysql-user=sbtest 
--mysql-password=<パスワード> 
--time=60 
--events=0 
--threads=1 
--oltp_read_only=on run >> /tmp/sysbench_oltp_read_only_1.log
  • Read Writeの例
sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua 
--oltp-table-size=1000000 
--db-driver=mysql 
--mysql-host=<DBサーバのIPアドレス or エンドポイント> 
--mysql-db=sbtest 
--mysql-user=sbtest 
--mysql-password=<パスワード> 
--time=60 
--events=0 
--threads=1 
--oltp_read_only=off run >> /tmp/sysbench_oltp_read_write_1.log

6.3 計測結果

 計測結果を以下に示します。単位はTransaction per secondです。

  • Read Only
対象/スレッド数 1 2 4 16 200 500
AWS 228.92 405.27 615.24 804.34 791.74 721.49
GCP 178.85 307.33 531.70 745.20 708.65 664.51
IDCF(lux) 314.59 493.36 700.20 973.62 927.30 882.19
IDCF(monstera) 296.45 484.28 651.48 924.41 930.86 841.27

ReadOnly2.PNG

  • Read Write
対象/スレッド数 1 2 4 16 200 500
AWS 100.80 188.70 320.92 538.65 598.57 553.02
GCP 103.72 197.73 318.18 543.03 534.49 515.96
IDCF(lux) 190.75 306.82 439.92 699.05 694.88 676.92
IDCF(monstera) 189.57 310.65 411.68 690.48 672.42 652.98

ReadWrite2.PNG

  • どのクラウドサーバもスレッド数16以降は性能が横ばいになり、少しずつ低下しています。
  • Read Only では GCP < AWS < IDCF の順にトランザクション性能が高いことがわかりました。
  • Read Wite では AWS と GCP がほぼ同じ結果となり、IDCF はより高い性能を示しました。
  • IDCFの東日本リージョンのluxと西日本リージョンのmonsteraは、ほぼ同じ結果となりました。
  • IDCFはデータベースサービスが無いのでデータベースの構築とチューニングに手間がかかります。

補足:IDCFの東日本リージョンで実施した際のエラー内容

  • CPUテスト実行時:
# sysbench cpu --threads=1 run
sysbench 1.0.5 (using system LuaJIT 2.0.4)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

Illegal instruction
  • メモリテスト実行時:
# sysbench memory run
sysbench 1.0.5 (using system LuaJIT 2.0.4)

Illegal instruction
  • OLTPテストでprepare実行時:
# sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua 
--db-driver=mysql 
--oltp-table-size=10000 
--mysql-host=localhost 
--mysql-db=sbtest 
--mysql-user=sbtest 
--mysql-password=SysbenchPassword1! prepare
sysbench 1.0.5 (using system LuaJIT 2.0.4)

Creating table 'sbtest1'...
Inserting 10000 records into 'sbtest1'
Illegal instruction

 テストデータをインサートするタイミングで以下のエラーが発生。
 MySQlにはsbtestテーブルが作成されており、レコードはゼロ件でした。
 /var/log/mysqld.log には以下のように出力されていました。

Aborted connection 7 to db: 'sbtest' user: 'sbtest' host: 'localhost' (Got an error reading communication packets)

 ※ henry, jouleの2つのゾーンで同様の現象が発生し、残念ながら今回は測定不能となりました。

続きを読む

:beginner: Amazon EC2 Simple Systems Manager (SSM) エージェントのインストール

:beginner:
Amazon EC2 Systems Managerを使用するためのエージェントを導入するまでの手順です。
内容としては初心者向けになっています。

前提条件

SSMエージェントの導入対象インスタンスからS3へのアクセス(HTTPS)が出来る必要があります。

Simple Systems Manager 用の管理ポリシーを追加

SSMを使用したいインスタンスに割り当てているIAMロールへSSMの管理ポリシーをアタッチする。

ロールがない場合は作成する。
2017-06-21-14-20-20.png

「AmazonEC2RoleforSSM」を選択し「ポリシーのアタッチ」を実施する。
2017-06-21-14-23-37.png

2017-06-21-14-26-28.png

Simple Systems Manager エージェントのインストール

:warning: Amazon Linux、RHEL、および CentOS 64 ビット の 東京リージョンの場合の手順

新規インスタンスの場合はユーザーデーターに以下を追加で定義する。

#!/bin/bash
cd /tmp
sudo yum install -y https://amazon-ssm-ap-northeast-1.s3.amazonaws.com/latest/linux_amd64/amazon-ssm-agent.rpm

既に稼働中のインスタンスの場合はログイン後に以下のコマンドを実行する。

sudo yum install -y https://amazon-ssm-ap-northeast-1.s3.amazonaws.com/latest/linux_amd64/amazon-ssm-agent.rpm
[ec2-user@ip-10-0-2-141 ~]$ sudo yum install -y https://amazon-ssm-ap-northeast-1.s3.amazonaws.com/latest/linux_amd64/amazon-ssm-agent.rpm
Loaded plugins: priorities, update-motd, upgrade-helper
amazon-ssm-agent.rpm                                            | 6.0 MB  00:00:00
Examining /var/tmp/yum-root-Mncwuv/amazon-ssm-agent.rpm: amazon-ssm-agent-2.0.822.0-1.x86_64
Marking /var/tmp/yum-root-Mncwuv/amazon-ssm-agent.rpm to be installed
Resolving Dependencies
amzn-main/latest                                                | 2.1 kB  00:00:00
amzn-updates/latest                                             | 2.3 kB  00:00:00
--> Running transaction check
---> Package amazon-ssm-agent.x86_64 0:2.0.822.0-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================
 Package                Arch         Version             Repository               Size
=======================================================================================
Installing:
 amazon-ssm-agent       x86_64       2.0.822.0-1         /amazon-ssm-agent        17 M

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

Total size: 17 M
Installed size: 17 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : amazon-ssm-agent-2.0.822.0-1.x86_64                                 1/1
amazon-ssm-agent start/running, process 7104
  Verifying  : amazon-ssm-agent-2.0.822.0-1.x86_64                                 1/1

Installed:
  amazon-ssm-agent.x86_64 0:2.0.822.0-1

Complete!
[ec2-user@ip-10-0-2-141 ~]$

Simple Systems Manager エージェントの起動確認

[ec2-user@ip-10-0-2-141 ~]$ sudo status amazon-ssm-agent
amazon-ssm-agent start/running, process 7104
[ec2-user@ip-10-0-2-141 ~]$

ちなみにAmazon Linux の場合 Upstartでの管理になります。

[ec2-user@ip-10-0-2-141 ~]$ sudo initctl list |grep amazon-ssm-agent
amazon-ssm-agent start/running, process 7104
[ec2-user@ip-10-0-2-141 ~]$

Simple Systems Manager への登録確認

EC2 の「SYSTEM MANAGER共有リソース」の「マネージドインスタンス」を選択します。

エージェントをインストールしたインスタンスが登録されていることが確認できます。
2017-06-21-15-11-56.png

続きを読む

IAMでクロスアカウントスイッチロール設定メモ

軽くテストしたので個人的な備忘録です。

★クロスアカウントスイッチロールすると嬉しいこと

複数のAWSアカウント間を認証画面介さず行き来できる
個人用IAMアカウント作るのは一か所でよくアカウント毎でなくなる
SDKつかってるような一部のツールではスイッチできないものもあるがawscliくらいならスイッチロールでいける
スイッチ先で権限を限定してスイッチ元でアカウントの増減を制御できるので
別会社間のメンバーの増減のアカウント管理のやり取りが生じなくてたぶんべんり

アカウント番号はサポート画面の右上に出てる。

★参考

Swith Roleで複数のAWSアカウント間を切替える – Qiita
超簡単!今すぐ使える「クロスアカウントアクセス」 | Developers.IO
AWS Black Belt Techシリーズ AWS IAM
【小ネタ】複数のSwitch Roleでのクロスアカウントアクセスをブラウザのブックマークで管理する | Developers.IO

一番したのやつ履歴が5こくらいまでできえることに憤慨している人は幸せになれそう。

★実際のクロスアカウントスイッチロール実装手順の簡易なメモ

0.テストするアカウントを2つようい

アカウント1
※スイッチ元
Account Number 1234zzzzzzzz

アカウント2
※スイッチ先
アカウント番号 5678xxxxxxxx

1.スイッチ先でロールを作成する

※お客様先にスイッチする場合お客様作業

IAMサービスを選択してロールを作る

新しいロールの作成
 >ロールの選択(クロスアカウントアクセスのロールで外部IDの使用を許可しないほうを選択)
  (※外部ID許可とはldapやadなどのIAMクレデンシャルでないID連携を許可するものと思われ)
  >このアカウントにアクセスできる IAM ユーザーの AWS アカウントの ID を入力(スイッチ元のIDを入力)
   (MFAが必要にチェックはデバイスやアプリの用意が可能な場合に入れる)
   >ポリシーのアタッチ(既存から選ぶのでカスタムにしたいならあらかじめ調べておく)
    (とりあえず試験用なので適当な権限にする(arn:aws:iam::aws:policy/AdministratorAccess ))
    >ロール名を入力:mygroup-admin

2.スイッチ元でロールを設定する

とりあえずユーザとグループを作る

グループ:mygroup
ユーザ:とりあえず二人くらいを作成

グループのインラインポリシーを作成しスイッチ先のアカウントとロールを設定する
ポリシー名:switch-to-otheraccount-name

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::5678xxxxxxxx:role/mygroup-admin"
  }
}

3.スイッチ元で自分のユーザで入りなおしてから右上からスイッチロールを選択してスイッチする

アカウント:5678xxxxxxxx
ロール:mygroup-admin

お客様先にスイッチする場合、
・スイッチ元のアカウントIDをお伝えする
・作成したロール名とわたる先のアカウント名とアカウントIDを聞いて設定
・スイッチロールしてみる
・スイッチ履歴は5個くらいしか残らないので便利なリンクを作っておく

ということになります。

★証跡を追えるようにするためにスイッチ元でCloudTrailの設定

見た感じすでに設定済みな模様でござったのでリンク先をどうぞ。S3もみたところ数年前からログがあった。
Amazon Web Services ブログ: 【AWS発表】 AWS CloudTrail – AWS APIコールの記録を保存
AWSの操作履歴を記録するCloudTrailを試してみた « サーバーワークス エンジニアブログ

★アカウントのエイリアスの設定

あんまり関係ないがIDだと視認性が微妙なので設定したほうがよさそう(なくてもいい)

AWS アカウント ID とその別名 – AWS Identity and Access Management

変えたたらサブドメインがアカウント番号からエイリアス名になる(アカウント番号でもアクセスできるまま)
https://my-alias.signin.aws.amazon.com/console

★アカウント設定(パスワードポリシー)

ISMS的なアレ(または顧客要望)にのっとって適宜。
Account settingsから実施。

Minimum password length: x(x文字を要する)
Require at least one non-alphanumeric character(記号を要する)
Allow users to change their own password (自分で更新する)
Enable password expiration
Password expiration period (in days): xx(xx(日)で期限がきれる)

★ルートアカウントでアクセスしない

スイッチロールの設定時にrootアカウントにアクセスできるように設定しなければ
メニューにスイッチロールでないので物理的にルートアカウントにアクセスは不可能。
クラスメソッドのリンクが詳しい(rootでも設定するといけるけどやらないほうがいい))
単に運用上パスワード変えて限定共有する、クレデンシャル無効化する、MFAデバイス用意等。
あとCloudTrail的に個人IAMで操作したほうが証跡が追いやすい。

★クレデンシャルの書き方

たぶん以下のようになる。

[account2]
role_arn = arn:aws:iam::5678xxxxxxxx:role/mygroup-admin
source_profile = account1
region=us-xxxx-x

★スイッチロールのポリシーアタッチされてるグループにいるユーザをcliでだす

$ aws iam get-group --group-name mygroup --profile account1|jq -c -r '.Users[].UserName'

以上

続きを読む

【MySQL】AWA RDSでmax_allowed_packetを変更するのはコンソールから行う

この記事について

タイトルですべてを語ってます。自分が忘れた時に見返す用&「rds max_allowed_packet 変更」とかでググった人の気づきになればうれしいです。

詳細な手順は親切に示してあるページが沢山あるので割愛します。(気が向いたら追記するかも)

手順

1.AWSコンソールからRDSのmax_allowed_packetを変更したいインスタンスの所属しているパラメータグループを確認する
2.該当のパラメータグループの設定変更画面からmax_allowed_packetを変更し、保存する
3.該当のインスタンスを再起動する

参考にした記事

mysql max_allowed_packetを変更する – Qiita
http://qiita.com/_am_/items/91824da643256d46b847

Amazon RDS でパラメータグループの値を変更する
https://aws.amazon.com/jp/premiumsupport/knowledge-center/rds-modify-parameter-group-values/

続きを読む

AmazonECRとEC2を使って手元でビルドしたDockerイメージをAWS上でサクッと動かす

ECR(EC2 Container Registry)に登録したDockerイメージをEC2上でコンテナとして起動するまでの一通りの流れを書いてみた
ECSも一通り検証終わっていて、サービスではそちらを使う予定だが、基礎を振り返るという意味でのまとめ。

Docker

ここ一ヶ月ひたすらdockerを触っているが、やはり手元の開発環境で動いたものが、別の環境でそのまま動くというのは他にないメリット。
これまでだと、開発環境でOK→STでまた一から作る→本番でも同じくみたいなことしてたけど、ホスト側にDockerエンジン入れるだけで、実際のプロセスは開発環境のものをそのまま移植出来るというところはかなり熱い。といった印象。

やること

  • ECRを使う準備
  • ECRへのDockerイメージの登録
  • EC2作成
  • EC2上にECRからpullしたDockerコンテナを立てる

ECRとは

正式名称 EC2 Container Registry
Amazonが提供するフルマネージドのDockerコンテナレジストリ。
Dockerイメージを管理して、ECS(EC2 Container Service)やEB(Elastic Beanstalk)に簡単にデプロイすることが出来るソリューション

ECR使うと何がうれしい

  • EC2インスタンスにIAMroleを付与するだけ、EC2側で面倒な認証をせずにdockerイメージを使える
  • S3がバックエンドなので、可用性高い
  • 自動的に暗号化されたり、https通信されるのでセキュリティも安心

ECRを使う準備(ローカルマシンで実施)

AWS Command Line Interface のインストール を参考にAWS CLIを手元のマシンにインストールしておく。

基本的には、AWS CLIで操作する。

1.リポジトリの作成&確認

$aws ecr create-repository --repository-name tst-shnagai
{
    "repository": {
        "registryId": "xxxxx",
        "repositoryName": "tst-shnagai",
        "repositoryArn": "arn:aws:ecr:ap-northeast-1:xxxxx:repository/tst-shnagai",
        "createdAt": 1496229520.0,
        "repositoryUri": "xxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai"
    }
}

リポジトリは、GUIから見ると、ECSサービスの中の[リポジトリ]に出来る

Amazon_EC2_Container_Service.png

2.ecrにログイン

セッションは12時間なので、感覚的に翌日には切れてる感じ。

## これで一発

$ $(aws ecr get-login --region ap-northeast-1)
Flag --email has been deprecated, will be removed in 17.06.
Login Succeeded

## $()の式展開を使わない場合

$ aws ecr get-login --region ap-northeast-1
docker login -u AWS -p eyJwYXlsb2FkIjoicURLTkxCTFhobUJuSTRxSDRNSUFBOEprc0txSnVuTVgrdzRzNkl4NU5rRDUxM0N...
### 標準出力の結果を貼り付けてログイン
$ docker login -u AWS -p eyJwYXlsb2FkIjoicURLTkxCTFhobUJuSTRxSDRNSUFBOEprc0txSnVuTVgrdzRzNkl4NU5rRDUxM0N...
Login Succeeded

ECRへのDockerイメージの登録(ローカルマシンで実施)

手元にある何かしらのDockerイメージをECRにpushする手順
手元で、Dockerイメージに対して、ECR用のタグづけを行ってから、ECRにpushする

1.docker tagコマンドでタグづけをする

今回は例として元々手元にある[apache_td]というdockerイメージに対して、ECRのルールに沿った名前でタグ付け(aliasつけるようなもの)する

## 元々のイメージ
$ docker image list |grep apache_td
apache_td                                                         latest              2c42dd3f5e5c        13 days ago         1.4GB

## タグ付けを実施
$ docker tag apache_td:latest  xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest

## imageIDは変わらないので、下記のような検索するとapache_tdがECRに対応したイメージとしてタグ付けされたことがわかる
$ docker image list |grep 2c42dd
xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai     latest              2c42dd3f5e5c        13 days ago         1.4GB
apache_td                                                         latest              2c42dd3f5e5c        13 days ago         1.4GB

2. 1でタグづけしたDockerImageをECRにpushする

$ docker push xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
The push refers to a repository [xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai]
47d1cbb6b480: Layer already exists
...
latest: digest: sha256:14b7a5d491fa694c00f026bbc6c6cd09e0ddc63d0e586569a0de42a8ce7ec5d1 size: 2411

GUIで、タグ名とプッシュされた日時を確認して無事イメージがアップされていることを確認する

Amazon_EC2_Container_Service.png

ここまでで、ECRへのDockerイメージの登録は完了!!

EC2インスタンスの作成

1.通常通りEC2インスタンスを作成する(OSはデフォルトでawscliが入っているamazon linuxだと楽)

ポイントは、IAMRoleに[AmazonEC2ContainerRegistryReadOnly]ポリシを付与しておくことのみ

IAM_Management_Console.png

2. dockerのインストール

AWSの公式ドキュメントに沿ってやるだけなので、コマンドだけ羅列
Docker のインストール

ec2-userでdockerコマンドがsudoなしでうてるとこまでやっておく。

$ sudo yum update -y
$ sudo yum install -y docker
$ sudo service docker start
### ec2-userでsudoなしでdockerコマンドを打てるようにするため
$ sudo usermod -a -G docker ec2-user
###再ログイン
$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.1-ce

EC2上にECRからpullしたDockerコンテナを立てる(EC2上で実施)

1. ECRへのログイン

IAMRoleがついていない場合は、ログインで弾かれる

$ $(aws ecr get-login --region ap-northeast-1)
Login Succeeded

2. ECRからDockerイメージをpullする

## ECRにアップロードしたイメージをpull
$ docker pull xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
latest: Pulling from tst-shnagai
996fe98f55d8: Pull complete
...
e6b377ddca6e: Pull complete
Digest: sha256:14b7a5d491fa694c00f026bbc6c6cd09e0ddc63d0e586569a0de42a8ce7ec5d1
Status: Downloaded newer image for xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest

## 手元のイメージとして登録されたことを確認
$ docker image ls
REPOSITORY                                                      TAG                 IMAGE ID            CREATED             SIZE
xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai   latest              2c42dd3f5e5c        13 days ago         1.4 GB

3. dockerコンテナを起動する

pullしてきたイメージからコンテナを起動する

## ホストの8080ポートにマッピングするtestという名前のコンテナを起動する
$ docker run -d --name test -p 8080:80 xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest
dbbb74b6ebe95666d356250de8310c19403078f53e020069e9a6d10e479b2873

## -lオプションで最後に起動したコンテナを表示
$ docker ps -l
CONTAINER ID        IMAGE                                                                  COMMAND                  CREATED             STATUS              PORTS                  NAMES
dbbb74b6ebe9        xxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/tst-shnagai:latest   "/bin/sh -c '/bin/..."   4 seconds ago       Up 4 seconds        0.0.0.0:8080->80/tcp   test

## 動作確認として、ホストの8080に対してcurlでリクエストしてみる
$ curl localhost:8080
version 1.2

まとめ

オーソドックスな、AWSでECRを使ってdockerコンテナを起動する一通りの流れをやってみた。dockerを手元で触ってる人だったら、特に躓くことなくやれる内容だと思う。
ECSは、基本オペレーション(この投稿でいうEC2以降の話)を抽象化して、クラスタというEC2集合体の上で、ELB,AutoScaling等を付加して使えるサービスなので、ココら辺をちゃんと理解してやるとやらないでは進みがだいぶ違うという印象を受ける。
裏で何が行われてるのかなという道理を理解することは大事。

続きを読む

AWS Lambda + Serverless Framework + Slackで作るカスタマイズ可能なfeedリーダー その1

概要

AWS Lambda + Serverless Framework + Slackを使ってカスタマイズ出来るfeedリーダーを作ろうという記事のその1です。
(最初は一つの記事で完結させようとしていたのですがやることが多すぎました…なお続編があるかどうかは不明)

こんなの作ったよ系の記事なので、ツールとかフレームワークの説明は少なめかも。

feedの例:
slack.png

そもそもfeedリーダーを作ろうと思った動機

実はfeedの機能自体はSlackにあって、各チャンネルで

/feed subscribe https://hoge/feed 

のように打つとそのチャンネルに定期的にフィードの記事が流れてきます。ただ

  • 一つ一つの記事のdescriptionがとても長い
  • feedによっては大きいサイズの画像が表示される

などの理由から、流れてくる記事をカスタマイズしたいなーという思いから作り始めました。

Serverless Frameworkの説明

Serverless Frameworkは、AWS Lambdaなどの、関数単位で提供されているサービスの環境準備やデプロイ、パッケージング、バージョン管理、ローカルでのデバッグなどをやってくれるフレームワーク・ツールです。
3か4つぐらいのコマンドさえ覚えておけばなんとかなるので、非常に使いやすいです。
詳しくは以下の記事が分かりやすいかと思います。

具体的なデプロイのコマンドなどは後述のhttps://github.com/yudetamago/my_rss_to_slack_service
を参照のこと。

今回の記事で出来たもの

とりあえず

  • Serverless Frameworkを使ったデプロイ
  • デプロイした関数をデバッグ実行するとfeed(今のところRSSのみ)を取ってきてSlackのwebhookに送信する

という最低限feedの内容をSlackに引っ張ってこれるところまで出来ました。
コードではサンプルとしてAmazon Web Services ブログのfeedを取ってきています。

コードの仕組み・説明

出来たもの
https://github.com/yudetamago/my_rss_to_slack_service

全体としてはfeedをHTTP GETで取ってきて、Slack通知用に変換して送信しているだけだったりします。
(今回は最低限のところしか作っていないので、自分で関数を呼び出してfeed内容を取得してくるだけです。。)

Lambda Functionの機能自体に関連する部分

まず serverless.yml で指定した feedToSlack という関数を handler.jsmodule.exports で定義します。そして後述するfeedの処理を終えてレスポンスを返すときには、引数の callbackにレスポンス内容を入れて callback(null, response) のように呼び出すとLambdaの処理は終了します。

feedの処理

今回はfeedParserというライブラリを使っていて、リクエストをそのまま pipe でパーサーのほうに流しています。記事を読み込むと parser.on('readable') のコールバック関数が呼ばれるので、そこで読み込んだ記事を items に入れたあと、slackのattachmentsに入れています。

これからやること/やりたいこと

  • descriptionにHTMLタグが入っているときの処理

    • 現状ではタグがそのままplain textで表示されるので、どうしようかな…という気持ち。
  • RSSやAtomなどフィードの種類に依存しないようにする
    • item["rss:description"]["#"] が依存している部分だけれど、これは正直頑張るしかない。
  • 同じitemが2回以上送られないよう重複管理
    • これだけはステートフルになってしまうので、何らかの方法で楽したい…
  • 定期的にフィードを取ってくるようにする
  • 複数のフィードに対応する
    • 1つのLambda Functionで並列にHTTP GETする(そもそも出来るの?)か、フィードごとにLambda Function作るかみたいなところから検討する感じ。

まとめ

とりあえず最低限のところまでは出来たので、気力があれば続き作ります!

続きを読む