> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/6-2.-docker-2-docker-network.md). # 6-2. Docker #2 : Docker Network Docker Network에 대하여 ## 도커 환경에서의 통신 및 네트워크 단어와 개념 * 도커 환경에서는 기본적으로 사용하는 docker0 Bridge 네트워크, 사용자 맞춤형 User Defined 네트워크 등 다양한 드라이버와 인터페이스를 활용한다. * bridge network: Docker에서 사용하는 리눅스 네트워크 드라이버 종류를 의미하며 항상 기본값으로 설정된다. * docker0: Docker의 bridge 네트워크 드라이버가 실제 환경에서 사용하는 구현체이자 리눅스 인터페이스이다. * host network: 네트워크 격리 없이 호스트의 네트워크를 그대로 사용하는 방식이다. 사용자가 직접 지정하는 별도의 맞춤형 브릿지 네트워크를 생성할 때는 별도의 브릿지 구현체를 사용하여 DNS 제공 및 네트워크 단위 격리 등의 동작을 독립적으로 수반한다. ### 브릿지 네트워크 * Host 도커 엔진에서 사용하는 기본적인 도커 네트워크로, 호스트 도커 엔진에 구축되어있는 컨테이너(DinD 환경 포함), 쉽게 말하면 동일한 도커 엔진에서 구동하는 컨테이너 및 노드들의 통신에 사용하는 네트워크이다. * default bridge (docker0 브릿지): 컨테이너들이 하나의 큰 L2 네트워크에 묶여 있는 형태이다. 이 환경에서는 컨테이너 간 자체적인 내장 DNS가 제공되지 않는다. * user-defined bridge (사용자 정의 브릿지): 컨테이너들을 네트워크별로 분리하여 관리할 수 있다. 자체 내장 DNS를 지원하며 네트워크별로 정책을 다르게 적용하는 것이 가능하다. ### 오버레이 네트워크 * overlay는 서로 다른 도커 엔진에서 구동하는 컨테이너간의 통신을 위한 네트워크이며, 도커 엔진이 다르다면 같은 엔진에서 공유하는 통신 네트워크인 브릿지 네트워크로는 부족하다. 반드시 overlay 네트워크를 통해 논리적 연결 통로 필요하며, 물리적 통로(bridge)를 통해 통신을 진행해야 한다. * with overlay : * ``` Worker1 shopping-network │ nginx ================== VXLAN ================== Worker2 shopping-network │ mysql ``` * overlay + bridge * ``` Service Packet ↓ Overlay ↓ VXLAN ↓ Host Bridge ↓ Worker ↓ Overlay ↓ Container ``` ### veth pair와 데이터 전달 원리 * veth(virtual ethernet pair)는 가상의 LAN 케이블 역할을 수행하며, 데이터 패킷을 케이블의 다른 쪽으로 전달할 때 사용한다. 컨테이너의 독립된 네트워크 네임스페이스를 서로 연결할 때 필수적으로 활용된다. 컨테이너 내부의 네트워크 인터페이스인 eth0가 veth pair를 통해 호스트 측의 vethXXXX 인터페이스와 연결되고, 이는 다시 호스트의 브릿지(docker0 또는 br-xxxx) 인터페이스로 결합되는 연결 흐름을 형성한다. ### 로컬 개발 환경 및 도커 환경에서의 네트워크 차이 * 외부 요청의 도커 네트워크 유입 과정 외부 클라이언트가 호스트로 요청을 보낼 때와 호스트 내부에서 컨테이너 간 통신이 이루어질 때는 리눅스의 네트워크 메커니즘을 거친다. 외부에서 호스트의 특정 포트로 진입한 요청은 Host Linux의 네트워크 네임스페이스를 통과하며, iptables의 규칙을 강하게 적용받는다. * 이때 외부 요청의 목적지 주소를 컨테이너의 내부 사설 IP 주소로 바꾸어주는 DNAT(Destination Network Address Translation) 가 동작하며, 변환된 요청은 호스트의 L2 Bridge(docker0 등) 인터페이스의 Forwarding 처리를 거쳐 veth pair를 타고 최종 목적지 컨테이너의 eth0 인터페이스로 인입된다. * 기본 네트워크가 아닌 User-Defined Network 역시 Host의 iptables 규칙을 거치긴 하나, 동일 사용자 정의 네트워크 내부에서 컨테이너 간 직접 통신할 때는 별도의 NAT 처리가 수반되지 않는다. 도커 네트워크는 컨테이너 내부에 독립적으로 완결된 네트워크가 아니라, 호스트의 Linux network namespace, bridge, iptables가 고도로 조합되어 작동하는 형태이다. * 컨테이너 간의 통신은 기본적으로 Host(docker0) 브릿지 네트워크를 통해 가능하다. * 그러나 컨테이너 실행 목적이 다르다면 당연히 동일한 목적의 TCP 통신을 위한 별도의 도커 네트워크를 구성해주는 것이 필요하다. 다만 이 경우 iptables에 기반한 DNAT이 불가능하기에, 반드시 각 L2 네트워크의 ip주소를 통한 통신이 이루어져야 한다. * 컨테이너 내부 localhost 호출의 실체와 DNS 동작 컨테이너 내부와 호스트 환경에서의 localhost 실행 결과는 주체에 따라 완전히 다르게 동작한다. * 호스트에서 `curl localhost:8080`을 실행하는 경우: iptables의 DNAT 규칙이 작동하여 호스트의 포트를 컨테이너 내부의 포트로 매핑해 준다. * 컨테이너 내부에서 `curl localhost`를 실행하는 경우: 네트워크 주체가 컨테이너 자신으로 한정되므로 외부 iptables나 DNAT와 아무런 관계가 없이 자기 자신을 호출하는 결과만 반환한다. * 따라서 컨테이너 내부에서 다른 컨테이너를 호출할 때는 localhost를 사용하면 안되며, 반드시 목적지 컨테이너의 이름이나 사설 IP를 지정해야 한다. 사용자 정의 브릿지 환경에서는 이 과정에서 도커 내부의 DNS가 작동하여 컨테이너 이름을 올바른 사설 IP 주소로 해석해 준다. L2 Bridge Forwarding 방식의 동작 원리는 동일하게 적용된다. ### 외부 체계와의 통신 프로토콜 특징 * 전송 프로토콜과 데이터 규격의 관계 데이터베이스나 Redis와 같은 시스템들은 저마다의 고유한 데이터 규격 프로토콜을 별도로 정의하여 사용한다. 기본적으로 외부 체계 및 다른 컨테이너와의 모든 통신은 네트워크 최하단에서 TCP/IP 전송 프로토콜을 엄격하게 적용하여 데이터를 안전하게 실어 나른다. * 다만 그 전송 계층 위에서 오고 가는 실제 데이터의 내용과 포맷 규격이 웹 통신을 위한 HTTP이거나, 각 데이터베이스 벤더사가 지정한 별도의 데이터베이스 프로토콜이거나, Redis에서 사용하는 RESP(REdis Serialization Protocol) 규격 등으로 다르게 적용되어 해석될 뿐이다. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://leehyokyun.gitbook.io/openbook/6-2.-docker-2-docker-network.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.