플레이데이터 풀스택 백엔드 9기 6월 3주차 회고

플레이데이터 풀스택 백엔드 9기 14주차 주간회고 및 학습기록 (열네번째 기록)

---

이번 주에는 Ansible, CircleCI, DevOps, Docker에 대해 배웠다. 처음 Docker를 배웠을 때는 개념이 잡히지 않아 좀 힘들었기 때문에 비유를 통해 이해하려고 노력했다. 내가 이해한 방식을 기록하고자 한다. 

 

1. 비유를 통한 Docker의 이해

Docker

• 여러 컨테이너를 띄울 수 있는 운영 플랫폼
• 비유: 배

Dockerfile

• 이미지를 만들기 위한 스크립트 파일
• 이런 환경에서 시작해서, 이 파일 복사하고, 이런 프로그램 설치하고, 이렇게 실행해줘...등의 명령어 모
• 비유: 설계도(이미지)를 만드는 레시피

Image

• 컨테이너의 실행 설계도 (서비스 운영에 필요한 서버 프로그램, 소스코드 및 라이브러리, 컴파일 된 실행 파일을 묶는 형태)
• 특정 프로세스를 실행하기 위한 모든 파일과 설정값을 지닌 파일들의 묶음
• 비유: 화물 설계도 / 적재계획표

Container

• 이미지를 실행한 인스턴스 
• 실제로 동작하는 애플리케이션/서비스
• 독립된 소프트웨어 실행 환경
• 비유: 배 위의 독립된 화물 컨테이너

Volume

• 컨테이너의 데이터 저장 공간
• 컨테이너가 삭제되어도 데이터 유지 가능
• 비유: 배 안의 영구 저장소 (배가 가라앉아도 데이터는 남음)
  

Registry

•  이미지를 저장하고 배포하는 공간 
• ex: Docker Hub
• 비유: 전 세계 컨테이너 설계도가 저장된 항구

흐름

1. 설계도면 초안(Dockerfile)으로 설계도(Image) 제작
2. '이런 물건을 이렇게 넣은 컨테이너를 하나 만들자'는 내용을 담은 설계서(Image)를 바탕으로
3. 화물 컨테이너 (Container : 실행 중인 애플리케이션)를 제작
4. 배 (Docker)는 이 컨테이너들을 태우고 움직임
5. 화물 컨테이너 (Container)들은 서로 격리되어 있지만, 같은 배 안에서 통신 가능

---

2. 컨테이너와 MSA의 관계

컨테이너

• 하나의 애플리케이션 또는 서비스 단위를 실행하는 독립적인 실행 환경
• 마이크로서비스 하나
• 3차 프로젝트 (영화 리뷰/추천 사이트) 예시
  • user-service → 유저 관련 기능을 담은 컨테이너
  • movie-service → 영화 정보 관련 기능을 담은 컨테이너
  • review-service → 리뷰 관련 기능을 담은 컨테이너
  • recommend-service → 추천 알고리즘을 담은 컨테이너

MSA (Microservice Architecture)

• 하나의 큰 시스템을 여러 작고 독립적인 서비스로 나누는 방식
• 각 컨테이너는 자신만의 실행환경을 갖고 있기 때문에 개별 서비스를 실행하기 좋은 기술

"웹서버 도커 이미지로부터 여러 개의 컨테이너를 생성하면, 생성된 컨테이너의 개수만큼 웹서버가 생성되고, 이 컨테이너들은 외부에 웹 서비스를 제공하는 데 사용된다."

 

Image: 실행 가능한 웹서버 프로그램을 담고 있는 설계도
>> 이 이미지로부터 컨테이너를 여러개 생성하면, 그 설계도를 복사해서 독립적으로 실행한 웹서버 인스턴스들이 생김
>> 이미지 하나로 컨테이너를 여러개 생성하면, 그만큼 웹서버가 병렬로 떠 있는 것 (수평 확장: scale out)
>> 영화 검색 요청이 많아지면 검색기능 컨테이너의 개수를 늘려서 부하 분산 가능 

 

결국 사용자(client)가 웹사이트 하나에 접속하여 하나의 서비스를 사용하는 것처럼 보이지만

내부에서는 요청마다 각기 다른 컨테이너가 응답하는 구조

---

3. 내/외부 포트 의미 및 포트 충돌 해결 방법

ubuntu라는 이미지로 mywebserver라는 컨테이너를 생성하는 코드

>> -p 옵션을 추가하여 컨테이너의 포트를 호스트의 포트와 바인딩할 수 있음

 

[호스트 포트(외부포트)] : [컨테이너 포트(내부포트)] 

>> 위에서는 호스트의 80번 포트와 컨테이너의 80번 포트를 연결

>> 앱(컨테이너)는 내부 포트 80에서 실행 중 & 외부에서는 localhost:80으로 접속해야 앱을 볼 수 있으

>> 내/외부 포트 번호가 달라도 괜찮음

 

비유

• 호스트 포트 (외부 포트) - 외부에서 컨테이너(앱)으로 접근하는 문 
• 컨테이너 포트 (내부 포트) - 컨테이너 안에서 앱이 열어놓은 문

외부 포트와 내부 포트를 나눠서 굳이 외부 포트를 매핑해야 하는 이유

• 보안
  : 컨테이너 내부는 외부에서 보이지 않음. 내부 포트는 기본적으로 비공개이고, -p 옵션을 통해 명시적으로 외부 포트를 열어주지 않으면 외부에 노출되지 않음 내부 포트를 외부에서 자동 접근하도록 허용하면 보안상 매우 위험하고 도커의 격리 원칙이 붕괴됨
• 격리된 구조
  : 도커는 컨테이너를 외부와 격리된 환경으로 만듦. 따라서 내부에서 포트를 열어도 외부와 연결하지 않으면 접근 불가
  /
  하나의 서버에서 여러 컨테이너를 돌릴 수 있음. 즉 외부 포트는 호스트 기준으로 유일해야 하는 반면, 컨테이너마다 내부 포트는 중복돼도 무방 >> 여러 앱이 같은 포트를 써로 격리되어 충돌 없이 돌아감