コンテナからホスト側のサービスに繋がらない

レン

コンテナの中から、ホストで動かしてるデータベースに繋ごうとすると失敗する…設定は合ってるのに。

プロクラ

設定は合っているんだと思うよ。ただ、コンテナの中では 127.0.0.1 の指す先が違うんだ。ホストではなく、コンテナ自身を指している。だから「誰も居ない」という結果になる。

127.0.0.1 の指す先

• ホスト上の 127.0.0.1 → ホスト自身
• コンテナの中の 127.0.0.1 → そのコンテナ自身
• コンテナはそれぞれ独立したネットワークを持っている
• だから、同じ設定ファイルを持ち込むと繋がらなくなる

プロクラ

手元で動かしていたときの設定を、そのままコンテナに持ち込むと必ずこれに当たる。開発から本番へ移すときの定番の詰まりどころだよ。

ホストへ繋ぐ方法

• ホストを指す特別な名前が用意されている環境では、それを使う
• ホスト側のネットワークをそのまま使う設定にする（分離は失われる）
• Dockerが作るネットワークにおける、ホスト側のアドレスを指定する
• そもそも、その相手もコンテナにしてしまう

プロクラ

4つめが、実は一番すっきりすることが多いよ。データベースもコンテナにすれば、サービス名で繋げるようになる。ホストとコンテナが混ざった構成は、後々ややこしくなりがちだ。

コンテナ同士なら名前で繋がる

プロクラ

同じネットワークにあるコンテナ同士は、サービス名で相手を見つけられる。IPアドレスを書く必要は無いし、再作成でアドレスが変わっても壊れない。

• 接続先には、サービス名をそのまま書く
• ポート番号は、公開していない内部のものでよい
• 外に公開する必要が無いなら、公開の指定をしない
• この構成なら、外部から直接触られる入口も減る

プロクラ

3つめは守りの面でも大事だよ。データベースを外に公開する設定にしていると、意図せずインターネットから接続できる状態になることがある。コンテナ同士で繋ぐなら、公開は不要だ。

逆にホストからコンテナへ

• 公開したポートに対して、ホストの 127.0.0.1 経由で繋がる
• 公開していなければ、ホストからも直接は繋がらない
• 一時的に確認したいだけなら、コンテナの中に入って試すのが早い
• その場合、コンテナ内から自分自身を指す形になる

レン

127.0.0.1 が別のものを指してたんだ。それなら繋がらないわけだよ。

設定ファイルの書き分け

プロクラ

手元と本番で接続先が変わるなら、設定を環境変数で外に出しておくと楽だよ。同じイメージのまま、渡す値だけを変えられる。

• 接続先をコードに直接書かない
• 環境変数として渡し、環境ごとに値を変える
• 認証情報も同じ扱いにする（イメージに焼き込まない）
• 手元用と本番用で、設定ファイルを分けておく