Caddy 2 not running in Docker: "cannot assign requested address" - caddy

I'm trying to run the official Caddy 2 docker image. According to that page, to do that you should run:
docker run -p 80:80 \
-v $PWD/index.html:/usr/share/caddy/index.html \
-v caddy_data:/data \
caddy
When I run this, I get the following error:
{"level":"info","ts":1590185286.853735,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
run: loading initial config: loading new config: starting caddy administration endpoint: listen tcp 45.90.28.0:2019: bind: cannot assign requested address
I'm not sure why it's trying to bind to that IP address by default? I tried changing it in the Caddyfile but it still doesn't bind correctly, and anyway that doesn't really solve the underlying issue here.
What could be causing this problem? Should I be using Caddy 1 instead?

I experienced this issue recently on Linux and the root cause for me was that my ISP supplied routers DNS server was resolving localhost to an incorrect IP address.
You might want to try changing your DNS servers to Cloudflare's 1.1.1.1 or Google's 8.8.8.8 servers.

Related

Nextcloud with Traefik - Bad Gateway / Connection Refused

I recently installed Nextcloud over a lamp stack and want to run Traefik in front. For that, I tweaked the apache2 ports.conf to:
Listen: 127.0.0.1:180
. Now I also configured a .toml for Traefik that points to this address.
When I try to open the website, it gives me "Bad Gateway".
Trying to solve the error I searched the Traefik logs and found this:
msg="'502 Bad Gateway' caused by: dial tcp 127.0.0.1:180: connect: connection refused"
Thinking it must be a problem with trusted_proxies I configured Apache to open it's port to the public and also changed the Traefik .toml to see wheter it would work.
It did. That means that Nextcloud definetly accepts my proxy and the proxying works all good.
Problem is, It doesn't work when I configure it on localhost.
The access.log and nextcloud.log show nothing.
Any help?
Many thanks
The solution is simple, but hidden.
Traefik is a Docker container, so normally it can't communicate with services not in the docker network.
The fix is:
ip addr show docker0
Bind Apache2 to this IPv4: (my example) Listen 172.17.0.1:180 and also modify the Traefik Config.
Then Apache2 will listen on the docker0 network which containers have access to.

Is there a way to specify hostname when starting container on azure cloud instance

I have been trying to setup a docker image on Azure and am running into an issue.
The image has been designed to require a -h hostname argument when starting it using the docker commands.
The image is here: https://hub.docker.com/r/sverhoeven/cartodb/
I can't translate these commands into something I can do on Azure.
The options for -h are as follows:
How to use a different hostname:
For example to use cartodb.example.com as a hostname start with:
docker run -d -p 80:80 -h cartodb.example.com sverhoeven/cartodb
The chosen hostname should also resolve to an IP adress of the machine where the web server is running.
If you don't have a domain/subdomain pointing to your server yet, you can use the servers external ip address:
docker run -d -p 80:80 -h <servers-external-ip-address> sverhoeven/cartodb
Here is what happens by not telling the image what hostname to use - Note, when you don't specify the hostname, it defaults to localhost. I am seeing a lot of 127.0.0.1 in the log output and some references to localhost. That is concerning.:
Started GET "/" for 127.0.0.1 at 2018-06-20 01:53:59 +0000
Processing by Admin::PagesController#index as */*
...
Redirected to http://localhost/login
...
Started GET "/favicon.ico" for 127.0.0.1 at 2018-06-20 01:54:25 +0000
ActionController::RoutingError (No route matches [GET] "/favicon.ico"):
...
Started POST "/sessions/create" for 127.0.0.1 at 2018-06-20 01:54:39 +0000
Started GET "/user/dev/dashboard/" for 127.0.0.1 at 2018-06-20 01:54:39 +0000
I am looking for suggestions or solutions.
Note: This is tangentially related to another question I asked concerning the carto image here.
After going around and around, the short answer is no, this is not possible right now. Workaround is to use an environment variable

Elasticsearch connecting to some random IP

Whenever I am executing curl command to query my Elasticsearch Instance, I am seeing it is trying to connect to random IP 208.73.211.70
curl -4 -u admin:root123 localhost:9200/amas/tasks/_search?pretty -v
* About to connect() to localhost port 9200 (#0)
* Trying 208.73.211.70...
I have not configured this IP anywhere in my configuration. Does anyone have idea what might be happening ?
That's something cURL is doing. If there is no Elasticsearch instance running on 208.73.211.70 it's not even reaching Elasticsearch.
Maybe you have a weird settings in hosts or some broken DNS entries?
Entry for localhost was missing in my /etc/hosts file. Because of which localhost was getting resolved to my domain address instead of 127.0.0.1. Adding localhost entry in /etc/hosts file resolved it.

Docker daemon and DNS

I am trying to force the docker daemon to use my DNS server which is binded to bridge0 interface.
I have added --dns 172.17.42.1 in my docker_opts but no success
DNS server reply ok with dig command:
dig #172.17.42.1 registry.service.consul SRV +short
1 1 5000 registry2.node.staging.consul.
But pull with this domain fails:
docker pull registry.service.consul:5000/test
FATA[0000] Error: issecure: could not resolve "registry.service.consul": lookup registry.service.consul: no such host
PS: By adding nameserver 172.17.42.1 in my /etc/resolv.conf solve the issue but the DNS has to be exclusively for docker commands.
Any idea ?
You passed --dns 172.17.42.1 to docker_opts, so since that you should be able to resolve the container hostnames from inside other containers. But obviously you're doing docker pull from the host, not from the container, isn't it? Therefore it's not surprising that you cannot resolve container's hostname from your host, because it is not configured to use 172.17.42.1 for resolving.
I see two possible solutions here:
Force your host to use 172.17.42.1 as DNS (/etc/resolv.conf etc).
Create a special container with Docker client inside and mount docker.sock inside it. This will make you able to use all client commands including pull:
docker run -d -v /var/run/docker.sock:/var/run/docker.sock:rw --name=client ...
docker exec -it client docker pull registry.service.consul:5000/test

Docker DNS issue on local machine

I have an issue with Docker not resolving my local DNS. Running even a basic ping will no longer work. Current version 0.11.1 running on Fedora 20. The last time I worked with docker (version 0.9) everything was fine.
sudo docker run base ping google.com
ping: unknown host google.com
My local DNS is resolving fine outside of Docker and I don't have localhost (127.0.0.1) set in my resolv.conf file. I have also tried setting the dns with the same outcome:
sudo docker run --dns=8.8.8.8 base ping google.com
ping: unknown host google.com
Any help would be greatly appreciated.
If anyone else has this issue I got it working by clearing out the iptables:
iptables -F
For a more permanent solution after restarting I listed the iptables before and after flushing but couldn't really see what was affecting it. I ended up loading the Firewall Configuration, and enabling the Masquerade zone worked. Not sure why this setting had changed or if a change in newer Docker versions now needed this to be set, but it works. Interestingly I had previously tried just enabling IP forwarding (sysctl -w net.ipv4.ip_forward=1), but this had no effect for me.

Resources