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ボリュームをあらかじめ大きくしておくか、別ボリュームをアタッチしてマウントしとく必要があるようです。

続きを読む

TensorFlow with GPU on Docker を AWS で起動する

構成

https://github.com/NVIDIA/nvidia-docker にある以下の図が分かりやすい。

図

今回、Server は AWS の p2 インスタンス (GPU インスタンス)。
Host OS は Ubuntu 16.04 を利用する。

手動でインストールが必要なものは以下の通り。

  • CUDA Toolkit / CUDA Driver

    • NVIDIA GPU をコントロールするために必要
    • 2つ同時にインストールされる
  • Docker Engine
  • nvidia-docker
    • Docker コンテナ内から CUDA Toolkit 経由で GPU を触るために必要

1. AWS インスタンス起動

GPU インスタンスの p2 系を起動する。

AMI
Ubuntu Server 16.04 LTS (HVM), SSD Volume Type
備考
ディスクサイズは 100 GB に変更する (デフォルトは 8 GB、足りない)

2. CUDA のインストール

公式ドキュメント 通りに進める。
ただ、ドキュメントが長いので読まない方が良い。ハマると果てしなくハマって辛い。

実際に必要なのは3箇所のみ。

  • “2. Pre-installation Actions” > “2.6. Download the NVIDIA CUDA Toolkit”
  • “3. Package Manager Installation” > “3.6. Ubuntu”
  • “6. Post-installation Actions” > “6.1.1. Environment Setup”

実際のコマンドは以下の通り。

## 2.6 Pre-installation Actions (Download the NVIDIA CUDA Toolkit)
$ wget https://developer.nvidia.com/compute/cuda/8.0/Prod2/local_installers/cuda-repo-ubuntu1604-8-0-local-ga2_8.0.61-1_amd64-deb

## 3.6 Package Manager Installation (Ubuntu)
$ sudo dpkg -i cuda-repo-ubuntu1604-8-0-local-ga2_8.0.61-1_amd64-deb
$ sudo apt-get update
$ sudo apt-get install cuda

## 6.1.1 Post-installation Actions (Environment Setup)
$ echo 'export PATH=/usr/local/cuda-8.0/bin${PATH:+:${PATH}}' >> ~/.bashrc
$ source ~/.bashrc

nvcc が入れば成功。

$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2016 NVIDIA Corporation
Built on Tue_Jan_10_13:22:03_CST_2017
Cuda compilation tools, release 8.0, V8.0.61

3. Docker のインストール

公式ドキュメント (Install using the repository) 通りに、Docker CE をインストールする。

インストール完了したら、sudo 無しで動作するよう ubuntu ユーザを docker グループに追加して、SSH ログインし直す。

$ sudo usermod -aG docker ubuntu

hello-world が動けば完了。

$ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
78445dd45222: Pull complete
Digest: sha256:c5515758d4c5e1e838e9cd307f6c6a0d620b5e07e6f927b07d05f6d12a1ac8d7
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.
...

4. nvidia-docker のインストール

公式ドキュメント 通りに進める。

“Quick start” > “ubuntu distributions” のコマンドを実行すればOK。

$ wget -P /tmp https://github.com/NVIDIA/nvidia-docker/releases/download/v1.0.1/nvidia-docker_1.0.1-1_amd64.deb
$ sudo dpkg -i /tmp/nvidia-docker*.deb && rm /tmp/nvidia-docker*.deb

以下のコマンドで Docker コンテナがホスト (p2 インスタンス) の GPU を認識していることが確認できる。

$ nvidia-docker run --rm nvidia/cuda nvidia-smi
Sun Apr 23 06:10:55 2017
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 375.39                 Driver Version: 375.39                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla K80           Off  | 0000:00:1E.0     Off |                    0 |
| N/A   47C    P8    28W / 149W |      0MiB / 11439MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID  Type  Process name                               Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

TensorFlow

あとは TensorFlow でもなんでもコンテナ内から GPU が触れる。

https://hub.docker.com/r/tensorflow/tensorflow/

$ nvidia-docker run -it -p 8888:8888 tensorflow/tensorflow:latest-gpu

続きを読む

Amazon Dash ButtonをHackするのはJust do itでしょ、と思って手を出したら落とし穴にどハマった件

Exective Summary

そもそもやりたかったこと:

Amazon Dash Buttonを押して、AWS上の全EC2を停止する。
(利用料が個人レベルでない上に、お小遣いが少ないもので…)

前提・制約:

