visibilityspots / dockerfile-cloudflared Goto Github PK

Until the last updates, the docker worked without problems in my QNAP
Now, log problems:
r12 0x1033f94, r13 0x1033f95, r14 0x0, r15 0x0, r16 0x0, r17 0x6, r18 0x7f7e86b447,� r19 0xd0, r20 0x4000131708, r21 0x400048e160,� r22 0x16, r23 0x0, r24 0xffffffffffffffa2, r25 0xd8af20, r26 0x1664938, r27 0x16fc35d, r28 0x4000000180, r29 0x4000130e68, lr 0xb8dcc0, sp 0x4000130e70, pc 0xb8e4c0, fault 0x0, SIGILL: illegal instruction, PC=0xb8e4c0 m=0 sigcode=1, instruction bytes: 0x0 0x6 0x38 0xd5 0xe0 0x7 0x0 0xf9 0xc0 0x3 0x5f 0xd6 0x0 0x0 0x0 0x0, , goroutine 1 [running, locked to thread]:, golang.org/x/sys/cpu.getisar0(0x400007f110), /tmp/release/vendor/golang.org/x/sys/cpu/cpu_arm64.s:14 fp=0x4000138e70 sp=0x4000138e70 pc=0xb8e4c0, golang.org/x/sys/cpu.readARM64Registers(), /tmp/release/vendor/golang.org/x/sys/cpu/cpu_arm64.go:65 +0x30 fp=0x4000138eb0 sp=0x4000138e70 pc=0xb8dcc0, golang.org/x/sys/cpu.doinit(), /tmp/release/vendor/golang.org/x/sys/cpu/cpu_linux_arm64.go:38 +0x2c fp=0x4000138ed0 sp=0x4000138eb0 pc=0xb8dfbc, golang.org/x/sys/cpu.archInit(), /tmp/release/vendor/golang.org/x/sys/cpu/cpu_arm64.go:45 +0x20 fp=0x4000138ee0 sp=0x4000138ed0 pc=0xb8dc70, golang.org/x/sys/cpu.init.0(), /tmp/release/vendor/golang.org/x/sys/cpu/cpu.go:199 +0x20 fp=0x4000138ef0 sp=0x4000138ee0 pc=0xb8d220, runtime.doInit(0x1664900), /usr/local/go/src/runtime/proc.go:6308 +0xdc fp=0x4000139050 sp=0x4000138ef0 pc=0x44775c, runtime.doInit(0x16711e0), /usr/local/go/src/runtime/proc.go:6285 +0x60 fp=0x40001391b0 sp=0x4000139050 pc=0x4476e0, runtime.doInit(0x16646c0), /usr/local/go/src/runtime/proc.go:6285 +0x60 fp=0x4000139310 sp=0x40001391b0 pc=0x4476e0, runtime.doInit(0x1663800), /usr/local/go/src/runtime/proc.go:6285 +0x60 fp=0x4000139470 sp=0x4000139310 pc=0x4476e0, runtime.doInit(0x166c940), /usr/local/go/src/runtime/proc.go:6285 +0x60 fp=0x40001395d0 sp=0x4000139470 pc=0x4476e0, runtime.doInit(0x1666a20), /usr/local/go/src/runtime/proc.go:6285 +0x60 fp=0x4000139730 sp=0x40001395d0 pc=0x4476e0, runtime.doInit(0x166fd80), /usr/local/go/src/runtime/proc.go:6285 +0x60 fp=0x4000139890 sp=0x4000139730 pc=0x4476e0, runtime.doInit(0x166e9a0), /usr/local/go/src/runtime/proc.go:6285 +0x60 fp=0x40001399f0 sp=0x4000139890 pc=0x4476e0, runtime.doInit(0x166a960), /usr/local/go/src/runtime/proc.go:6285 +0x60 fp=0x4000139b50 sp=0x40001399f0 pc=0x4476e0, runtime.doInit(0x1667f80), /usr/local/go/src/runtime/proc.go:6285 +0x60 fp=0x4000139cb0 sp=0x4000139b50 pc=0x4476e0, runtime.doInit(0x1672540), /usr/local/go/src/runtime/proc.go:6285 +0x60 fp=0x4000139e10 sp=0x4000139cb0 pc=0x4476e0, runtime.doInit(0x166e3a0), /usr/local/go/src/runtime/proc.go:6285 +0x60 fp=0x4000139f70 sp=0x4000139e10 pc=0x4476e0, runtime.main(), /usr/local/go/src/runtime/proc.go:208 +0x214 fp=0x4000139fd0 sp=0x4000139f70 pc=0x4395d4, runtime.goexit(), /usr/local/go/src/runtime/asm_arm64.s:1130 +0x4 fp=0x4000139fd0 sp=0x4000139fd0 pc=0x46e3f4, , r0 0x1, r1 0x400012a3a0, r2 0x4000138eb0, r3 0x0, r4 0x0, r5 0x1049d20, r6 0x1000, r7 0x6,� r8 0xf9, r9 0x400007f13f, r10 0x1000, r11 0x1, r12 0x1033f94, r13 0x1033f95, r14 0x0, r15 0x0, r16 0x0, r17 0x6, r18 0x7f87b5d447,� r19 0xd0, r20 0x4000139708, r21 0x400048e160,� r22 0x16, r23 0x0, r24 0xffffffffffffffa2, r25 0xd8af20, r26 0x1664938, r27 0x16fc35d, r28 0x4000000180, r29 0x4000138e68, lr 0xb8dcc0, sp 0x4000138e70, pc 0xb8e4c0, fault 0x0

