AWS S3 Storage Inventory の出力をダウンロードする

やりたいこと

AWS S3 には定期的にバケット内のファイル一覧を出力する Storage Inventory という機能がある。
この機能の出力は マニフェストファイル + データファイル(複数件) という構成になっている。
このままでは扱いが少々面倒なので、一つのファイルにまとめて出力させたい。

コード

言語は Python 3。boto3が必要。

# download_inventory.py
import sys
import json
import gzip
import shutil
import boto3

s3 = boto3.client('s3')

def download_inventory(manifest_bucket, manifest_prefix, outfile):
    checksum_key = manifest_prefix + '/manifest.checksum'
    manifest_key = manifest_prefix + '/manifest.json'

    print('Manifest: s3://{}/{}'.format(manifest_bucket, manifest_key))
    print('Manifest checksum: s3://{}/{}'.format(manifest_bucket, checksum_key))

    checksum_res = s3.get_object(
            Bucket=manifest_bucket,
            Key=checksum_key)
    checksum = checksum_res['Body'].read().decode('utf-8').strip()

    manifest_res = s3.get_object(
            Bucket=manifest_bucket,
            Key=manifest_key,
            IfMatch=checksum)
    manifest_body = manifest_res['Body'].read()

    manifest = json.loads(manifest_body.decode('utf-8'))
    outfile.write((manifest['fileSchema'] + 'n').encode('utf-8'))
    for entry in manifest['files']:
        destbucket = manifest['destinationBucket'].replace('arn:aws:s3:::', '', 1)
        print('Inventory: s3://{}/{}'.format(destbucket, entry['key']))
        inventory_res = s3.get_object(
                Bucket=destbucket,
                Key=entry['key'],
                IfMatch=entry['MD5checksum'])

        with gzip.open(inventory_res['Body']) as f:
            shutil.copyfileobj(f, outfile)

if __name__ == '__main__':
    if len(sys.argv) != 4:
        sys.exit('Usage: python download_inventory.py <output> <manifest bucket> <manifest prefix>')

    with open(sys.argv[1], 'wb') as outfile:
        download_inventory(sys.argv[2], sys.argv[3], outfile)
        print('Saved: ' + sys.argv[1])

使い方

python download_inventory.py 出力先ファイル名 バケット名 マニフェストファイルが存在するバケット名 マニフェストファイルのキープレフィックス

例: マニフェストファイルが s3://mybucket/someprefix/2017-06-22T00-02Z/manifest.json に存在する場合は次の通り。

python download_inventory.py output mybucket someprefix/2017-06-22T00-02Z

インベントリの内容は output に出力される。

続きを読む

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つのゾーンで同様の現象が発生し、残念ながら今回は測定不能となりました。

続きを読む

Rails + Capistrano + Unicorn である日 Gemfileが読み込めなくなった話

Railsアプリを Capistrano + Unicorn + nginxでデプロイができるようになって喜んでいたのですが
ある日いつもの bundle exec cap production deployは成功するが結果が反映されなくなった、、、

