ECSにZabbix環境をデプロイする【cloudpack大阪ブログ】

cloudpack大阪の佐々木です。
Zabbix環境をコンテナとしてECS上につくってみたので、まとめときます。

デプロイ方法

ecs-cliとdocker-compose使ってデプロイします。

基本的なやり方はこちら
http://qiita.com/taishin/items/076a7699c787da68e396

docker-coposeはv2が使えるらしいので、今回はv2で記述しています。
http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/cmd-ecs-cli-compose.html

Amazon ECS CLI の最新バージョンでは、Docker 構成ファイル構文のバージョン 1 と 2 がサポートされています。

v2のリファレンス
https://docs.docker.com/compose/compose-file/compose-file-v2/

docker-compose.yml

docker-compose.yml
version: '2'

services:
  mysql-server:
    image: mysql
    mem_limit: 268435456
    environment:
      - MYSQL_DATABASE=zabbix
      - MYSQL_USER=zabbix
      - MYSQL_PASSWORD=zabbix
      - MYSQL_ROOT_PASSWORD=zabbix
    volumes:
        - /ecs/zabbix_mysql:/var/lib/mysql
    logging:
      driver: awslogs
      options:
        awslogs-group: "ECS-zabbix"
        awslogs-region: "us-east-1"
        awslogs-stream-prefix: "zabbix"

  zabbix-server-mysql:
    image: zabbix/zabbix-server-mysql:ubuntu-3.2-latest
    mem_limit: 134217728
    environment:
      - DB_SERVER_HOST=mysql-server
      - MYSQL_USER=zabbix
      - MYSQL_PASSWORD=zabbix
      - MYSQL_DATABASE=zabbix
    logging:
      driver: awslogs
      options:
        awslogs-group: "ECS-zabbix"
        awslogs-region: "us-east-1"
        awslogs-stream-prefix: "zabbix"
    links:
      - mysql-server
    ports:
      - 10050:10050

  zabbix-web-nginx-mysql:
    image: taishin/zabbix-web:latest
    mem_limit: 134217728
    environment:
      - DB_SERVER_HOST=mysql-server
      - ZBX_SERVER_HOST=zabbix-server-mysql
      - MYSQL_USER=zabbix
      - MYSQL_PASSWORD=zabbix
      - MYSQL_DATABASE=zabbix
      - TZ=Asia/Tokyo
      - COMPOSE_HTTP_TIMEOUT=200
    logging:
      driver: awslogs
      options:
        awslogs-group: "ECS-zabbix"
        awslogs-region: "us-east-1"
        awslogs-stream-prefix: "zabbix"
    links:
      - mysql-server
      - zabbix-server-mysql
    ports:
      - 8090:80

順番に説明します。

コンテナ

下記の3つで構成するようにしました。
– mysql
– zabbix-server
– zabbix-web

Zabbixのコンテナはこちらのを使用します。
https://hub.docker.com/u/zabbix/

zabbix-webはそのまま使うとグラフの日本語が文字化けしますので、日本語フォントを入れて、Buildします。
Dokcerfileは下記のようになります。

FROM zabbix/zabbix-web-nginx-mysql:ubuntu-3.2-latest
RUN apt-get update -y && apt-get install -y fonts-ipafont
RUN ln -s /usr/share/fonts/opentype/ipafont-gothic/ipagp.ttf /usr/share/zabbix/fonts/ipagp.ttf
RUN sed -i -e 's/graphfont/ipagp/g' /usr/share/zabbix/include/defines.inc.php

ecs-cliで使うdocker-composeはbuildに対応していないので、あらかじめビルドしてどこかにアップしておく必要があります。
http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/cmd-ecs-cli-compose.html

重要
build ディレクティブは現在サポートされていません。

今回は自分のdockerhubにアップしておきました。

メモリ制限

メモリ制限は下記に記述でハード制限ができます。ソフト制限はできないっぽいです。

    mem_limit: 268435456

永続化データ

MySQLのデータは永続化したいので、ボリュームを作成します。
下記の記述でホストOSの/etc/zabbix_mysqlがコンテナの/var/lib/mysqlにマウントされます。

    volumes:
        - /ecs/zabbix_mysql:/var/lib/mysql