(甲) 我が家にはWindows10マシンしかない(Linuxマシンはない、という意味)。
(乙) 一方、AWS Dash ButoonをHackするツールとしては、Linux/OS X向けNode.js系ツールが主流らしい([1],[3],[5],[9])。
⇒Amazon Dash Buttonは、ボタンを押すとARPリクエストを送出(ブロードキャスト)する。それを同じLANで待ち受けて検知できるのがDasher。その検知をトリガーにして任意の処理(WebAPIを呼び出す、等)を起動できる。
(丙) 我が家にはAWS Dash Buttonが2つある。それは、購入商品の指定/設定を、
  (A) 意図的に途中でやめてあるモノ
  (B) 無邪気に最期まで完了した(知らずに済ませてしまった)モノ
  の2種類だ。
(丁) 呼び出されたら「全EC2を停止する」というAPIは、AWS IoT/API Gateway/Lambdaのサーバレスアーキで作成済み。
⇒世間の情報も豊富だし、小1時間程度でできるっしょーとたかをくくる。

俺的に考え得た・試した選択肢

①Windows10+Dasher・・・×
②Windows10+Bash on Windows+Dasher・・・×
③Windows10+Cygwin+Dasher・・・×
④Windows10+win-node-dash-button・・・×
⑤Windows10+Vagrant+VirtualBox+Ubuntu+Dasher・・・○
⑥Windows10+Docker-Machine+VirtualBox+Boot2Docker+Dasher・・・×
⑦Windows10+Docker-Machine+VirtualBox+Boot2Docker+Docker+Ubuntu+Dasher・・・未

紆余曲折の結果が…コレだ…ワン・ツー・スリー…

⑤Windows10+Vagrant+VirtualBox+Ubuntu+Dasher

学べる(学べた)コト

・Git
・node.js/npm/node-gyp/node_pcap
・python/pip
・Bash on Windows/Cygwin/Ubuntu
・Docker-Machine/Vagrant/VirtualBox
・Wireshark/tcpdump
・NW/ARP/DNS

嵐の後の所感

やってみた結果として、Amazon Dash Buttonは幅広く技術を体験するのに良いテーマだったという実感。
(「フェルマーの最終定理」と同じ構図?定理の意味の理解はトリビアルだが、その証明を理解するには色々な数学的知識が必要!)
次は『Dash Button(丙)-(B)』のHackを試みる…(方向性としては『DNSサーバをポジティブに偽装する』)
…まあ、AWS IoT Buttonが日本でも発売されたら、それを使うけどね…

俺が落ちた落とし穴の各論

以下、詳細:(細々と続く)

参考情報

[1] Amazon Dash ButtonをただのIoTボタンとして使う
[2] node-dash-button@GitHub
[3] Amazon Dashボタンのハックにおける期待と落胆(Wi-Fi編)
[4] dasher@GitHub
[5] Amazon Dash Buttonを(正しくない方向で)使ってみた
[6] Dash Button for Node@GitHub
[7] node_pcap
[8] node_pcapのWindows7対応Folk
[9] win-node-dash-button
[10] Windowsでnpm installしてnode-gypでつまずいた時対処方法
[11] これはすごい!分解とパケット解析で分かったAmazon Dash Buttonの「本気度」
[12] これはすごい!Amazon Dash Buttonをプレゼンに使う
[13] これはすごい!Amazon Dash Buttonでツイートできた

続きを読む

Amazon EC2上のRed Hat Enterprise LinuxにX11転送でElixir ReportをGUIインストールする手順

この記事はクラウド環境のLinuxインスタンスに、帳票ツールのElixir ReportをGUIインストールする手順についてまとめたものです。

以前の記事、Amazon EC2上にRed Hatインスタンスを作成してElixir Reportをコンソールインストールする手順では、デスクトップ環境のないLinuxインスタンスにコンソールインストールする手順を試してみました。

今回は、SSHのX11転送(X11フォワーディング)機能を使って、デスクトップ環境の入っていないAmazon EC2上のRed Hat Enterprise LinuxのインスタンスでElixir Reportのレポートサーバーのインストーラを実行し、GUIインストーラをWindows側に表示してインストールしてみたいと思います。

環境

Windows 8.1
Elixir Report 8.7J
Amazon EC2 Red hat Enterprise Linux 7.3

WindowsにTera Termをインストールする

この記事では、Linux OSへのSSH接続にTera Termを使用します。Tera TermのWindowsへのインストールは、以前の記事[SSH接続用にWindowsにTera Termをインストールする]を参考にしてください。

WindowsにXサーバーをインストールする

