dongqing8765 2017-09-09 16:28
浏览 184

sqlx.Connect()卡在docker alpine:latest中

I have problem that I've managed to reduce to the following code:

package main

import (
    "fmt"
    "github.com/jmoiron/sqlx"
    _ "github.com/lib/pq"
    "os"
)

func main() {
    addr := os.Getenv("DB")
    fmt.Println("Postgres addr: " + addr)

    _, err := sqlx.Connect("postgres", addr)

    if err != nil {
        fmt.Println("Could not connect...")
    } else {
        fmt.Println("Connecting successful")
    }
}

I set up a repo with the code and more explanations at:

https://github.com/mraxus/mystery-golang-alpine

When I build and run this Go code with a valid DB url in a docker image (here golang:latest) throught docker-compose, where both the above program and the postgres db is in separate containers, the program runs as expected:

build_1     | Postgres addr: postgres://postgres@postgres/postgres?sslmode=disable
build_1     | Connecting successful

However, when I run the same program in same setup (docker-compose) with the base image alpine:latest, the program just gets stuck at the sqlx.Connect():

alpine_1    | Postgres addr: postgres://postgres@postgres/postgres?sslmode=disable

I have no idea why this is. Do you know? I have setup a project to see if others can reproduce and get the same problem as I get:

https://github.com/mraxus/mystery-golang-alpine

Love to hear some insights that can help me solve this issue.

My system details:

  • macOS 10.12.6 (Sierra, MBP Mid 2015 15-inch)
  • docker 17.06.1 1-ce-mac24
  • 写回答

1条回答

  • donglu7286 2017-09-11 11:32
    关注

    Proper solution (by realizing the actual problem)

    So it turns out that the corporate network at work have a search domain set. This affects the alpine containers name resolution. However, the default golang is not.

    To solve the problem, you can overwrite docker-compose containers search domain, by modifying the config:

    build:
        dns_search: .
        image: image:build
        ...
    
    alpine:
        dns_search: .
        image: image:alpine
        ...
    

    See https://github.com/mraxus/mystery-golang-alpine/pull/4

    Alternative solution (not having realized the actual problem)

    By forcing go to use the cgo name resolver, there is no longer any issues:

    In docker-compose.yml

    alpine:
        image: mamarcus.org/project:alpine
        links:
            - postgres
        environment:
            DB: "postgres://postgres@postgres/postgres?sslmode=disable"
            GODEBUG: "netdns=cgo"
    

    See https://github.com/mraxus/mystery-golang-alpine/pull/3

    It should be mentioned that this solution is still iffy. In our real dev environment, containing ~20 services configured in docker-compose, some docker alpine images still did not resolve properly. But when updating the configuration with the "proper solution", everything worked like a charm.

    评论

报告相同问题?

悬赏问题

  • ¥20 为什么我写出来的绘图程序是这样的,有没有lao哥改一下
  • ¥15 js,页面2返回页面1时定位进入的设备
  • ¥200 关于#c++#的问题,请各位专家解答!网站的邀请码
  • ¥50 导入文件到网吧的电脑并且在重启之后不会被恢复
  • ¥15 (希望可以解决问题)ma和mb文件无法正常打开,打开后是空白,但是有正常内存占用,但可以在打开Maya应用程序后打开场景ma和mb格式。
  • ¥15 绘制多分类任务的roc曲线时只画出了一类的roc,其它的auc显示为nan
  • ¥20 ML307A在使用AT命令连接EMQX平台的MQTT时被拒绝
  • ¥20 腾讯企业邮箱邮件可以恢复么
  • ¥15 有人知道怎么将自己的迁移策略布到edgecloudsim上使用吗?
  • ¥15 错误 LNK2001 无法解析的外部符号