マネジメントコンソールで見るとこんな感じです。

Kobito.NcjJB2.png

Kobito.dg0AbK.png

amazon-ecs-optimizedのAMIを使う場合は下記も注意です。
http://qiita.com/taishin/items/cff9c3212d0f697653e4

Log

コンテナが出力するログはCloudwatch Logsに転送します。
http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/using_awslogs.html

docker-compose v1のときは

log_driver: awslogs

こんな記述でしたが、v2では下記のような表記になります。

    logging:
      driver: awslogs
      options:
        awslogs-group: "ECS-zabbix"
        awslogs-region: "us-east-1"
        awslogs-stream-prefix: "zabbix"

ロググループはあらかじめ作成しておく必要があります。

ストリームプレフィックスですが、

  • awslogs-stream-prefix をつけない場合

Kobito.V9TWgn.png

コンテナごとに乱数のストリーム名になります。

  • awslogs-stream-prefix をつけた場合
    Kobito.GSxPru.png

ストリーム名が下記のフォーマットになるので、付けておいた方が分かりやすいです。

prefix-name/container-name/ecs-task-id

ポート

ホストの8090番ポートをコンテナの80番ポートに転送しています。

    ports:
      - 8090:80

ちなみに固定ポートではなく、ダイナミックポートにする場合は下記のように書きます。

    ports:
      - :80

デプロイ

ecs-cli compose service up です。

$ ecs-cli compose service up                                                  [10:47:02]
WARN[0000] Skipping unsupported YAML option...           option name=networks
WARN[0000] Skipping unsupported YAML option for service...  option name=networks service name=zabbix-server-mysql
WARN[0000] Skipping unsupported YAML option for service...  option name=networks service name=zabbix-web-nginx-mysql
WARN[0000] Skipping unsupported YAML option for service...  option name=networks service name=mysql-server
INFO[0001] Using ECS task definition                     TaskDefinition="ecscompose-zabbix-docker:40"
INFO[0002] Created an ECS service                        service=ecscompose-service-zabbix-docker taskDefinition="ecscompose-zabbix-docker:40"
INFO[0002] Updated ECS service successfully              desiredCount=1 serviceName=ecscompose-service-zabbix-docker
INFO[0003] Describe ECS Service status                   desiredCount=1 runningCount=0 serviceName=ecscompose-service-zabbix-docker
INFO[0018] ECS Service has reached a stable state        desiredCount=1 runningCount=1 serviceName=ecscompose-service-zabbix-docker

マネージメントコンソールでタスク定義をいじるようり、docker-composeの方がだいぶ楽ですね。

続きを読む

ECSのAMIで使われる/dev/xvdczについて【cloudpack大阪ブログ】

cloudpack大阪の佐々木です。
ECSでコンテナ用のボリュームを作ったらどこに保存されるか?という話です。

ECSで使うamazon-ecs-optimizedのAMIはデフォルトでは下記のディスク構成になっています。(2015.09.d 以降)

  • /dev/xvda 8G
  • /dev/xvdcz 22G

http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/launch_container_instance.html

Amazon ECS に最適化された、2015.09.d 以降の AMI を使用している場合、インスタンスには 2 つのボリュームが設定されます。[Root] ボリュームはオペレーティングシステム用で、2 番目の Amazon EBS ボリューム (/dev/xvdcz にアタッチ) は Docker 用です。

永続化データを取り扱う場合、ボリュームを追加すると思います。/dev/xvdcz はDocker用ボリュームってことなので、当然そちらに作られるのかと思ったのですが、違うようです。

https://github.com/aws/amazon-ecs-agent/issues/312

/dev/xvdcz is dedicated to layer storage; since volumes are not layers, they’re not stored there.

実際にやってみます。
タスク定義はこんな感じです。

"volumes": [
  {
    "name": "volume-0",
    "host": {
        "sourcePath": "/ecs/mysql"
    }
  }
]

