docker参考サイト

現在dockerに関して勉強中だが、初めてdockerを触ってから今までで、dockerの理解に役立ったサイトをメモ

・本家dockerサイト(英語)
https://docs.docker.com/

・Docker ドキュメント日本語化プロジェクト
本家dockerのドキュメントを日本語訳しているサイト。
dockerの仕様に関しては基本的にここをみればわかる。
http://docs.docker.jp/

・FAworks – ブログ
外国の方がdockerの仕組みについてわかりやすく投稿されたものを、日本語訳したもの。
dockerのレイヤに関して図が記載されているので分かりやすい。
https://fa-works.com/blog/visualizing-docker-containers-and-images
 
・Qiita – dockerコンテナ間の連携について
dockerコンテナ間で連携させるにはどうしたらいいか、実例を交えて記載されていてとても参考になる。
ただ、あまり難しいことは書いてないので、どちらかというと初学者向けな印象。
http://qiita.com/taka4sato/items/b1bf33941a1ec8b69fd2

docker コンテナ起動時のシェル実行について2

引き続きdockerの話。

前回の投稿でコンテナ起動時にシェルを実行する方法について書いた。
dokcer コンテナ起動時のシェル実行について

前回の投稿に記載している内容で、コンテナ起動時にシェルを実行できるようになったが、
シェルの内容によっては、シェルの処理が終了したらコンテナがstopするので注意が必要。

例えば、下記内容のシェルをコンテナ起動時に実行するとする。

この場合、コンテナが起動してdocker_test.shのプロセスが立ち上がっても、すぐに終了する。
なぜなら、dockerではコンテナ起動時に指定したプロセスが終了すると、コンテナは停止してしまうから。

もし、コンテナ起動時にシェルを実行して、そのあともコンテナを起動し続けたい場合は、
下記のようにシェルを記述する。

最後に/bin/bashを起動する事により、echoコマンドが実行し終わっても
コンテナが停止しないようにしている。

これでシェル実行後にコンテナを停止しないようにできる。
ただ、この方法だと「docker stop」コマンドが実行された際にTERMシグナルを受け取る事が
できかったりするみたいなので、改善が必要。
参考URL:めもめも

改善の詳しい内容はまだ勉強中…。上記URL参考。

docker コンテナ起動時のシェル実行について

個人的な事でdockerを使用してコンテナ起動時に、コンテナ内のシェルを実行させようとした時にはまったのでメモ。

まず、下記のようなDockerfileを用意。

ADDでtest.shを/tmpフォルダに配置して、実行権限を付与。
CMDでコンテナ起動時にtest.shを実行。

これでコンテナ起動時にtest.shが実行されるはずだが、実行されなかった。
色々調べた結果、runコマンドでコンテナを実行する際に、コマンドを指定していたのが原因だった…

runコマンド実行時にコマンドを指定するとDockerfileの中で指定した、CMDは上書きされる為に/bin/bashのみが実行されていたのが原因。

/bin/bashを省いてコンテナを起動すると、ちゃんとシェルが実行された。

結構時間をとってしまった。dockerをもっと勉強しないと…

参考URL
http://www.ajisaba.net/

Raspberry Pi 2に使用するMicroSDのフォーマットについて

Raspberry Pi 2 Model BにOS「Raspbian」をインストールしようと思ってMicorSDをセットして電源を入れたところ、「Waiting for SD card (settings partition)」と表示されたまま次に進まなかった。

「・・・(settings partition)」となっていたので、パーティションの設定を行っているのかと思い、30分ほど待ってみたけど全然終わりそうにない・・・。
いろいろ調べてみたところ下記リンクにたどり着き、原因がMicroSDのフォーマットにあることがわかった。
teratail

MicroSDカードをWindowsの標準機能でフォーマットしたけれども、Windowsの標準ではexFat形式でフォーマットされてしまうらしく、「Raspbian」をインストールする際に使用する「NOOBS」が対応しているのはFAT16・FAT32のみの為、上手く動作しないことが原因だったみたい。

再度、公式にフォーマットする際に推奨されている「SD Formatter 4.0」を使用して、MicroSDカードをフォーマットし直してOS「Raspbian」のインストールを行ったところ、上記メッセージが表示されることなくインストール画面に進むことができた。

Apache Solrで空間検索を利用する際のスキーマの定義

Apache Solrで空間検索を利用する際は、schema.xmlに経度・緯度のフィールドを定義するだけではなく、ダイナミックフィールドも合わせて定義する必要があるので注意。

ダイナミックフィールドを定義していない場合、Apache Solrの起動時にエラーとなってしまう。

Apache Solr 新規コアの設定方法

Apache Solrではコアと呼ばれる単位で検索対象のデータ構造を定義するスキーマ等を保持する。
なのでApache Solrの勉強に新規にコアを作成・スキーマを定義して、Apache Solrを起動しようとしたらうまく動かなくて、つまずいたので記録。

構築環境は下記。

  • CentOS 6.7
  • Apache Solr-4.5.1
  • OpenJDK-1.7.0

まず、Apache Solrをインストールするとサンプルディレクトリが付いていて、その中にApache Solrを動かすのに必要なファイル等が一通り入っているので、それをコピーして流用する。(一から作るのは慣れないうちは大変…)

Apache Solrには「Solrホームディレクトリ」と呼ばれる、Solrサーバ稼働中にさまざまな場面でファイルを参照する起点となるディレクトリがある。
その中にコアに関する設定ファイルがあるのでそれを修正する。