It gives me the impression that it is not detecting well the version of arm that it has to download and that is why it fails. any ideas?

would be great to have a --port ${DNSp1} variable so that the user could use their own port, also would be good to be able to use port 53 without resorting to root.

need to also use that variable for the health check which currently fails if you change the port.

I'm sorry if this seems out of place, but I thought I would post it here. I have been using Pihole for quite sometime on my home network, and with Cloudflare DNS for several months without issue.

A couple weeks ago I came across your blog article to use Cloudflared for DNS over HTTPS in a dockerized environment with Pihole. I switched to this method, using just the Cloudflared docker container as my DNS for Pihole.

ODDLY, the only issue I seem to experience since making this switch is with my iOS/tvOS devices. They fail to connect to Apple's servers?? to update. However... you hit retry like 2-3 times and it eventually works. This started happening after switching to the Cloudflared DNS over HTTPS.

Any idea what might be causing this? Pihole shows nothing being blocked.

could you specify a gateway option also to use with another container as vpn ?

I'm getting this error since last update:

time.c:118: Operation not permitted timer.c:634: fatal error: RUNTIME_CHECK(isc_time_now((&now)) == 0) failed Aborted

I don't know what's happening, but I found in google that maybe there is a problem with "dig"

On my AT&T network, I cannot talk to 1.1.1.1 but I can talk to 1.0.0.1.

Would it be possible to allow environmental variables to be used to pick which upstream DNS server is used so the order could be changed?

From my point of view it does not really make a difference if this container would run on port 54 or 8053 or something like that. Running on a high port by default would allow the container to run as user nobody.

I don't think we necessarily want to pull the latest master branch of cloudflared. It looks like they are now tagging official releases
https://github.com/cloudflare/cloudflared/releases

When running cloudflared --version via dgoss or docker run the version that is always returned is:
cloudflared version DEV (built unknown).

However when I download the latest release myself I get the following:
cloudflared version 2020.10.2 (built 2020-10-21-1908 UTC)

I can send a PR eventually, not a high priority. I think the DEV version still includes all the latest changes, but I haven't actually confirmed this (yet).

It's a bit odd that dockerfile-cloudflared image in docker hub contains a description not its own, but from dockerfile-domain-watcher:
https://hub.docker.com/r/visibilityspots/cloudflared

Hi there,

Are you still planning on maintaining this?
Seems like there has not been any update to the Docker image on DockerHub in a while.

Thanks!

When trying to run this image using docker compose, I am getting consistent issues with it being unable to find the manifests which I know you already created in #5. When I click on the dockerfile tab in the hub it shows a very outdated version of the file, so I was wondering if it wasn't updating correctly for some reason?

Also, would you be able to add the aarch64 tag into the manifest so that this can be run on Raspberry Pi?

I'm trying to verify whether my local image matches that of dockerhub. Running on Pi3, armv7, Docker version 20.10.6, build 370c289