dfではRootボリュームの/dev/xvda1 だけが見えています。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       7.8G  1.7G  6.1G   22% /
devtmpfs         1.9G   96K  1.9G    1% /dev
tmpfs            1.9G     0  1.9G    0% /dev/shm

コンテナにログインし、マウントしているボリュームに2Gのファイルを作成します。

$ docker exec -it 706e24a04caa /bin/bash
root@706e24a04caa:/# dd if=/dev/zero of=/var/lib/mysql/test.out bs=1024 count=2000000
root@706e24a04caa:/# ls -lh /var/lib/mysql/test.out
-rw-r--r-- 1 root root 2.0G Apr 25 04:47 /var/lib/mysql/test.out

ログアウトして、dfを実行してみます。

[ec2-user@ip-172-31-49-18 ~]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       7.8G  3.6G  4.2G   47% /
devtmpfs         1.9G   96K  1.9G    1% /dev
tmpfs            1.9G     0  1.9G    0% /dev/shm

/dev/xvda1 が増えています。

ではDocker用のボリューム /dev/xvdcz はどんな感じで使われているのでしょうか?
ここに詳しく書いてました。
http://enakai00.hatenablog.com/entry/20140420/1397981156

ホストOSからはこんな感じで見えています。

# lsblk
NAME                                                                                         MAJ:MIN   RM  SIZE RO TYPE MOUNTPOINT
xvda                                                                                         202:0      0    8G  0 disk
└─xvda1                                                                                      202:1      0    8G  0 part /
xvdcz                                                                                        202:26368  0   50G  0 disk
└─xvdcz1                                                                                     202:26369  0   50G  0 part
  ├─docker-docker--pool_tmeta                                                                253:0      0   52M  0 lvm
  │ └─docker-docker--pool                                                                    253:2      0 49.5G  0 lvm
  │   ├─docker-202:1-263192-5c6d48e2f8751428fe02afdadbd0cea776f6019d7ea6b84b3313a66d0c1f8ed7 253:3      0   10G  0 dm
  │   ├─docker-202:1-263192-eca78b256bf5721af414556f0ab42f4436e5ddd2dfb060da1f0ccf843cdbe11a 253:4      0   10G  0 dm
  │   ├─docker-202:1-263192-035491c621338eac035f0a3ee3894dc7c02c0f2989a33bce5e4628226edb1f10 253:5      0   10G  0 dm
  │   ├─docker-202:1-263192-d27d60081d632b3cc0e5b7c7213f40b4eec77d445d0c445abdf69efc83535d54 253:6      0   10G  0 dm
  │   └─docker-202:1-263192-60b1cb416a8ced69c0f6f5c71b842298427dfa406dd7ed6f5f44a56dc3d5f78f 253:7      0   10G  0 dm
  └─docker-docker--pool_tdata                                                                253:1      0 49.5G  0 lvm
    └─docker-docker--pool                                                                    253:2      0 49.5G  0 lvm
      ├─docker-202:1-263192-5c6d48e2f8751428fe02afdadbd0cea776f6019d7ea6b84b3313a66d0c1f8ed7 253:3      0   10G  0 dm
      ├─docker-202:1-263192-eca78b256bf5721af414556f0ab42f4436e5ddd2dfb060da1f0ccf843cdbe11a 253:4      0   10G  0 dm
      ├─docker-202:1-263192-035491c621338eac035f0a3ee3894dc7c02c0f2989a33bce5e4628226edb1f10 253:5      0   10G  0 dm
      ├─docker-202:1-263192-d27d60081d632b3cc0e5b7c7213f40b4eec77d445d0c445abdf69efc83535d54 253:6      0   10G  0 dm
      └─docker-202:1-263192-60b1cb416a8ced69c0f6f5c71b842298427dfa406dd7ed6f5f44a56dc3d5f78f 253:7      0   10G  0 dm

まとめ

ECSで永続化データ用のボリュームを使う場合は、Rootボリュームをあらかじめ大きくしておくか、別ボリュームをアタッチしてマウントしとく必要があるようです。

続きを読む

S3+CloudFrontで、index.htmlが落ちてくる/付加されないばあい

概要

