あるコンテナからデプロイされた Web アプリケーションを、別のコンテナにデプロイされた rabbitmq に接続しようとしています。
この docker-compose を使用して RabbitMQ コンテナーに接続する を参考にして、次の docker-compose を作成しました。
version: '3'
services:
webapp:
container_name: chat
build:
context: .
depends_on:
- broker
ports:
- "8080:8080"
broker:
container_name: rabbit_chat
image: rabbitmq
command: rabbitmq-server
expose:
- 5672
- 15672
healthcheck:
test: ["CMD", "curl", "-f", "http://broker:5672"]
interval: 30s
timeout: 10s
retries: 5
webapp は Web アプリケーションのサービスであり、次の rabbitmq-properties を指定します。
host = broker
port = 15672
login = guest
password = guest
ドキュメントでは、docker-compose のサービス名を使用して、default-net でコンテナを接続することを推奨しているため、ホストとして「ブローカー」を選択しました。
そして、これは機能しません。また、接続のホストとして「localhost」を使用しようとしました。
さらに、コンテナ「rabbit_chat」を検査すると、出力に次の内容が表示されます。
"Log": [
{
"Start": "2020-04-11T14:54:25.0988242Z",
"End": "2020-04-11T14:54:25.2920557Z",
"ExitCode": -1,
"Output": "OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused \"exec: \\\"curl\\\": executable file not found in $PATH\": unknown"
}
答え1
試してみる通信網:
services:
webapp:
...
networks:
- mynetwork
broker:
...
networks:
- mynetwork
networks:
mynetwork:
これにより、内部 DNS も設定されるので、実際に他のコンテナーを参照するためのbroker
ホスト名として使用できます。webapp
答え2
コメントから判断すると、docker ポートの問題ではなく、アクセス許可の問題のようです。
まず、rabbit-mq コンテナー内から curl を試してください。ログから判断すると、rabbit コンテナーに curl がインストールされていないようですので、インストールして試してください。
次に、外部 (マシン) から試してください。rabbit
コンテナー内のポートをマップするだけです: "5672:5672" と "15672:15672"。curl
localhost:5672 (または、docker examine を実行して、コンテナーの IP アドレスに直接 curl を実行してください)。
イメージは同じベースイメージから構築されていますか? おそらく、rabbit イメージに ufw があるのでしょう。
また、マシンの ufw をシャットダウンして確認してください (ある場合)
docker-compose 内のコンテナ間で通信する最良の方法はネットワーク ブリッジを使用することです。そのため、最終的にはこれを使用する必要があります。