Looking at latest: https://hub.docker.com/layers/visibilityspots/cloudflared/latest/images/sha256-8dca4d6083ba6564632d29f2b1628af39515b4cea31550f49ebcdc4417b9ef9a?context=explore
I see a digest of sha256:8dca4d6083ba6564632d29f2b1628af39515b4cea31550f49ebcdc4417b9ef9a for the armv7 arch.

Pulling the image docker pull visibilityspots/cloudflared:latest and running docker inspect returns a digest of sha256:98f5bf4de5b5aab77ef04faa39fd166c46a076d1145ce798ba6f760db73f7044

What am I missing here? How do I verify the images that I have match that of the servers?

Here is the full output of the inspect:

docker inspect visibilityspots/cloudflared:latest
[
    {
        "Id": "sha256:972fc30a188fde42bb7748be866f5776470560a46267ee8828d8092501e3022c",
        "RepoTags": [
            "visibilityspots/cloudflared:latest"
        ],
        "RepoDigests": [
            "visibilityspots/cloudflared@sha256:98f5bf4de5b5aab77ef04faa39fd166c46a076d1145ce798ba6f760db73f7044"
        ],
        "Parent": "",
        "Comment": "buildkit.dockerfile.v0",
        "Created": "2021-04-26T08:54:12.702960307Z",
        "Container": "",
        "ContainerConfig": {
            "Hostname": "",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": null,
            "Cmd": null,
            "Image": "",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": null
        },
        "DockerVersion": "",
        "Author": "",
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "cloudflared",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "UPSTREAM1=https://1.1.1.1/dns-query",
                "UPSTREAM2=https://1.0.0.1/dns-query",
                "PORT=5054",
                "ADDRESS=0.0.0.0",
                "METRICS=127.0.0.1:8080"
            ],
            "Cmd": [
                "/bin/sh",
                "-c",
                "/usr/local/bin/cloudflared proxy-dns --address ${ADDRESS} --port ${PORT} --metrics ${METRICS} --upstream ${UPSTREAM1} --upstream ${UPSTREAM2}"
            ],
            "Healthcheck": {
                "Test": [
                    "CMD-SHELL",
                    "nslookup -po=${PORT} cloudflare.com 127.0.0.1 || exit 1"
                ],
                "Interval": 5000000000,
                "Timeout": 3000000000,
                "StartPeriod": 5000000000
            },
            "ArgsEscaped": true,
            "Image": "",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {
                "maintainer": "Jan Collijs"
            }
        },
        "Architecture": "arm",
        "Variant": "v7",
        "Os": "linux",
        "Size": 68305008,
        "VirtualSize": 68305008,
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/8fdc89e5d92e5bcf2c071a36187a777b646f50d0db08254fbea2f09e9497b7a9/diff:/var/lib/docker/overlay2/0718ea7231173595b3cc31dac7657c7e6946dd351bf01246491d9b09b69afc21/diff:/var/lib/docker/overlay2/99fc3319d89cd7cb7905adf968400c61f9156a637f7c40cb67030ea67d5f109b/diff",
                "MergedDir": "/var/lib/docker/overlay2/fcec3668483550d89ae33d0a4134a2f05e62ce17ad2bd8c5ae9b825391efb72d/merged",
                "UpperDir": "/var/lib/docker/overlay2/fcec3668483550d89ae33d0a4134a2f05e62ce17ad2bd8c5ae9b825391efb72d/diff",
                "WorkDir": "/var/lib/docker/overlay2/fcec3668483550d89ae33d0a4134a2f05e62ce17ad2bd8c5ae9b825391efb72d/work"
            },
            "Name": "overlay2"
        },
        "RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:e678d54c933532243e4ca1cb0b7ef7d6fa4969783100e0022246bc14d83972e9",
                "sha256:a12272c41df18361eb321674f3835d3480339521bb0b62ae90aecf9074bbf7e5",
                "sha256:d35110086134dd6844390f6a3987817e04ad4fd6c155fe2c3aa047f20bd1a663",
                "sha256:ca2bbf190f72796b1968a177adafa673e208bd821e29624fb24bf7edca4ac1bd"
            ]
        },
        "Metadata": {
            "LastTagTime": "0001-01-01T00:00:00Z"
        }
    }
]

