Information Security Study
240208 도커(DNS 개요 및 동작구조, load balancing 실습), 컨테이너 프록시(필요성, 포워드/리버스 프록시, nginx 소개) 본문
240208 도커(DNS 개요 및 동작구조, load balancing 실습), 컨테이너 프록시(필요성, 포워드/리버스 프록시, nginx 소개)
gayeon_ 2024. 2. 8. 16:02도커 DNS
배경 및 이론
사용자가 만든 네트워크에는 자동으로 컨테이너들이 등록된다.
이 DNS를 제어해 DNS 서버 생성과 로드밸런싱까지 한 번 학습했다.
도커 DNS는 사용자 정의 네트워크 내부 컨테이너의 이름을 자동으로 확인하도록 도커 호스트에 생성된다.
127.0.0.11 대역을 활용한다.
동일 network alias 할당을 통해 round robin 방식으로 응답
-> 로드밸런서처럼 사용 가능
컨테이너간 이름 조회가 가능한 이유
: 컨테이너 생성 시 호스트 시스템에서 다음 세 파일을 복사해서 컨테이너 내부에 적용하기 때문
저장경로는 다음과 같다.
/etc/hostname
/etc/hosts
/etc/resolv.conf
도커 DNS는 libnetwork라는 sandbox의 구현체에 구현되어 있다.
핵심 네트워킹 및 서비스 검색기능을 제공한다.
-> 등록된 모든 컨테이너를 이름으로 찾게 도와준다.
--name, 혹은 --net-alias 에 명칭을 적어 DNS에 등록된다.
조회 방식
- ping 컨테이너명을 입력한다.
- DNS resolver를 이용해서 컨테이너 내부에 등록된 이름인지 찾는다.
- 컨테이너 내부에 등록된 이름이 아니라면 도커엔진 내의 DNS서버에 질의한다.
- 질의한 타겟에게 결과를 전달한다.
- 최종적으로 전달된 내역을 토대로 연결한다.
위 순서로 동일 네트워크 내부의 다른 컨테이너를 조회한다.
실습하기
$ docker network create dnsnet
으로 네트워크를 생성한다.
생성 후 ls로 ID를 확인해 준 뒤
route 명령어로 대역을 확인한다.
dnsnet은 24번 대역에 생성되었다.
그리고 나서 이 대역에 ES를 설치한다.
$ docker run -d --name=es1 --net=dnsnet --net-alias=esnet-tg \
-p 9201:9200 -p 9301:9300 -e "discovery.type=single-node" elasticsearch:7.17.10
$ docker run -d --name=es2 --net=dnsnet --net-alias=esnet-tg \
-p 9202:9200 -p 9302:9300 -e "discovery.type=single-node" elasticsearch:7.17.10
--net-alias를 통해 esnet-tg라는 타겟 그룹을 만드는 것이다.
나머지는 환경변수 전달이나 포트바인딩 등이다.
위와 같이 만들면 그룹은 1개인데 컨테이너는 2개가 된다.
$ docker ps | grep es
위 명령어를 이용해 잘 돌아가고 있나 확인한다.
해당 컨테이너들의 ip를 inspect로 모두 조회해본다.
나온 ip 주소들을 확인한다.
다음으로 사용자 정의 네트워크에 DNS기능이 자동으로 활성화되는지 확인했다.
이를 위해 busybox 라는 이미지의 컨테이너를 띄워야 한다.
$ docker run -it --rm --name=request-container --net=dnsnet busybox nslookup esnet-tg
busybox의 nslookup 기능을 이용해 esnet-tg을 조회하면 아래와 같이 DNS 관련 정보가 나온다.
$ docker run -it --rm --name=request-container --net=dnsnet busybox nslookup 1번서버아이피
$ docker run -it --rm --name=request-container --net=dnsnet busybox nslookup 2번서버아이피
형식으로 조회를 해보면 각 컨테이너가 등록된 DNS서버의 주소가 정확하게 나오게 된다.
ip로 조회를 해보니 es1과 es2가 어디에 소속되어있는 서버인지 확인할 수 있었다.
es1.dnsnet
es2.dnsnet
es3을 추가로 만들어 띄우고 esnet-tg로 조회했다.
엘라스틱서치 특성상 9200포트를 모두 열어야 하므로
같은 네트워크를 사용하는 centos를 활용해 한 번 조회할 것이다.
$ docker run -it --rm --name=request-container --net=dnsnet centos:8 bash
bash 진입 후
$ curl -s esnet-tg:9200
명령어로 해당 alias인 esnet-tg에서 9200포트를 쓰는 모든 요소를 검색했다.
처음에 나오는 name을 확인한다.
다시 같은 명령을 입력해 보면 name이 바뀌어 있다.
이것으로 라운드 로빈 방식으로 순회해서 컨테이너 접속을 하고 있음을 알 수 있다.
위 이미지와 같이 es1, es2, es3을 번갈아가며 부하를 완화하고 있는 것이다.
컨테이너를 조회해서 alias에 대한 정보는
$ docker inspect 컨테이너명
명령어를 사용하면 된다.
실습: load balancing을 docker dns로 구현하기
1. 사용자 정의 Bridge network를 생성한다. (nginx 사용)
2. --net-alias를 이용해서 target group을 생성한다.
3. 등록된 DNS를 확인한다.
등록된 DNS를 확인하는 방법
$ sudo apt-get -y install dnsutils
로 설치한 다음
$ dig 타겟그룹명
명령어로 조회하면 된다.
아래 server 부분을 보면 53으로 배정되어 있다.
컨테이너 프록시 이해하기
프록시
프록시
: 대리자
기존에 서버와 클라이언트가 다이렉트로 통신을 하고 있었다면
요청자와 응답자 사이에 위치한 프록시 서버는 사용자의 요청을 대리로 받아서 서버들에게 적절히 분배한다.
프록시 서버는 위치와 역할적 개념에 따라서 포워드 프록시와 리버스 프록시로 나뉜다.
포워드 프록시
: 사용자의 존재를 서버에게서 숨긴 프록시
리버스 프록시
: 서버의 존재를 사용자에게서 숨긴 프록시
프록시를 활용의 이점
- 다중호스트에 트래픽을 분산시킬수 있는 로드밸런싱 구현이 가능
- html, js, css등의 정적 파일을 캐싱할 수 있는 캐시서버 구현 가능
- 학교나 사내망에서 특정 사이트 접근을 제어하는 차단 기능 구현 가능
- 무중단 배포를 통한 서비스 경험 향상 및 내구성 증가
- SSL암호화 적용을 통한 보안 강화 등 가능
프록시가 있어야 하는 이유
- 프록시가 없다면 사용자 요청이 직접 웹서버에 전달되어서 서버가 부담을 크게 받는다.
- 단일 웹서버만 구성한다면 장애가 발생했을 때 서비스 가용성에 치명적인 문제가 생긴다.
- 다중 웹서버를 만든다고 해도 적절한 분산로직을 설정하지 않으면 hotspot이라고 불리는 한 서버에 트래픽이 몰리는 현상이 발생할수도 있다.
- 최종 사용자 입장에서 레이턴시가 증가하는 등의 문제가 발생한다.
nginx
- 기본 구성값으로 웹서버를 실행할 수 있고 점유율이 상당히 높다.
- config파일의 간단한 수정만으로도 리버스 프록시를 구현할 수 있다.
- 쿠버네티스의 “인그레스 컨트롤러”로 “엔진엑스 인그레스 컨트롤러”를 선택할 수 있다.
- api트래픽 처리를 고급 http기능으로 사용가능한 api gateway구성이 가능하다.
- MSA트래픽 처리를 위한 MicroGateway로 사용할 수 있다.
- /etc/nginx 하위에 있는 nginx.conf 파일에 대한 변경을 통해 구성할 수 있다.
'네트워크 캠퍼스 > Docker' 카테고리의 다른 글
240213 도커(nginx 리버스 프록시) (0) | 2024.02.13 |
---|---|
240206 도커 네트워크(bridge 조회, 내부 망 host 등록, 브릿지/오버레이, 사용자 정의 네트워크) (1) | 2024.02.06 |
240205 도커(attac, exec, diff, docker commit/export, mount), 도커 네트워크(개요, bridge-utils, brctl) (0) | 2024.02.05 |
240202 도커(컨테이너 상태 감지, inspect로 내부 구조 확인, cp로 호스트파일 복사, events, kill) (0) | 2024.02.02 |
240130 도커(이미지 삭제, 가상머신 분리, 원격 레포지토리에 이미지 업로드, 이미지 검증, 도커허브 없이 이미지 옮기기) (1) | 2024.01.30 |