Linux上のGUIアプリケーションをWindows側で操作するには、WindowsのリモートデスクトップやVNC経由でLinuxのデスクトップに接続することもできますが、この記事では、Linux上で動作しているアプリケーションのGUIをWindows側に表示する方法としてX11転送を利用します。

この方法ではWindows側にXサーバーがインストールされている必要があるので、今回はXmingというフリーのWindows用Xサーバーを使用します。こちらの記事を参考にしました。

【参考記事】フリーのWindows用Xサーバー「Xming」のインストールと基本設定、使い方

  1. Xmingインストーラをダウンロードサイトからダウンロードします。本記事の作成時(2016年11月)で最新のXming(Xming-6-9-0-31-setup.exe)と、Xming-fonts(Xming-fonts-7-7-0-10-setup.exe)をダウンロードします。1ダウンロードファイル選択.png  

  2. Xmingのインストーラをダブルクリックで起動します。選択項目は基本的にデフォルト設定を受け入れてインストールします。[Next]で進みます。
    2install01.png

  3. インストール先を指定して次に進みます。

  4. コンポーネントの選択画面では、デフォルト設定を受け入れて進みます。3install03.png

  5. アイコンやタスクの選択ステップも同様に、デフォルトのまま進みます。4install05.png

  6. インストール前の確認項目をチェックして進み、インストールを完了します。5install07.png

  7. インストールの完了画面で[Launch Xming]にチェックを入れて終了すると、Xmingが起動してタスクトレイにアイコンが表示されます。
    6icon.png

    [注意]Xming起動時に、Windowsファイアウォールの警告が表示されることがあります。その場合は、アクセスを許可します。

  8. 次にXming-fontsをインストールします。Xming-fontsのインストーラを起動し、コンポーネントの選択でデフォルトを受け入れます。
    7fontinstall01.png

  9. インストールの内容を確認して進めると、インストールが完了します。8fontinstall03.png

Amazon EC2 Red Hatインスタンスの作成と準備

Amazon EC2上に、デフォルトの構成でRed Hatインスタンスを作成します。以前の記事[Red Hatインスタンスの作成と準備]セクションを参考にしてください。

インスタンスの作成と、Windows上のTera TermからRed Hatインスタンスへ接続するまでの手順が完了します。

X11転送の設定をする

X11転送に関する、Red Hat側およびWindows側の設定と確認を行います。

Linux側の設定

  1. Red Hatインスタンスで、X11転送が有効化されているか確認します。/etc/ssh/sshd_config内で、X11Forwardingyesになっていれば問題ありません。

    $ sudo cat /etc/ssh/sshd_config |grep X11
    X11Forwarding yes
    #X11DisplayOffset 10
    #X11UseLocalhost yes
    #       X11Forwarding no
    
  2. 手順1で、X11Forwardingnoになっている場合は、/etc/ssh/sshd_configをバックアップした上で設定をyesに変更し、sshdを次のコマンドに従って再起動します。

    $ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_org
    $ sudo vi /etc/ssh/sshd_config
    $ sudo service sshd restart
    Redirecting to /bin/systemctl restart  sshd.service
    
  3. XアプリケーションをX11転送によりWindows上に表示できるか確認するため、今回はxeyesというXアプリケーションをRed Hatインスタンスにインストールしておきます。

    $ sudo yum –y install xeyes
    

Windows側の設定とテスト

  1. Windows側でXmingが起動していることを確認します。

  2. Tera Termの設定で、リモートのXアプリケーションをローカルに表示する設定を行います。Tera Termの[設定]-[SSH転送]をクリックします。
    9TeraTerm_SSH転送設定.png

  3. [リモートの(X)アプリケーションをローカルのXサーバに表示する]にチェックを入れて、[OK]をクリックします。
    10TeraTerm_SSH転送設定01.png

  4. 一旦Tera Termからログアウトして、再度ログインし直します。

  5. DISPLAY変数が設定されているかコマンドで確認します。

    $ echo $DISPLAY
    
  6. 前の手順で何も返ってこなかった場合は、先ほどインストールしたxeyesを実行しても次のようなエラーになってしまいます。

    $ sudo xeyes
    Error: Can't open display:
    

    Red Hatインスタンス側にxauthと、x11のライブラリが不足しているようなので、必要なライブラリを次のコマンドでインストールしました。

    $ sudo yum –y install xorg-x11-xauth.x86_64 xorg-x11-server-utils.x86_64
    
  7. 一旦Tera Termでログアウトします。

    $ exit
    
  8. 再度Tera TermでRed Hatインスタンスにログインして、次のコマンドでDISPLAY変数を確認します。筆者の環境では自動でlocalhost:10.0が設定されていました。

    $ echo $DISPLAY
    localhost:10.0
    
  9. xeyesを実行してみます。無事Windows側にxeyesアプリケーションが表示されました。

    $ xeyes
    

    11xeyes.png

    [注意]次のようなX転送のエラーが出るときは、XmingがWindows側で起動していない可能性があります。起動していることを確認してください。
    12TTSSHエラー.png