S3+CloudFrontで静的なページをAWSにもっていこうとした所、引っかかった部分のまとめ。

  • w3mで接続確認しようとすると、内容が表示されずにindex.htmlがダウンロードされる
  • Content-Typeを疑い、opensslでつなごうとするとSSLのエラー

以上の状態からの対応作業

CustomSSL(SNI)の証明書の場合の接続確認

  • 証明書が有効か確認しようとしてみるとエラー
$openssl s_client -connect example.com:443
no peer certificate available
  • サーバーネームを指定する必要がある
$openssl s_client -connect example.com:443 -servername example.com

GET / HTTP/1.0で400 Bad Request

GET / HTTP/1.0

HTTP/1.1 400 Bad Request

Server: CloudFront
Date: Mon, 24 Apr 2017 03:00:56 GMT
Content-Type: text/html
Content-Length: 551
Connection: close
  • きちんとHostもつける
GET / HTTP/1.0
Host: example.com

HTTP/1.1 200 OK
Content-Type: application/x-directory
Content-Length: 0
Connection: close

CloudFrontで設定したドメイン / へのアクセス時に、index.htmlが補完されない(デフォルトルートオブジェクト)

  • S3で設定していたとしても、CloudFront側で設定しなければindexは補完されない
HTTP/1.1 200 OK
Content-Type: application/x-directory
Content-Length: 0
Connection: close

http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/DefaultRootObject.html

SNIのところと、indexの補完が出ずに二日も時間取ってしまった悲しみ…

続きを読む

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

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

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

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

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

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

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

Try a sample

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

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

cb-2.png

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

Createを押しやす。


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

cb-3.png

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

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

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

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

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

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

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

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

cb-8.png

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

音声入力してみる

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

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

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

cb-13.png


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

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

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

sampleを作ってわかったこと

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

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

考えられる用途

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

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

大変そうな点

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

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

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

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

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

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

まとめ

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

以上!

続きを読む

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

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

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

AWS X-Ray デーモンの実行

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

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

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

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

Dependencies Resolved

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

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

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

Installed:
  xray.x86_64 0:2.0.0-1                                                         

Complete!

Lambdaアプリ側の準備

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

続きを読む

メモ: Route 53 で Privacy Protection がなかなか有効にならないときには、ドメインのロックを有効にして Don’t hide にしてから hide にするといいよ

Amazon Route 53で汎用JPドメインを申請してみた

の方法を参考にしつつ、自分も Privacy Protection を有効化しました。

とても些細なハマりどころなのですが、
1 日ほど待っても WHOIS 情報が自分の住所のまま、ということがありました。

ワークアラウンドで解決したのでやり方を書いておきます。

1. Privacy Protection を有効化するにはドメインのロックが必要

連絡先情報を非表示にできるのは、移管できないようにドメインがロックされている場合のみです。ドメインを Amazon Route 53 に移管する場合または から移管する場合は、WHOIS クエリでお客様の連絡先情報が表示されるように、プライバシー保護を無効にする必要があります。移管が完了したらプライバシー保護を再度有効にすることができます。

http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/domain-privacy-protection.html

わすれがちです。ドメインのロックを有効にしましょう。

Registered Domains > ドメインを選択 > Transfer lock で (enable) をクリックすると有効になります。

2. ドメインのロックと Privacy Protection を有効にする順番

ここが私の躓きのポイントでした。

ドメインのロックを有効化しても、その前に既に Privacy Protection が有効化されている状態だと、自動的に WHOIS 情報は更新されることはないようです。

一度 Privacy Protection を無効にしてから有効にすることで強制的に更新する、というワークアラウンドが必要になります。

つまり

  1. ドメインのロックを有効化
  2. Privacy Protection を無効化 (Edit contacts からラジオボタンを Don’t hide contact information と選んで Save)
  3. (無効化処理が完了するまで数十秒ほど待つ)
  4. Privacy Protection を有効化 (Edit concats からラジオボタンを Hide contact information if … と選んで Save)

という手順になります。

