[도커] 1장 시작하기 전에

도커는 컨테이너 라는 경량 단위로 애플리케이션을 실행하는 기능을 제공하는 플랫폼이다.

모놀리식 vs 마이크로서비스 (https://yozm.wishket.com/magazine/detail/1813/)

1.1 컨테이너가 IT 세상을 점령한 이유

• 운영 환경과 테스트 환경을 막론하고 애플리케이션을 빌드하고, 배포하고, 관리하는 모든 업무가 도커를 통해 이뤄지고 있다.

• 도커를 활용하면 프로덕트 출시 작업이 아주 쉬워지며, 유연성이 뛰어나 어떤 프로젝트든 도커를 도입할 수 있다.

1.1.1 클라우드 환경으로 이주하기

애플리케이션의 클라우드 환경 이주는 거의 모든 조직에서 최우선 관심사 일 것이다. 서버, 스토리지, 네트워크 심지어 전원까지 마이크로소프트나 아마존, 구글에 맡겨버릴 수 있다는것은 매력적인 조건이다.

전 세계에 존재하는 글로벌 데이터 센터에 우리 애플리케이션을 입주시켜 사실상 무제한의 확장성을 누릴 수 있고, 새로운 환경에 애플리케이션을 배포할 수 있으며 비용도 실제 사용한 만큼만 부담하면 된다. 그런데 클라우드 환경으로 이주하려면 어떻게 해야할까?

클라우드 환경으로 이주하려면..!
as is
아래 두가지 선택지가 있음

서비스로서의 플랫폼(PaaS)

• 우리 애플리케이션의 각 컴포넌트를 하나씩 클라우드 매니지드 서비스로 옮기는 까다로운 프로젝트를 진행해야 한다.
• 애플리케이션이 특정 클라우드에 종속되는 결과를 낳지만 운영비를 절감할 수 있다.

서비스로서의 인프라(Iaas)

• 애플리케이션의 각 컴포넌트를 가상머신에서 동작시킨다.
• 특정 클라우드에 종속되는 신세는 면할 수 있지만 운영비가 상승한다.

도커를 도입하면
to be

• 애플리케이션의 각 컴포넌트를 컨테이너로 이주한 다음 애저 쿠버네티스 서비스나 아마존 일랙스틱 컨테이너 서비스 혹은 직접 구축한 도커 클러스터에서 전체 애플리케이션을 실행할 수 있다.

• 컨테이너로 애플리케이션을 이주하려면 어느 정도 비용이 필요하다.

• 기존 설치 절차를 Dockerfile이라는 스크립트로 재작성해야하고, 배포 관련 사항 역시 도커 컴포즈나 쿠버네티스에서 사용되는 애플리케이션 매니페스트로 재작성해야한다.

• 코드를 수정할 필요는 없다. 컨테이너화된 애플리케이션은 업무용 노트북부터 클라우드까지 어떤 환경이든 기존과 동일한 기술 스택에서 그대로 동작한다.

1.1.2 레거시 애플리케이션 현대화하기

컨테이너를 활용하면 거의 모든 애플리케이션을 클라우드에서 실행할 수 있따. 그러나 기존 애플리케이션의 구조를 낡은 모놀리식 설계로 방치한다면 도커 혹은 클라우드 플랫폼의 진가가 발휘되기 어렵다.

컨테이너 환경에서는 30초면 새 기능을 단계적으로 자동 배포할 수 있지만, 이 새 기능이 모놀리식 설계를 가진 200만 줄 코드의 일부분이라면 이야기가 조금 달라진다. 이 상태에서 새 기능을 출시하려면 기존 기능이 망가지지 않았는지 확인하는 회귀 테스트에만 2주가 걸릴것이다.

도커로 이주하는 과정은 낡은 설계를 탈바꿈하는 첫걸음이다. 애플리케이션을 전면적으로 재구현하지 않고도 새로운 패턴을 도입할 수 있다!

방법은 간단하다. Dockerfile 스크립트와 도커 컴포즈 문법을 따라 애플리케이션을 단일 컨테이너로 옮긴다. 이것만으로 통짜 애플리케이션의 컨테이너 이주가 끝난다.

컨테이너는 가상 네트워크를 통해 외부에 노출되지 않고 서로 통신할 수 있다. 이 통짜 애플리케이션을 분할해 기능별로 별도의 컨테이너에 배치할 수 있다. 결과 적으로 통짜 애플리케이션이 여러 개의 컨테이너로 분할된 분산 애플리케이션으로 거듭나게 된다.

새로 추가된 기능은 별도의 컨테이너로 분리된다. 이들 컴포넌트는 자신만의 출시 주기를 가지며 기존 통짜 애플리케이션과 별도의 기술 스택을 가질 수도 있다.
외부에서 들어오는 모든 요청은 라우팅 컴포넌트로 전달된다. 라우팅 컴포넌트는 요청 내용에 따라 요청을 기존 통짜 애플리케이션 혹은 새로 추가된 컨테이너로 라우팅한다. 통짜 애플리케이션은 재구현 없이 서서히 마이크로서비스로 분할된다.

새로운 설계로 거듭난 애플리케이션은 마이크로서비스 아키텍처의 다양한 장점을 누릴 수 있다.

• 핵심 기능을 작고 독립된 단위로 만들어 따로따로 다루면서 변경 내용을 빠르게 테스트 할 수 있다. (애플리케이션 전체를 변경한 것이 아니라 해당 기능이 포함된 컨테이너만을 변경했기 때문이다.)
• 해당 기능의 확장성을 조절할 수 있다.
• 필요에 맞는 적절한 기술 기반을 선택할 수 있다.

도커를 도입하면 레거시 애플리케이션의 설계를 쉽게 현대화 할 수 있다.

1.1.3 클라우드 환경에 적합한 새로운 애플리케이션 개발하기

도커는 분산 애플리케이션이든 모놀리식 설계든 기존 애플리케이션을 클라우드로 이주하는 데 유용하다.
통짜 애플리케이션이라면 도커를 통해 컴포넌트를 분할하고 새로운 설계를 적용해 클라우드나 데이터센터 어디든 원하는 곳에서 애플리케이션을 운영할 수 있으며, 클라우드 확장을 고려한 완전히 새로운 애플리케이션 개발이라면 도커를 통해 더 빠른 개발이 가능하다.

마이크로서비스 아키텍처 (책에 데모이미지가 있음 p32)

• 각 컴포넌트는 자신만의 데이터를 가지며 API를 통해 이 데이터를 외부에 제공한다. 프런트엔드는 이들 API 서비스를 이용하는 웹 애플리케이션 형태다.
• 데모 애플리케이션은 여러 가지 프로그래밍 언어로 구현됐으며 서로 다른 데이터베이스 기술을 함께 사용한다.
• 반면 모든 컴포넌트는 공통적으로 Dockerfile을 통해 패키징 되며 도커 컴포즈 파일 형태로 전체 애플리케이션이 정의된다.

사용자는 웹 애플리케이션을 사용한다. 이 웹 애플리케이션은 NodeJS로 구현돼 도커 컨테이너에서 동작한다.
웹 프런트엔드는 여러 개의 마이크로서비스에서 제공하는 API를 사용한다. 이들 마이크로서비스는 자신만의 데이터를 가지며 서비스와 데이터스토어 모두 도커 컨테이너에서 동작한다.
이 외에 서비스가 큐를 통해 메시지를 퍼블리시/구독하는 비동기적인 워크플로도 있다. 서비스와 메시지 큐 역시 도커 컨테이너에서 동작한다.

도커를 이용해 코드를 컴파일하는 방법을 배운다. 분산 애플리케이션을 빌드하고 실행하는 데는 별도의 개발 도구가 필요치 않다. 도커를 설치하고, 소스 코드 저장소를 복제한 다음, 한 번의 명령으로 코드를 빌드하고 전체 애플리케이션을 실행할 수 있다.

도커는 서드파티 소프트웨어를 도입하는 데도 유용하다. 이런 방법으로 코드를 작성하지 않고도 애플리케이션에 새로운 기능을 추가할 수 있다.

도커 허브는 다양한 사람이 자신이 작성한 컨테이너를 공유하는 서비스다.

CNCF는 모니터링부터 메시지 큐까지 원하는 용도에 적합한 오픈소스 프로젝트의 목록을 제공한다. 이들모두 도커 허브를 통해 자유롭게 사용할 수 있다.

1.1.4 기술 혁신: 서버리스와 그 너머

현대 IT 기술을 주도하는 요소 중 하나는 일관성이다. 개발 팀은 모든 프로젝트에서 같은 도구, 같은 프로세스, 동일한 런타임을 사용하기를 원한다. 도커를 통해 이러한 요구를 만족시킬 수 있다.

도커 클러스터를 구축하면 모든 제품의 빌드, 배포, 운영을 같은 도구와 같은 방법으로 수행할 수 있다.

컨테이너 도입 후 마주할 가장 흥미진진한 기술 혁신은 서버리스 함수다.

어떠한 어플리케이션이라도 단일 도커 클러스터 혹은 서버를 이용해 실행할 수 있따. 그리고 아키텍처나 기술 기반과 무관하게 이들 애플리케이션의 빌드, 배포, 관리를 일원화 할 수 있다.
운영 환경 클러스터를 리눅스나 윈도에서 혹은 두 운영체제를 섞어 구성할 수 있다.
컨테이너화된 애플리케이션을 관리하기 위한 도커 스웜 API나 쿠버네티스 API를 사용할 수 있도록 클러스터를 설정할 수 있다.

서버리스 기술은 곧 컨테이너 기술이다.
개발자에게 있어 서버리스 기술의 목표는 개발자가 함수 코드를 작성하고 서비스에 푸시하면 서비스가 코드를 빌드하고 패키징하도록 하는 것이다. 함수 사용 측에서 함수를 호출하면 서비스는 해당 함수의 인스턴스를 생성해 요청을 처리한다. 이 과정에는 빌드 서버도, 파이프라인도, 관리가 필요한 운영 환경도 없다.

1.1.5 데브옵스 도입하기

대부분의 조직이 직면하는 가장 큰 문제는 역시 운영이다.
기술 조직은 '개발 팀'과 '운영 팀'으로 나뉘어 프로젝트 생애주기의 서로 다른 부분을 담당한다.

출시 시점의 문제점은 개발 팀과 운영 팀이 서로 책임을 미루게 되기 쉽다. 따라서 이후 발생할 수 있는 문제를 방지하기 위해 이 시점에 품질 게이트를 둔다. 그러다 보면 결국 점점 늘어나는 품질 게이트로 인해 불어나는 위험과 작업량을 감당하지 못해 한 해에 한두 번밖에 출시하지 못하게 된다.

데브옵스는 기민한 소프트웨어 유지 보스를 위해 애플리케이션의 전체 생애주기를 담당하는 전담 팀을 둔다. 이름부터가 개발과 운영을 합친것이다. 분기별 대규모 릴리스를 작은 규모의 일일 배포로 대체하게하는 식이다.

개발자와 운영자가 서로 다른 기술을 사용하는데 어떻게 하나의 팀을 이룰 수 있을까? 여기서 바로 도커의 진가가 발휘된다.
컨테이너로의 전환을 통해 데브옵스 도입을 촉진할 수 있다. 팀원 모두가 Dockerfile과 도커 컴포즈 스크립트를 사용하면 같은 기술과 도구로 팀을 통일할 수 있다.

CALMS라는 데브옵스를 위한 프레임워크가 있다. C문화(Culture), 자동화(Automation), 린(Lean), 측정(Matric), 공유(Sharing)의 머리글자를 딴것이다. 도커는 이 개념과 밀접하다.

자동화는 컨테이너 환경의 핵심이고 분산 애플리케이션은 린 원칙에 따라 만들어지며, 배포 프로세스와 운영 로그로부터 얻은 측정치를 쉽게 활용할 수 있고 도커 허브는 이미 있는 것을 다시 만드는 노력을 절약할 수 있는 공유의 장이다.