AWS-EC2へのHadoop+Hiveインストールではまったところ

いろいろハマったけれど、ちゃんと公式ドキュメントを読んでその通りにインストールするのが大事。

Hadoop サンプル実行失敗

下記のようなメッセージが表示され一向に処理が進まない
ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 0

/etc/hosts の 127.0.0.1 の行にec2のホスト名を追加することで解決した

Hive関連

基本はドキュメント通りに。
http://www.cloudera.com/content/cloudera/en/documentation/cdh5/v5-0-0/CDH5-Installation-Guide/cdh5ig_hive_installation.html

metastoreの設定には注意

デフォルトのderbyではうまく動作しなかったため、metastoreにはMySQLを使用した。
またmetastoreのスキーマはドキュメントでは hive-schema-0.12.0.mysql.sql だが hive-schema-0.13.0.mysql.sql を使用する。(0.12.0だと動かなかった)

SOURCE /usr/lib/hive/scripts/metastore/upgrade/mysql/hive-schema-0.13.0.mysql.sql;

Hive-JSON-Serdeを使う場合の注意

rcongiu/Hive-JSON-Serde を使うと最新のHiveに対応していなかった。
最新版に対応してくれている sheetaldolas/Hive-JSON-Serde の json-serde-1.1.9.8 を使うことで解決した。

https://github.com/sheetaldolas/Hive-JSON-Serde

DDL実行時エラーへの対処