ここに気が付かないと「おかしいな、ちゃんと有効化にしてるのにな〜、すぐには反映されないのかな〜」と何度も Edit contacts したり、何時間か反映を待ってみたり、無駄な時間を過ごす羽目になります……。

続きを読む

Angular2をAWSのS3とCloudFrontでホスティングする

Angular2を使い始めたら、すぐAngular4がリリースされましたね。この世界の動きは早いですね:older_man_tone2:

今日はやっとAngular2をAWSでサーバレスでホスティングしてみました。方式も手順も難しくはないですが、すぐ忘れてしまいますので、いつも通りメモしたいと思います。

AWSでホスティング

Angular2とサーバの関係

Angular2はコンパイル後はindex.htmlとcss, javascriptのセットからなる、静的なコンテンツですので、Webサーバを選ばずホスティングできるようです。

AWSで静的コンテンツをホスティングする

AWSの完全ガイドはこちらですが、少々難しいので、端折りながら…

基本的には、

1. S3にコンテンツをアップロードする
2. CloudFrontで、S3のコンテンツを配信する
3. Route 53で、CloudFrontのホスト名に対して公開したいホスト名をエイリアスで付ける

という手順になるようです。

S3にRoute53でエイリアスを付けることも可能ですので、S3だけでもホスティングはできるのですが、S3はHTTPsに対応していないようです。そのため、今回の手順は(HTTPsに対応している)CloudFrontまで入れています。

実際の手順

1. S3での作業

AWSの公式ガイドはこちらです。

1-1. バケットを作成

バケット名は、ホストするサーバ名にします。
※ここではAWSの例通り、『example.com』とします。

1-2. 静的ウェブサイトホスティングを有効にする

バケットのプロパティタブで、上記の項目をクリックし、ラジオボタンで『有効にする』を選択します。

AWS入力欄
- インデックスドキュメント:index.html
- エラードキュメント:error.html

を入力して保存します。

Angular2を ng build コマンドでトランスパイルすると、index.htmlが生成されますので、インデックスドキュメントはそれを参照する形になります。error.htmlはAngular2では用意されませんので、自分でエラーページを作って、名前をerror.htmlにします。

1-3. アクセス許可で、バケットポリシーを作成する

バケットのプロパティタブで、上記の項目をクリックし、『バケットポリシーの編集』ボタンを押して、ダイアログに以下のポリシーJSONを貼り付けます。

ポリシー
{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"AddPerm",
        "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::example.com/*"
      ]
    }
  ]
}

コロンの後ろに続く、『example.com』の記載は、ホストするサーバ名(バケット名)になります。

1-4. Angular2ファイルのアップロード

ng buildコマンドを実行し、生成されたコンテンツ(デフォルトでは、distフォルダ)の中の、全てのファイル(index.html, xx.buldle.js, xx.buldle.js.map)を作成したS3バケットにアップロードします。

独自に、favicon, error.htmlを作成している場合は、それも同じS3バケットにアップロードします。

1-5. S3でのホスティングの確認

プロパティタブ>静的ウェブサイトホスティングで表示されるエンドポイントをクリックして、ブラウザに表示されれば成功です。

エンドポイント例)
example.com.s3-website-ap-northeast-1.amazonaws.com

以上でS3での作業は完了です。

2. CloudFrontでの作業

2-1. Distributionを新規作成する

まず、Web distributionを作成するボタンを押し、その後に以下を設定します。

  • Origin Domain Nameに、S3バケットのエンドポイントを設定
  • Viewer Protocol PolicyをRedirect HTTP to HTTPSに設定(任意)
  • Allowed HTTP Methodsに、GET, HEAD, OPTIONSを設定(任意)※1
  • Alternate Domain Names(CNAMEs)にRoute 53で設定するホスト名を設定
  • SSL Certificateを、Custom SSL Certificateを設定(任意)※2
  • Default Root Objectに『index.html』を設定 ※3

※1) CORSをする場合は、プリフライトリクエストに対応するためにOPTIONSを有効にする必要があります。
※2) CloudFrontのHTTPs化については、こちらこちらを参考にしました。
※3) デフォルトルートオブジェクトについては、こちらの説明をご参照ください。

