바라건대, 당신이 이 기사를 읽을 필요가 없고, 당신이 지루하거나 잘못된 종류의 검색을 했기 때문에 여기에 있는 것일 뿐입니다. 또는 Docker 컨테이너가 최근에 잘 작동했고 환경을 변경하지 않았음에도 불구하고 실제로 Docker 컨테이너가 더 이상 인터넷에 액세스할 수 없는 문제에 직면할 수 있습니다.
이것은 매우 모호한 문제 진술처럼 들리지만 이것은 내가 갑자기 직면한 것입니다. 내 컨테이너는 임시 오류 해결 URL과 같은 오류와 함께 네트워크 액세스 권한이 없습니다. 그것은 이름 확인과 관련된 문제처럼 보였고, 발생하지 않아야 했기 때문에 저를 더욱 괴롭혔습니다. 그러나 우리는 앞서 나가고 있습니다. 테스트 호스트:systemd가 있는 Ubuntu - 후자에 중요합니다. 천천히 진행합시다.
자세한 문제
시스템에 Docker를 구성했습니다. 잘 작동합니다. 여러 이미지, 여러 컨테이너가 있고 고급 네트워크 규칙도 사용했으며 모든 것이 완벽하게 정리된 것 같습니다. 그런 다음 업데이트나 패키지 설치와 같은 컨테이너에서 특정 활동을 더 이상 수행할 수 없음을 알게 됩니다. 이를 디버깅하는 가장 좋은 방법은 소개 가이드에서 설명한 것처럼 실행 중인 컨테이너 인스턴스에 셸을 연결하는 것입니다. 실제로 실행 중인 컨테이너 내부에는 다음과 같은 내용이 표시됩니다.
# apt-get update
Err:1 https://archive.ubuntu.com/ubuntu bionic InRelease
일시적인 실패로 'archive.ubuntu.com' 해결
0% [보안 연결 중. ubuntu.com]
이것은 DNS 문제(이름 확인)처럼 보입니다. 컨테이너는 도메인 이름을 IP 주소로 확인하는 방법을 파악할 수 없으므로 업데이트와 같은 데이터를 가져오기 위해 서버에 연결할 수 없습니다. 여기에는 두 가지 문제가 있습니다. 하나, 왜 갑자기 문제가 발생했는가? 둘째, 실제로 네트워크를 수정해야 합니다. 이제 이 문제를 우아하게 해결하는 방법을 보여드리겠습니다.
솔루션
먼저 문제가 발생한 이유를 이해합시다. 여기에 즉각적인 대답은 없지만 살펴봐야 할 몇 가지 사항에는 즉각적인 환경 이상의 것이 포함될 수 있습니다. 예를 들어 호스트는 변경되지 않았지만 네트워크에는 라우터, 네트워크 정책, DNS 서버 자체가 있을 수 있습니다. 일반적으로 즉각적인 설정 외부에서 발생하는 상황을 제어할 수 없으므로 문제가 있는 위치를 파악하는 가장 좋은 방법은 문제를 단계별로 격리하는 것입니다.
- 호스트 시스템에 네트워크가 있고 URL을 확인할 수 없는 경우 먼저 이를 분류해야 합니다. 호스트와 대상 사이, 그리고 그 사이에 존재하는 모든 네트워크 인프라에 문제가 있을 가능성이 큽니다.
- 호스트 시스템에 네트워크가 있고 URL을 올바르게 확인할 수 있는 경우 특히 Docker 컨테이너가 URL을 확인하는 방법에 문제가 있습니다. 이것이 우리가 다음에 집중해야 할 부분입니다.
- Docker 네트워크 인터페이스가 실행 중인지 확인합니다(ip 또는 ifconfig와 같은 명령 사용). 그렇지 않은 경우 다음 단계로 이동하기 전에 먼저 수정해야 합니다.
ifconfig 도커0
- 컨테이너 인스턴스에 IP 주소가 있는지 확인합니다. 그렇지 않은 경우 수정해야 합니다.
docker inspect <컨테이너 이름 또는 ID> | grep -i "ipaddr"
- 가능한 경우 컨테이너 내에서 동일한 결과를 얻는지 확인하십시오(ip 또는 ifconfig). 결과가 이전 명령에서 본 것과 일치하지 않으면 수정해야 합니다.
- 컨테이너를 외부에서 ping할 수 있는지 확인하십시오(ping 명령을 사용할 수 있는 경우 그 반대도 가능). ping이 작동하면 네트워크가 올바르게 구성되었고 트래픽을 차단하는 방화벽 규칙이 없다는 좋은 표시일 수 있습니다(대부분).
이름 확인
이러한 모든 검사에서 이상한 문제나 오류가 반환되지 않으면 다음 단계는 DNS 확인에 집중하는 것입니다. 이에 대한 구성은 /etc/resolv.conf 구성 파일에서 사용할 수 있습니다. 이는 Linux의 물리적 인스턴스와 가상 머신 및 컨테이너 모두에 해당됩니다. 컨테이너가 다음과 같은 것을 사용한다는 것을 알 수 있을 것입니다.
...
# 지원되는 모드에 대한 자세한 내용은 man:systemd-resolved.service(8)를 참조하십시오.
# /etc/resolv.conf 작업.
xyz 검색
네임서버 X.Y.Z.W
...
네임서버 IP 주소는 대부분 외부 IP 주소(ISP와 같은 것) 또는 localhost(127.0.0.X)일 것입니다. 질문:이것이 호스트의 /etc/resolv.conf 파일과 일치합니까?
답은 아마도 호스트의 /etc/resolv.conf 파일에 localhost가 정의되어 있을 것입니다. 이제 컨테이너에서 시도해 보십시오. resolv.conf 파일을 편집하고 nameserver 줄의 IP 주소를 호스트 값 =localhost와 일치하는 주소로 바꿉니다. 문제가 해결된다면 좋습니다. 하지만 그렇지 않을 가능성이 높습니다.
그러나 이 시점에서 호스트의 네트워크 연결에 문제가 없습니다. 따라서 사용자 환경에서 DNS 서버의 REAL 주소를 파악해야 합니다. 그리고 이것은 대부분의 최신 Linux 배포판이 systemd를 사용한다는 사실로 인해 더욱 복잡해집니다. 음모가 두꺼워집니다.
systemd로 DNS 찾기
네. 우리는 네임서버가 무엇인지 파악해야 하며 이를 위해 systemd 명령을 사용해야 합니다. 대부분의 경우 시스템에 systemd가 있는 경우 네트워크 이름 확인 관리자 및 서비스인 systemd-resolve도 사용하고 있습니다. 구성은 /etc/systemd/resolved.conf에 저장됩니다. 그러나 systemd-resolve 명령을 사용하여 명령줄에서 결과를 얻을 수도 있습니다.
systemd-resolve --status
링크 3(wlp59s0)
현재 범위:DNS
LLMNR 설정:예
MulticastDNS 설정:아니요
DNSSEC 설정:아니요
DNSSEC 지원:아니요
DNS 서버:10.50.34.1
2001:64c:1462:b023::1
DNS 도메인:dedoimedo
여기에 무엇이 있습니까? 흥미로운 것들이 많이 있습니다. 그러나 정말로 중요한 것은 DNS 서버를 읽는 줄입니다. 이것이 우리가 원하는 것입니다. 이 IP 주소를 컨테이너 /etc/resolv.conf 파일에 넣고 다시 시도하십시오. 네트워크가 다시 작동해야 합니다.
왜 이 문제가 발생합니까?
이제 그 이유에 대해 다시 논의할 수 있습니다. systemd-resolve 문서를 보면 선택한 작업 모드가 이름 확인과 일부 충돌을 일으키는 시스템에 약간의 변경이 있었을 수 있습니다(정기적인 업데이트로 인해 발생할 수 있음). 특히 /etc/resolv.conf가 처리되는 방식을 보면 첫 번째 모드 상태는 다음과 같습니다.
systemd-resolved는 기존 Linux 프로그램과의 호환성을 위해 /run/systemd/resolve/stub-resolv.conf 파일을 유지 관리합니다. 이 파일은 /etc/resolv.conf에서 심볼릭 링크될 수 있습니다. 이 파일은 127.0.0.53 DNS 스텁(위 참조)을 유일한 DNS 서버로 나열합니다. 또한 systemd-resolved에서 사용 중인 검색 도메인 목록도 포함되어 있습니다. 검색 도메인 목록은 항상 최신 상태로 유지됩니다. /run/systemd/resolve/stub-resolv.conf는 응용 프로그램에서 직접 사용해서는 안 되며 /etc/resolv.conf의 심볼릭 링크를 통해서만 사용해야 합니다. 이 파일은 로컬 DNS API를 우회하는 모든 로컬 클라이언트를 올바른 검색 도메인 설정으로 systemd-resolved에 연결하기 위해 /etc/resolv.conf에서 심볼릭 링크될 수 있습니다. 이 작업 모드를 권장합니다.
이 등식의 링크 중 하나가 끊어졌거나 무언가가 변경된 경우 Docker 서비스가 실제로 무엇을 제공하는지 결정할 수 없으며 결국 이름 확인이 되지 않을 수 있습니다. 따라서 해결책은 컨테이너가 이해하고 사용할 수 있는 실제 네트워크 DNS 주소를 제공하는 것입니다. 제 입장에서는 약간 추측이지만 상당히 정확하다고 생각합니다.
결론
또 다른 수수께끼가 풀리고 또 다른 앞 유리가 밝혀졌습니다. 또는 뭔가. 저는 반마법 솔루션을 좋아하지 않지만 매우 복잡하고 계층화된 시스템 인프라가 있는 경우 때때로 솔루션이 문제만큼 나쁩니다. 그들이 문제를 해결하지 못한다는 것이 아니라 당신이 마땅히 해야 할 것보다 가시성과 통제력이 떨어진다는 것입니다. 하지만 이것이 Linux와 IT의 모든 것, 끝없는 추상화의 미래입니다.
주제에 관해서는 이 작은 가이드가 컨테이너 모험을 위한 비교적 빠르고 쉬운 수정을 제공할 수 있기를 바랍니다. Docker를 사용 중이고 이름 확인이 컨테이너 인스턴스 내에서 더 이상 작동하지 않는 경우 위에 작성된 팁과 요령을 테스트한 다음 올바른 수정 사항을 사용하여 고유한 이미지를 빌드해야 합니다. 이 모든 것을 다시 싸우십시오. 이제 끝입니다.
건배.