レポートサーバーのインストーラをRed Hatに転送する

Tera Termを利用して、Windows側にあるElixir ReportのレポートサーバーのLinux OS用インストーラ(elixirreport87_linux64.bin)と、ライセンスファイル(*.license)をRed Hatインスタンスに転送します。

この手順については、以前の記事[レポートサーバーのインストーラをRed Hatに転送する]を参照してください。

ファイルの転送が完了したら、次の準備を行っておきます。

  1. インストールは現在ログインしているec2-userで行います。ec2-userのLANG環境変数が英語になっている場合は、日本語(ja_JP.UTF-8)に変更しておきます。

    $ echo $LANG
    en_US.UTF-8
    $ export LANG=ja_JP.UTF-8
    $ echo $LANG
    ja_JP.UTF-8
    
  2. 転送したインストーラに実行権限を与えます。

    $ chmod +x ./elixirreport87_linux64.bin
    $ ls -la
    -rwxr-xr-x. 1 ec2-user ec2-user 279506476 Sep 29 00:00  elixirreport87_linux64.bin
    

GUIインストーラの実行とエラーの発生

いよいよインストーラを実行してみます。しかし、エラーでインストーラが終了してしまいました。必要なライブラリがRed Hat側に不足しているようです。

$ ./elixirreport87_linux64.bin
Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
strings: '/lib/libc.so.6': No such file