これでコアの設定は終わったので、検索するデータに関する定義をschema.xmlに記載して、いざApache Solrを起動するとエラーとなり起動できなかった。

「textが定義されていない」という内容のエラーメッセージなので、schema.xmlにtextという定義に関して何か設定ミスがあるのかと思って調べてみたけれども、「text」という内容はどこにも記載していなかった。
いろいろ調べてみた結果schema.xmlではなく、コアの動作に関する設定ファイルであるsolrconfig.xmlの中の設定が原因だった。

どうもrequestHandlerの設定で「text」というフィールドをデフォルトで検索するようになっていた為に、「undefined field text」と怒られていたみたい。
下記リンクが参考になった。
stack overflow

デフォルトで検索するフィールドをshema.xmlで定義しているフィールドに設定すると、エラーとなることなくApache Solrの起動に成功。

CloudFormerで作成したテンプレートの注意点

CloudFormerを使用して既存のAWS上の環境をテンプレートにして、同じ環境を新たに作成したい事があるかと思うけれども、そういった場合、CloudFormerを使用して作成したテンプレートをそのまま使うと問題になるんじゃないかなと思った点があったのでメモ。

  • AWSリソースの名前が指定されていないので、そのまま使用するとリソース名が自動生成となる。
  • EC2のリソースを監視しているCloudWatchアラームをテンプレートにした場合、監視先のインスタンスIDが紐付いたままになる。(同じEC2のリソースを監視するアラームが新たに作成される)
  • CloudWatchLogGroupのアラームは、テンプレートを使用して作成した場合、CloudWatchLogGroupに同じ内容のアラームが追加で作成される。(同じ内容のアラームが新たに作成される)

リソース名が自動生成されるのは、作成したテンプレートにリソース名を指定するようにすれば対応可能。
下記はSNSにリソース名を指定した例。

CloudWatchアラームに関しては、他に良い方法があるかもしれないけれども、一度テンプレートを使用してアラームを作成後、変更を加えるか、もしくはテンプレートを使用しないで作成する必要があると思う。

AWS SDK for GOでのCloudSearch検索方法

前提条件として

  • CloudSearchでDomainが作成されている
  • CloudSearchに検索するためのデータが登録されている

が実施済みなこと。

下記のコードでGo言語を使用して、CloudSearchから検索できる。

まず、リージョンとCloudSearch Domainへのエンドポイントを指定して、cloudsearchdomainのインスタンスを作成する。
次にSearchInput構造体に検索文字列を設定して、最後にcloudsearchdomainのSearchメソッドで検索を行う。

これでCloudSearchから検索結果を取得できる。

また、同様の方法でCloudSearchのサジェスタを使用して、入力候補を取得する事ができる。

CloudSearchからの検索方法と同じように、構造体に入力候補を取得する為の情報を入力した後、Suggestメソッドで入力候補を取得可能。
Go言語の使い方は下記、AWS SDK for GoのAPI Referenceを見るとサンプルが付いているので判りやすい。
AWS SDK for GO API Reference

取得した入力候補をjsonにしてフロントエンドにレスポンスとして返し、フロントエンド側で入力候補を表示するように実装すれば、Googleの検索ボックスみたいにオートコンプリートを表示させる事ができるようになる。

JAWS DAYS 2016に参加してきました

AWSのユーザグループであるJAWS-UGによる一年に一度のイベントの
JAWS DAYS 2016に参加してきました。

会場であるベルサール新宿グランドに着くと、
早速JAWS DAYS 2016のカンバンが出迎えてくれました。

JAWS-DAYS-2016

受付で登録を行い、会場へ。
私が受付をした時間は早かったので、会場内の人はまだ少なかったですが、
30分ほどすると徐々に増えてきて、開始5分前には立ち見の人が出るほど人が増えてきました。

開始時間の10:00になると、開会宣言の後にJAWS-UG代表の金春さんのキーノートが始まります。
内容はJAWS-UGのこれまでとこれから、そしてコミュニティについての話でした。
技術的な話はなかったですが、コミュニティに参加することの大切さを考えさせられる話でした。

金春さんのキーノートの後は、各セッションが始まります。
皆さん自分の興味のあるセッションに向かって我先にと向かって行きます。
かくいう私もそうでした(笑)

各セッションはAWSを実際に使用した人の話であったり、
AWSのソリューションアーキテクトの方による各サービスの詳しい内容・制限事項の話だったりと
AWSをまだまだ勉強中の自分にはプラスになるものばかりでした。

特にAPI Gateway&lambdaのセッションは立ち見もあふれて
ブースに入りきらないほどで、皆さんの関心の高さが伺えました。
↓はAWS西谷さんのスライド資料です。
http://www.slideshare.net/keisuke69/aws-lambda-amazon-api-gateway-deep-dive

そして各セッションが終わった後は懇親会とLT大会の始まりです。
懇親会に参加する皆さんが一堂に会して、LTを肴にお酒を飲みます。

LTは5分という短い時間でしたが、セッションに負けないくらい
濃い内容ばかりで、経験溢れる方の話もあれば、なんと大学院生の登壇者もいました。
大学院生とは思えないしっかりした内容・話し方でびっくりしました。

懇親会の最後にはAWS samurai 2015に選出された皆さんの紹介です。
エバンジェリスト高岡さん司会のもと、
2015年にコミュニティに貢献された4名の方が紹介されました。
選出された皆さんおめでとうございます。
AWS-samurai-2015

次のJAWS DAYSは来年ですが、また参加したくなる内容のイベントでした。
参加してない方がいれば、来年是非参加してみてください。