가상화 공부

용어 정리

포트 포워딩

포트포워딩 : 네트워크 통신에서 외부 네트워크에서 내부 네트워크의 특정 서비스에 접근할 수 있도록 하는 기술

포트포워딩 기본 개념

1. 외부 네트워크에서 특정 IP 주소와 포트로 전송된 데이터 패킷이 도착
2. 라우터나 방화벽이 이 패킷을 가로채서 내부 네트워크의 다른IP 주소와 포트로 전달한다.
3. 이를 통해 외부에서 내부 네트워크의 특정 서비스에 접근할 수 있게 된다.

Virtual Box에서의 포트 포워딩

virtual Box에서 포트포워딩을 설정하는 이유

• 호스트 컴퓨터(현재 내 로컬(교육 컴퓨터)은 Window OS)에서 가상머신 VM에 접속하기 위해
• XShell과 같은 SSH 클라이언트를 사용하여 가상 머신에 원격으로접속하기 위해
• 가상머신에서 실행 중인 웹 서버 등의 서비스에 호스트 컴퓨터에서 접근하기 위해

즉, 다시 말해 포트포워딩은 Virtual Box 환경에서 호스트 운영체제(windows)와 가상 머신 사이의 통신을 가능하게 하는 기술이다.

• 이 기술은 호스트 시스템의 특정 포트로 전송된 트래픽을 가상 머신의 지정된 포트로 리디렉션하는 매핑을 생성
• VirtualBox에서 포트포워딩을 설정하면 Windows 호스트 시스템에서 가상 머신 내부에서 실행 중인 서비스에 접근할 수 있는 경로가 만들어짐!

가상화(Virtualization)의 이해

가상화는 물리적 컴퓨팅 리소스(하드웨어)를 논리적으로 분할하여 여러 개의 독립적인 가상 환경을 생성하는 기술이다. 이 과정에서 실제 하드웨어 위에 추상화 계층을 구축하여 물리적 자원을 효율적으로 활용한다.

물리적 리소스의 논리적 분할이란 ?

물리적 컴퓨터는 CPU, 메모리(RAM), 저장 장치(하드 디스크), 네트워크 인터페이스 등의 하드웨어 리소스로 구성된다. 가상화 기술은 이러한 물리적 리소스를 소프트웨어적으로 나누어 여러 가상 시스템에 할당한다.

예를 들면:

• 8코어 CPU를 가진 서버를 가상화하여 각각 2코어를 사용하는 4개의 가상 머신 생성
• 32GB RAM을 가진 컴퓨터에서 각 가상 환경에 8GB씩 할당
• 1TB 저장 공간을 여러 가상 디스크로 분할

가상화의 핵심 아이디어

가상화의 핵심은 물리적 리소스와 그것을 사용하는 소프트웨어 사이에 추상화 계층을 두는것. 이 추상화 계층은 물리적 하드웨어를 다수의 논리적 단위로 나누거나 (이게 보통), 반대로 여러 물리적 장치를 하나의 논리적 단위로 결합할 수도 있다.

예시1 : 내 컴퓨터에서 Virtual Box 사용하기

8GB RAM, 4코어 CPU, 500GB 저장 공간이 있는 Windows 컴퓨터를 가지고 있다고 가정. VirtualBox를 설치하면:

• 이 물리적 컴퓨터 위에 가상 환경을 만들 수 있다.
• 가상 환경에 4GB RAM, 2코어 CPU, 100GB 가상 디스크를 할당할 수 있음
• 이 가상 환경에 Linux를 설치하고 실행할 수 있다.
• Windows(호스트 OS)와 Linux(게스트 OS)가 동시에 실행되지만, Linux는 자신이 실제 컴퓨터에서 실행되고 있다고 "생각"한다.

예시2 : 데이터 센터에서의 가상화

대형 서버(128코어 CPU, 1TB RAM, 100TB 저장 공간)가 있는 데이터 센터에서는:

