Skip to main content

Command Palette

Search for a command to run...

네트워킹: 컨테이너 통신

Updated
3 min read
네트워킹: 컨테이너 통신

컨테이너와 통신

컨테이너도 컨테이너 외부와 통신이 가능한데 통신하는 대상으로 이를 구분하자면 크게 세 가지 케이스가 있다.

WWW 통신

컨테이너는 기본적으로 WWW(World Wide Web)에 요청을 보낼 수 있다. 따라서 컨테이너 내부의 도커화 된 애플리케이션은 컨테이너 외부의 웹에 request를 전송하는 것이 가능하다.

컨테이너라고 별 다른 설정이 필요하지는 않고 애플리케이션 내부에 외부 WWW로 request를 보내는 코드가 있으면 작동한다.

컨테이너-로컬 호스트 통신

컨테이너는 호스트 머신의 서비스와도 통신할 수 있다.

이것도 크게 복잡할 것은 없으나 컨테이너 내부에서 localhost를 사용하려 하면 호스트 머신이 아니라 컨테이너 내부의 localhost로 인식하기 때문에

localhost:3000

이었다면

host.docker.internal:3000

으로 교체해주면 된다.

host.docker.internal를 사용하게 되면 도커에 의해 호스트 머신의 IP주소로 변환된다.

예를 들면

호스트 머신의 MongoDB를 사용하기 위해

