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

続きを読む

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操作を出来るようにしようと思います。

続きを読む

オンプレのESXi6.0でAWS StorageGatewayファイルゲートウェイを作成

  • 2017.06.16 create

AWS StorageGatewayってどんなものかってことでESXi6.0でインスタンス建ててみました。

ゲートウェイの種類
ファイルゲートウェイ
 今回はこちらのを作成します。ファイルゲートウェイをNFSサーバとしてLinuxのNFSクライアントからマウントしてみたいと思います。
 その他に下記の利用方法もあり。

ボリュームゲートウェイ
 オンプレミスのアプリケーションサーバーから iSCSI デバイスとしてマウントできる。
 「キャッシュ型ボリューム」と「保管型ボリューム」の2パターンあり
  - キャッシュ型ボリューム
   データをS3に保存し、頻繁にアクセスするデータサブセットのコピーをローカルに保持します。
  - 保管型ボリューム
   データをS3に保存し、データをローカルに保存し、そのデータのポイントインタイムスナップショットをS3に非同期バックアップします。こちらバックアップ用途で次回試してみたいと思います。
 
仮想テープライブラリ
 Amazon S3 にデータをバックアップして、既存のテープベースのプロセスを使用しながら、Amazon Glacier に保存します。

  


参照URL:ファイルゲートウェイで簡単ファイルサーバ
サーバーワークスさんのエンジニアブログサイトがとても分かりやすかったので参考にさせていただきました。リンクさせていただきます。


環境

Hypervisor:ESXi6.0
最新版VMware vSphere Hypervisor 6.5ですが サポートされているハイパーバイザーとホストの要件 に載っていなかったため6.0にしました。
NFSクライアント:CentOS Linux release 7.3.1611 (Core)

ゲートウェイの作成

1. awsコンソール からStorageGatewayを作成

  ファイルゲートウェイを選択します。
alt

2. ESXiのOVAイメージダウンロード

  イメージのダウンロードをポチします。
alt

ダウンロードできたら一旦awsコンソールからは離れてESXi側で仮想マシンを作成します。

3. ESXiの仮想マシンへデプロイ

  3.1新規仮想マシン作成
alt
  OVFファイルまたはOVAファイルから仮想マシンをデプロイを選択
alt
  仮想マシン名を入力し、先ほどダウンロードしたOVAファイルを指定
alt
  データストアの選択
alt
  デプロイオプション ディスクのプロビジョニングはシックを選択
alt
  完了ポチして作成
alt

  • ハードディスク2にアップロードバッファ用のディスクを追加します。(最低1つ以上のディスクが必要です。)
    ディスク1と同様にシックプロビジョニングで作成します。
    alt

  • 時刻の同期
    仮想マシンオプションの時刻設定

    • ホストとゲスト時間を同期
      にチェックを入れます
      image.png

ゲートウェイを起動します。
固定IP等設定する場合はコンソールメニューから設定します。
alt

  
ここでawsコンソールに戻ります。

4. ゲートウェイに接続

  作成したゲートウェイのIPを入力します。
  IPはオンプレ環境のローカルIPで大丈夫です。
alt

5. ゲートウェイのアクティブ化

  タイムゾーン、ゲートウェイ名を入力してアクティブ化します。
alt

6. ローカルディスクの構成

  アップロードバッファ用に作ったディスクをキャッシュに指定します。
alt

7. ファイル共有の作成

  S3バケットは事前に作成しておいてください。
   ファイル共有にIAMロールがつくのでバケットポリシーは特に何も入れなくても大丈夫です。
  ・ゲートウェイ、S3バケット名を入力します。
  ・ストレージクラス S3標準 NFSに使用したので標準にしておきます。
  ・S3バケットへのアクセス 新しいIAMロールで自動作成されます。
alt

8. 確認

  ここではマウントオプションのSquashをAll squashに変更しました。
  root squashだとクライアントでNFSマウントしたらrootユーザ以外で書き込めませんでした。
alt

これでファイルゲートウェイの作成完了。うぇいw
クライアントの端末からNFSマウントできれば成功です。

クライアントからNFSマウント
#  mount -t nfs -o nolock 192.168.1.1:/awstest-file-storage /storagegw
# df -h
ファイルシス                        サイズ  使用  残り 使用% マウント位置
/dev/mapper/cl-root                    14G  2.3G   12G   17% /
devtmpfs                              487M     0  487M    0% /dev
tmpfs                                 497M     0  497M    0% /dev/shm
tmpfs                                 497M   13M  484M    3% /run
tmpfs                                 497M     0  497M    0% /sys/fs/cgroup
/dev/sda1                            1014M  184M  831M   19% /boot
tmpfs                                 100M     0  100M    0% /run/user/0
192.168.1.1:/awstest-file-storage     8.0E     0  8.0E    0% /storagegw

