EC2 Instance にApache Kafka をインストール

[ 前提 ]
EC2 から、適当にInstance を立ち上げて、Internet に接続できる環境を構築しておく。
今回利用したAMI は、以下の通り。
Amazon Linux AMI 2017.03.1 (HVM), SSD Volume Type - ami-a4c7edb2


[ 本題 ]
Instance にSSH で接続する。 上記のAMI には、Java7 しかInstall されておらず、現状最新版のApache Kafka はJava8 が無いと、以下のException が発生して、動作できないようなので、Java8 をInstall する。

java.lang.UnsupportedClassVersionError
Unsupported major.minor version 52.0

Java は以下のOpenSDK からリリースされているものを利用する。
java-1.8.0-openjdk-devel.x86_64
コマンドは以下の通り。

sudo yum install java-1.8.0-openjdk-devel.x86_64

（余談）devel というのが、Oracle のJava のJDK に当たるもののようで、java-1.8.0-openjdk.x86_64 はJRE に当たるものだそうです。

Install が終わったら、Java7 からJava8 への切り替え作業をする。
コマンドは以下の通り。

sudo alternatives --config java

一応、"java -version" で、Java8 が利用されているか、version を確認しておく。
ここで、やっとApache Kafka をInstance にダウンロードし、解凍する。ついでにディレクトリも移動しておく。

wget http://ftp.jaist.ac.jp/pub/apache/kafka/0.11.0.0/kafka_2.12-0.11.0.0.tgz

tar -zxvf kafka_2.12-0.11.0.0.tgz cd kafka_2.12-0.11.0.0
とりあえずここまできたら、zookeeper をデーモン起動させる。

bin/zookeeper-server-start.sh -daemon config/zookeeper.properties

最後にKafka を起動させる。

bin/kafka-server-start.sh config/server.properties

ここで以下のException が発生する。原因は、/etc/hosts ファイルに、ip-<AWSのPrivateIP> を解決するためのIP Address の記載が無い。

ava.net.UnknownHostException: ip-<AWSのPrivateIP>: ip-<AWSのPrivateIP>: Name or service not known
        at java.net.InetAddress.getLocalHost(InetAddress.java:1505)
        at kafka.server.KafkaHealthcheck.$anonfun$register$1(KafkaHealthcheck.scala:60)
        at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:234)
        at scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:59)
        at scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:52)
        at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
        at scala.collection.TraversableLike.map(TraversableLike.scala:234)
        at scala.collection.TraversableLike.map$(TraversableLike.scala:227)
        at scala.collection.AbstractTraversable.map(Traversable.scala:104)
        at kafka.server.KafkaHealthcheck.register(KafkaHealthcheck.scala:58)
        at kafka.server.KafkaHealthcheck.startup(KafkaHealthcheck.scala:50)
        at kafka.server.KafkaServer.startup(KafkaServer.scala:280)
        at kafka.server.KafkaServerStartable.startup(KafkaServerStartable.scala:38)
        at kafka.Kafka$.main(Kafka.scala:65)
        at kafka.Kafka.main(Kafka.scala)

そのため、以下の１行をhosts ファイルに追加する。（ip-から始まる方は、${hostname -s} の結果）

<AWSのPrivateIP> ip-<AWSのPrivateIP>

無事、Kafka が起動できたら、topic を作成してみる。

bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic my-topic

EC2インスタンス上のDocker上でインスタンスを起動して失敗する場合

インスタンスの起動失敗時、EC2インスタンスにSSH でログインして、以下のパスのログを確認する。

vi /var/log/ecs/ecs-agent.log-yyyy-MM-dd-xx

失敗している原因が不明な場合、インスタンス起動時の作業ディレクトリ（WorkingDirectory）の指定をしていない可能性もある。
この設定は、タスク定義を作成する時に指定する。
例えば、Dockerfile で以下のようにJar ファイルをローカルからDocker のインスタンスにコピーした場合、そのコピー先を作業ディレクトリに指定して見るとうまくいくかも。

COPY test.jar /var/

この場合、作業ディレクトリを"/var"と設定しておく。

ECSで管理しているContainerからRDS（Aurora）に接続

ECSで管理しているContainerにWebApplicationをデプロイ後、RDS(Aurora)に接続するまで。
まず、RDSのページから、Aurora インスタンスを起動する。
インスタンスが起動したら、テーブル作成のため、mysql client を利用してログインする。
ローカルPC -> Aurora だと、色々面倒なので、ECS インスタンスにmysql client をinstall して、そこからログインする。
mysql client のinstall は、以下の通り。

sudo yum install mysql

Aurora に設定したDB ユーザ、パスワードを入力して、Aurora にログインする。
ログインコマンドは以下の通り。

mysql -u username -p -P 3306 -h ecs-cluster-db.cluster-xxxxxxxx.us-east-1.rds.amazonaws.com

ログインしたら、適当にテーブルを作成する。
また、WebbApplication からアクセスするログインアカウントが上記と異なる場合、ユーザの作成と権限付与をする必要がある。

コマンドは以下の通り。

CREATE USER 'user_name' IDENTIFIED BY 'password';
GRANT ALL ON db_name.* to 'user_name'@'%' identified by 'password'; <- ALL をSELECT にすればRead only user ができる。

とりあえずこれでRDS 側の設定は終わったので、WebApplication からAurora にアクセスしてみる。
ここでは、jdbc ドライバを利用したアクセスを試みる。 コマンドは以下の通り。

jdbc:mysql://ecs-cluster-db.cluster-xxxxxxxx.us-east-1.rds.amazonaws.com:3306/db_name