• 이 서버를 가상화하여 32개의 가상 서버로 나눌 수 있다.
• 각 가상 서버는 4코어, 32GB RAM, 3TB 저장 공간을 가질 수 있다.
• 각 가상 서버는 서로 다른 기업이나 애플리케이션에 할당될 수 있다.

가상화 이점

• 리소스 효율성: 하나의 물리적 시스템에서 여러 운영체제를 실행함으로써 하드웨어 활용도를 높인다.
• 격리와 보안: 각 가상 환경은 다른 환경으로부터 독립되어 있어, 하나에 문제가 생겨도 다른 환경에 영향을 주지 않는다.
• 유연성: 필요에 따라 가상 환경을 쉽게 생성, 수정, 삭제할 수 있다.
• 이동성: 가상 머신은 쉽게 백업하고 다른 물리적 하드웨어로 이동할 수 있음.

---

컨테이너 가상화의 이해

컨테이너 가상화란 무엇인가

컨테이너 가상화는 운영체제 수준의 가상화 기술로, 호스트 운영체제의 커널을 공유하면서도 애플리케이션과 그 의존성을 격리된 환경에서 실행할 수 있게 해준다. 전통적인 VM 가상화와 달리, 컨테이너는 각각 완전한 운영체제를 포함하지 않고 호스트 OS의 커널을 직접 사용한다. (호스트 OS 커널 공유)

VM 가상화와 컨테이너 가상화의 근본적차이

VM 가상화는 하드웨어를 가상화하여 그 위에 게스트 OS를 올리는 방식이다. 각 VM은 자체 커널과 운영체제를 가지며, 하이퍼바이저라는 소프트웨어가 이들을 관리한다.

컨테이너 가상화는 운영체제 수준에서 격리된 프로세스 공간을 만든다. 모든 컨테이너는 호스트 OS의 커널을 공유하면서도 서로 독립된 사용자 공간을 가진다.

컨테이너 가상화의 핵심 기술 & 컨테이너 가상화가 가져온 패러다임의 변화

컨테이너 가상화는 리눅스 커널의 여러 기능을 활용하여 구현

1. 애플리케이션 중심 접근방식

VM이 전체 운영체제를 가상화하는 반면, 컨테이너는 애플리케이션과 그 의존성만 패키징한다. 이는 "한 컨테이너에 한 서비스"라는 마이크로서비스 아키텍처의 핵심 원칙과 맞닿아 있다.

2. 경량화된 가상화

컨테이너는 VM에 비해 크기가 매우 작고(MB 단위), 시작 시간이 훨씬 빠르다(초 단위 또는 그 이하). 이로 인해

• 자원 효율성: 더 적은 CPU와 메모리로 더 많은 워크로드 처리 가능
• 빠른 확장성: 수요 증가에 따라 신속하게 새 인스턴스 생성 가능
• 빠른 개발 주기: 개발, 테스트, 배포 과정이 간소화됨

3. 불변 인프라(Immutable Infrastructure) 개념

컨테이너는 "빌드 한 번, 어디서나 실행"이라는 철학을 가능하게 한다. 개발 환경에서 작동하는 컨테이너는 테스트 환경과 프로덕션 환경에서도 동일하게 작동한다. 이는 "환경 차이로 인한 문제"를 크게 줄인다.

4. DevOps 및 CI/CD 가속화

컨테이너는 개발 및 운영 팀 간의 협업을 촉진하고, 지속적 통합 및 배포(CI/CD) 파이프라인을 간소화한다.

---

컨테이너 가상화의 핵심 개념

컨테이너 가상화는 호스트 OS의 커널을 공유하면서도 격리된 공간에서 애플리케이션을 실행하는 기술.

커널 공유의 의미

운영체제의 커널은 하드웨어와 소프트웨어 사이의 중요한 중재자 역할.

커널은 CPU, 메모리, 디스크 네트워크 인터페이스와 같은 하드웨어 자원을 관리하고 프로세스들에게 이러한 자원을 할당.