create tableを実行すると下記のようなエラーが発生した。
Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. MetaException(message:Got exception: org.apache.hadoop.security.AccessControlException Permission denied: user=hive, access=WRITE, inode="/user":hdfs:supergroup:drwxr-xr-x

下記コマンドで /user の書き込みを可能にして対処
sudo su hdfs -c 'hadoop fs -chmod 777 /user'

僕を苦しめたDockerのバグ２つ

Postfixが動かない！(setgidが効かない)

Docker1.2では修正済みですが、Docker1.1ではsetgidが効きません。
Postfixが何故かうまく動かず、調べてみるとpostfixのコマンドであるpostdropとpostqueueはsetgidされていなければならいないのがされていませんでした。
手動でchmod g+s postqueueとかしてみても、付かない！
Dockerのバグでした。幸いDocker1.2は既にリリースされていたので、Dockerをアップデートするだけで解決しました。

docker pullするとdockerデーモンごとクラッシュする！

当然ですがdockerデーモンがクラッシュすると起動しているコンテナは全滅します。
恐ろしいですね。。。
修正のpullリクエストがマージ済み(2014/10/01現在)のようですが、自分でDockerをビルドするかDocker1.3(Docker.1.2.1?)を待たなければなりません。
https://github.com/docker/docker/pull/7864

QuincyKitでiOSアプリのクラッシュレポートを取得したときに困ったメモ

iOSアプリでクラッシュレポートを取得するためにQuincyKitというライブラリを使ってみた。
https://github.com/TheRealKerni/QuincyKit

わかりにくかったところをメモしておく。

クラッシュレポートが送信されるタイミング

クラッシュレポートはクラッシュした次の起動のタイミングで送信される仕様になっている。クラッシュした時ではネットワークが使えないかもしれないので、ローカルにレポートを保存しておき、次回起動時にレポートを送信するということなのだろう。

symbolicateとは何か

送信されたレポートのスタックトレースには最初は標準ライブラリのシンボル名しか表示されない。
そこで送信されたレポートには手動でアプリ固有のシンボル名を表示できるようにする処理を行う。これをsymbolicateと呼んでいる。

symbolicateで起きた問題

symbolicateするにはリポジトリのserver/localに配置されているスクリプトを使う。
symbolicate.phpはサーバーのレポートをsymbolicateして更新するスクリプトでsymbolicatecrash.plはコマンドラインで指定したクラッシュレポートをsymbolicateするスクリプトだ。

僕の環境ではこれを使うにあたって3つ問題が発生した。

１．原因不明だがfile_get_contents()がWarningを出して止まってしまう
symbolicate.phpのfile_get_contents()を使っている場所をcurlを使うように修正して対応した。

２．MoreUtils.pmがなくてsymbolicatecrash.plが動かない
標準では入っていないパッケージだったようなので下記の通りインストールした。
sudo cpan install List::MoreUtils

３．symbolicateを実行してもシンボル名が表示されない
これは下記のサイトを参考にXCodeのBuild Settingsを修正したところ直った。
http://support.hockeyapp.net/kb/client-integration-ios-mac-os-x/how-to-solve-symbolication-problems
僕の場合はStrip Debug Symbols During CopyをYESに変更する必要があった。

Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader

Apacheのcommons-daemonを使ってサーバープログラムをデーモン化しようとしていたらjsvcの起動でエラーに遭遇。

「Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader」

調べても解決してるっぽい記事がでてこない。
原因はjsvcの-cpオプションに指定するjarを相対パスでしていたことだった。
jsvcは-userを指定して実行ユーザーを変えたりできるのでJVM実行時のカレントディレクトリは別の場所になっているようだ。
-cpに指定するパスはすべて絶対パスにすることで起動に成功した。

dockerコンテナを別のコマンドで立ち上げる方法はver.1.1から？

docker1.1からコンテナを別のコマンドで立ち上げることができるようになるかも。
https://github.com/dotcloud/docker/issues/1228#issuecomment-45546178

dockerコンテナは停止してもstartコマンドで再度立ち上げることができる。
しかし、現在(v1.0)はstartコマンドはdocker runの時に実行したコマンドでしか起動できない。
もし障害が起きてコンテナが停止して、更にはコンテナがstartで起動しなくなっていたら、原因解析やデータを救出したりすることが難しくなる。

現時点でできる対策としては
・必ずsshdを同時に起動しておく
・volumeや--volumes-fromなどを使ってデータを隔離しておく
といったところ。

最悪これらの設定をしていなかった場合は停止したコンテナを一度commitしてイメージを作成してから再度docker runすることでコンテナが停止したタイミングのデータにアクセスできる。
まぁこれができれば問題ないじゃんって話もあるけど同じコンテナですぐに繋げられる方が楽だよね。

nsinitというのを使って直接dockerの空間にアタッチする方法があるので、それを使えばデータ救出や障害解析ができそう。

とはいえ、実験とかの時に無駄にコンテナを量産しなくてすむし、ぜひぜひ別コマンドでの起動に対応して欲しい。

dockerのEXPOSEはdocker run -Pもしくはdocker run --linkで意味を持つ

dockerのハマりどころとしてEXPOSEが理解できないというのがあると思う。
EXPOSEは書いただけで何か動作が変わるといったものではなく、他の機能から参照されて意味を持つ。
dockerに入門したてだとEXPOSEを指定しないとコンテナにネットワーク接続できないと勘違いしてしまったりするがそんなことはない。
EXPOSEしなくてもdocker run -pオプションでポートを外部公開できるし、dockerネットワークのIPを使ってコンテナ間もしくはホスト・コンテナ間で通信可能だ。

僕の知っている限り、EXPOSEの指定はdocker run -PもしくはDockerのlink機能を使ってコンテナ間連携をするときだけ意味を持つ。

doker run -PはEXPOSEしているすべてのポートをpublishする。
マッピングの指定をしないのでdockerが勝手にホストのポートを割り当てる。

docker run --link は連携対象のコンテナを指定するとEXPOSEしているポートに接続するための環境変数を付けてコンテナを起動する。

linkのドキュメント：
https://docs.docker.com/userguide/dockerlinks/


(この記事の情報は docker ver0.11.1 にて確認しています)

dockerは再起動しても変更が消えることはない

dockerに関する記事で「dockerは再起動すると変更が元に戻る」っていう書き方をしている人が多いけど誤解なのでこういう書き方はやめていただきたい。
docker run の意味は新しいコンテナでプロセスを起動するということであって再起動ではない。
そしてdockerには再起動という概念は別にあって、それは停止したコンテナに対するdocker startだ。
docker restartというコマンドもある。この再起動の場合にはコンテナ上の変更が元に戻るということはない。