これでアクセスできない場合、ネットワークの問題があるはず。
一番簡単な解析方法はtcpdump でパケットを眺める。
Container インスタンスに、ssh でログインする。
ログインしたら、tcpdump をインストール。
コマンドは以下の通り。

sudo yum install tcpdump

インストールしたら、ifconfig でeth0 のNIC を確認し、IP を控えておく。
実際にtcpdump を取得する。
コマンドは以下の通り。

sudo tcpdump -s0 -i eth0 -w packet.cap

パケットを取得したら、packet.cap ファイルが実行したフォルダに置かれるので、ローカルPC に持ってきてWireshark などで解析をする。
ssh でcontainer インスタンスに入っているので、ローカルPC にファイルを持ってくるには、SCP コマンドを利用するか、S3 にファイルを一旦アップロードしてからダウンロードするやり方が簡単。
Tera term を利用しているなら、File > SSH SCP でFrom に、"./packet.cap"と入力してReceive ボタンを押せば、ローカルPC にダウンロードできる。
S3 に一旦、アップロードする場合のコマンドは、以下の通り。

aws s3 cp ./packet.cap s3://bucket-name

Docker でMySQL コンテナを立ち上げた時にやったこと

// MySQL のコンテナを起動する

docker@default:~$ docker run --name mysqld -e MYSQL_DATABASE=mydb -e MYSQL_USER=user -e MYSQL_PASSWORD=password -e MYSQL_ROOT_PASSWORD=admin -d mysql

// MySQL にLogin

docker@default:~$ docker run --link mysqld:mysql -it --rm mysql bash

// MySQL にLogin 後、環境変数をチェック

root@95825593d169:/# env

// DB にlogin しようとして、error

root@95825593d169:/# mysql -u root -p mydb
Enter password:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

// 上記エラー時、mysqld.sock が'/var/run/mysqld/mysqld.sock'にあるかどうかを確認

root@95825593d169:/# ls -al /var/run/mysqld/

// mysqld.sock がない場合、以下のコマンドで作成

root@95825593d169:/# touch /var/run/mysqld/mysqld.sock

// ディレクトリの所有者変更（不要かも）

root@95825593d169:/# chown mysqld:mysql /var/run/mysqld

// MySQL を再起動

root@95825593d169:/# /etc/init.d/mysql restart

// ログフォルダを設定していないと、以下のWarning

No directory, logging in with HOME=/
2017-06-22T05:59:53.076720Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2017-06-22T05:59:54.729911Z 0 [Warning] InnoDB: New log files created, LSN=45790
2017-06-22T05:59:54.991579Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
2017-06-22T05:59:55.300196Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 03cdccff-5710-11e7-b6a7-0242ac110005.
2017-06-22T05:59:55.314362Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2017-06-22T05:59:55.337119Z 1 [Warning] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option.
2017-06-22T05:59:56.130826Z 1 [Warning] 'user' entry 'root@localhost' ignored in --skip-name-resolve mode.
2017-06-22T05:59:56.130938Z 1 [Warning] 'user' entry 'mysql.sys@localhost' ignored in --skip-name-resolve mode.
2017-06-22T05:59:56.130978Z 1 [Warning] 'db' entry 'sys mysql.sys@localhost' ignored in --skip-name-resolve mode.
2017-06-22T05:59:56.131009Z 1 [Warning] 'proxies_priv' entry '@ root@localhost' ignored in --skip-name-resolve mode.
2017-06-22T05:59:56.131069Z 1 [Warning] 'tables_priv' entry 'sys_config mysql.sys@localhost' ignored in --skip-name-resolve mode.

// 最初に作ったDB, User が消えていたので、ルートでログイン

root@95825593d169:/# mysql -u root -p

// 消えたユーザを作成する

CREATE USER 'user' IDENTIFIED BY 'password';
GRANT ALL ON mydb.* TO 'user'@'%' IDENTIFIED BY 'password';

Docker QuickTerminal をWindows7 にインストール後、起動したらエラー

以下のようなエラーが発生

Looks like something went wrong in step ´Checking if machine default exists´

コントロールパネル＞プログラム＞プログラムと機能 で、Oracle VM VirtualBox を修復したらエラーが解消されました。 その際、コントロールパネル＞ネットワークとインターネット＞ネットワーク接続 を確認した所、VirtualBox Host-Only Network が１つ追加されていました。
ちなみに、以下の構成で、#3 だけが有効になっている状態で起動できました。
＃ローカルエリア接続は有効です。

VirtualBox Host-Only Network
VirtualBox Host-Only Network #2
VirtualBox Host-Only Network #3

MySQL Workbench での設定とTips

外部参照の無効/有効
SET FOREIGN_KEY_CHECKS = 0/1;

Read only 権限のユーザ

mysql> GRANT SELECT ON *.* TO 'username'@'host_or_wildcard' IDENTIFIED BY 'password';
mysql> FLUSH PRIVILEGES;

MySQL のユーザ一覧を参照

mysql> select host, user from mysql.user;

vagrantでsshした後、sudo cd でcommand not found がでる場合

nginx のエラーログを参照したかったので、vagrant でCentOS にssh でアクセス後に、以下のコマンドを実行したら、command not found が出た。

sudo cd /var/log/nginx
sudo: cd: command not found

cd はbuild-in コマンドですが、sudo はプログラムに適用します。 つまり、先ほどのコマンドはcd がプログラムではないため、実行できません。
そのため、以下のコマンドで、ユーザをsuper user へ昇格させた後に、cd コマンドを実行すると、やりたいことができます。

sudo -i

参考：https://askubuntu.com/questions/291666/why-doesnt-sudo-cd-var-named-work