On VPN, puller fails to resolve dns name on MacOS

[suman-ganta]

When puller is used to pull a docker image over VPN on MacOS. The root cause seem to be this issue. Apparently the go_library definition need to have cgo=True for this to work on Mac.

So, to summarize the issue, the host name resolution is not honoring Mac's DNS configuration, instead it is always reading /etc/resolv.conf to get the name servers.

[smukherj1]

I'm a little apprehensive of straying too far from default options when building the various Go binaries. Users of rules_docker can build their own versions of the binary, upload them somewhere and override the http_file directive here by calling http_file prior to importing rules_docker with the name of the http_file target set to go_puller_darwin. Could you please first try this and confirm if this fixes your issue?

[gibfahn]

I can confirm that building the binary on macOS does fix the issue (as expected).

So I guess there are three possibilities for rules_docker:

1. Wait for Go upstream to fix the issue.
   • In the meantime every user who uses a VPN on macOS (which seems to be quite a few people looking at the number of comments on net: Support the /etc/resolver DNS resolution configuration hierarchy on OS X when cgo is disabled golang/go#12524) will have to build their own copy of go_puller_darwin and maintain it somewhere as new versions are released, which is a lot of maintenance for a single bug.
2. Build this target with cgo enabled.
   • This requires a C/C++ compiler toolchain be configured as a toolchain, which your base image l.gcr.io/google/bazel doesn't seem to have. I'm not sure if Google has a C++ compiler toolchain anywhere, but it does seem to complicate things.
3. Use a library that fixes the issue
   • I saw https://github.com/JohnStarich/go/tree/master/dns referenced in the GitHub issue.

Adding an example failure for others who might be searching for this issue:

2020/04/24 11:38:53 Image pull was unsuccessful: reading image "<dockerURL>": Get "https://<dockerURL>": dial tcp: lookup docker... on <IP> no such host

---

Example cgo failure without a C toolchain configured:

$ docker run --rm -it -v $PWD:/code -w /code l.gcr.io/google/bazel bazel --platforms=@io_bazel_rules_go//go/toolchain:darwin_amd64_cgo container/go/cmd/puller
INFO: Build option --platforms has changed, discarding analysis cache.
ERROR: While resolving toolchains for target @io_bazel_rules_go//:cgo_context_data: No matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type. Maybe --incompatible_use_cc_configu2020-04-24re_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file? See https://github.com/bazelbuild/bazel/issues/10134 for details and migration instructions.
ERROR: Analysis of target '//container/go/cmd/puller:puller' failed; build aborted: No matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type. Maybe --incompatible_use_cc_configure_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file? See https://github.com/bazelbuild/bazel/issues/10134 for details and migration instructions.
INFO: Elapsed time: 0.355s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 593 targets configured)

---

To use a built version add this above the rules_docker setup:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")

# Built on macOS with: bazel build container/go/cmd/puller
http_file(
    name = "go_puller_darwin",
    executable = True,
    urls = [
      "file:///tmp/darwin-puller"
      "https://example.com/puller-darwin-amd64",
    ],
    # sha256sum $(bazel run --run_under "echo " container/go/cmd/puller)
    sha256 = "606ad426b6c09c8623dda7bfb123365413b6b80eb0c126d2f7b5d810ea3aed78",
)

[smukherj1]

Regarding the C/C++ toolchain issue, I asked for migration help here.

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

[gibfahn]

Please don't close this, continuous pain for us 😁

Don't think I have the ability to assign someone to this.

[gibfahn]

Looks like #1795 would fix this as it runs the macOS build on macOS 🎉

[zoidyzoidzoid]

I should work on getting #1795 merged

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

[gibfahn]

Still an issue

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

[gibfahn]

Still an issue

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

[gibfahn]

Still an issue

[shs96c]

It's still an issue

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

[zoidyzoidzoid]

You can try moving to rules_oci.

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!