mongoose.connect(
  'mongodb://localhost:27017/swfavorites',
  { useNewUrlParser: true },
  (err) => {
    if (err) {
      console.log(err);
    } else {
      app.listen(3000);
    }
  }

이러한 코드가 포함된 애플리케이션의 이미지를 빌드하고 컨테이너에서 돌리려고 하면 정상적으로 작동하지 않는다.

mongoose.connect(
  'mongodb://host.docker.internal:27017/swfavorites',
  { useNewUrlParser: true },
  (err) => {
    if (err) {
      console.log(err);
    } else {
      app.listen(3000);
    }
  }

로 바꿔주면 호스트 머신의 몽고DB를 사용 가능하다.

당연하겠지만 애초에 컨테이너 내부에 있는 DB가 아니기 때문에 컨테이너를 삭제해도 데이터는 날아가지 않는다.

컨테이너-컨테이너 간 통신

컨테이너는 또 다른 컨테이너와도 통신할 수 있다. 위에서는 로컬의 몽고DB와 통신했으나 몽고DB가 돌고 있는 컨테이너와 애플리케이션 컨테이너를 연결할 수 있다.

몽고DB 이미지는 도커허브에서 이미 제공되고 있으므로 별다른 도커파일 작성 없이

docker run mongo

를 실행하면 몽고DB를 가진 컨테이너를 돌리게 된다.

따라서 몽고DB 컨테이너를 detached 모드로 다시 돌려보면

docker run -d --name mongodb mongo                                 ─╯
cbce28bf42f3516a50e3287d15280c49272dff34c72f7d12ee174f0b92d42ca4

이런 식으로 생성된다.

이제 로컬의 몽고DB에서 몽고DB 컨테이너의 몽고DB로 연결해야 하는데

docker container inspect mongodb

명령어를 이용해 컨테이너를 검사하면 정보들이 출력되는데 내리다보면 IPaddress를 발견할 수 있다.

발견한 IPaddress를

mongodb://IPaddress:27017/swfavorites

에 집어넣어주면 컨테이너의 몽고DB와 통신할 수 있게 된다.

Docker Network

컨테이너끼리 통신하는 데 위처럼 주소를 그냥 하드코딩해도 돌아는 가겠지만 또 다른 방법이 있다.

docker run --network my_network

--network옵션을 붙여주면 여러 컨테이너를 한 네트워크 안에 묶어버릴 수 있다.

그림으로 보자면 위와 같은 느낌이다. 컨테이너들을 기능별로 분리할 수 있으면서도 통신이 원활하다면 상당히 바람직한 상황일 것이다.

그러면 도커 네트워크를 이용하는 컨테이너를 돌리기 위해

docker run -d --name mongodb --network favorites-net mongo                                                                                     ─╯
90ed02f4da3372b12429598fc1d9e6604e162d23bb8cf15d523c248fa3b594d9
docker: Error response from daemon: network favorites-net not found

를 시도하면 네트워크를 찾을 수 없다는 에러가 나온다.

네트워크는 자동적으로 생성되지 않기 때문에

docker network create favorites-net

네트워크를 만들어주면 된다.

네트워크를 만든 후 위 명령어를 다시 실행해주면

docker run -d --name mongodb --network favorites-net mongo                                                                                     ─╯
b4b5344edb4da69500e4a0d50138e4c85c50dc88e95e66194288930fc3f6dce7

성공적으로 진행된 것을 알 수 있다.

아까 네트워크를 사용하면 주소를 하드코딩하지 않아도 된다고 하였다. 그럼

mongodb://IPaddress:27017/swfavorites

이 부분도 그대로 적을 필요가 없다는 말이 되겠다. 여기에는

mongodb://컨테이너이름:27017/swfavorites

통신하는 컨테이너 이름을 적어주면 된다.

내부적으로는 도커가 컨테이너 이름을 받아 컨테이너의 IP주소로 변환하는 과정이 이루어지기 때문에 통신이 가능하다.

그러면 다시 애플리케이션 컨테이너를 만들어서 돌려볼 차례다. 같은 네트워크에 넣어줘야하기 때문에

docker run --name favorites --network favorites-net -d --rm -p 3000:3000 favorites-node                                                        ─╯
c2e2d4059cb3053f24aef257973a61c5bec157a94d032d9861f88ccf5c3dde23

똑같이 --network 옵션에 같은 네트워크를 설정해준다.

5 views

More from this blog

락프리 데이터 구조와 알고리즘

여기서는 락프리 데이터 구조를 설명한다. 락프리(lock-free) 란 배타락을 이용하지 않고 처리를 수행하는 데이터 구조 및 그에 대한 조작 알고리즘을 총칭한다. 왜 락프리인가? 전통적인 동시성 제어 방법인 뮤텍스나 세마포어는 여러 문제점을 가지고 있다: 성능 저하: 락 경합(lock contention)으로 인한 대기 시간 데드락: 여러 스레드가 서로의 락을 기다리는 상황 우선순위 역전: 낮은 우선순위 스레드가 높은 우선순위 스레드를 ...

Jul 27, 20257 min read126

소프트웨어 트랜잭셔널 메모리

소프트웨어 트랜잭셔널 메모리 동시성 프로그래밍에서 공유 자원에 대한 안전한 접근은 항상 중요한 과제다. 전통적으로 뮤텍스 락과 같은 비관적 락(Negative Lock) 방식을 사용해왔다. 이 방식은 크리티컬 섹션에 진입하기 전에 반드시 락을 획득해야 하며, 락을 얻지 못하면 코드 실행 자체가 블록된다. 하지만 이와는 다른 접근 방식이 있다. 바로 낙관적 락(Optimistic Lock) 방식인데, 이는 "일단 실행하고 나중에 검증하자"는 철학...

Jul 20, 202517 min read263

공평한 배타 제어

공평한 배타 제어 여기서는 공평한 배타 제어에 대해 설명한다. 먼저 컨텐션(contention) 이라는 개념을 이해할 필요가 있다. 컨텐션이란 여러 스레드가 동시에 같은 락을 획득하려고 경쟁하는 상황을 말한다. 컨텐션이 높을수록 스레드들이 락을 기다리는 시간이 길어지고 성능이 저하된다. 이러한 컨텐션 상황은 시스템 아키텍처에 따라 더욱 복잡해질 수 있다. 특히 비균일 메모리 접근(Non-Uniform Memory Access, NUMA) 와 같...

Jul 13, 20259 min read21

KernelSnitch[논문 리뷰]

Paper 1. Intro 이 글은 NDSS 2025에서 발표된 KernelSnitch 논문을 소개이다. 이 연구는 커널의 평범한 데이터 구조체들이 가진 본질적인 특성이 어떻게 심각한 보안 취약점이 되는지를 보여준다. 핵심은 이러하다: "데이터 구조체의 크기에 따른 접근 시간 차이를 이용해 커널의 비밀 정보를 유출할 수 있다" 여기서는 커널 힙 포인터 유출에 집중해서 설명한다. 이 공격이 성공하면 KASLR을 우회하고 더 심각한 커널 익스플로...

Jul 11, 20257 min read131

멀티태스크와 액터 모델

멀티태스크 협조적/비협조적 멀티태스크 선점: 프로세스와의 협조 없이 수행하는 컨택스트 스위칭이라고는 하나, 결국 뺏어오는 게 가능하냐의 문제다. 협조적 멀티태스크(비선점형, cooperative): 각각의 프로세스가 자발적으로 컨택스트 스위칭을 수행하는 멀티태스크 방식. 장점: 멀티태스크 매커니즘을 구현하기 쉽다. 단점: 프로세스가 자발적으로 컨텍스트 스위칭을 해야하는데, 만약 버그가 발생하여 프로세스가 무한 루프에 빠지거나 정지하게 되면 그 ...

Jul 6, 20252 min read25
M

MaxLog

35 posts