使用 docker-compose 连接到 RabbitMQ 容器 [英] Connecting to RabbitMQ container with docker-compose

查看:53
本文介绍了使用 docker-compose 连接到 RabbitMQ 容器的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想在一个容器中运行 RabbitMQ,在另一个容器中运行工作进程.worker 进程需要访问 RabbitMQ.

I want to run RabbitMQ in one container, and a worker process in another. The worker process needs to access RabbitMQ.

我希望通过 docker-compose 管理这些.

I'd like these to be managed through docker-compose.

到目前为止,这是我的 docker-compose.yml 文件:

This is my docker-compose.yml file so far:

version: "3"

services:

  rabbitmq:
    image: rabbitmq
    command: rabbitmq-server
    expose:
      - "5672"
      - "15672"

  worker:
    build: ./worker
    depends_on:
      - rabbitmq
    # Allow access to docker daemon
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

所以我公开了 RabbitMQ 端口.工作进程使用以下 URL 访问 RabbitMQ:

So I've exposed the RabbitMQ ports. The worker process accesses RabbitMQ using the following URL:

amqp://guest:guest@rabbitmq:5672/

这是他们在官方教程中使用的,但是 localhost 已被替换为 rabbitmq,因为容器应该是 可通过与容器名称相同的主机名发现:

Which is what they use in the official tutorial, but localhost has been swapped for rabbitmq, since the the containers should be discoverable with a hostname identical to the container name:

默认情况下,Compose 会为您的应用设置一个网络.服务的每个容器都加入默认网络,并且该网络上的其他容器都可以访问,并且它们可以通过与容器名称相同的主机名发现.

By default Compose sets up a single network for your app. Each container for a service joins the default network and is both reachable by other containers on that network, and discoverable by them at a hostname identical to the container name.

每当我运行此程序时,我都会收到连接被拒绝错误:

Whenever I run this, I get an connection refused error:

Recreating ci_rabbitmq_1 ... done                                                                                                                                                    
Recreating ci_worker_1   ... done                                                                                                                                                    
Attaching to ci_rabbitmq_1, ci_worker_1                                                                                                                                              
worker_1    | dial tcp 127.0.0.1:5672: connect: connection refused                                                                                                                   
ci_worker_1 exited with code 1        

我觉得这很有趣,因为它使用的 IP 127.0.0.1(我认为)是 localhost,即使我将 rabbitmq 指定为主机名.我不是 docker 网络方面的专家,所以也许这是需要的.

I find this interesting because it's using the IP 127.0.0.1 which (I think) is localhost, even though I specified rabbitmq as the hostname. I'm not an expert on docker networking, so maybe this is desired.

如果需要,我很乐意提供更多信息!

I'm happy to supply more information if needed!

编辑

这里有一个几乎相同的问题.我想我需要等到 rabbitmq 启动并运行,然后再启动 worker.我尝试通过健康检查来做到这一点:

There is an almost identical question here. I think I need to wait until rabbitmq is up and running before starting worker. I tried doing this with a healthcheck:

version: "2.1"

services:

  rabbitmq:
    image: rabbitmq
    command: rabbitmq-server
    expose:
      - "5672"
      - "15672"
    healthcheck:
      test: [ "CMD", "nc", "-z", "localhost", "5672" ]
      interval: 10s
      timeout: 10s
      retries: 5

  worker:
    build: .
    depends_on:
      rabbitmq:
        condition: service_healthy

(注意不同的版本).但是,这不起作用 - 它总是会因为不健康而失败.

(Note the different version). This doesn't work, however - it will always fail as not-healthy.

推荐答案

啊哈!我修好了它.@Ijaz 完全正确 - RabbitMQ 服务需要一段时间才能启动,我的工作人员会在它运行之前尝试连接.

Aha! I fixed it. @Ijaz was totally correct - the RabbitMQ service takes a while to start, and my worker tries to connect before it's running.

我尝试使用延迟,但是当 RabbitMQ 花费的时间比平时更长时,这失败了.

I tried using a delay, but this failed when the RabbitMQ took longer than usual.

这也表明了一个更大的架构问题——如果队列服务(在我的例子中是 RabbitMQ)在生产期间离线会发生什么?现在,我的整个网站都失败了.需要有一些内置的冗余和轮询.

This is also indicative of a larger architectural problem - what happens if the queuing service (RabbitMQ in my case) goes offline during production? Right now, my entire site fails. There needs to be some built-in redundancy and polling.

正如 this related answer 所述,我们可以在 docker-compose 3+:

As described this this related answer, we can use healthchecks in docker-compose 3+:

version: "3"

services:

  rabbitmq:
    image: rabbitmq
    command: rabbitmq-server
    expose:
      - 5672
      - 15672
    healthcheck:
      test: [ "CMD", "nc", "-z", "localhost", "5672" ]
      interval: 5s
      timeout: 15s
      retries: 1

  worker:
    image: worker
    restart: on-failure
    depends_on:
      - rabbitmq

现在,worker 容器将重新启动几次,而 rabbitmq 容器保持不健康状态.rabbitmqnc -z localhost 5672 成功时立即变得健康 - 即当排队时!

Now, the worker container will restart a few times while the rabbitmq container stays unhealthy. rabbitmq immediately becomes healthy when nc -z localhost 5672 succeeds - i.e. when the queuing is live!

这篇关于使用 docker-compose 连接到 RabbitMQ 容器的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