8.0E(エクサバイト)って単位初めて見ましたw

続きを読む

Amazon LinuxにImageMagick6の最新版を入れる

remiレポジトリを追加

$ rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

CentOS-Baseリポジトリを追加

$ vi /etc/yum.repos.d/CentOS-Base.repo
CentOS-Base.repo
[base]
name=CentOS-6 - Base
mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os
gpgcheck=1
enabled=0
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-6

古いパッケージを削除

$ yum remove -y libtiff
$ yum remove -y graphviz
$ yum remove -y libwebp libwebp-devel
$ yum remove -y ImageMagick ImageMagick-devel ImageMagick-libs

新しいパッケージをインストール

$ yum install -y libtiff --enablerepo=remi,epel,base --disablerepo=amzn-main
$ yum install -y graphviz --enablerepo=remi,epel,base --disablerepo=amzn-main
$ yum install -y libwebp libwebp-devel --enablerepo=epel --disablerepo=amzn-main
$ yum install -y ImageMagick6 ImageMagick6-devel ImageMagick6-libs --enablerepo=remi,epel,base

続きを読む

AmazonLinuxでAWSのLocalStackインストール手順

リンク: https://github.com/atlassian/localstack

Dockerインストール

確認する:

$ sudo yum search docker
Loaded plugins: priorities, update-motd, upgrade-helper
========================================================================================= N/S matched: docker ==========================================================================================
docker-storage-setup.noarch : A simple service to setup docker storage devices
docker.x86_64 : Automates deployment of containerized applications
docker-devel.noarch : A golang registry for global request variables (source libraries)
docker-pkg-devel.noarch : A golang registry for global request variables (source libraries)

  Name and summary matches only, use "search all" for everything.


$ sudo yum info docker

Loaded plugins: priorities, update-motd, upgrade-helper
Available Packages
Name        : docker
Arch        : x86_64
Version     : 17.03.1ce
Release     : 1.50.amzn1
Size        : 22 M
Repo        : amzn-updates/latest
Summary     : Automates deployment of containerized applications
URL         : http://www.docker.com
License     : ASL 2.0 and MIT and BSD and MPLv2.0 and WTFPL
Description : Docker is an open-source engine that automates the deployment of any
            : application as a lightweight, portable, self-sufficient container that will
            : run virtually anywhere.
            :
            : Docker containers can encapsulate any payload, and will run consistently on
            : and between virtually any server. The same container that a developer builds
            : and tests on a laptop will run at scale, in production*, on VMs, bare-metal
            : servers, OpenStack clusters, public instances, or combinations of the above.

インストール:

$ sudo yum install -y docker

サービス起動

$ service docker start

LocalStackインストール

プロジェクトをクローンする

$ git clone https://github.com/atlassian/localstack.git

起動する:

make docker-run

# Or using docker-compose:

docker-compose up

続きを読む

AWS ソリューションアーキテクトプロフェッショナル 受けてきました&勉強法(2017/6版)

前書き

image.png

 前回 の続きです。ソリューションアーキテクトアソシエイト(SAA)に受かったので今度はプロフェッショナル(SAP)に挑戦しました。

AWS の資格試験はわかりにくい

ワークショップについて

 公式サイトから読み取れないので補足。以下のクラスがありますが、

レベル/分野 アーキテクト 開発 運用
アソシエイト取得済み Advanced Architecting on AWS DevOps Engineering on AWS 同左
アソシエイト未取得向け Architecting on AWS Developing on AWS Systems Operations on AWS
AWS 未経験者向け Amazon Web Services 実践入門 1 / 2 同左 同左

 前提事項は記載ありるものの、いきなり Advanced などを受けてもいいし、受けずに受験に挑んでも大丈夫です。アソシエイト未取得向けのを2つ受ける必要はなさそうなので、Architecting 受けてから Developing 受けたりするのは、けっこう内容の重複がある ので、お金がもったいない。
 その他のクラスは試験に出てくる頻度が低いので、興味があれば受ければいいやつです。

 ソリューションアーキテクトアソシエイト(SAA) だけは試験対策として半日のワークショップがありますので、時間とお金があれば受けるといいかと。

認定試験について

 おさらいですが。
image.png

 ワークショップと同じく、範囲がかぶっているので アソシエイト取れたらほかのアソシエイトもいけそう なので、資格の数を増やすにはよさそうです、プロフェッショナルはそう簡単にいかないですが。英語版の資格として Advanced Networking 、Big Dataが追加となっています。Security(Beta) もあった気がしますが、 Beta が取れていないのかな。いずれさらに上の階級にある Master が提供されるかもしれないという噂があったりします。

