【问题标题】:Docker golang gin postgresDocker golang gin postgres
【发布时间】:2019-12-23 17:27:30
【问题描述】:

我正在尝试使用 Postgres 为 golang 应用程序设置一个 docker。 如果我删除/评论 Postgres,go 应用程序在容器中运行良好。同样,我能够启动 Postgres 容器并登录到它。我可以做 docker-compose up。 但是当我进行 API 调用时,例如:localhost:3000/api/admin/users。它给出了错误:

error: {
        "error": "+dial tcp 127.0.0.1:5432: connect: connection refused"
    }

Postgres 连接字符串是这样的:

connStr := fmt.Sprintf("host=postgres user=anurag password=anu_12345 dbname=bankingapp sslmode=disable")

db, err := sql.Open("postgres", connStr)

Dockerfile

FROM golang:1.13


WORKDIR /go/src/banking-app
COPY . .

RUN go get -d -v ./...
RUN go install -v ./...

CMD ["go" , "run", "main.go"]


docker-compose.yml

version: '3'
services:
  web:
    build: .
    ports:
      - "3000:3000"
  postgres:
    image: "postgres"
    environment:
      POSTGRES_USER: 'anurag'
      POSTGRES_PASSWORD: 'anu_12345'
      POSTGRES_DB: 'bankingapp'


【问题讨论】:

  • 您是否尝试过在 postgress 服务定义中使用端口? ``` image: postgres:latest restart: always ports: - 5432:5432
  • @Oras,我有。但我认为我不需要。 compose 默认情况下创建一个桥 n/w。另外,我可以通过网络应用成功ping postgres

标签: postgresql docker go docker-compose go-gin


【解决方案1】:

似乎是@Oras 端口提到的一些丢失的端口:5432:5432 只需添加它以从问题中排除端口,也从您遇到的错误中,您的 docker 应用程序容器 取决于在数据库容器上,因此您需要有办法等到您的数据库容器启动并且您的应用程序容器可以连接它,检查depends_on docker compose:

https://docs.docker.com/compose/compose-file/

version: '3'
services:
web:
  build: .
  ports:
    - "3000:3000"
  depends_on:
    postgres
  restart_policy:
    condition: on-failure
  postgres:
    image: "postgres"
    ports:
      - "3000:3000"
    environment:
      POSTGRES_USER: 'anurag'
      POSTGRES_PASSWORD: 'anu_12345'
      POSTGRES_DB: 'bankingapp'

使用depends_on时有几点需要注意:

  1. depends_on 在启动 web 之前不会等待 db 和 redis “准备好” - 仅在它们启动之前。如果您需要等待服务准备好,请参阅控制启动顺序以了解有关此问题的更多信息以及解决此问题的策略。

  2. 版本 3 不再支持depends_on 的条件形式。

  3. 当使用 3 版 Compose 文件以 swarm 模式部署堆栈时,将忽略 depends_on 选项。

根据上述说明,您可能仍会遇到此问题,但重启策略将重启应用容器,您将连接到数据库。

【讨论】:

  • 我倾向于与您对端口的看法不同。在我看来,我们只在需要连接到网络外部时才公开端口。因为docker-compose 提供了默认的桥接网络,所以我们不会暴露端口。 depends_on 只是为了强制容器依赖。感谢您的答复。节日快乐!
  • 我同意你的观点,我检查过,我发现我的观点在这里无效,但也许对于你的情况,你需要一个自定义的entrypoint 来检查你的应用程序容器中的数据库可用性如果它起来了。圣诞节快乐!给你。
【解决方案2】:

我找到了答案。 只需要使用 mount 重建图像或加载。 代码没有刷新。

抱歉打扰了。

【讨论】:

    猜你喜欢
    • 2022-12-01
    • 1970-01-01
    • 2018-05-12
    • 2022-01-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多