unicorn.log
I, [2017-06-18T07:25:00.381245 #18202]  INFO -- : executing ["/var/www/myapp/shared/bundle/ruby/2.4.0/bin/unicorn", "-c", "/var/www/myapp/current/config/unicorn/production.rb", "-E", "production", "-D", {11=>#<Kgio::UNIXServer:fd 11>}] (in /var/www/myapp/releases/20170618072435)
I, [2017-06-18T07:25:00.381795 #18202]  INFO -- : forked child re-executing...
/home/suppin/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/bundler-1.15.1/lib/bundler/definition.rb:31:in `build': /var/www/myapp/releases/20170606053023/Gemfile not found (Bundler::GemfileNotFound)

エラーを見に行ったところGemfileがないと言われていました・・・

解決方法

myapp/config/unicorn/production.rb に下記を追記してあげる。
(環境によってはパスが異なるかもしれません)

production.rb
before_exec do |server|
  ENV["BUNDLE_GEMFILE"] = File.join(File.expand_path("../../../../", __FILE__), "current", "Gemfile")
end

その後unicornを再起動

補足

capistranoを使っていて、いつものkill -9コマンドでpidを殺しにいくと自動デプロイするときに怒られる。なのでcurrent/tmp/pid/unicorn.pidとかのファイルを削除してあげる必要がある。

解決方法は
http://unlearned.hatenablog.com/entry/2014/03/10/230954
を参考にさせていただきました。ありがとうございます。

続きを読む

パーティションされていないマウントされている EBS をオンラインで拡張する(XFS編)

Amazon EBSのアップデートで 「エラスティックボリューム」の発表 でずっと試してみたいなと思っていたのをテストしてみたので記事にします。

Qiitaを見ると既に一杯記事が上がっています。

1.まずボリュームサイズの変更
EBSボリュームのサイズ変更をやってみる – Qiita
 –>この記事ではボリュームサイズの変更のみ

2.ルートデバイス以外の場合
Amazon LinuxにアタッチされているEBSのボリュームサイズを拡張する。 – Qiita
 –>スクリーンショット付きで分かりやすいです。初心者向け

3.ルートデバイスのEBSでは一手間必要です
オンラインでEC2のルートディスクを拡張する – Qiita
 –>そのまま、resize2fs ではダメなようです
   sudo growpart /dev/xvda 1を追加作業しています

4.結論だけとっととみたい人向け
rootにmountされているEBSを、mountしたまま拡張する手順 – Qiita
 –>いきなり、growpart /dev/xvda 1 してます

5.Ubuntuでも同様にリサイズ可能です
AWS EBSのルートディスク拡張した際のサイズ拡張のやりかた – Qiita
 —>Ubuntu 14.04です

6.再起動すると適用されます
EC2のボリューム(EBS)容量拡張方法検証 (AmazonLinux) – Qiita
 —>実は再起動したときに自動的に拡張されるようです。
   再起動可能で手間を省きたい人向け

7.最後は自動でリサイズされるスクリプトです
AWS EBSのリサイズをシェルスクリプトにまとめてみた – Qiita
 –>費用を最小限に抑えられますね。

他にも記事がありましたが、ボリュームをデタッチしたりしていたので除外しました。

で、今さら感は非常にあるのですが、XFSでやってみた人がいないので書いてみます。
作業した OS は CentOS-7.3 Official Image です。

1. ボリュームを用意

今回は、ルートボリューム以外の場所をNFSデータ領域としてつかってみることにしたので、10GiBほどEBSを作ってみました。

image.png

アタッチが終了したので Diskの状況はこんな感じです

[root@ ~]# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  200G  0 disk
└─xvda1 202:1    0  200G  0 part /
xvdg    202:96   0   10G  0 disk

xvdg として接続されています。

2. XFSでフォーマットする

NFSのデータ領域として使うのでXFSを選択しました。
パーティションを作るとボリューム拡張した時にパーティションも拡張しないといけないので、パーティション無しでXFSをフォーマットします。

[root@ ~]# mkfs.xfs /dev/xvdg
meta-data=/dev/xvdg              isize=512    agcount=4, agsize=655360 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=2621440, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

3. マウントします

マウントしてみますが、とりあえずテスト用のディレクトリにマウントしてみます。

[root@ ~]# mkdir /test_mount
[root@ ~]# mount /dev/xvdg  /test_mount/
[root@ test_mount]# df -h
Filesystem      Size  Used Avail Use% Mounted on
  <<<中略>>>
/dev/xvdg        10G   33M   10G   1% /test_mount

大丈夫のようです

4. ボリュームを拡張する

ボリューム拡張の方法は記載しませんが、以下のように20GiBに拡張されました。
image.png

以下のように増えています。

[root@ ~]# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
  <<<中略>>>
xvdg    202:96   0   20G  0 disk /test_mount

5. ファイルシステムをリサイズする

この状態では、ファイルシステムは以下のままです。

[root@ test_mount]# df -h
Filesystem      Size  Used Avail Use% Mounted on
  <<<中略>>>
/dev/xvdg        10G   33M   10G   1% /test_mount

xfs_growfs コマンドでXFSファイルシステムを拡張します

[root@ test_mount]# xfs_growfs /dev/xvdg
meta-data=/dev/xvdg              isize=512    agcount=4, agsize=655360 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=2621440, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2621440 to 5242880

6. 拡張されたか確認する

確認してみます。

[root@ test_mount]# df -h
Filesystem      Size  Used Avail Use% Mounted on
  <<<中略>>>
/dev/xvdg        20G   33M   20G   1% /test_mount

増えてますね。

7. まとめ

パーティションを切らずにファイルシステムを作れば簡単にファイルシステムを拡張出来ることが分かりました。ますます、AWSが便利に使えそうです。

#この記事を書く前は、「パーティションを切らずにファイルシステムをフォーマットできる」と言うことを知らず、ボリューム全体を一つのパーティションにする方法ばかり調べていました。ボリュームをそのままファイルシステムでフォーマットすればいいということを知ったので書いてみました。

続きを読む

AWSでWebサイトを作りますか。

AWSのEC2でWordPressを使ってサイトを作った備忘録。変な所でハマったので。
EC2上にAmazon Linux AMI乗っけてその上でApache起動させてそこにWordPress乗せるという回りくどいことをやっているのであんまり参考にならないかも……。

AWSへの登録

AWS公式の「まずは無料で登録」から。日本語だからわかりやすい。

使えるクレジットカードが必要なのは要注意。
AU WalletはMastercardなはずなんだけどダメでした。

EC2インスタンスの作成

認証が終わったら、左上の「サービス」をクリック。
使うことの出来るサービス一覧がずらりと並んでます。
その中で左上の「EC2」を選択。
170617.PNG

青い「インスタンスの作成」ボタンを押すとインスタンスが作成できる……のだが、その前に自分が今どこのリージョンを使っているのかを確認する。
これは右上、自分の名前の横に書いてある。
170617-1.PNG
自分の場合はバージニア北部ですね。

AWSでは、作成したインスタンスは「(アカウント名)が(リージョン名)に作ったインスタンス」ではなく「(リージョン名)に保管されている(アカウント名)が作ったインスタンス」みたいな感じで管理されているみたいです。
なので、インスタンスを作ってから右上を弄ってリージョンを変えると見た目上作成したインスタンスが消えます
あくまで見た目上なので、当然リージョンを移動すればまた見えるようになります。よいこのみなさんはわたしみたいに「き、消えた!?」と焦らないようにしてください。
逆に、インスタンスが消えた!?と思ったらまずは自分のいるリージョンを確認しましょう。

この時参考にしたブログ

リージョンを確認したらインスタンスを作っていきます。
とは言っても、画面に表示されるものを読みながらやっていけばできます。
自分はこのあたりを参考にしつつやりました。

この時、下の青いボタンを押すとその後の設定をすっ飛ばしてインスタンスを作ってくれます。
親切なんだか不親切なんだかわからん……。

自分はここでAMIにAmazon Linux AMIを入れてしまいましたが、実はここで直にWordPressが選べるみたいです。左メニューの「AWS Marketplace」をクリックしてから検索窓に「WordPress」と入れて検索してみてね!

最後に公開鍵と秘密鍵のキーペアを作成します。プルダウンから「新しいキーペアの作成」を選び、適当な名前を付けてDL。これは後で必要になるので、どこに保存したか忘れないようにしておきましょう。

セキュリティグループ

無事にインスタンスが作成出来たらインスタンスの管理画面になります。
インスタンスの状態が「Running」になったら(大体一分位?)、SSH接続に必要なセキュリティグループの設定をします。
インスタンスを選択して「説明」タブを見ると、今使っているセキュリティグループがわかります。
これをクリックするとセキュリティグループの設定へ飛べます。

170617-2.PNG

セキュリティグループの設定ページで「インバウンド」タブを選択するとこんな感じ。
最初は「HTTP」しか無いと思うので、「編集」→「ルールの追加」でSSHを作ってやりましょう。
170617-3.PNG

本当はソースをちゃんと指定してあげたほうがいいんですが、使ってる回線が可変IPなので……。
固定IPを持っているよいこのみなさんはちゃんと指定しましょうね。

SSH接続

さっき作った秘密鍵をPuTTYごった煮版内のPuTTYgenから「読込」してやってPuTTY用の秘密鍵ファイルを作ります。
「全てのファイル(*.*)」で探すのを忘れずに。じゃないと見えません。
そして.ppk形式で保存。パスワードはかけておいたほうが良いでしょう。

PuTTYの設定は下記の通り。

フィールド
セッション>ホスト名 ec2-user@(パブリック DNS (IPv4))
セッション>ポート 22
セッション>接続タイプ SSH
接続>SSH>認証>認証のためのプライベートキーファイル (上で作った.ppkファイル)

セッション一覧で適当な名前をつけて「保存」したら「開く」で接続を始めます。
初回はダイアログが出ますが「OK」でスルー。
秘密鍵のパスワードの入力を求められたら入力。
AMIの起動画面が出たら成功です。

この辺の話は公式のガイドページが詳しいです。

Apacheのインストール

インストール。

# sudo yum -y install httpd

起動。

# sudo service httpd start

わーいらくちーん。
この時点でブラウザからhttp://(パブリック DNS (IPv4))を見てみるとテストページが見れます。

WordPressのインストール

まずはWordPressに必要なPHPとMySQLをインストール。

# yum install httpd mysql-server php php-mysql wget

/etc/php.iniを弄ってタイムゾーンの設定をしときます。

# vi /etc/php.ini
 ; Defines the default timezone used by the date functions
 ; http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone
 date.timezone = "Asia/Tokyo"

ここを参考にしつつMySQLの設定。
このページに沿ってやるとwpという名前のデータベースとwpという名前のユーザが出来上がっています。

WordPress本体を落としてきて解凍。
さらにApacheがWordPressを読み込めるようにしておく。

# cd /tmp
# wget http://ja.wordpress.org/wordpress-4.8-ja.tar.gz
# tar zxvf wordpress-3.5.1-ja.tar.gz 
# cp -r wordpress /var/www/
# chown -R apache.apache /var/www/wordpress

/etc/httpd/conf/httpd.confを弄って、

  • DocumentRootをWordPressにし、
  • DocumentRootのディレクトリに対して.htaccessによる上書きを許可しておく。
# vi /etc/httpd/conf/httpd.conf
 DocumentRoot "/var/www/wordpress"
 (中略)
 <Directory "/var/www/wordpress"> ←ここをちゃんとDocumentRootと同じにしておく
     AllowOverride All

WordPressの設定ファイルを作る。
予めサンプルファイルが用意されているので、それをコピーして……

# cd /var/www/wordpress
# sudo cp wp-config-sample.php wp-config.php

書き換え。

# vi wp-config.php

 // データベース情報を設定します。
 define('DB_NAME', 'wp');
 define('DB_USER', 'wp');
 define('DB_PASSWORD', 'password');
 define('DB_HOST', 'localhost');
 define('DB_CHARSET', 'utf8');

 // 「put your unique phrase here」を 適当な文字列に置き換えます。
 define('AUTH_KEY',         'put your unique phrase here');
 define('SECURE_AUTH_KEY',  'put your unique phrase here');
 define('LOGGED_IN_KEY',    'put your unique phrase here');
 define('NONCE_KEY',        'put your unique phrase here');
 define('AUTH_SALT',        'put your unique phrase here');
 define('SECURE_AUTH_SALT', 'put your unique phrase here');
 define('LOGGED_IN_SALT',   'put your unique phrase here');
 define('NONCE_SALT',       'put your unique phrase here');

自分はここでPuTTYの文字コードをUTF-8にしていなかったため、viでwp-config.phpを開いた瞬間に画面を文字化けしたものが覆うという大惨事になってしまいました。
その時にwp-config.phpが壊れてしまったようで、ファイルの上半分が消失するという事態に……。
バックアップって大事だね!(もう一度cp wp-config-sample.php wp-config.phpしながら)

ここで再びhttp://(パブリック DNS (IPv4))を覗いてみるとWordPressの初期設定画面が開きます。
もしも「データベース接続確立エラー」と出るならwp-config.phpのデータベース情報のどこかが間違ってます。
もしもwp-config.phpの中身が表示されているようならSyntax Errorです。直しましょ。

独自ドメイン設定

サイト自体は完成したので次はドメインとパブリックDNSを紐付けてやります。

これを参考にしてElastic IPを作成、ついでRoute53を設定。Whoisが更新されたのを確認してからドメインをブラウザに入れてみると……。

動かない。何故だ。

正確に言うと、動いてはいるっぽいけどサイトのテキストしか表示されない。
その状態で色々弄っていたら、あることに気づく。

管理画面に遷移しようとすると新たに設定したElastic IPではなく以前のパブリックDNSが出る。

ちょっと調べてみたらこんなページが。
なるほど、DBには前のパブリックDNSしか登録されてないからこうなるのね。
変えてやったら無事動きましたー!よかったー。

さて、あとはサイト本体を作るだけだ……。

続きを読む

Go言語でDynamoDB接続を試みたときの備忘録

前提

最近、Go言語を触り始めた。

GoからDynamoDBに接続するにあたって、 aws-sdk-go/aws/service/dynamodb を使おうとし、ドキュメントを読んでたら結構難しそうだったので、 guregu/dynamo を使うことにした。

また、DynamoDBも触ったことがなかった。

ゴールは、GoでDynamoDBに読み書きすること!

DynamoDBの設定

まず、AWSコンソール画面からDynamoDBのテーブルを作ります。

スクリーンショット 2017-06-17 16.47.12.png

上記の画面で、「テーブル名」を Test とします。

「プライマリーキー」を user_id とします。型は「数値」にします。

他のattributeにかんしては、時間に関する値を想定してますが、実際にGoからItemをPUTするときに足されるので、定義する必要はありません。(そもそも登録もできない。)

(キャメルケースがいいのか、パスカルケースがいいのか等の命名規則もあるかと思いますが、一旦これでいきます。)

これでAWS側の用意は出来ました。

あと、もう一つ大事なこととして
IAMで、DynamoDBにアクセスできる権限をもったユーザーを作成し、

  • アクセスキー
  • シークレットキー

を入手しましょう。

Go言語をかく!

user_dynamo.goという名前でファイルを作成します。

必要なモジュール

以下のリアブラリをimportします。

user_dynamo.go
import (
  "fmt"
  "time"
  "github.com/aws/aws-sdk-go/aws"
  "github.com/aws/aws-sdk-go/aws/session"
  "github.com/aws/aws-sdk-go/aws/credentials"
  "github.com/guregu/dynamo"
)
ライブラリ名 説明
fmt 標準出力に使う。
time 現在時刻を取得するのに使う。
github.com/aws/aws-sdk-go/aws configに関するオブジェクト作成につかう
github.com/aws/aws-sdk-go/aws/session sessionに関するオブジェクト作成につかう
github.com/aws/aws-sdk-go/aws/credentials awsへのアクセス情報に関するオブジェクト作成につかう
github.com/guregu/dynamo github.com/aws/aws-sdk-go/aws/service/dynamodbに対する操作を便利にしてくれるライブラリ

DynamoDBのスキーマ定義

この言い回しが正しいかわかりませんが、DynamoDBのUserテーブルに登録する予定の項目を構造体として定義します。

user_dynamo.go
type User struct {
  UseId int `dynamo:"use_id"`
  CreatTime time.Time `dynamo:"created_time"`
}

inttime.Time のあとのバッククウォートで囲まれた部分はGoで「タグ情報」と呼ばれるものになります。

DynamoDBのUserテーブルにアクセス

user_dynamo.go
func main(){
  c := credentials.NewStaticCredentials("<アクセスキー>", "<シークレットキー>", "") // 最後の引数は[セッショントークン]

  db := dynamo.New(session.New(), &aws.Config{
      Credentials: c,
      Region: aws.String("<region名>"), // "ap-northeast-1"等
  })
  table := db.Table("User")

 // 続く
}

のように書きます。

データをPUTする

user_dynamo.go
func main(){
  // 続き

  u := User{UserId: 3, CreatTime: time.Now().UTC()}
  fmt.Println(u)

  if err := table.Put(u).Run(); err != nil {
    fmt.Println("err")
    panic(err.Error())
  }

上記をまとめると

user_dynamo.go
package main

import (
  "fmt"
  "time"
  "github.com/aws/aws-sdk-go/aws"
  "github.com/aws/aws-sdk-go/aws/session"
  "github.com/aws/aws-sdk-go/aws/credentials"
  "github.com/guregu/dynamo"
)


type User struct {
  UseId int `dynamo:"use_id"`
  CreatedTime time.Time `dynamo:"created_time"`
}


func main(){
  cred := credentials.NewStaticCredentials("<アクセスキー>", "<シークレットキー>", "") // 最後の引数は[セッショントークン]

  db := dynamo.New(session.New(), &aws.Config{
      Credentials: cred,
      Region: aws.String("<region名>"), // "ap-northeast-1"等
  })

  table := db.Table("User")

  u := User{UserId: 100, CreatedTime: time.Now().UTC()}
  fmt.Println(u)

  if err := table.Put(u).Run(); err != nil {
    fmt.Println("err")
    panic(err.Error())
  }

それではterminalから

$ go run user_dynamo.go

とうってみてください。DynamoDBに

user_id created_time
100 2017-06-02T09:25:56.000147134Z

と登録されたかと思います。これで、DynamoDBへのデータ登録は完了です。

データの読み取り

DynamoDBより

「user_idが100のデータ全て」

データを読み取る場合は以下のようになります。

user_dynamo.go
func main(){
  // 続き
  var users []User
  err := table.Get("user_id", 100).All(&users)
  if err != nil {
    fmt.Println("err")
    panic(err.Error())
  }

  fmt.Println(users) // [{100 2017-06-02T09:25:56.000147134 +0000 UTC}]と出力される。

  for i, _ := range users {
    fmt.Println(users[i]) // {100 2017-06-02T09:25:56.000147134 +0000 UTC}
  }
}

また全データを取得したい場合は

err := table.Get("user_id", 1).All(&users)

というところを

err := table.Scan().All(&users)

とすれば大丈夫です。

さらに created_time によって、絞りたい場合は以下のようにすれば大丈夫です。

err := table.Get("user_id", 1).Filter("created_time >= ?", "2017-06-01 00:00:00").All(&users)

注意点

DynamoDBでは、プライマリーキーは、DBで一つしか存在できないので、本コードでは書き込みをするたびに書き換わります。

参考にしたサイト

http://www.geocities.jp/m_hiroi/golang/abcgo07.html
https://github.com/guregu/dynamo
http://qiita.com/guregu/items/2e9ac305791935b86f5d
https://developers.eure.jp/tech/aws-sdk-go-tutorial-sqs-dynamodb/

続きを読む

EC2上にhubotを設置してslackと連携させる

最近ChatOpsに興味が出てきたので、とりあえずEC2上にhubotが動作する環境を作り、slackと連携出来るようにしました。

前提

以下の環境が既にあること。

  • EC2
  • slack

環境構築

  • nvm〜hubotの起動までは全てEC2上での作業です。

nvmのインストール

  • curlでインストールします
sudo curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.2/install.sh | bash
  • .bash_profileに以下を追記します
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm
  • nvmコマンドが実行できることを確認します
nvm help

nodejsのインストール

  • nvmでnodejsのv6.11.0をインストールします
  • 公式サイトを見ると includes npm 3.10.10 と書いてあるのでnpmも一緒にインストールされます
nvm install 6.11.0
  • インストールされたことを確認します
node -v
npm -v

redisのインストール

  • elasticacheは使わずAmazon Linux上にredisをインストールします
  • epelだとバージョンが古いようなのでremiを利用します
sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
sudo yum --enablerepo=remi install redis
  • redisを起動させます
sudo service redis start

hubotのインストール

  • hubotの環境を構築します
  • npmでhubot,coffescript,redis,yo,generator-hubotをインストールします
npm install -g hubot coffee-script redis yo generator-hubot
  • hubotをインストールします
mkdir -p ~/deploy-sushi
cd deploy-sushi
yo hubot
  • 対話式で色々聞かれるので自身の環境に合わせて入力してください
? ==========================================================================
We're constantly looking for ways to make yo better!
May we anonymously report usage statistics to improve the tool over time?
More info: https://github.com/yeoman/insight & http://yeoman.io
========================================================================== Y/no


省略


? Owner (User <user@example.com>)
? Bot name (deploy-sushi)
? Description (A simple helpful robot for your Company)
? Bot adapter (campfire)
  • 今回は?4つに以下のように答えました
? Owner {MY_EMAIL}
? Bot name deploy-sushi
? Description this is deploy boy
? Bot adapter slack
  • hubotを立ち上げて動作確認をします
bin/hubot
  • いろんなメッセージが出た後にEnterを押せば deploy-sushi> という対話が始まります
deploy-sushi> deploy-sushi ping
deploy-sushi> PONG
  • hubot-slackをnpmでインストールします
npm install hubot-slack

slackと連携させる

  • slack上の操作に変わります
  • slackのサイドメニューを開き Configure Apps を開きます

スクリーンショット 2017-06-17 14.12.32.png

  • 画面上部に Hubot を入力し、検索結果をクリックします

スクリーンショット 2017-06-17 14.16.11.png

  • Installボタンをクリックします

スクリーンショット 2017-06-17 14.17.17.png

  • hubotの名前を入力して Add Hubot Integrationをクリックします

スクリーンショット 2017-06-17 14.18.21.png

  • 作成が完了したらhubotの詳細画面に遷移するので画面上部の Setup Instructions のところに記載されている HUBOT_SLACK_TOKEN={YOUR_API_TOKEN} をコピーしておきます
  • 画像を変更する・・・など何か編集を加えた場合、画面下部の保存ボタンをクリックして更新してください

  • EC2に戻り以下の環境変数をexportします

echo 'export HUBOT_SLACK_TOKEN={YOUR_API_TOKEN}' >> ~/.bash_profile
source ~/.bash_profile
  • アダプタを指定してhubotを起動します
bin/hubot --adapter slack
  • slackのどこかのチャンネルにhubotをinviteして動作確認します

スクリーンショット 2017-06-17 14.29.14.png

  • 動作確認ができたらEC2起動時に自動でhubotが立ち上がるようにします

hubotの永続実行

  • foreverをnpmでインストールします
npm install -g forever
  • bin/hubot を書き換えます
以下を追記
forever start -w -c coffee node_modules/.bin/hubot --adapter slack


以下をコメントアウト
exec node_modules/.bin/hubot --name "deploy-sushi" "$@"

  • バックグラウンドで動くことを確認します
bin/hubot
ps aux | grep hubot

EC2起動時のスクリプト作成

sudo vi /etc/init.d/start_deploy_hubot
#!/bin/bash
#chkconfig: 2345 99 10
#descpriction: start deploy hubot
DIR="/home/ec2-user/deploy-sushi"
cd $DIR
bin/hubot
  • 実行権限を付与します
sudo chmod 755 /etc/init.d/start_deploy_hubot
  • サービスに追加します
sudo chkconfig --add start_deploy_hubot
  • EC2インスタンスを再起動してhubotが立ち上がっていることを確認してください

hubotが起動しなかった・・・

  • npm,foreverのパスがec2-userにしか通っていないかったのでrootでnpm,foreverするとコマンドが見つからない。
  • トークンもec2-userの .bash_profile に記述していたので見つからない。
  • とりいそぎ bin/hubot に以下を追記しました
    • npm install よりも前に追記してください
export PATH="/home/ec2-user/.nvm/versions/node/v6.11.0/bin:$PATH"
export HUBOT_SLACK_TOKEN={YOUR_API_TOKEN}
  • EC2を再起動して、hubotが立ち上がっていることを確認してください

    • プロセスの確認をします
ps aux | grep hubot
  • slackのチャンネルでもpingして返答があることを確認してください

おわり

hubotがサーバ上で動き続けるようになったので、次回はslackからgit操作を出来るようにしようと思います。

続きを読む