I'm having this issue too !

I think a clean solution would be to add a configuration field to allow users to choose an image containing the "true" and "ip" binaries (with a default value of "alpine:3.2")

That way we could push the alipne:3.2 image to our private registry and tell the plugin to use "my.private.registry/alpine:3.2" instead of "alpine:3.2"

Code changed in jenkins
User: Vincent Latombe
Path:
src/main/java/com/cloudbees/jenkins/plugins/docker_build_env/Docker.java
src/main/java/com/cloudbees/jenkins/plugins/docker_build_env/DockerBuildWrapper.java
src/main/resources/com/cloudbees/jenkins/plugins/docker_build_env/DockerBuildWrapper/global.jelly
src/main/resources/com/cloudbees/jenkins/plugins/docker_build_env/DockerBuildWrapper/help-imageSbinIp.html
http://jenkins-ci.org/commit/docker-custom-build-environment-plugin/0645b879410fe76bc743d30880f7364602d49a38
Log:
JENKINS-33232 Allow to define globally a docker image to use to
execute /sbin/ip

Compare: https://github.com/jenkinsci/docker-custom-build-environment-plugin/compare/9af2c39488e3^...0645b879410f

Letting user configure an image for this internal usage is far too technical for a good UX imho.
I'd prefer the plugin to bundle a tiny go executable it can run as a single layer docker image to offer comparable gateway IP discovery.

doesn't seem to be a trivial thing to re-implement ip routes in go (not available using go's `net` API, would require to do some syscalls ...
simplest option then would probably to bundle an alpine image export (10Mb) as a tar.gz resource in plugin, so this one can load an run without dependency on dockerhub accessibility.

The problem IMHO, is not so the ip routes, but the fact than the plugin doesn't care of what we define in the FROM line.

For example if i want to use official image from ourcompany registry eg :
FROM mycompany-registry/team/ubuntu:latest

the plugin fail on "Unable to find image 'alpine:3.2' locally" even if i don't care of alpine image and don't need it

If the FROM clause was correctly implemented then the problem of ip route, than alpine can't be reached from internal network can be easily bypassed by using our internal images...

Please advice how to achieve connection to local docker registry. Is this problem solved?

Hi! There is one more issue within working with private registry: If I set credentials to access to my registry, plugin creates `auths` block within `~/.docker/config.json` for my registry. Thats ok! BUT! It creates same auth record for alpine! And pulling failed with authorization error!

For example: I set my image as `test/test-image` and registry `registry.test.com`, then add credentials. Then build fails with that reason:

09:25:32 $ docker run --rm --entrypoint /bin/true alpine:3.2
09:25:32 Unable to find image 'alpine:3.2' locally
09:25:33 docker: Error response from daemon: Get https://registry-1.docker.io/v2/library/alpine/manifests/3.2: unauthorized: incorrect username or password.
09:25:33 See 'docker run --help'.
09:25:33 [ssh-agent] Stopped.
09:25:33 FATAL: Failed to run docker image registry.yandex.net/mediaselling/python-binary-deps
09:25:33 java.lang.RuntimeException: Failed to run docker image registry.yandex.net/mediaselling/python-binary-deps

And here is my config.json content:

{"auths": {
  "registry.yandex.net": {"auth": "SOME_CRED"},
  "https://registry.test.com/":   {
    "auth": "MY_TOKEN",
    "email": "lawyard@test.com"
  },
  "https://index.docker.io/v1/":   {
    "auth": "MY_TOKEN",
    "email": "lawyard@test.com"
  }
}}

So, I suppose we dont need to do that - create auths config for alpine image.

Just stopping by to confirm, this bug has the indirect effect of corrupting the auths in config.json.

Has anyone found a solution / workaround for this problem? Please share it out. Thanks.