컨테이너는 이 커널을 호스트 OS와 공유. 이것이 의미하는 바는

1. 컨테이너 내부의 애플리케이션이 시스템 호출을 할 때, 이 호출은 호스트 OS의 커널로 직접 전달된다.
2. 각 컨테이너는 별도의 운영체제를 완전히 복제하지 않고, 필요한 라이브러리와 애플리케이션만 포함한다.
3. 하나의 커널이 여러 컨테이너의 요청을 처리하므로 자원 효율성이 높아진다.

불변 인프라(Immutable Infrastructure)의 철학

컨테이너 기술의 핵심 철학 중 하나는 불변 인프라. 이는 인프라를 변경하지 않고, 필요할 때 새로운 버전으로 완전히 대체한다는 개념

불변 인프라 접근법에서는
1. 문제가 발생하면 기존 서버를 수정하지 않고 새로운 서버를 배포한다.
2. 애플리케이션 업데이트 시 기존 컨테이너를 수정하지 않고 새 버전의 이미지로 만든 컨테이너로 교체한다.

이 접근법은 환경의 일관성을 유지하고, 변경 사항을 추적하며, 롤백을 쉽게 만든다.

---

도커 학습을 위한 필수 CS지식

운영체제 기본 개념: 프로세스와 스레드

프로세스(Process)란 ? 프로세스는 실행 중인 프로그램의 인스턴스

프로세스의 특징

1. 독립성: 각 프로세스는 독립된 메모리 공간을 가지며, 다른 프로세스의 메모리에 직접 접근할 수 없다.
2. 자원 소유: 각 프로세스는 자신만의 자원(메모리, 파일 등)을 소유
3. 멀티태스킹: 현대 운영체제는 여러 프로세스를 동시에 실행할 수 있으며, CPU 시간을 나누어 각 프로세스에 할당한다.

스레드란(Thread)?

스레드는 프로세스 내에서 실행되는 더 작은 실행 단위

하나의 프로세스는 여러 스레드를 가질 수 있으며, 이들은 프로세스의 자원을 공유

프로세스 vs 스레드: 실생활 비유

프로세스와 스레드의 관계를 이해하기 위해 회사 조직을 예로 들어 비교

• 회사(프로세스): 각 회사는 독립적인 공간, 자원, 예산을 가지고 있다.
• 직원(스레드): 한 회사 내의 직원들은 같은 사무실 공간, 자원, 정보를 공유한다.

여러 회사(프로세스)가 있고, 각 회사는 여러 직원(스레드)을 가질 수 있다. 회사 간에는 자원과 정보 공유가 제한적이지만, 한 회사 내 직원들은 쉽게 정보와 자원을 공유할 수 있다.

도커 컨테이너와 프로세스의 연관성

도커 컨테이너는 기본적으로 격리된 프로세스(또는 프로세스 그룹)이다.

각 컨테이너는
1. 독립된 프로세스 공간: 각 컨테이너는 자체 프로세스 ID 공간을 가지며, 컨테이너 내부에서는 자신의 프로세스만 볼 수 있다.
2. 자원 제한: cgroups를 통해 CPU, 메모리 등의 자원 사용량을 제한할 수 있다.
3. 네임스페이스 격리: 프로세스, 네트워크, 파일 시스템 등이 다른 컨테이너와 격리된다.

시스템콜이란 ?

시스템콜은 애플리케이션이 운영체제 커널의 서비스를 요청하는 프로그래밍 인터페이스이다. 다시 말해, 애플리케이션이 하드웨어나 운영체제의 보호된 리소스에 접근하기 위해 사용하는 통로.

현대 운영체제는 보안과 안정성을 위해 두 가지 주요 실행 모드를 가지고 있음

• 사용자 모드(User Mode) : 일반 애플리케이션이 실행되는 제한된 권한모드
• 커널 모드(Kernel Mode) : 운영체제 핵심코드가 실행되는 전체 권한 모드

