New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

registry(run in alpine) notification error #2467

Open
wrfly opened this Issue Dec 9, 2017 · 11 comments

Comments

Projects
None yet
5 participants
@wrfly

wrfly commented Dec 9, 2017

When I configure registry:latest to push events to my notification server, the registry (which running on alpine) will not parse hosts file but query the endpoint from the DNS(and fall back to the hosts file).

docker run --network host -ti --rm -v ./registry/:/etc/docker/registry --add-host www.google.com:172.17.0.1 registry

config:

version: 0.1
log:
  level: debug
storage:
    delete:
      enabled: true
    filesystem:
        rootdirectory: /var/lib/registry
http:
    addr: :5000
    debug:
        addr: localhost:5001
    headers:
        X-Content-Type-Options: [nosniff]
notifications:
    endpoints:
        - name: local-8083
          url: http://www.google.com:8083/callback
          timeout: 1s
          threshold: 10
          backoff: 1s
          disabled: false 

I built the latest version of registry and run it in both my laptop(Ubuntu) and Ubuntu container, it works fine.

I thought it's a bug with alpine.

@timchenxiaoyu

This comment has been minimized.

timchenxiaoyu commented Dec 12, 2017

how to build in alpine?

@wrfly wrfly changed the title from registry(build in alpine) notification error to registry(run in alpine) notification error Dec 12, 2017

@wrfly

This comment has been minimized.

@stevvooe

This comment has been minimized.

Contributor

stevvooe commented Jan 17, 2018

@wrfly Could you confirm with dig that the expected value isn't being resolved?

I suspect that because this is using host networking, the /etc/hosts file in the container is ignored and it just uses the machine's host file.

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Jan 17, 2018

Could be this issue (I see it's already linking to this one); docker/distribution-library-image#66

@wrfly

This comment has been minimized.

wrfly commented Feb 1, 2018

@thaJeztah Yep, I made a PR but no body replied me.....
Would you mind review that PR?

@stevvooe Actually it's a common error with images based on alpine... Alpine doesn't need /etc/nsswitch.conf but golang does. See gliderlabs/docker-alpine#367

@stevvooe

This comment has been minimized.

Contributor

stevvooe commented Feb 6, 2018

@wrfly I LGTM'd your PR. Should the fix actually be in the base image?

@wrfly

This comment has been minimized.

wrfly commented Feb 7, 2018

@stevvooe Em...... That PR would be a workaround, the ultimate solution is to solve it in the base level but I think it would be a long way to go. It might be some discussion about alpine and Go...
But as @thaJeztah said, it's a bug of Go which assumes that linux always is glibc. gliderlabs/docker-alpine#367 So, I'm on your side! 😆

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Feb 7, 2018

Should the fix actually be in the base image?

It might be some discussion about alpine and Go

Yes, indeed; I understand the reason for the Alpine maintainers to not accept it in the base image, so putting it in the distribution image is probably the best solution for now.

I'm not sure it's a bug in Go, but more an "opinionated" approach, I guess; might be worth opening an issue to see if they are open to making the behaviour customizable.

@wrfly

This comment has been minimized.

wrfly commented Feb 8, 2018

@thaJeztah I thought I found something.... https://golang.org/src/net/net.go

By default the pure Go resolver is used, because a blocked DNS request consumes

only a goroutine, while a blocked C call consumes an operating system thread.

When cgo is available, the cgo-based resolver is used instead under a variety of

conditions: on systems that do not let programs make direct DNS requests (OS X),

when the LOCALDOMAIN environment variable is present (even if empty),

when the RES_OPTIONS or HOSTALIASES environment variable is non-empty,

when the ASR_CONFIG environment variable is non-empty (OpenBSD only),

when /etc/resolv.conf or /etc/nsswitch.conf specify the use of features that the

Go resolver does not implement, and when the name being looked up ends in .local

or is an mDNS name.


The resolver decision can be overridden by setting the netdns value of the

GODEBUG environment variable (see package runtime) to go or cgo, as in:


    export GODEBUG=netdns=go    # force pure Go resolver

    export GODEBUG=netdns=cgo   # force cgo resolver


The decision can also be forced while building the Go source tree

by setting the netgo or netcgo build tag.

It's not a bug of Go, we have to set a build tag for registry or add an environment variable.

There are there solutions for this "bug":

  1. Set a build tag -tags netcgo
  2. Export an environment variable export GODEBUG=netdns=cgo
  3. Add annsswitch.conf to that image

CC @stevvooe

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Feb 8, 2018

Yes, overriding the resolver is a known workaround, but I'm not sure we should set that

@wrfly

This comment has been minimized.

wrfly commented Feb 8, 2018

I'm testing on it. Both export GODEBUG=netdns=cgo and adding nsswitch.conf are OK.
The build tag didn't work.(with go1.9.3)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment