[코드 스테이츠] 111일차, "16주차 복습"

---

[ 오늘의 TODO ]

1. 코드 스테이츠) 월~목 개념 복습
   // Docker
2. 생활) 물 1L 이상 마시기
3. 생활) 1시간 이상 걷기 

 

---

[ 오늘의 복습 ]

1.  Docker

  일상생활에서 사용하는 컨테이너는 다음의 장점이 있다.

1. 물자를 싣고 내릴 때, 선박이 입항해 있는 시간을 획기적으로 단축한다
2. 물자를 싣고 내릴 때, 필요한 인력을 대폭 감소한다.

  개발자들은 이 컨테이너 기술을 소프트웨어를 수송하는 배포에 사용하고 싶었다. 그 결과 리눅스 컨테이너라는 걸 만들었고, 2013년에 Docker 가 등장했다. 일반적인 애플리케이션 실행은 어떤 환경에 구애를 받으나 도커와 같은 컨테이너를 이용하면 실행 환경에 구애받지 않고 애플리케이션을 실행할 수 있다. 

 

1-1) 컨테이너 방식의 장점

  의존성 충돌 문제를 해결한다. 

  어떤 애플리케이션은 반드시 어떤 환경이 구축돼야 한다. 쉽게는 윈도우용 프로그램을 실행하려면 윈도우 운영체제가 필요한 것과 같다. A 라는 프로그램을 실행하고자 할 때 B 프로그램이 반드시 필요한 경우 "A 는 B 에 의존 관계를 가지고 이있다" 고 말한다.

 

  일반적으로 한 컴퓨터에 여러 버전의 동일한 애플리케이션이 설치되지 않는다. 예를 들어, php 의존 관계를 가진 다른 두 애플리케이션 중 하나는 제대로 된 실행을 보장할 수 없다. 왜냐하면 각각의 프로그램이 php 의 다른 버전을 의존할 수 있기 때문이다. 컨테이너 기술은 이 문제를 해결한다. 컨테이너 기술은 애플리케이션을 컨테이너 내에 구성한다. 컨테이너에서 실행 중인 애플리케이션은 어떠한 의존성도 공유하지 않고, 각자 고유의 의존성을 포함한다는 얘기다.

 

  컨테이너를 바탕으로 한 컴퓨터에 여러 컨테이너가 존재하고 이를 통해 애플리케이션 실행 환경이 서로 격리 된다. 하나의 컴퓨터 내에 서로 다른 php 가 설치될 수 있는 건 컨테이너 하나하나가 애플리케이션 실행과 관련해 높은 수준의 격리를 제공하기 때문이다. 컨테이너는 다음의 내용들을 격리하고 독립적으로 소유한다. 

 

1. 프로세스
   특정 컨테이너에서 작동하는 프로세스는 기본적으로 그 컨테이너에서만 액세스가 가능하다
   컨테이너 안에 실행되는 프로세스는 다른 컨테이너 프로세스에 영향을 줄 수 없다.
   
   
2. 네트워크
   기본적으로 컨테이너 각각에 IP 주소가 할당된다.
   
   
3. 파일 시스템
   컨테이너 안에서 사용되는 파일 시스템은 구획화돼 있다. 해당 컨테이너 명령이나 파일등의 액세스를 제한할 수 있다.
   
   

  도커가 작동하시는 방법을 보면 가상 머신과 비슷하게 보인다. 가상 머신은 하나의 호스트 컴퓨터 위에 여러 독립적인 도커를 비롯한 리눅스 컨테이너 기술은 가상 머신의 접근 방법과 조금 다르다. 

  개발과 배포 환경을 일치시킨다. 

  Node.js 나 Python 웹 서비스를 개발하면 하나의 애플리케이션을 만들기 위해 비슷한 개발 환경을 구축한다. 특정 버전 이상의 Node.js, MySQL 등을 개발자 각자 본인 운영체제 설치하고 개발을 진행한다. 하지만, OS 나 Node.js 의 런 타임 환경 버전을 비슷하게 맞추기 위해 커뮤니케이션을 해야하고 시스템 환경 변수를 애플리케이션에 맞게 구성해야 제대로 작동하는 경우도 종종 볼 수 있다. 이렇게 사소한 실수나 사전 설치 항목의 부재는 문제 해결에 많은 시간을 소모하게 한다. 새로운 프로젝트의 투입되는 개발자의 경우 작성된 코드를 돌리고 싶으나 환경 세팅으로 어려움을 겪게 된다. 

 

  그러나 도커는 이런 문제를 해결해준다. 도커가 실행 중이라면, 어떤 운영체제든 상관 없이 즉시 설치하고 실행할 수 있다. 그렇기에 도커는 OS 에 상관 없이 즉시 애플리케이션 실행 환경을 만들 수 있다는 점, 개발을 컨테이너 위에서 진행할 경우 모든 개발팀이 동일한 환경 하에 개발을 진행할 수 있다는 점에서 매우 편리하다. 

 

  위의 환경 세팅은 배포에서도 동일하게 적용된다. 웹 서비스의 배포란 "어떤 애플리케이션이 특정 런타임 환경 위에서 실행되고, 사용자에게 이를 제공한다." 라는 것인데 실행 환경 구성과 본질적으로 다를 것이 없다. 서비스를 인터넷상에 공개적으로 노출하느냐, 내 컴퓨터 상에 프라이빗하게 작동하느냐의 차이일 뿐이다. 그래서 이제 배포의 패러다임이 달라졌다. 서버에 파일 하나하나 업로드 하는 방식이 이전의 ㅅ방식이었다면 이제 컨테이너에 담긴 애플리케이션을 실행하는 방식으로 서비스를 제공한다. EC2 상에 도커를 설치하거나ㅣ, 좀 더 편리하게 도커 컨테이너를 EC2 서버에서 실행할 수 있게 하는 서비스인 EC2 를 이용해서 보다 쉽게 애플리케이션을 배포할 수 있다. 

 

"내 컴퓨터에선 작동되는데? (네 잘못이겠죠)" 라고 하는 옛날 밈은 도커와 같은 컨테이너 방식 배포로 이제 더이상 사용할 수 없다. (짤이 귀여워서 가져옴)

  

  수평확장이 쉽고 각 서버에 새로운 내용을 배포하기 쉽게 만들어 준다.

  우리가 매일 사용하는 글로벌 웹 서비스는 트래픽이 장난 아니다. 예를 들어, 구글의 경우 전 세계의 사람이 동시 접속하고 있다. 그렇게 많은 사람을 단 하나의 서버 컴퓨터로 받아들이는 것은 거의 불가능하다. 그것을 가능하게 하는 것은 서비스 제공자들이 트래픽 분산을 위해 프록시 서버를 운영하는 것이다. 프록시 서버는 여러 대의 동일한 검색 서버 중 한 곳을 이용할 수 있도록 돕는다. 이런 서버를 리버스 프록시의 한 종류인 로드 밸런서라고도 부른다. 

 

  동일한 서비스가 여러 컴퓨터에서 작동한다는 말은 도커가 필요하다는 것을 의미한다.' 컨테이너 기술의 가장 큰 장점은 실행 환경의 일치다. 더 많은 트래픽으로 인해 서버 증설에 컨테이너 기술은 활발하게 이용되고 있다. 동일한 애플리케이션 구성을 바탕으로 해당 어플리케이션을 컨테이너로 실행하고, 로드 밸런서에 이 서버를 추가하기만 하면 된다. 이런 기술을 응용해, 새로운 버전의 애플리케이션을 여러 서버 중 몇 대에만 운영해서 테스트 하는 방법도 가능하다. 그렇기에 새 버전의 애플리케이션에서 발생할 수 있는 문제들을 미리 확인하고, 이 문제가 사용자 전체에게 영향을 끼치지 않도록 만들 수 있다. 

 

 

1-2) 도커 핵심 키워드

  컨테이너

  애플리케이션이 의존성, 네트워크 환경, 파일 시스템에 구애받지 않고 도커라는 기술 위에 실행될 수 있도록 만든 애플리케이션 상자다.

  이미지

  실행되는 모든 컨테이너는 이미지로부터 생성된다. 이미지를 이용해서 여러 컨테이너를 생성할 수 있고 수평 확장이 가능해진다. 이미지는 기본 이미지로부터 변경 사항을 추가/커밋해서 다른 이미지를 만들 수 있다. Node.js 이미지를 기본 이미지로 삼고 내가 만든 애플리케이션을 추가해 넣고 이미지화 할 수 있다. 

  레지스트리

  이미지는 레지스트리에 저장된다. 대표적인 이미지 레지스트리로는 Docker Hub, Amazon ECR 이 있다. 도커 CLI 에서 이미지를 이용해 컨테이너 생성할 때, 호스트 컴퓨터에 이미지 존재하지 않는다면, 기본 레지스트리로부터 다운을 받는다. 

 

 

 

2. 배포 자동화

  배포 자동화란 한 번의 클릭 혹은 명령어 입력으로 전체 배포 과정을 자동으로 진행하는 것을 의미한다. 수동적이고 반복적인 배포 과정을 자동화하여 시간이 절약되고 휴먼 에러(수동적으로 작업하는 중에 생기는 실수를 의미) 를 방지할 수 있다. 

 

2-1) 배포 파이프라인

  파이프라인이란 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 의미한다. 파이프라인은 배포 과정을 Stage 로 나누고 각 Stage 마다 주어진 작업을 수행한다.

 

  Source Stage

  원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 생길 경우, 이를 감지하고 다음 단계로 전달할 작업을 수행한다

  버전 컨트롤 도구를 이용한 소스 코드를 관리하고 전달한다.

  Build Stage

  Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다. Build 단계를 거쳐 생성된 결과물을 다음 단계로 넘긴다.

  Deploy Stage

  Build 단계에서 전달받은 결과물을 실제 서비스에 반영하고 서비스를 업데이트한다.

 

  파이프라인의 단계는 상황과 필요에 따라 세분화되거나 간소화될 수 있다. 

 

 

 

3. AWS 개발자 도구

  AWS 에는 개발자 도구 섹션이 존재하여 배포 자동화 파이프라인을 구축할 수 있다.

 

3-1) CodeCommit

  Source Stage 구성할 때 이 서비스를 이용한다. CodeCommit 은 Github 과 비슷하다. CodeCommit 의 경우 서비스, 보안과 관련된 기능에 있어서는 Github 보다 더 좋다. 따라서 소스 코드 유출이 크게 작용하는 기업에서는 중요한 요소가 된다. 다만, 과금을 고려해야 한다. 

 

3-2) CodeBuild

  Build Stage에 필요한 서비스다. 유닛 테스트, 컴파일, 빌드 같은 Build Stage 에서 필수적으로 실행돼야할 작업을 명령어로 실행할 수 있다. 

 

3-3) CodeDeploy

  Deploy Stage 구성할 때는 다양한 서비스를 이용할 수 있다. 실행되고 있는 서버 애플리케이션에 실시간으로 변경 사항을 전달할 수 있다. S3 서비스를 함께 이용하면 버킷을 이용해 업로드된 정적 웹 사이트에 변경 사항을 실시간으로 전달하고 반영할 수 있게 된다.

 

3-4) CodePipeline

  각 단계를 연결하는 파이프라인을 구축할 때 사용한다.