시스템 콜 작동 방식

• 호출 준비: 애플리케이션이 시스템 콜 매개변수를 준비한다.
• 트랩 발생: 특별한 명령어를 실행하여 사용자 모드에서 커널 모드로 전환.
• 커널 실행: 커널이 요청된 시스템 콜을 식별하고 처리한다.
• 결과 반환: 작업 완료 후, 결과가 사용자 프로그램에 반환되고 사용자 모드로 다시 전환된다.

이 과정은 CPU의 특별한 명령어와 하드웨어 지원을 필요로 함.

컨테이너와 시스템 콜의 관계

컨테이너 기술과 시스템 콜은 중요한 관계.

1. 커널 공유
   컨테이너의 핵심 특징 중 하나는 호스트OS의 커널을 공유한다는 것. 이는 컨테이너 내부에서 실행되는 프로세스의 시스템 콜이 호스트 커널로 직접 전달된다는 뜻.

VM과의 큰 차이점

• VM: 게스트 OS → 게스트 커널 시스템 콜 → 하이퍼바이저 → 호스트 커널
• 컨테이너: 컨테이너 내 애플리케이션 → 시스템 콜 → 호스트 커널 (직접 전달)

이런 직접적인 시스템 콜 처리는 컨테이너가 VM보다 가볍고 빠른 주요 이유

네임스페이스(Namespaces)와 cgroups의 이해

네임스페이스와 cgroups(컨트롤 그룹)는 리눅스 컨테이너 기술의 두 핵심 기반 요소

이 두 기술이 어떻게 컨테이너의 격리와 자원 제한을 가능하게 하는지 알아보자

네임스페이스(Namespaces)

네임스페이스는 리눅스 커널의 기능으로, 프로세스가 시스템 자원을 보는 방식을 격리하는 역할을 한다. 이를 통해 프로세스 그룹에게 자신만의 격리된 시스템 자원 뷰를 제공

네임스페이스의 핵심 개념

네임스페이스는 "같은 시스템에서 실행되는 프로세스들이 서로 다른 세계에 있는 것처럼 느끼게 한다"고 생각하면 된다. 예를 들어, 두 프로세스가 각각 다른 네임스페이스에 있다면, 같은 컴퓨터에서 실행되고 있어도 서로 볼 수 없고 간섭할 수 없다.

컨트롤그룹(cgroups)

cgroups(Control Groups)는 프로세스 그룹의 자원 사용을 제한, 격리, 측정하는 리눅스 커널 기능이다. 네임스페이스가 프로세스가 보는 것을 격리한다면, cgroups는 프로세스가 사용할 수 있는 것을 제한한다.

cgroups는 프로세스 그룹에 대한 자원 할당 및 제한 메커니즘을 제공. 이를 통해 시스템 관리자는 CPU, 메모리, 디스크 I/O, 네트워크 등의 자원 사용량을 관리할 수 있다.

cgroups의 주요 기능

1. 자원 제한 (Resource Limiting)
   • 프로세스 그룹이 사용할 수 있는 자원의 양을 제한합니다.
   • 예: 컨테이너가 사용할 수 있는 메모리 양을 512MB로 제한
2. 우선 순위 부여 (Prioritization)
   • 일부 프로세스 그룹에 다른 그룹보다 더 많은 자원을 할당할 수 있습니다.
   • 예: 중요한 컨테이너에 더 많은 CPU 시간 할당
3. 회계 (Accounting)
   • 프로세스 그룹이 사용하는 자원의 양을 측정하고 보고합니다.
   • 자원 사용량 모니터링 및 과금에 유용합니다.
4. 제어 (Control)
   • 프로세스 그룹의 실행을 제어합니다(중지, 재개, 프리징 등).
   • 자원 부족 시 어떤 프로세스를 먼저 종료할지 결정할 수 있습니다.

---

OSI 모델과 TCP/IP 스택 이해하기

네트워킹 개념은 컨테이너와 도커 환경에서 매우 중요.

도커와 컨테이너 환경에서의 네트워크 통신

1. 컨테이너 네트워크 모드

브리지 모드 : 컨테이너가 내부 가상 네트워크에 연결되고 NAT를 통해 외부와 통신(기본모드)

호스트 모드 : 컨테이너가 호스트의 네트워크 네임스페이스를 직접 사용

오버레이 모드 : 여러 호스트에 걸친 컨테이너 간 통신 가능

DNS 해결 : 컨테이너는 기본적으로 도커의 내장 DNS 서버를 사용하여 다른 컨테이너의 이름을 IP 주소로 해석할 수 있다.

브리지 모드에서 NAT를 통한 외부 통신

브리지 모드와 포트 매핑 자세히 이해하기

브리지 모드는 도커의 기본 네트워크 모드. 컨테이너들이 호스트 시스템과는 분리된 자체 내부 네트워크에서 작동하게 한다. 여기서 NAT(Network Address Translation, 네트워크 주소 변환)가 중요한 역할을 한다.

NAT의 기본 개념

NAT는 한 네트워크의 IP 주소를 다른 네트워크의 IP 주소로 변환하는 프로세스이다.

컨테이너가 외부로 요청을 보낼 때(아웃바운드 통신)

예를 들어, 컨테이너가 구글 서버(8.8.8.8)로 요청을 보내는 상황을 생각해보면

• 요청 생성: 컨테이너(172.17.0.2) 내부의 애플리케이션이 8.8.8.8:443으로 HTTPS 요청을 생성합니다.
• 패킷 정보:
  • 출발지 IP: 172.17.0.2 (컨테이너 IP)
  • 출발지 포트: 33456 (임의의 높은 포트 번호)
  • 목적지 IP: 8.8.8.8 (구글 DNS 서버)
  • 목적지 포트: 443 (HTTPS)
• NAT 처리: 이 패킷이 도커 브리지를 통과할 때, 도커 엔진의 NAT 기능이 작동합니다:
  • 출발지 IP: 192.168.1.100 (호스트 컴퓨터의 IP로 변경)
  • 출발지 포트: 45678 (NAT에 의해 변경된 새 포트)
  • 목적지 IP: 8.8.8.8 (변경 없음)
  • 목적지 포트: 443 (변경 없음)
• 외부 통신: 패킷이 인터넷으로 나갑니다. 외부에서 볼 때는 마치 호스트 컴퓨터에서 직접 요청이 온 것처럼 보입니다.
• 응답 추적: NAT 장치는 이 변환 정보를 '연결 추적 테이블'에 저장해둔다.

원본(컨테이너 172.17.0.2:33456) <-> 변환(호스트 192.168.1.100:45678)

• 응답 수신: 구글 서버가 응답을 보냅니다:
  • 출발지 IP: 8.8.8.8
  • 출발지 포트: 443
  • 목적지 IP: 192.168.1.100 (호스트 IP)
  • 목적지 포트: 45678 (NAT에 의해 변경된 포트)
• NAT 역변환: 호스트에 도착한 패킷을 NAT가 다시 변환합니다:
  • 출발지 IP: 8.8.8.8 (변경 없음)
  • 출발지 포트: 443 (변경 없음)
  • 목적지 IP: 172.17.0.2 (컨테이너 IP로 복원)
  • 목적지 포트: 33456 (원래 포트로 복원)
• 컨테이너 전달: 변환된 패킷은 도커 브리지를 통해 해당 컨테이너로 전달됩니다.

외부에서 컨테이너로 요청이 들어올 때 (인바운드 통신, 포트 매핑 사용)

포트 매핑 설정 : docker run -p 8080:80 nginx명령으로 컨테이너를 시작했다고 가정.

• 외부 요청: 외부 클라이언트(203.0.113.5)가 호스트의 8080 포트로 HTTP 요청을 보냅니다:
  • 출발지 IP: 203.0.113.5 (클라이언트)
  • 출발지 포트: 52000 (임의의 클라이언트 포트)
  • 목적지 IP: 192.168.1.100 (호스트 IP)
  • 목적지 포트: 8080 (호스트의 매핑된 포트)
• 목적지 포트 변환(DNAT): 도커의 NAT 엔진이 패킷의 목적지를 변환합니다:
  • 출발지 IP: 203.0.113.5 (변경 없음)
  • 출발지 포트: 52000 (변경 없음)
  • 목적지 IP: 172.17.0.2 (컨테이너 IP로 변경)
  • 목적지 포트: 80 (컨테이너 내부 포트로 변경)
• 컨테이너 전달: 변환된 패킷이 컨테이너의 웹 서버에 전달됩니다.
• 응답 생성: 컨테이너의 웹 서버가 응답을 생성합니다:
  • 출발지 IP: 172.17.0.2 (컨테이너 IP)
  • 출발지 포트: 80 (웹 서버 포트)
  • 목적지 IP: 203.0.113.5 (외부 클라이언트)
  • 목적지 포트: 52000 (클라이언트 포트)
• 출발지 변환(SNAT): 응답 패킷이 나갈 때 NAT 엔진이 출발지를 변환합니다:
  • 출발지 IP: 192.168.1.100 (호스트 IP로 변경)
  • 출발지 포트: 8080 (호스트 매핑 포트로 변경)
  • 목적지 IP: 203.0.113.5 (변경 없음)
  • 목적지 포트: 52000 (변경 없음)
• 응답 전송: 변환된 응답 패킷이 외부 클라이언트에게 전송됩니다.

도커 브리지의 역할

도커 브리지('docker0')는 이 모든 과정에서 중요한 역할을 한다.

1. 가상 스위치처럼 작동하여 컨테이너들이 서로 통신할 수 있게 한다.
2. 컨테이너와 호스트 사이의 통신을 가능하게 한다.
3. NAT 기능이 이 브리지에서 작동하여 패킷의 출발지/목적지 주소를 적절히 변환한다.
4. 컨테이너 IP 주소를 관리하고 할당한다.

이처럼 도커의 NAT와 브리지 네트워크는 컨테이너가 자체 격리된 네트워크 환경을 가지면서도 외부 세계와 통신할 수 있게 해주는 핵심 메커니즘

도커 포트 매핑의 완전 이해

포트 매핑은 도커 컨테이너를 외부에서 접근 가능하게 만드는 핵심 기능

포트 매핑(또는 포트 포워딩)은 호스트 시스템의 특정 포트에 도착하는 네트워크 트래픽을 컨테이너의 특정 포트로 전달하는 메커니즘이다. 이는 외부에서 컨테이너 내부에서 실행 중인 서비스를 접근할수 있게 해준다.

왜 포트 매핑이 필요한가 ?

앞서 배운 NAT의 작동 방식을 생각해보면, 컨테이너는 내부 네트워크에서 사설 IP를 가지고 있다. 이 사설 IP는 외부에서 직접 접근할 수 없다. 컨테이너에서 외부로 나가는 트래픽은 NAT를 통해 호스트 IP로 변환되어 통신이 가능하지만, 그 반대 방향은 기본적으로 허용되지 않는다.
포트 매핑은 이 문제를 해결하여 외부에서 컨테이너 내부 서비스에 접근할 수 있는 경로를 제공한다.

docker run -p 8080:80 nginx

-p 8080:80의 의미

• 8080 : 호스트 시스템의 포트 번호
• 80 : 컨테이너 내부의 포트 번호

이 매핑은 호스트의 8080 포트로 들어오는 모든 트래픽을 컨테이너의 80포트로 전달하라. 는 지시이다.

포트 매핑의 상세 동작 과정

웹 브라우저에서 http://localhost:8080에 접속하는 경우를 예로 들어보자

1. 요청 생성:
   브라우저가 localhost:8080으로 HTTP 요청을 보낸다.
2. 호스트 수신:
   요청이 호스트 시스템의 8080 포트에 도착
3. 포트 매핑 확인:
   도커 엔진은 8080 포트에 대한 매핑 규칙을 확인한다.
4. 목적지 변환(DNAT):
   도커는 패킷의 목적지를 변환한다.
   - 원래 목적지: localhost:8080
   - 변환된 목적지: [컨테이너IP]:80
5. 컨테이너 전달:
   변환된 패킷이 도커 브리지를 통해 컨테이너로 전달된다.
6. 서비스 처리:
   컨테이너 내부의 웹 서버(nginx)가 포트 80에서 요청을 받아 처리한다.
7. 응답 생성:
   웹 서버가 HTTP 응답을 생성한다.
8. 출발지 변환(SNAT):
   응답 패킷이 나갈 때 출발지가 변환된다.
   - 원래 출발지: [컨테이너IP]:80
   - 변환된 출발지: localhost:8080
9. 클라이언트 전달:
   변환된 응답 패킷이 브라우저에 전달된다.

포트 매핑의 다양한 형태

1. 특정 호스트 인터페이스에 바인딩

docker run -p 127.0.0.1:8080:8080 nginx

이 명령은 호스트의 루프백 인터페이스(127.0.0.1)의 8080 포트만 컨테이너의 80 포트에 매핑합니다. 이 경우 외부 네트워크에서는 접근할 수 없고, 호스트 시스템 내에서만 접근 가능합니다.

2. 호스트의 임의 포트 사용

docker run -p 80 nginx
이 명령은 호스트의 임의의 사용 가능한 포트를 컨테이너의 80 포트에 매핑합니다. 실제 할당된 포트는 docker ps 명령으로 확인할 수 있습니다.

• 보통 호스트 포트번호는 작성하는게 기본. 베스트 프랙티스는 1번

여러 포트 매핑

docker run -p 80:80 -p 443:443 web-server

여러 -p 플래그를 사용하여 여러 포트를 동시에 매핑할 수 있다.

실제 활용 예시

웹 애플리케이션 배포

docker run -p 8080:8080 -p 8443:8443 spring-boot-app

Spring Boot 애플리케이션의 HTTP(8080)와 HTTPS(8443) 포트를 모두 호스트에 노출합니다.

데이터베이스서버

docker run -p 127.0.0.1:3306:3306 mysql

MySQL 데이터베이스를 로컬 개발 환경에서만 접근 가능하게 합니다.

api와 관리 인터페이스

docker run -p 80:80 -p 8080:8080 api-server

80 포트는 API 서비스용, 8080 포트는 관리 인터페이스용으로 사용합니다.

포트 매핑 보안

• 바인딩 제한 : 외부에 공개할 필요가 없는 서비스는 127.0.0.1에만 바인딩하여 로컬 접근만 허용하는 것이 좋다.
• 호스트 포트 충돌: 한 포트는 한 번에 하나의 프로세스만 사용할 수 있으므로, 이미 사용 중인 호스트 포트에 매핑하려고 하면 오류가 발생합니다.

최종 정리

최종 사용자(엔드 유저)는 항상 호스트 포트를 통해 컨테이너 내부 서비스에 접근한다.

예를 들어 -p 8080:80으로 설정된 웹 서버 컨테이너가 있다면:

1. 사용자는 http://호스트IP:8080으로 접속합니다
2. 도커의 포트 매핑 시스템이 이 요청을 자동으로 컨테이너의 80 포트로 전달합니다
3. 컨테이너 내부의 웹 서버가 요청을 처리하고 응답을 돌려보냅니다
4. 응답은 다시 포트 매핑을 통해 사용자에게 전달됩니다

이 모든 과정이 사용자에게는 투명하게 처리됩니다. 사용자는 컨테이너의 내부 IP나 포트를 알 필요가 없고, 마치 서비스가 호스트 시스템의 해당 포트에서 직접 실행되고 있는 것처럼 접근할 수 있습니다.