試験概要

 概要をざっくり記載します。アソシエイトの倍の時間でついでに受験料も倍です。合格ラインはやはり65%という噂です。1問あたり2分ちょっとで解き、3時間集中し続ける というなかなかヘビーな内容です。

TOPIC DATA
試験時間 170分間
問題数 80問
合格ライン 非公開
受験料 ¥32,400

出題範囲

 出題範囲を確認すると、アソシエイトでは高可用性がほとんどでしたが、Pro では求められるものが変わっていることがわかります。そのほか試験ガイドをざっと読みました。

TOPIC 出題率
高可用性および事業継続性 15%
原価計算 5%
デプロイメントマネージメント 10%
ネットワーク設計 10%
データストレージ 15%
セキュリティ 20%
拡張性と伸縮自在性 15%
クラウド移行およびハイブリッドなアーキテクチャ 10%

学習

セミナーを受講する

 前述の Advanced Architecting on AWS を受講しました。
 セミナーには AWS 社員の方や、AWS をすでに実務で利用されているかたが多くいて、私のような素人も半分くらいいる印象でした。私は実業務で AWS に触れたことが実はほとんどなく、本気の AWS 運用に必要な知識を持ち合わせていなかったので次のような観点が非常に勉強になりました。

  • ユーザ管理:IAM と ADやフェデレーションでの連携を考慮し、大規模運用を考える
  • コスト観点:一括請求やスポットインスタンスの選び方で、大幅なコスト削減を考える
  • 運用・監査:KMSを使用した暗号化、CloudLogs でのロギング、ClodWatch でのモニタリングで運用・監査への対応を考える
  • 可用性・セキュリティ:大規模&複数VPCのデザイン、MultiAZ、MultiRegion で可用性向上を実現する、DDoS からインフラを保護する

AWS 活用資料集(BalckBelt)、WhitePaper を読む

 アップデートもあるので、改めて時間を見つけて読みました。時間があるときは Webinar にも参加しました。 Webinar だと日々疑問に思っていることの質問を AWS の SA に直接質問できるので、すごくおトクです。

  • BlackBelt

    • Amazon EC2
    • Elastic Load Balancing
    • Auto Scaling
    • Amazon EC2 Container Service
    • AWS Elastic Beanstalk
    • AWS Lambda
    • Amazon EBS
    • Amazon S3
    • Amazon CloudFront
    • Amazon Glacier
    • AWS Storage Gateway
    • Amazon Elastic File System
    • AWS CloudTrail & AWS Config
    • AWS Support & Trusted Advisor
    • AWS Directory Service
  • WhitePaper

    • セキュリティのベストプラクティス
    • セキュリティプロセスの概要
    • リスクとコンプライアンス
    • AWS を用いた故障耐障害性の高いアプリケーションの構築
    • 新しいリージョンへの AWS リソースの移行
    • 災害対策目的での AWS の使用

本読む

 AWS 事例全集 といった AWS が配っている冊子もありますが数がひたすら多いので、勉強用としてこちらの本で一般的なアーキテクチャを学びました。

image
Amazon Web Services 定番業務システム12パターン 設計ガイド

試験に向けて

 以下、結果もあわせて書いていきます。

サンプル問題集にチャレンジ

ソリューションアーキテクト プロフェッショナル

 サンプル問題を解いた結果、微妙でした。アソシエイトは本試験とくらべて非常に簡単だったので、先が思いやられます。

結果

4/6問 正解

ソリューションアーキテクト以外もやってみる

 SysOpsアソシエイト、DevOpsアソシエイトのサンプル問題もやってみました。ソリューションアーキテクトとはちょっと毛色の違うサービス(CloudFormationとかSQSとか)が出てくるので復習になります。Pro は回答が書いていなかったのでやっていません。

SysOps結果

6/10問 正解

DevOps結果

6/9問 正解

模擬試験

 データ書いておきます。なお、アソシエイト合格者はバウチャーコードが利用できますので活用しましょう。問題文はコピーできます。

TOPIC DATA
試験時間 90分間
問題数 40問
合格ライン 明記なし
受験料 ¥4,320

結果

得点: 27%
結果: 不合格

 時間足りなさすぎました。結果を分析しますが全体的に悪すぎて手のうちようがない感じでした。。。