Hi,

I'm using Kubernetes and when I add the argument --lb-pool I get this message

Incorrect Usage. flag provided but not defined: -lb-pool frontend-lb-pool-a0edd36a

It looks like the "--lb-pool" is seen as "-lb-pool"

Is it an issue on your end or is it cloudflared?

i want to add new zone like in bind9 or a simple A record for my local domain something like this

traefik.local.mydomain.site         192.168.1.3

is something like this possible ?

In addition to #24 (which is still giving the same error) it seems there are couple errors within the build output:
https://travis-ci.org/github/visibilityspots/dockerfile-cloudflared/jobs/737883452

1. The command '/bin/sh -c setcap CAP_NET_BIND_SERVICE+eip /usr/local/bin/cloudflared' returned a non-zero code: 127
   The command "docker build -t visibilityspots/cloudflared:$TAG --build-arg ARCH="$ARCH" --build-arg GOARCH="$GOARCH" --build-arg GOARM="$GOARM" ./" exited with 127.

2. Error: Cannot perform an interactive login from a non TTY device
   The command "echo "$DOCKER_PASSWORD" | docker login --username visibilityspots --password-stdin" exited with 1.

3. denied: requested access to the resource is denied
   unauthorized: authentication required
   The command "docker push visibilityspots/cloudflared:$TAG" exited with 1.

Error 3 is expected because of 2, no clue what the impact of 1 is will need to research.

Hello, is there a way to edit a config.yml file ? I did not find it in the container

I'm trying to use volumes in order to store pihole's config file outside of my container. This would allow me to easily upgrade my container whenever pihole's latest changes. See this example from pihole's repo.

However, whenever I add the volumes section to my docker-compose file, it ends up breaking my cloudflared container. The container will keep on running and can't see anything weird in my container's logs, but DoH (DNS over HTTPS) stops working. I'm using https://1.1.1.1/help in order to verify this. As soon as I leave out the volumes section and re-run docker-compose up, everything works fine 🤷, which is driving me nuts.

My docker-compose.yml file:

version: "3.8"

services:
  cloudflared:
    image: visibilityspots/cloudflared:amd64
    container_name: cloudflared
    environment:
      TZ: '${TIMEZONE}'
    restart: unless-stopped
    networks:
      pihole_net:
        ipv4_address: 10.0.0.2

  pi-hole:
    image: pihole/pihole:latest
    container_name: pihole
    restart: unless-stopped
    ports:
        - "53:53/tcp"
        - "53:53/udp"
        - "67:67/udp"
        - "80:80/tcp"
        - "443:443/tcp"
    environment:
      ServerIP: 10.0.0.3
      DNS1: '10.0.0.2#5054'
      DNS2: ''
      TZ: '${TIMEZONE}'
      DNSMASQ_LISTENING: all
      WEBPASSWORD: admin
    volumes:
      - './etc-pihole/:/etc/pihole/'
      - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
    networks:
      pihole_net:
        ipv4_address: 10.0.0.3
    dns:
      - 127.0.0.1
      - 1.1.1.1
    cap_add:
      - NET_ADMIN

networks:
  pihole_net:
    driver: bridge
    ipam:
     config:
       - subnet: 10.0.0.0/29

I'm running this container on some raspberry pi's and have done so for some time. I was setting it up tonight and for whatever reason it keeps marking the container as unhealthy with the recurring complaint:

time.c:118: Operation not permitted timer.c:634: fatal error: RUNTIME_CHECK(isc_time_now((&now)) == 0) failed Aborted

I can't really figure out what, if anything, is actually wrong because the container functionally works just fine. So I think it's the health check and specifically the nslookup binary that is throwing the error not the command itself. Consoling into the container and just running "nslookup" throws that error. I'm happy to help troubleshoot this if it is helpful.

I'm trying to start a container based on your image from Docker Hub using my Synology NAS, but it fails to startup everytime with the following error:

Failed to open the metrics listener: listen tcp 192.64.119.253:0: bind: cannot assign requested address

I'm using all of the default configurations with host networking. Is there some configuration I need to change?

Missing example for docker-compose.yml

Would it be possible to implement the fix in your docker image?

cloudflare/cloudflared#91 (comment)

