Не удается обновить / отправить письма / загрузить темы... Проблема с Docker?

Поддержка
1

Здравствуйте,

В последние дни у нас внезапно возникла проблема с отправкой писем… Затем мы попытались обновить систему, но безрезультатно (страница обновления зависает, и каждый компонент — Docker, Discourse, плагины — застревает на этапе «Проверка новой версии…»). После этого мы попытались обновить всё через root, но процесс rebuild завершился ошибкой со следующим сообщением (среди прочего):

fatal: unable to access 'https://github.com/discourse/discourse.git/': Could not resolve host: github.com

Наш хостинг-провайдер подтвердил, что проблем с подключением сервера, SSL, фаерволом или чем-либо другим нет.

Я подозреваю, что проблема связана с Docker. Я даже проверил эту тему: Docker иногда не может подключиться к github.com — Установка — Discourse Meta и выполнил следующие команды:

# cd /var/discourse/
# ./launcher enter app
# wget -O - -v https://github.com/discourse/logster.git/ |wc

Получил следующий результат:

--2025-02-28 09:45:51--  https://github.com/discourse/logster.git
Resolving github.com (github.com)... failed: Temporary failure in name resolution.
wget: unable to resolve host address 'github.com'
      0       0       0

Есть ли у кого-нибудь идеи, как решить эту проблему?

2

Работаете ли вы в особой территории, например, в материковом Китае?

Сначала проверьте DNS на вашем хосте, а затем DNS внутри вашего Docker-контейнера.

Проверка DNS на хосте:

resolvectl status|egrep Servers
nslookup github.com

Проверка DNS внутри Docker:

docker exec -it app bash -c "cat /etc/resolv.conf"
docker exec -it app bash -c "wget -O - -v https://github.com/discourse/logster.git/ |wc"
3

Хорошо, вот ситуация:

DNS на хосте:

#resolvectl status|egrep Servers
DNS-серверы: 8.8.8.8
Резервные DNS-серверы: 8.8.8.8
DNS-серверы: 8.8.8.8 8.8.4.4

#nslookup github.com
Сервер: 8.8.8.8
Адрес: 8.8.8.8#53

Неавторитетный ответ:
Имя:   github.com
Адрес: 140.82.112.3

DNS в Docker:

#docker exec -it app bash -c "cat /etc/resolv.conf"
# Сгенерировано Docker Engine.
# Этот файл можно редактировать; Docker Engine не будет вносить дальнейшие изменения после его
# модификации.

nameserver 8.8.8.8
nameserver 8.8.4.4

# Основано на файле хоста: '/etc/resolv.conf' (устаревший)
# Переопределения: [nameservers]

#docker exec -it app bash -c "wget -O - -v https://github.com/discourse/logster.git/ |wc"
--2025-02-28 12:20:17--  https://github.com/discourse/logster.git/
Разрешение github.com (github.com)... не удалось: временная ошибка при разрешении имени.
wget: не удалось разрешить адрес хоста «github.com»
      0       0       0

P.S: Наш хост работает в Канаде.

4

Спасибо… Я понятия не имею, как это могло произойти, но я не эксперт по Docker.

Какая у вас операционная система хоста и как вы установили Discourse? Использовали ли вы пакет, предоставленный хостинг-провайдером, или это стандартная установка? (Или установка для разработки??) Как вы установили Docker?

Но всё это раньше работало, а потом перестало, так что, возможно, проблема связана с Docker. Может быть, вы сможете обновить свою установку Docker??

5

Это стандартная установка, которая работала очень хорошо в AlmaLinux в последние несколько месяцев (а до этого тоже отлично в CentOS).

Как можно обновить установку Docker (без обычных инструкций по пересборке с помощью лаунчера или через веб-сайт, так как ни один из этих методов, похоже, не работает)?

6

Прежде чем продолжить, сделайте резервную копию (если это возможно) и загрузите локальную копию. (Попробуйте, например, переместить сайт Discourse на другой VPS с помощью rsync)

Попробуйте выполнить следующие команды, они могут дать подсказку:

docker --version
docker run hello-world
7

С небольшой помощью ChatGPT я выяснил, что проблема заключается в конфигурации сети Docker Bridge или в чём-то подобном.

Я попробовал несколько решений, но пока без успеха. Это я ещё не пробовал:

На изображении показаны шаги для ручного сброса сети Docker: остановка Docker, удаление каталога сети и перезапуск Docker. (Подпись сгенерирована ИИ)
На изображении показаны шаги для ручного сброса сети Docker: остановка Docker, удаление каталога сети и перезапуск Docker. (Подпись сгенерирована ИИ)1170×727 54.6 KB

Безопасно ли это для производственной среды? (даже если это приведёт к кратковременному простою)

8

Боюсь, я не знаю. Надеюсь, у вас есть актуальная резервная копия. Возможно, наименее нарушающим работу решением будет перезагрузка.

9

Я просто публикую обновление по ситуации. Проблема была решена с помощью ChatGPT.

После попыток различных решений этот шаг показал, что возникла проблема с разрешениями или политиками безопасности:

  1. Попробуйте запустить контейнер с флагом --privileged

Это обходит некоторые ограничения, которые могут влиять на работу сети.

docker run --rm --privileged alpine ping -c 4 github.com

Если это сработает, значит, проблема в разрешениях или политиках безопасности.

После этого я применил следующую рекомендацию:

  1. Снова проверьте правила iptables

Поскольку Docker зависит от iptables, давайте убедимся, что у него правильные правила пересылки.

Выполните:

sudo iptables -t nat -L -v -n | grep -i docker

Если правила, связанные с Docker, не отображаются, добавьте их вручную:

sudo iptables -P FORWARD ACCEPT

sudo iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT

sudo iptables -t nat -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE

Затем перезапустите Docker:

sudo systemctl restart docker

И снова выполните тест.

… что полностью решило проблему. :grin: