컨테이너끼리 연결하기

이 실습은 진짜 VM 에서 돕니다

이 상자는 파드가 아니라 KubeVirt 가 띄운 가상머신입니다. 리눅스 커널이
따로 돌고 systemd 가 실제로 서비스를 관리하며, docker 는 흉내가 아니라
진짜 도커 엔진입니다. docker run 으로 띄운 컨테이너는 실제로 프로세스가
되고 docker exec 도 docker logs 도 그대로 동작합니다.

예전에는 이 실습이 파드 안에서 돌았습니다. 커널 권한을 전부 내려놓은 상자라
컨테이너를 띄우는 단계가 막혀 있었고, 그래서 이미지 아카이브를 직접 풀어
보는 우회로 배웠습니다. 이제 우회가 필요 없습니다.

알아 둘 것이 둘 있습니다.

처음 뜨는 데 1분 남짓 걸립니다. VM 이 부팅하고 도커를 설치하기

때문입니다. 파드 실습(보통 40초)보다 느립니다.

브라우저 미리보기가 없습니다. VM 으로 들어오는 연결은 채점 포트

하나만 열려 있습니다. 웹 서버를 띄웠다면 VM 안에서 curl 로 확인하세요.

목표

사용자 정의 네트워크로 컨테이너끼리 이름으로 통신하게 만들고, 네트워크가
다르면 서로 보이지 않는다는 것을 확인하며, 포트를 루프백에만 여는 습관을
들입니다.

왜 중요한가

컨테이너 네트워킹의 사고는 대부분 두 가지 오해에서 나옵니다. 하나는
"컨테이너의 127.0.0.1 이 호스트의 127.0.0.1 이겠거니" 하는 것이고, 다른
하나는 "포트를 열었으니 방화벽이 막아 주겠거니" 하는 것입니다. 첫 번째는
네트워크 네임스페이스가 루프백까지 복제한다는 사실로, 두 번째는 컨테이너로
가는 패킷이 호스트를 최종 목적지로 삼지 않는다는 사실로 설명됩니다.
바인딩 주소를 제한하는 것이 가장 단순하고 확실한 통제라는 결론이
여기서 나옵니다.

단계

1. /root/ops2 를 만들고, dk-net 이라는 사용자 정의 네트워크를 만듭니다.
2. nginx:1.27-alpine 을 dk-api 라는 이름으로 dk-net 에 붙여 백그라운드 실행합니다.
3. alpine:3.20 을 dk-client 라는 이름으로 같은 dk-net 에 붙여 계속 떠 있게 실행합니다.
4. dk-client 안에서 컨테이너 이름으로 dk-api 에 HTTP 요청을 보내 응답을 /root/ops2/dns.txt 로 저장합니다. nginx 기본 페이지가 담기면 됩니다.
5. dk-net2 라는 네트워크를 새로 만들고 dk-lonely 컨테이너를 그 네트워크에만 붙여 띄웁니다. dk-lonely 에서 dk-api 에 닿지 않는 것을 확인하고 /root/ops2/isolated.txt 에 unreachable 이라고 적습니다.
6. nginx:1.27-alpine 을 dk-pub 이라는 이름으로 띄우되 컨테이너의 80 포트를 127.0.0.1 의 8080 포트에만 퍼블리싱합니다.
7. dk-lonely 를 지우지 말고 dk-net 에도 추가로 연결한 뒤, 이제 dk-api 이름이 해석되는지 확인합니다.
8. /root/ops2/net.md 에 dk-api, dk-client, dk-lonely, dk-pub 을 각각 한 줄씩 적고, dk-lonely 줄에는 소속 네트워크 개수를, dk-pub 줄에는 퍼블리싱한 바인딩 주소와 포트를 함께 적습니다.

참고

docker network connect <네트워크> <컨테이너> 로 이미 뜬 컨테이너에 네트워크를 추가합니다.
docker exec dk-client getent hosts dk-api 로 이름 해석만 따로 확인할 수 있습니다.
이 환경은 rootless 라 1024 미만 포트를 열 수 없습니다. 8080 을 씁니다.
흔한 실수 1: 3단계에서 alpine 을 그냥 띄우면 즉시 끝납니다. 계속 도는 명령을 주세요.
흔한 실수 2: 6단계에서 바인딩 주소를 생략하면 모든 인터페이스에 열립니다. 채점은 이것을 실패로 봅니다.

단계 8개

사용자 정의 네트워크 만들기
네트워크에 컨테이너 붙이기
같은 네트워크에 하나 더
이름으로 서로 찾기
다른 네트워크는 보이지 않는다
호스트로 포트 열기
이미 뜬 컨테이너를 네트워크에 추가로 붙이기
도달 관계 정리