コンテナ同士を繋ぐ

이 실습은 진짜 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단계에서 바인딩 주소를 생략하면 모든 인터페이스에 열립니다. 채점은 이것을 실패로 봅니다.

사용자 정의 네트워크 만들기

/root/ops2 를 만들고, dk-net 이라는 사용자 정의 네트워크를 만듭니다.

네트워크를 다루는 하위 명령 그룹이 있습니다. 기본 브리지를 쓰지 않는 이유는 이름 해석 때문입니다.

네트워크에 컨테이너 붙이기

nginx:1.27-alpine 을 dk-api 라는 이름으로 dk-net 에 붙여 백그라운드 실행합니다.

컨테이너를 띄울 때 어느 네트워크에 붙일지 지정할 수 있습니다. inspect 의 NetworkSettings.Networks 로 확인하세요.

같은 네트워크에 하나 더

alpine:3.20 을 dk-client 라는 이름으로 같은 dk-net 에 붙여 계속 떠 있게 실행합니다.

두 번째 컨테이너는 계속 떠 있어야 안에서 명령을 돌릴 수 있습니다.

이름으로 서로 찾기

dk-client 안에서 컨테이너 이름으로 dk-api 에 HTTP 요청을 보내 응답을 /root/ops2/dns.txt 로 저장합니다. nginx 기본 페이지가 담기면 됩니다.

같은 사용자 정의 네트워크에 있으면 컨테이너 이름이 곧 호스트명입니다. 안에서 HTTP 요청을 보내 응답을 저장하세요.

다른 네트워크는 보이지 않는다

dk-net2 라는 네트워크를 새로 만들고 dk-lonely 컨테이너를 그 네트워크에만 붙여 띄웁니다. dk-lonely 에서 dk-api 에 닿지 않는 것을 확인하고 /root/ops2/isolated.txt 에 unreachable 이라고 적습니다.

새 네트워크에만 붙인 컨테이너에서 접근을 시도해 보고 결과를 결론 단어로 기록하세요.

호스트로 포트 열기

nginx:1.27-alpine 을 dk-pub 이라는 이름으로 띄우되 컨테이너의 80 포트를 127.0.0.1 의 8080 포트에만 퍼블리싱합니다.

바인딩 주소를 생략하면 모든 인터페이스에 열립니다. 루프백으로 제한하세요. 1024 미만 포트는 이 환경에서 열 수 없습니다.

이미 뜬 컨테이너를 네트워크에 추가로 붙이기

dk-lonely 를 지우지 말고 dk-net 에도 추가로 연결한 뒤, 이제 dk-api 이름이 해석되는지 확인합니다.

컨테이너를 다시 만들지 않고도 네트워크를 붙이는 명령이 있습니다. 기존 연결은 유지해야 합니다.

도달 관계 정리

/root/ops2/net.md 에 dk-api, dk-client, dk-lonely, dk-pub 을 각각 한 줄씩 적고, dk-lonely 줄에는 소속 네트워크 개수를, dk-pub 줄에는 퍼블리싱한 바인딩 주소와 포트를 함께 적습니다.

각 컨테이너가 어느 네트워크에 몇 개 붙어 있는지, 어떤 포트가 어디에 열려 있는지를 실제 값으로 적으세요.