ビッグデータ処理のプロジェクトoceanusで、セットした覚えのない環境変数がセットされており、それがたまたまコンテナで使っている変数名と同じだったため、原因の特定に時間がかかってしまった。
RabiitMQを使うことになって、それを使うコンテナには、RABBITMQ_PORTという自分で付けた名前の環境変数を使っていた。
ポートはデフォルトのまま5672を使っているが、あとで変更できるようにPython側では下記のように呼び出していた。
from os import environ RABBITMQ_PORT = environ.get('RABBITMQ_PORT', 5672)
getを使うことで、RABBITMQ_PORTがない場合は、デフォルトの5672が使われるように書いていたつもりで、ローカルでは問題なく動いていた。
しかし、Kubernetes(Google Container Engine)にアップすると、RABBITMQ_PORTに下記のような、ポート番号だけでなく、Kubernetes上のローカルIPまで含めた値が入ってしまい、エラーが起きていた。
tcp://10.7.251.6:5672
調べてみたら、Kubernetesでは、同一クラスタ内のサービスに繋げるように、それぞれのホスト名、ポート番号などを自動で環境変数にいれてくれるようだ。
ドキュメントにも書いてあり、完全に見落としていた。
ドキュメントにあるように例えば、redis-masterというservice名だったら、下記の環境変数がすべてセットされる。
REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
今回自分のアプリケーションでは、たまたまサービス名と、それから生成される環境変数が同じになってしまっていた。
ここらへんの環境変数を整理して、この環境変数名でアプリケーション側から呼び出すようにすれば、新規作成時にServiceのIPを指定しなくても、一気につながるようにできるはず。
WEBサーバー、DBサーバー、キャッシュサーバー、MQサーバーなど、Kubernetes内のネットワークが増えてきたら、この変数名を使ってyamlを書いたりするのが必須になりそう。
Kubernetes: Up and Running; Dive into the Future of Infrastructure
- 作者: Kelsey Hightower,Brendan Burns,Joe Beda
- 出版社/メーカー: Oreilly & Associates Inc
- 発売日: 2017/04/25
- メディア: ペーパーバック
- この商品を含むブログを見る
プログラマのためのDocker教科書 インフラの基礎知識&コードによる環境構築の自動化
- 作者: 阿佐志保,山田祥寛
- 出版社/メーカー: 翔泳社
- 発売日: 2015/11/20
- メディア: 大型本
- この商品を含むブログ (3件) を見る