TOPIC 出題率 正解率(模擬結果) 模擬出題数(予測) 誤答数(予想)
高可用性および事業継続性 15% 33% 6 4
原価計算 5% 0% 2 2
デプロイメントマネージメント 10% 0% 4 4
ネットワーク設計 10% 50% 4 2
データストレージ 15% 50% 6 3
セキュリティ 20% 25% 8 6
拡張性と伸縮自在性 15% 16% 6 5
クラウド移行およびハイブリッドなアーキテクチャ 10% 25% 4 3

出題傾向を抑える

 ベストプラクティスが複数書いてあって、どれも正解だけどよりベストなものを選ぶという問題や、コスト/可用性/移行期間/既存システムとの連携 のどれが求められているのかといった、真の目的を把握しないと答えられない問題が多くありました。
 また、昔の AWS 構成を最新のサービスで置き換えるような問題もあるため、古くなった知識はアップデートが必要です。

模擬試験の復習と弱点克服

 CloudHSM とかの暗号化系、DirectConnect/StorageGateway などの低レイヤー系、TrustedAdvisor など課金系、STS/IAMロールなどの認証系、StepFunctions や SWF などフロー系、Redshift や Kinesis などのBigData系 は、アソシエイトでも踏み込んだ問題が出なかったので個人的に苦手でした。これらは BlackBeltで復習しました。
 また、コピーした模試の問題はを1つづつ調べ、答え合わせをしました。模擬試験については本試験でも出ることがあるので暗記するつもりで復習しました。英語で回答を解説しているサイトがあるので大いに活用しました。

本試験

結果

合格!

image.png

内訳

総合スコア: 66%

トピックレベルのスコア:
1.0 High Availability and Business Continuity: 91%
2.0 Costing: 75%
3.0 Deployment Management: 62%
4.0 Network Design: 37%
5.0 Data Storage: 91%
6.0 Security: 56%
7.0 Scalability & Elasticity: 69%
8.0 Cloud Migration & Hybrid Architecture: 28%

所感

 なんとかギリギリセーフでした。本試験、すごい疲れます。。。
 実務半年程度のペーペーなので試験勉強と実務知識が比例するわけじゃなく、試験としては問題数こなすのが一番という気がしました。本試験のほうが模試より簡単だったので絶望せずがんばりましょう。

 次は DevOps に挑戦したいです。

続きを読む

Amazon Linux(2017.03)にdocker-composeでZabbix3.2をインストールするまで

Zabbixサーバーのインストールと起動

Zabbixは公式でdocker-composeの定義を用意してくれていますので、とっても簡単に起動までできます。

Amazon Linuxを立ち上げてSSHで接続したところから、下記のコマンドで起動できます。

sudo yum update -y
sudo yum install -y docker git

# Docker起動
sudo service docker start

# docker-composeのインストール
curl -L https://github.com/docker/compose/releases/download/1.13.0/docker-compose-`uname -s`-`uname -m` > /tmp/docker-compose
chmod 755 /tmp/docker-compose
sudo mv /tmp/docker-compose /usr/local/bin/

# zabbixのdocker-compose定義を取得
git clone --depth=1 https://github.com/zabbix/zabbix-docker.git

# zabbix起動
cd zabbix-docker
sudo /usr/local/bin/docker-compose -f docker-compose_v2_alpine_mysql_latest.yaml up -d

Webにアクセスするとログイン画面が表示されます。
初期状態では Admin/zabbix でログインできます。

初期状態でzabbix-server自体がホストとして登録されていますが、接続に失敗している状態になっています。
IPが127.0.0.1に設定されていますが、Dockerコンテナ内なのでDockerコンテナ内から接続可能なIPである必要があります。
sudo docker psなどでコンテナ名を確認し、コンテナ名をドメインとして登録することで接続できます。(Dockerネットワーク内はコンテナ名でIPを引けるため)

zabbix-agentのインストールと起動

RPMはRedHat7ではなく6用のものを使う必要があります。
7用のものを使うとsystemdが必要と言われてエラーになります。

インストールしてすぐに起動するとバインドアドレスが0.0.0.0/0になっているので油断しますが、設定ファイル(/etc/zabbix/zabbix_agentd.conf)を編集しないとローカルホスト以外からのアクセスはできないので注意が必要です。

sudo rpm -ivh http://repo.zabbix.com/zabbix/3.2/rhel/6/x86_64/zabbix-release-3.2-1.el6.noarch.rpm
sudo yum install zabbix-agent

# Server=127.0.0.1 の部分をZabbixサーバーのIPに変更する
sudo vim /etc/zabbix/zabbix_agentd.conf

sudo service zabbix-agent start

セキュリティグループ

下記のポートを開けるのを忘れないこと。
サーバー: 10051
エージェント: 10050

続きを読む