3. Route53の作業

DistoributionのDomain Name(例:dxxxxxxxx.cloudfront.net)を、ホスト名のエイリアスに設定すれば完了です。

Route53入力例)
Name: example.com
Alias Target: dxxxxxxxx.cloudfront.net

参考)S3に対してRoute 53でホスト名を割り振る場合

HTTPsが必要ない場合には、CloudFrontまで使わずにS3だけでホスティングすることができます。

このとき、Route 53でエイリアスとして指定するのは、S3のwebホスティングを示すドメイン名部分です。面白いことに『example.com』のような固有値が必要ありません。

Route53入力例)
Name: example.com
Alias Target: s3-website-ap-northeast-1.amazonaws.com

私も最初は『example.com』を付けたFQDN(example.com.s3-website-ap-northeast-1.amazonaws.com)を設定してハマりまして、こちらを参考にさせて頂いて上記の設定に気が付きました。

Route53でTargetが表示されない場合は、こちらのページをご参考にしてみたら良いかもしれません。

以上です:grinning:

続きを読む

AWS の Ubuntu 16.04 で Etherpad as a service

AWS上でEtherpadを動かし、外からアクセスするようにできるまでのメモ書き。
DBはmysqlを使用。pluginはテーブルと画像挿入のをインストール。

前準備
AWS上のUbuntuパスワード変更
http://d.hatena.ne.jp/thata/20101116/1289890621

nodesインストール(次のに含まれているから不要?)
http://qiita.com/yuji_azama/items/45c0b413453534dba291

Ubuntu 16.04 に Etherpad をインストール
(コマンドを入力したら実行できる状態まで)
https://linuxconfig.org/install-etherpad-web-based-real-time-collaborative-editor-on-ubuntu-16-04-linux

起動時サービス
(サーバ起動時に自動でEtherpadが起動できるようにする)
http://pangency.hatenablog.com/entry/2015/05/08/111025

script の中身は

#! /bin/sh

case "$1" in
  start)
    /opt/etherpad/bin/run.sh
    ;;
esac

exit 0

とします。

ドメイン設定
https://ja.amimoto-ami.com/2013/11/29/elastic-ip-and-route-53/

nginxをリバースプロキシサーバとして使う。
(nodejs は80番ポートで起動できない?)
以下、Ethepadのデフォルトポートは9001 だが、settings.jsでポートを8080に変えた時の例。

upstream web-nodejs {
  server localhost:8080;
}
server {
  listen       80;
  server_name  etherpad.dslabgroup.com;

  location / {
    proxy_pass http://web-nodejs/;
  }
}

外からは80番ポートでアクセスするので、AWSのセキュリティの設定は、80番ポートに外からアクセスできるようにしていればいい。

nginx enableする (サーバ起動時にnginx起動)
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples

plugins
https://static.etherpad.org/plugins.html # ここにPlugin一覧がある
https://help.ubuntu.com/community/Etherpad-liteInstallation#Plugins

cd /opt/etherpad-lite
npm install ep_tables2
npm install ep_copy_paste_images
# AWSでインスタンス再起動する
# (上記で自動でrun.shをするようにした場合の、サービスだけの再起動方法不明。。)

mysql 設定
デフォルトではjs製のDB DirtyDBを使うようになっている。データ毎(?)の容量の上限が1M?らしいので、mysqlに変える。
下記設定だけを行うと、create tableなどはetherpad 起動時に自動で行われる。
https://github.com/ether/etherpad-lite/wiki/How-to-use-Etherpad-Lite-with-MySQL
https://help.ubuntu.com/community/Etherpad-liteInstallation

続きを読む

Terraformでstate lockを触ってみた。

はじめに

初めてTerraformを触る折に
「v0.9以上だとstate lockっていう機能があるから使ったほうが良いよ」
というアドバイスをもらいました。
(そもそも、stateってなんですか?から始まるわけですが・・・)

初めてTerraformを触った時に、公式ドキュメントだけでは???な状態だったので
痕跡として残しておきます。

結果として、まだ使いこなせてません。というか僕の使い方は果たしてあっているのだろうか
なので情報としては不足しているかもしれませんが、とりあえず備忘録的に残します。
またわかったらUpdateします。

そもそもState Lockとは

完全に理解しないで書いてますが
Terraformは「自分が知っているリソース(EC2やS3)しか関与しないよ」というポリシーで
どのリソースを自分が扱ったか、というのをtfstateというJSONファイルで管理しているようです。

このtfstateファイルは、一人でTerraformを動かす場合は問題無いのですが
複数人でTerraformをいじる必要が出てきた時に問題で、それは「backend」モジュールを使うことで回避してきたようですが
同じタイミングでterraformを実施した場合、その部分までは制御しきれてなかったようです。

で、v0.9以上?から、「Plan/Applyをしているタイミングではロックする」機能が実装されたようで。
せっかくなので導入してみました。

公式サイト:https://www.terraform.io/docs/state/locking.html

準備

手動で準備が必要なものは
・terraformを実行するユーザのCredential情報
→ めんどくさかったので test-terraformとかいうユーザを別途作成しました。
・S3 Bucketの作成
→ terraform-s3-state とかいう名前で作りましょう
・DynamoDBの作成
→ 名前はなんでも良いです。terraform-state-lock とかで作りましょう。
  プライマリキーを「LockID」としてください。それ以外では動きません。
作り終えたら、読み込み・書き込み容量ユニットは最低の1にしておいたほうが良いと思います。

※ S3とDynamoDBをterraformで管理はしないほうが良さげです。
どのみち、初回実行時に「そんなリソース無いんだけど!」ってTerraformが怒ります。

動くまで

今回はState Lockの話がメインなので作るリソースはなんでも良いです。
リージョンが関係無いRoute53を題材にします。

route53.tf
# 適当に1ゾーン作ります。

resource "aws_route53_zone" "test_zone" {
    name    =   "test.lockstate.com"
}
settings.tf
# ネーミングよくないですが、providerとbackendの設定します

provider "aws" {
    access_key = "ACCESS_KEY"
    private_key = "PRIVATE_KEY"
}

terraform {
    backend "s3" {
        bucket     = "terraform-s3-state"
        key        = "terraform.tfstate"
        region     = "s3とdynamoがいるregion"
        lock_table = "terraform-state-lock"
    }
}

これで、「該当のディレクトリに移動して」$ terraform plan してください。(怒られます。)

Backend reinitialization required. Please run "terraform init".
Reason: Initial configuration of the requested backend "s3"

The "backend" is the interface that Terraform uses to store state,
perform operations, etc. If this message is showing up, it means that the
Terraform configuration you're using is using a custom configuration for
the Terraform backend.

とりあえず terraform init しろよと言われるので言われるがままに。

$ terraform init

ただし、以下の通り、認証情報がねーんだけど!って怒られる。なんやねん。

Initializing the backend...

Error configuring the backend "s3": No valid credential sources found for AWS Provider.
  Please see https://terraform.io/docs/providers/aws/index.html for more information on
  providing credentials for the AWS Provider

Please update the configuration in your Terraform files to fix this error
then run this command again.

ここらへんちゃんとよくわかってないですが、この問題の対処として2つありました。
A. settings.tfのbackendにaccess_key/secret_keyの2つを渡してCredential情報を平文で書く。
-> 変数でいいじゃん!と思ったんですが、変数で渡すと、Terraformがよしなにやる「前に」
  Backendが立ち上がるために違う方法で渡してくれ、と怒られました。
以下のようなメッセージ

% terraform init 
Initializing the backend...
Error loading backend config: 1 error(s) occurred:

* terraform.backend: configuration cannot contain interpolations

The backend configuration is loaded by Terraform extremely early, before
the core of Terraform can be initialized. This is necessary because the backend
dictates the behavior of that core. The core is what handles interpolation
processing. Because of this, interpolations cannot be used in backend
configuration.

If you'd like to parameterize backend configuration, we recommend using
partial configuration with the "-backend-config" flag to "terraform init".

B. 環境変数にaccess_key/secret_keyの2つを食わせる
  → 今はこちらを採用中。

