호스트를 찾을 수 없음: github.com

안녕하세요,

./launcher rebuild app

fatal: unable to access ‘GitHub - discourse/discourse: A platform for community discussion. Free, open, simple. · GitHub’: Could not resolve host: github.com

하지만

root@discourse:/var/discourse# host github.com
github.com has address 140.82.121.3
github.com mail is handled by 1 aspmx.l.google.com.
github.com mail is handled by 10 alt4.aspmx.l.google.com.
github.com mail is handled by 10 alt3.aspmx.l.google.com.
github.com mail is handled by 5 alt1.aspmx.l.google.com.
github.com mail is handled by 5 alt2.aspmx.l.google.com.

아무런 아이디어가 없나요?

감사합니다


FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -H -E -u discourse bash -c '
  set -o errexit
  if [ $(git rev-parse --is-shallow-repository) == "true" ]; then
      git remote set-branches --add origin main
      git remote set-branches origin tests-passed
      git fetch --depth 1 origin tests-passed
  else
      git fetch --tags --prune-tags --prune --force origin
  fi
' failed with return #<Process::Status: pid 144 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"code", "cmd"=>["sudo -H -E -u discourse git clean -f", "sudo -H -E -u discourse bash -c '\n  set -o errexit\n  if [ $(git rev-parse --is-shallow-repository) == \"true\" ]; then\n      git remote set-branches --add origin main\n      git remote set-branches origin $version\n      git fetch --depth 1 origin $version\n  else\n      git fetch --tags --prune-tags --prune --force origin\n  fi\n'", "sudo -H -E -u discourse bash -c '\n  set -o errexit\n  if [[ $(git symbolic-ref --short HEAD) == $version ]] ; then\n      git pull\n  else\n      git -c advice.detachedHead=false checkout $version\n  fi\n'", "sudo -H -E -u discourse git config user.discourse-version $version", "mkdir -p tmp", "chown discourse:www-data tmp", "mkdir -p tmp/pids", "mkdir -p tmp/sockets", "touch tmp/.gitkeep", "mkdir -p                    /shared/log/rails", "bash -c \"touch -a           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log\"", "bash -c \"ln    -s           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log $home/log\"", "bash -c \"mkdir -p           /shared/{uploads,backups}\"", "bash -c \"ln    -s           /shared/{uploads,backups} $home/public\"", "bash -c \"mkdir -p           /shared/tmp/{backups,restores}\"", "bash -c \"ln    -s           /shared/tmp/{backups,restores} $home/tmp\"", "chown -R discourse:www-data /shared/log/rails /shared/uploads /shared/backups /shared/tmp", "[ ! -d public/plugins ] || find public/plugins/ -maxdepth 1 -xtype l -delete"]}
bootstrap failed with exit code 128

그것은 컨테이너 내부에 있으므로 Docker 네트워킹 문제일 수도 있고, 일시적인 문제였을 수도 있습니다.

컨테이너가 기본적으로 호스트의 /etc/resolv.conf를 사용합니까? nameserver 127.0.0.1과 같은 로컬 리졸버가 있는 경우, 컨테이너 내부에서는 해당 리졸버에 접근할 수 없을 것으로 추측됩니다. Unbound는 Docker 컨테이너에 사용되는 172.16.0.0/12를 포함하여 모든 예약된 IP 범위에서 쿼리를 허용하도록 구성되어 있으므로, 이것이 문제는 아닙니다.

다만 재빌드 시에도 동일한 문제가 발생하고, 그 사이 자체 Unbound를 설정했으며, 해당 줄을 제거하여 /etc/resolv.conf가 이전처럼 nameserver 1.1.1.1만 포함하도록 변경한 후에도 재빌드가 여전히 같은 지점에서 실패합니다. 그래서 어딘가에 캐시되어 있는 건가요? :thinking:

호스트에서는 github.com을 문제없이 이름 해석할 수 있습니다.

수정: 아니, 이제 /etc/resolv.conf는 문제가 아닙니다. 디버그 출력을 추가했습니다:

I, [2025-09-25T17:32:38.092043 #1]  INFO -- : > cd /var/www/discourse && cat /etc/resolv.conf
I, [2025-09-25T17:32:38.093195 #1]  INFO -- : # Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 1.1.1.1

# Based on host file: '/etc/resolv.conf' (legacy)
# Overrides: []

I, [2025-09-25T17:32:38.093221 #1]  INFO -- : > cd /var/www/discourse && getent hosts github.com
I, [2025-09-25T17:32:58.111177 #1]  INFO -- :
I, [2025-09-25T17:32:58.111456 #1]  INFO -- : Terminating async processes

수정: apt update도 영원히 멈추고, 네트워크가 온라인인지 확인하기 위해 Discourse 템플릿에 추가한 테스트 curl도 실패합니다. nameserver 9.9.9.9도 작동하지 않으므로, 컨테이너에 네트워크 접근 권한이 없는 것 같지만 그 이유는 모르겠습니다.

… 수정2: 네, 우리의 경우 Fail2Ban이 잘못된 사용자 계정 이메일 주소를 사용하여 이메일을 보내려다 컨테이너 IP를 차단하여 Postfix 필터가 트리거되었습니다 :smile:.

따라서 컨테이너에 네트워크가 없는 경우 Fail2Ban을 확인하는 것이 디버그 단계가 될 수 있습니다.

수정3: Fail2Ban의 jail 설정에서:

ignoreip = 127.0.0.1/8 172.16.0.0/12

루프백 및 Docker IP가 차단되는 것을 방지하기 위해 설정했습니다.