Я запускаю набор служб в среде Docker. Все службы находятся за одним и тем же контейнером обратного прокси-сервера nginx, который шифрует с помощью letsencrypt и разделяет входящий трафик на основе поддоменов.
Сегодня внезапно (пока я возился с другой службой) мой контейнер Nextcloud начал возвращать 502 Bad Gateway
при доступе через обратный прокси.
Все остальные службы в порядке.
При проверке ошибки .log
, в который nginx записывает эти ошибки. Я вижу много таких ошибок:
512 connect() failed (111: Connection refused) while connecting to upstream
Это заставляет меня думать, что что-то не так с экземпляром контейнера Nextcloud.
Итак, я проверил состояние контейнера (я недавно перезапустил систему, поэтому до 13 минут):
docker ps -a | grep Nextcloud
6a4cd6dde4f6 nextcloud:21.0.1 "/entrypoint.sh apac…" About an hour ago Up 13 minutes 80/tcp Nextcloud
Здесь все в порядке. Поэтому я проверил вывод контейнера, запустив docker-compose в терминале (в отличие от его запуска как демона в фоновом режиме), который вообще не дал мне нового интересного вывода. Мои обновления браузера, похоже, вообще не доходили до контейнера Nextcloud.
После этого я хотел проверить, реагирует ли контейнер Nextcould вообще, поэтому я перенаправил порт хоста 5555 на порт 80 контейнера nextcloud и подключился к IP-адресу хоста напрямую через порт 5555. Это сработало. Я получил страницу «Доступ через ненадежный домен», что имеет смысл, поскольку я обращался к ней напрямую через IP-адрес хоста.
Хорошо, значит, обратный прокси-контейнер обнаруживает , в соединении отказано
, а контейнер Nextcloud вообще не получает никаких запросов, но, похоже, в остальном работает нормально.
Затем я создал временный контейнер для устранения неполадок Ubuntu и подключил его к той же сети докеров, что и обратный прокси-контейнер и контейнер Nextcloud. После установки некоторых инструментов я выполнил следующие команды:
root@491b7ef0f34f:/# ping Nextcloud
PING Nextcloud (10.10.7.3) 56(84) bytes of data.
64 bytes from Nextcloud.couplernets_nextcloud (10.10.7.3): icmp_seq=1 ttl=64 time=0.127 ms
64 bytes from Nextcloud.couplernets_nextcloud (10.10.7.3): icmp_seq=2 ttl=64 time=0.080 ms
64 bytes from Nextcloud.couplernets_nextcloud (10.10.7.3): icmp_seq=3 ttl=64 time=0.083 ms
64 bytes from Nextcloud.couplernets_nextcloud (10.10.7.3): icmp_seq=4 ttl=64 time=0.085 ms
^C
--- Nextcloud ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.080/0.093/0.127/0.019 ms
root@491b7ef0f34f:/# nmap -sV -p- Nextcloud
Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-25 18:43 UTC
Nmap scan report for Nextcloud (10.10.7.3)
Host is up (0.0000090s latency).
rDNS record for 10.10.7.3: Nextcloud.couplernets_nextcloud
Not shown: 65534 closed ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.38 ((Debian))
MAC Address: 02:42:0A:0A:07:03 (Unknown)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/
Nmap done: 1 IP address (1 host up) scanned in 7.64 seconds
root@491b7ef0f34f:/# wget Nextcloud:80/index.html
--2021-04-25 18:45:28-- http://nextcloud/index.html
Resolving nextcloud (nextcloud)... 10.10.7.3
Connecting to nextcloud (nextcloud)|10.10.7.3|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 156 [text/html]
Saving to: 'index.html.1'
index.html.1 100%[===================>] 156 --.-KB/s in 0s
2021-04-25 18:45:28 (7.66 MB/s) - 'index.html.1' saved [156/156]
Это говорит мне, что экземпляр Nextcloud должен быть в порядке, поскольку его порт открыт, и я могу получить доступ к файлу index.html
без проблем.
Затем я пошел проверить конфигурацию обратного прокси-сервера nginx.
server {
listen 443 ssl;
listen [::]:443 ssl;
#Add HSTS preload header
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
#Remove revealing headers
server_tokens off;
proxy_hide_header X-Powered-By;
server_name <cloud.domain.topdomain>;
include /config/nginx/ssl.conf;
client_max_body_size 0;
location / {
include /config/nginx/proxy.conf;
proxy_max_temp_file_size 2048m;
proxy_pass http://Nextcloud:80/;
}
}
Эта конфигурация такая же, как и у всех других служб, которые проходят через тот же контейнер обратного прокси. Единственное, что отличается, - это параметры конфигурации server_name
и proxy_pass
.
Отсюда я понятия не имею, что мне попробовать дальше. Помогите, пожалуйста. Любая помощь очень ценится.
Оказалось, что проблема была во внутреннем разрешении имен IP в контейнере Docker, который вел себя странно.
Когда я подключился к контейнеру обратного прокси и выполнил ping Nextcloud
, контейнер неправильно разрешил IP-адрес контейнера Nextcloud. Поэтому всякий раз, когда я пытался отправить что-либо в контейнер Nextcloud, сетевой уровень docker неправильно определял IP контейнера Nextloud и отправлял трафик в неправильный контейнер, что приводило к отказу в подключении.
Моим решением было отключить контейнер, который был неправильно разрешен. После этого к моему контейнеру Nextcloud можно было обратиться, используя имя хоста "Nextcloud".
Что вызвало проблему, остается неясным. Я вернусь сюда, если когда-нибудь узнаю.