init or plan実行時に、状況に応じて「ローカルのStateをS3にコピーするか / S3からStateファイルをローカルにコピーするか」聞かれるかもしれません。
初回(もしくはテスト)であればYes、すでに何回か実行しているような状況ではnoでいいんじゃないでしょうか。

これで、terraform plan (or apply)を実行すると
DynamoDBのLockDBに対して誰が使用しているか、のロック情報が書き込まれ
終わったタイミングでリリースされます。

ターミナルやシェルを複数立ち上げ、同じぐらいのタイミングで
terraform plan( or apply )を実行すると、ロックが成功できた奴以外はエラーで落とされます。
ただし、ロックがリリースされる前の実行中などにCtrl-Cなどで強制終了させるとロックが残り続けるので注意。
$ terraform force-unlock ID情報
で強制ロック解除できます。

今僕が解決できてない問題点

公式ドキュメントを見る限り、「terraform remote コマンドは terraform initコマンドに置き換えたよ!」と言っています。
また、backendを使用する、backendを書き換えた、などのタイミングに起因して terraform init を求められます。

が、terraform initは、「実行されたディレクトリに対して .terraform/terraform.tfstate」を吐き出します。
そしてそれが無いと怒ります。
まだ試せてはいませんが、以下のようなtfの配置をしていたりした場合
root配下でinitを実行しても、tfファイルがありませんと怒られる状況で
tfファイルがあるディレクトリまで移動しないとinitができない状態です。

$ terraform init ./route53/tf
とするとroot直下にtfファイルがコピーされる状況です。
なので、リソースごとに区切る、とか環境ごとに区切る、とかはうまくできていません。
別の見方をすれば、環境ごとに一つのディレクトリでリソース類は全部その中で管理しろよ!
というHashiCorpからのお達しなのか・・・?
これは、新しく実装されたEnvironmentを試せ、ということなんでしょうか。。。

と思ったらBackendConfigなるものがあるらしいのでそれを試してみよう。

root
├── settings
│   └── tf
│   └── settings.tf
├── route53
│   └── tf
│   └── route53.tf
└── ec2
└── tf
└── ec2.tf

Terraformとの付き合い方がよくわからない

続きを読む

AWSにDjango環境を構築する

versions

Python : 2.7
Django : 1.10

Environment

EC2インスタンス : Amazon Linux
WSGI : gunicorn
Proxy : nginx

install python packages

sudo yum update
sudo yum install gcc
sudo yum install python-devel
sudo yum install python-psycopg2
sudo yum install postgresql-devel
pip install -r requirements.txt

reverse proxy

sudo yum install nginx
sudo vi /etc/nginx/nginx.conf
  • nginx.confに追記 line : 49
location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

# http://mydomain/static/ をDjangoのsettings.pyでSTATIC_ROOTに指定したディレクトリへルーティング
location /static/ {
    autoindex on;
    alias   /usr/share/nginx/html/django-project-name/staticfiles/;
}
sudo chmod 777 -R /usr/share/nginx/html ※1
sudo service nginx restart
gunicorn django-project-name.wsgi -D

Memo

python manage.py runserver 0.0.0.0:8000  # 全てのホストアドレスからのアクセスを許可
python manage.py migrate
python manage.py createsuperuser

# 事前にsettings.pyにSTATIC_ROOTを設定する (defaultでは記載されていない)
python manage.py collectstatic  # STATIC_ROOTに指定したディレクトリに静的ファイルが生成される

※1 : このディレクトリ下にDjangoプロジェクトを設置
当初はSTATIC_ROOTに設定したディレクトリのシンボリックリンクのみをここに貼ったが
静的ファイルを読み込む際に403エラーが発生してしまうためプロジェクトごとこのディレクトリに設置
所有がrootのディレクトリに対して、パーミッションを777に設定してしまうのは多少疑問が残るところ

SSL証明書

証明書はAWS Certificate Managerで発行し、Elastic Load Balancerにインストール
ELBとEC2間の通信はhttpとなるが、ELBとEC2が同じリージョンにある場合セキュリティの問題はなさそう

続きを読む