Launching installer...

Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Stack Trace:
java.lang.NoClassDefFoundError: Could not initialize class java.awt.Toolkit
        at java.awt.Component.<clinit>(Component.java:593)
        at com.zerog.ia.installer.LifeCycleManager.g(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.h(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.a(DashoA8113)
        at com.zerog.ia.installer.Main.main(DashoA8113)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at com.zerog.lax.LAX.launch(DashoA8113)
        at com.zerog.lax.LAX.main(DashoA8113)
This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

必要なライブラリをインストールして実行時エラーを解消する

  1. 上記のエラーを最初から確認すると、まずlibc.so.6ファイルが見つからないという内容のエラーが出力されているので、次のコマンドでlibc.so.6ライブラリをインストールします。

    $ sudo yum -y install libc.so.6
    
  2. 次に発生しているInvocationTargetExceptionは、X11のライブラリが不足していることが原因のようです。必要なライブラリをインストールします。

    $ sudo yum –y install libXtst
    

起動したGUIインストーラの日本語が□に…フォントをインストールする

  1. 再度インストーラを実行してみます。

    $ ./elixirreport87_linux64.bin
    
  2. インストーラのGUIが起動しましたが、日本語が□表示になっています。Linux側に日本語フォントがインストールされていないことが原因でしょう。左下のキャンセルボタンをクリックしてインストールを中止します。
    13GUIトーフになる.png

    14終了02.png

  3. 日本語フォントをインストールします。VLゴシック、IPA明朝、IPAゴシックをインストールしました。

    $ sudo yum -y install vlgothic-fonts ipa-mincho-fonts ipa-gothic-fonts 
    

GUIインストールを実行する

  1. 再度インストーラを起動します。今度は日本語も表示されるようになりました。
    15GUI_01.png

  2. [次へ]で進み、[使用許諾契約の条項に同意する]にチェックして、進みます。
    16GUI_02.png

  3. [ライセンスキーファイルの登録]をクリックして、登録するライセンスファイルを選択します。
    17GUI_03.png

  4. インストールするモジュールにチェックが入っていることを確認して、次に進みます。この画面では、先ほどの手順で追加したライセンスでインストールできるモジュールだけが表示されます。18GUI_04.png

  5. レポートサーバーで使用するポート(今回はデフォルトの7001)、ログレベルを確認します。デフォルトのまま進みます。
    19GUI_ポート設定.png

  6. インストール先ディレクトリは、ec2-userにアクセス権のある場所を選択します。今回はユーザーディレクトリの下にします。
    20GUI_インストール先.png

    [注意]ec2-userに書き込み権限のない場所を指定すると、エラーが表示されます。

  7. 確認画面で内容を確認したら、[インストール]をクリックします。
    21GUI_確認.png

  8. 次の画面が表示されれば完了です。
    22GUI完了.png

ヘッドレスモードの設定とレポートサーバーの起動

インストールはX11転送でGUIを利用しましたが、今後、レポートサーバーの実行時にX Window Systemに接続できない場合は、Javaのヘッドレスモードを有効にする必要があります。

  1. レポートサーバーのインストール先/binディレクトリに移動します。筆者の環境では/home/ec2-user/ElixirReport87J/bin/になります。

    $ cd /home/ec2-user/ElixirReport87J/bin
    
  2. レポートサーバーの起動シェルスクリプトをバックアップした後、編集します。

    $ cp reportserver-start.sh reportserver-start.sh_org
    $ vi reportserver-start.sh
    

    ※5行目のheadless設定を追加して、保存します。

    #!/bin/sh
    JAVACMD="../jre/bin/java"
    
    $JAVACMD -mx512M 
            -Djava.awt.headless=true 
            -Duser.home=../license 
     (以下省略)
    
  3. レポートサーバーの起動シェルスクリプトを実行します。

    $ ./reportserver-start.sh &
    

    ※”&”を付加してバックグラウンド実行にします。

    【注意】起動ユーザーのLANG環境変数が英語の場合、レポートサーバーが英語ロケールで起動され、Webインターフェースのメニューなどが英語表示になってしまいます。日本語ロケールへ変更して起動してください。

  4. 起動に成功すると、コンソール上に次のようにCopyrightが表示されます。

    INFO  [main] com.elixirtech.ers2.Main - Copyright 2016 Elixir Technology Pte Ltd
    INFO  [Thread-19] com.elixirtech.ers2.EnsureServerStarted - Checking server     status
    
  5. Windows上のブラウザからレポートサーバーのWebインターフェースにログインしてみます。

    http://<パブリックIP>:7001
    

    23WebインターフェースURL.png

    【注意】ログイン画面が表示されないときは、以下のような原因が考えられます。
    ・レポートサーバーの起動に失敗している
    ・Red Hatインスタンスのセキュリティグループの設定で、ポート”7001”を追加していない

  6. ログイン画面が表示されたら、デフォルトで用意されている次の管理者ユーザーでログインします。

    ユーザー名: admin
    パスワード: sa
    
  7. [リポジトリ]以下のサンプルテンプレートを実行してみます。
    [samples]‐[demo]-[sales2]-[sales2.rml]を選択して、出力形式に”PDF”を選んで[OK]をクリックします。
    24レポート生成PDF選択.png

  8. PDF形式のレポートが生成できました。
    25フォントインストール後の結果.png

以上で完了です。

参考情報

Q1. No X11 DISPLAY variable was setエラーでインストールが終了する

X11などの設定を何も行っていない状態でGUIインストールを実行すると、X11のエラーでインストーラが終了してしまいます。この記事の[X11転送の設定をする]の項目を確認してみてください。

[参考情報]エラー出力の例
$ ./elixirreport87_linux64.bin
Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
strings: '/lib/libc.so.6': No such file

Launching installer...

Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Stack Trace:
java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
        at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:207)
        at java.awt.Window.<init>(Window.java:536)
        at java.awt.Frame.<init>(Frame.java:420)
        at java.awt.Frame.<init>(Frame.java:385)
        at javax.swing.JFrame.<init>(JFrame.java:189)
        at com.zerog.ia.installer.LifeCycleManager.g(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.h(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.a(DashoA8113)
        at com.zerog.ia.installer.Main.main(DashoA8113)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at com.zerog.lax.LAX.launch(DashoA8113)
        at com.zerog.lax.LAX.main(DashoA8113)
This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Q2. フォントをインストールしても、日本語が□のままになる

fc-listコマンドがRed Hatインスタンスで実行できるか確認してください。コマンドが入っていない場合は、フォントの管理に使用されるfontconfigパッケージを次のコマンドでインストールして、fc-listコマンドが使用できるようになるか確認した上で、再度インストールを試してみてください。

$ sudo yum –y install fontconfig

※この記事では、X11転送の確認用にxeyesアプリケーションをインストールしています。このインストール中、依存関係によりfontconfigが一緒にインストールされるため、日本語の表示には問題ありませんでした。xeyesをインストールしなかった場合は、別途fontconfigをインストールする必要があります。

Q3. Xアプリケーションを起動したが、Windows側にX転送エラーが表示される

次のようなX転送のエラーが出るときは、XmingがWindows側で起動していることを確認してください。
12TTSSHエラー.png

Q4. レポートサーバー起動時にWindows側にX転送エラーが表示され、レポートサーバーが起動できない

Q3と同様のエラーが表示され、レポートサーバーの起動中に次のようなjava.awt.AWTErrorが出力される場合は、ヘッドレスモードの設定が正しく行われていない可能性があります。この記事の[ヘッドレスモードの設定とレポートサーバーの起動]の項目を参考に、起動シェルスクリプトの編集を行ってみてください。

Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server using 'localhost:10.0' as the value of the DISPLAY variable.
        at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
        at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65)
(以下省略)

続きを読む

AmazonLinuxにClamAVをインストールしちゃったよ

Amazon LinuxにClamAVをインストール方法について記載しますー

環境

  • InstanceType:t2.medium
  • OS:Amazon Linux AMI release 2015.03

ClamAVインストール

$ sudo yum -y install clamav
$ sudo yum -y install clamav-update

パターンファイル更新

設定ファイルの編集しますー

$ sudo vim /etc/freshclam.conf
### Exampleをコメント化
# Comment or remove the line below.
Example
↓
# Comment or remove the line below.
# Example

### コメント外す
#UpdateLogFile /var/log/freshclam.log
↓
UpdateLogFile /var/log/freshclam.log

### コメントアウトを外す
#LogTime yes
↓
LogTime yes

パターンファイル自動更新

5分単位で自動更新されるように設定します。

$ sudo vim /etc/cron.d/clamav-update
### 時間間隔を変更
0  */3 * * * root /usr/share/clamav/freshclam-sleep
↓
0  */5 * * * root /usr/share/clamav/freshclam-sleep

自動更新の有効化

自動更新の有効化を実施します。

$ sudo vim /etc/sysconfig/freshclam
### コメント化
FRESHCLAM_DELAY=disabled-warn  # REMOVE ME#FRESHCLAM_DELAY=disabled-warn  # REMOVE ME

バージョン確認

$ sigtool --version
ClamAV 0.98.7/20394/Thu Apr 30 01:37:08 2015

パターンファイルのダウンロード先変更

パターンファイルのダウンロード先を日本とアメリカに設定します。
 ※ダウンロードが集中すると失敗する可能性があるため

### デフォルトをコメントアウト
#DatabaseMirror database.clamav.net

### 追加
DatabaseMirror db.jp.clamav.net
DatabaseMirror db.us.clamav.net

パターンファイルの更新

手動でパターンファイルの更新をします。

$ sudo freshclam

スキャンテスト

アンチウィルスのテストファイルとして利用されるeicarを作成します。
テキストファイルにテストコードを埋め込みます。

$ vim ~/eicar.com
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

準備できたので、スキャンしますー

$ sudo clamscan -r -i ~

----------- SCAN SUMMARY -----------
Known viruses: 6260545
Engine version: 0.98.7
Scanned directories: 1
Scanned files: 7
Infected files: 1
Data scanned: 0.02 MB
Data read: 0.01 MB (ratio 2.00:1)
Time: 11.612 sec (0 m 11 s)

スキャン結果に「Infected files: 1」と検出されましたね。
ということで、以上でClamAVのインストール方法でしたーヽ(*゚д゚)ノ

補足

ClamAVのバージョンが低いと以下のように怒られます。
最新版にアップデートするか、もしくは、2017.3のAmazon Linux AMIを使用することで、ClamAVのパッケージが最新化できます。
Amazon Linux AMI 2017.3 Packages

$ sudo freshclam
ClamAV update process started at Sun Apr 16 11:05:13 2017
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.98.7 Recommended version: 0.99.2

続きを読む

AWSの無料SSLを使ってmastodonインスタンスを立てる手順

サーバー周りをAWSで固めてmastodonインスタンス( https://mastodon.kumano-ryo.tech )を立てたので、その手順と資料をまとめました。

SSLは無料で使えますが、サーバーの使用量とかは普通にかかります。とはいえ、お1人〜10人鯖ぐらいならEC2のmicroでも動かせるので、そんなにお金はかからなそう。
立て終わった後に書いたので、記憶違いなどあるかもしれません。コメント・編集リクエストしてください :pray:

なぜAWSなのか

人数が少ないときは安く済ませられるし、リソースが足りなくなってもお金を突っ込めばスケールできるから(要出典)。

必要なもの

  • ドメイン
  • メールを配信する手段
  • AWSのアカウント
  • docker・Web・Linux・AWSなどについての基本的な知識

構成

  • mastodonの公式レポジトリに出てくるdocker-compose.ymlを使う
  • 無料SSLを使うためにRoute53とEastic Load Balancerを使う
  • Redisを外に出すためにElastic Cacheを使う(Optional)
  • Postgresを外に出すためにRDSを使う(Optional)
  • メール送信サービスとしてはSendGridを使った
    • 本筋とは関係ないので今回は省略
    • SMTPが使えればなんでもいい

手順

  1. 設定ファイルを埋める
  2. SSL接続を可能にする
  3. HTTPでのアクセスを禁止する
  4. 画像や動画などをS3に保存するようにする
  5. RedisとPostgresを外に出す(Optional)

設定ファイルを埋める

まずはEC2のインスタンスを立てましょう。OSはubuntu、インスタンスタイプはmediumでいいと思います。microにすると、CPUだかメモリが足りなくてAssetsのコンパイルでコケます。
しかし、サーバー自体はmicroでもそこそこ快適に動くので、デプロイが終わったらmicroにしましょう。
Security Groupの設定については、とりあえず80番と22番が任意の場所から接続できるようになってれば良いです。

そしてEC2上で、mastodon本体をcloneしてきます:

$ git clone https://github.com/tootsuite/mastodon.git

公式のREADMEを参考に、mastodonの設定をします。この時、LOCAL_HTTPSについては、falseにしてください

sudo docker-compose up まで行けたら、EC2インスタンスの80番ポートを3000番ポートにリダイレクトします:

$ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000

これにて http://yourdomain.com/から、mastodonインスタンスにアクセスできるようになりました!!!!

SSL接続を可能にする

とはいえhttpでログインするのは怖いので、SSLの設定をしましょう。
Elastic Load Balancerの無料SSLを使います。

ELBの作成

Elastic Load Balancerを作ります。
EC2のダッシュボード > ロードバランサー > ロードバランサーの作成から、ロードバランサーを作成します:

  • リスナー

    • HTTPSとHTTPの両方を選んでください
  • 証明書の選択

  • セキュリティグループの設定

    • 任意のIPアドレスからHTTPSが受けられるようなセキュリティグループを作成して設定する
  • ターゲットグループ

    • HTTPだけを追加する
  • ヘルスチェック

    • HTTPで/aboutにする
  • ターゲットの登録

    • 先ほど作成したEC2のインスタンスを選択する

      • ポートは80番を選択する

※作成されたELBのarnはメモっておきましょう。

ELBとインスタンスの接続

EC2ダッシュボード > ターゲットグループから、先ほど作成したターゲットグループを選び、「ターゲット」に登録してあるEC2インスタンスの状態がhealthyであることを確認する。

もしunhealthyであれば、ドキュメント等を参考にして解決しましょう。

ドメインとRoute 53を連携する

ドメインをELBで使えるようにします。
Route 53 > HostedZones > Create Hosted ZonesからHostedZonesを作成します。
HostedZoneを作成したら、ドメインのNSをHostedZonesのNSの値で置き換えます(参考: お名前.comのドメインをAWSで使用する4つの方法
)。
そして、Create Record Setから、Type ARecord Setを作成します。この時、ALIASをYesにして、Alias Targetを先ほどのELBのarnに設定します。

Congrats!

ここまでの手順で、https://yourdomain.comから自分のmastodonインスタンスにアクセスできるようになったはずです!やったね!

もし繋がらなかった場合は、ELBのセキュリティグループやターゲットグループの設定を見直してみてください。

最終的な状態では、

  • ELBにはHTTPSかHTTPでアクセスできる

    • ELBのリスナーに80番ポートと443番ポートが設定されている
  • ELBに入ってきたHTTPSまたはHTTPのアクセスは、EC2の80番ポートに転送される
    • ターゲットグループの「ターゲット」のEC2インスタンスの「ポート」の欄が80である
  • EC2のインスタンスは80番ポートでアクセスを受ける
  • 以上を妨げないようなセキュリティグループの設定である
    • ELBとEC2やその他のAWSのサービスが、すべて別のセキュリティグループを持つ

が満たされているはずです。

HTTPでのアクセスを禁止する

前節まででSSLでのアクセスが実現されましたが、依然HTTPでのアクセスも可能です。
EC2インスタンスへのアクセスがELB経由で行われるようにし、また、HTTPでアクセスされたときはHTTPSにリダイレクトするようにしましょう。

まず、EC2インスタンスのセキュリティグループのインバウンドルールについて、HTTPの行の「送信元」の欄に、ELBのセキュリティグループのID(sg-********)を入力して保存します。
これによって、ELBからのみEC2インスタンスにHTTPSでアクセスできるようになりました。

次に、EC2インスタンスの中で、以下のような設定ファイルでnginxを起動します:

server {
  listen 80;

  location / {
    if ($http_x_forwarded_proto != 'https') {
      rewrite ^ https://$host$request_uri? permanent;
    }
  }
}

これにより、HTTPアクセスをHTTPS付きのURLにリダイレクトすることができます。

画像や動画などをS3に保存するようにする

この状態だと、アップロードされた画像・動画やユーザーのアイコン画像は、すべてdockerコンテナの中に保存されます。
そのため、sudo docker-compose downするたびに、画像と動画が消えてしまうし、アイコン画像もなくなってしまいます。
これではうまくないので、メディアファイルのストレージをS3に設定しましょう。

まず、S3のバケットを作成します。バケットの名前とリージョンは覚えておきましょう。
次に、AWSのIAMコンソールからユーザーを作成して、アクセスキーを取得します。このとき、既存のポリシーを直接アタッチから、** AmazonS3FullAccess**を追加しておきましょう。

そして、.env.production.sampleのコメントアウトしてある設定を利用して、以下のように設定を書き加えます:

S3_ENABLED=true
S3_BUCKET=${your-bucket-name}
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
S3_REGION=${your-bucket-region}
S3_PROTOCOL=https
S3_ENDPOINT=https://s3-${your-bucket-region}.amazonaws.com

これで、画像・動画がS3にアップロードされるようになりました。

RedisとPostgresを外に出す(Optional)

前節までで、所望のmastodonインスタンスが手に入ったと思います。
この構成では、中央のEC2インスタンスの中で、Rails・Redis・Postgres・Sidekiq・nodejsの5つのDockerコンテナが動いていることになり、負荷が集中しています。

ところで、AWSはRedis専用のインスンタンスを提供していますし(ElasticCache)、postgres専用のインスタンス(RDS)も提供しています。
実際どのぐらい効果があるのかわかりませんが、これらのコンテナを中央のEC2から切り離してみましょう。

この辺からは適当です。

インスタンスを立てる

PostgresとRedisのインスタンスを立てます。

このとき、Postgresの設定は、mastodonのレポジトリ内の設定ファイル(.env.production)のDB_*変数に合わせて適当に変えましょう。
DB_HOSTの値は後で取得します。Redisも同様です。

次に、PostgresとRedisのセキュリティグループを編集して、EC2のインスタンスからアクセスできるように設定します。
「HTTPでのアクセスを禁止する」の節と同じ要領でできます。

Postgresのインスタンスタイプについてですが、無料枠に収まるようにmicroにしましたが、ちゃんと動いてるようです。Redisのインスタンスは、無料枠が無いようなので、適当にmicroにしました。今のところ大丈夫そうです。

PostgresとRedisのEndpointをメモっておきます

.env.productionを編集

.env.productionREDIS_HOSTDB_HOSTを、先程メモったEndpointに書き換えます。

docker-compose.ymlを編集

mastodonのdocker-compose.ymlを修正して、dbコンテナとredisコンテナの部分をコメントアウトしましょう。また、他のコンテナのdepend_onの部分もそれに合わせてコメントアウトします。

再起動

$ sudo docker-compose build
$ sudo docker-compose up -d

にてmastodonを再起動します。
これによって、RedisとPostgresがAWSのサービスを利用する形で切り出されたことになります。

その他

続きを読む

Let’s Encrypt を使った SSL 設定 for Amazon Linux

SSLのサイトを作ってみたくなった

ちょっとした無償サービスを作るにあたって、Let’s Encrypt を使った SSL を試しに使ってみたくてやってみました。
環境は、Amazon Linux。

手順

$ wget https://dl.eff.org/certbot-auto
$ chmod a+x certbot-auto
$ ./certbot-auto
(中略)
FATAL: Amazon Linux support is very experimental at present...
if you would like to work on improving it, please ensure you have backups
and then run this script again with the --debug flag!
Alternatively, you can install OS dependencies yourself and run this script
again with --no-bootstrap.

Amazon Linux は、–debug をつけろというのでつけました。

$ ./certbot-auto --debug
(中略)
The following errors were reported by the server:

Domain: XXX.XXX.jp
Type:   connection
Detail: Failed to connect to XXX.XXX.XXX.XXX:443 for tls-sni-01 challenge
(後略)

よくよく調べると以下に該当。

https://letsencrypt.jp/usage/dvsni-challenge-error.html

セキュリティグループに、443を指定するのを忘れていたので指定して、コンソソールからインスタンス再起動。

$ ./certbot-auto renew

インストールが終わったら、httpd を再起動。

$ sudo service httpd graceful

https でアクセスして完了を確認。

参考

https://letsencrypt.jp/
http://qiita.com/takahiko/items/a08895550727b95b6c36
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/SSL-on-an-instance.html#ssl_enable

続きを読む