Default $DNS values are currently hard coded into the docker build, and only the $UPSTREAM variables are set dynamically at runtime.

This is more a heads up not an issue

If you use this tool to redirect pihole traffic as upstream DNS Server

Be aware if you have local A records on your local network and use this tool/docker container to use DOH you will need to blakcli
SVCB _dns.resolver.arpa for iPhones as this will just push all dns to apple. After blacklisting this on pihole I managed to get my internal A records to work and DOH to work aswell.

I can't pull your docker container

Is TimeZone used in the dockerfile?

First off I love the docker container and my DNS privacy thanks you!

About once a week or so my DNS just takes a dump and I have not been able to figure out what the issue is and after multiple restarts and time passing it just seems to clear sometimes.

At first I thought it was a cloudflare issue, but I have a buddy that has a similar setup but without the docker and he does not seem to have any problems and according to cloudflared's site they are not having any downtime issues.

I also tried to switch the 1.1.1.1 and whatever there other one is as the primary and it did not seem to make a difference either.

Was thinking it might have something to do with the caching but I was not able to figure out if there is a way to change the cache timeout.

This is what I pull from the logs.

time="2019-07-25T09:35:03Z" level=error msg="failed to connect to an HTTPS backend "https://1.1.1.1/.well-known/dns-query\"" error="failed to perform an HTTPS request: Post https://1.1.1.1/.well-known/dns-query: net/http: request canceled (Client.Timeout exceeded while awaiting headers)",
time="2019-07-25T09:35:05Z" level=error msg="failed to connect to an HTTPS backend "https://1.0.0.1/.well-known/dns-query\"" error="failed to perform an HTTPS request: Post https://1.0.0.1/.well-known/dns-query: net/http: request canceled (Client.Timeout exceeded while awaiting headers)",
time="2019-07-25T09:35:05Z" level=error msg="failed to connect to an HTTPS backend "https://1.1.1.1/.well-known/dns-query\"" error="failed to perform an HTTPS request: Post https://1.1.1.1/.well-known/dns-query: net/http: request canceled (Client.Timeout exceeded while awaiting headers)",
time="2019-07-25T09:35:08Z" level=error msg="failed to connect to an HTTPS backend "https://1.1.1.1/.well-known/dns-query\"" error="failed to perform an HTTPS request: Post https://1.1.1.1/.well-known/dns-query: net/http: request canceled (Client.Timeout exceeded while awaiting headers)",

Thanks again for this container and hopefully I can figure out this one and only issue I have had.

UPDATE: 7-25-19 4:30PM Pacific

I found this in my googling, but my WAN IP does not change, or has not changed in a couple years.

https://community.cloudflare.com/t/solved-1-1-1-1-over-cloudflared-linux-nonstandard-port-fails-after-some-time/14856

Is it possible to map/mount locally the /cloudflared directory to don't lose the tunnel json and de config.yml after a container update?

Hola buenas tardes

funciona el contenedor a nivel local y acepta las peticiones de los contenedores que se desplieguen en su misma red pero desde otros equipos externos al host donde esta ejecutándose no funciona.

me pueden ayudar por favor

un saludo

Hi please provide a latest image using a mainfest which supports multi arch. This is a working example:
https://github.com/runningman84/docker-kube-router/blob/master/manifest.yaml
Right now it is not possible to pull the latest tag...

I was running some tests using the image hosted on DockerHub and found out it runs cloudflared on port 54 instead of 5054. On the README port 5054 is stated as the default.
Which of the 2 should be the expected behavior?

Hi,
Since the 2th of September all Travis CI builds on arm and arm64 architectures have failed with “CRON Fix: credential update” error, while the builds on amd64 architecture were successful.

The last docker image also doesn’t actually work properly, i have noticed the following errors in the logs:

time="2019-10-14T17:24:22Z" level=error msg="failed to connect to an HTTPS backend \"https://1.0.0.1/.well-known/dns-query\"" error="failed to perform an HTTPS request: Post https://1.0.0.1/.well-known/dns-query: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)"

Please fix the buils.

usefull links:
https://hub.docker.com/r/visibilityspots/cloudflared/tags?page=1&name=arm
https://travis-ci.org/visibilityspots/dockerfile-cloudflared/builds