1장. 시작하기 전에

1. 컨테이너가 IT 세상을 장악한 이유

도커가 없던 시절의 IT 업계는

협업하기 위한 동일한 환경을 만들기 위해 

동일한 툴 들을, 동일한 특정 버전으로, 반복적으로 설치해야 했다.

그 마저도 개발 환경 셋팅과 관련 문서가 없으면

많은 시간을 들여가면서 발생할 수 있는 많은 문제들에 시행 착오를 겪어야 했을 터였다.

 

도커 컨테이너가 등장하면서

빌드, 배포, 앱의 관리 등을

도커 하나로, 하나의 커맨드만으로도 동일한 환경을 만들 수 있게 되었다.

기존 환경을 만들기 위한 동일한 툴, 특정 버전의 툴 들을

도커 하나로 중앙 집중화 시킬 수 있게 되었고

이는 모든 사람이 동일한 환경을 쉽게 셋팅할 수 있게 만들어 줄 수 있다.

 

1.1. 클라우드에 앱을 이전하기

클라우드가 발전함에 따라 많은 회사들이 자사의 애플리케이션들을 클라우드로 이관시킨다.

• 클라우드 회사에게 서버, 디스크, 네트워크 등의 관리비용을 위임할 수 있음
• 사용한 만큼의 비용을 지불하면 되기 때문.

 

선택지는 보통 두 가지로

• PaaS (Platform as a Service)
  • 적은 비용이 들지만, 하나의 클라우드
• IaaS (Infrastructure as a Service)
  •  더 많은 비용 발생, 애플리케이션마다 가상 머신 작동 가능

 

여기서 도커는 세 번째 옵션을 제공해 준다.

기존 코드의 변경 없이 애플리케이션의 각 부분을 컨테이너로 만들고,

Azure Kubernetes Service나 Amazon's Elastic Container Service 등과 같은

도커 클러스터 서비스를 이용해 컨테이너를 작동 시킬 수 있다.

 

 

1.2. 레거시 앱의 현대화

도커로 앱을 옮기는 것은 앱을 처음부터 다시 만들지 않고 새로운 아키텍처를 적용시킬 수 있다.

필요한 만큼 애플리케이션을 나누어 컨테이너로 만들어 구동하면,

내부적으로 컨테이너 간에 통신을 할 수 있도록 구현이 가능하기 때문에,

코드의 변경 없이 아키텍처를 변경 시킬 수 있다.

ex) 모놀리스 → 마이크로 서비스

 

마이크로서비스 아키텍처처럼

주요 기능들을 독립적으로 관리할 수 있는 작고, 고립된 단위로 만들 수 있기 때문에,

기능들의 스케일을 확장하거나 축소시킬 수 있고, 요구사항에 맞는 다양한 기술들을 사용할 수 있게 된다.

 

그렇기 때문에,

오래된 애플리케이션 아키텍처를 현대화 할 때, 도커는 좋은 선택지가 될 수 있다.

 

 

1.3. 새로운 클라우드 네이티브 애플리케이션 구축

도커는 기존 애플리케이션을 모놀리스이든 분산 애플리케이션이든 클라우드로 가져올 수 있도록 도와줄 수 있다.

 

Cloud Native Computing Foundation (CNCF)는 

컨테이너를 사용한 이 새로운 아키텍처를

"오픈 소스 소프트웨어 스택을 사용하여 애플리케이션을 마이크로서비스로 배포하고
각 부분을 자체 컨테이너로 패키징하고, 리소스 활용 최적화하기 위해
컨테이너를 동적으로 오케스트레이션 하는 것"

으로 특정지었다고 한다.

 

이러한 새로운 마이크로서비스 애플리케이션의 데모 애플리케이션을 보고 싶다면,
https://github.com/microservices-demo 에서 확인할 수 있습니다.

 

이 마이크로서비스는,

각 구성 요소는 자체 데이터를 가지고 API를 통해 노출하게 되고,

프론트엔드는 모든 API를 사용하는 웹 애플리케이션이 된다.

 

각 구성 요소는 각자 자신을 패키징할 Dockerfile을 가지고 있으며,

전체 애플리케이션은 Docker Compose 파일로 정의하게 된다.

 

이러한 앱을 빌드하고 실행하기 위해서는 특별한 툴을 설치할 필요 없이

도커를 설치하고, 소스 코드를 복제하고,

하나의 커맨드로 전체 애플리케이션을 빌드하고 실행할 수 있다.

 

 

1.4. 기술 혁신: 서버리스 등

현대 IT에서 가장 중요하게 보는 것 중 하나가 일관성이다.

모든 프로젝트에 동일한 도구, 프로세스 및 런타임을 사용하기를 원한다.

 

앞서 간략하게 설명한 것처럼

도커를 사용하여 동일한 방식으로

전체 애플리케이션 환경을 구축, 배포 및 관리할 수 있다.

 

서버리스는 컨테이너에 대한 전부이다.

 

서버리스의 목표는

개발자가 기능 코드를 작성하고,

서비스에 푸시하고,

서비스가 코드를 빌드하고 패키징 하는 것이다.

 

개발자가 기능을 사용할 때,

서비스는 요청을 처리하기 위해 기능의 인스턴스를 시작한다.

관리할 빌드 서버, 파이프라인 또는 프로덕션 서버가 별도로 존재하지 않고

모두 플랫폼에 의해서 처리된다.

 

모든 클라우드 서버리스 옵션은

도커를 사용하여 코드와 컨테이너를 패키징하여 기능을 실행할 수 있다.

(서버리스에 대한 표준이 없기 때문에 클라우드 기능을 이식할 수는 없어 클라우드 서비스 간 호환이 불가능)

 

 

1.5. DevOps를 통한 디지털 트랜스포메이션

오늘날의 많은 기업들이 직면하고 있는 가장 큰 문제중 하나는 운영이다.

 

DevOps는 전체 애플리케이션의 라이프 사이클을 가지고

"Dev"와 "Ops"를 하나로 결합하여

소프트웨어 배포 및 유지 보수에 민첩성을 제공하는 것을 목표로 한다.

하지만 DevOps로의 역할을 수행하려면, 팀이 사용하는 기술을 바꾸지 않고는 어렵다.

 

이 때 도커가 큰 도움이 된다.

컨테이너로의 전환을 통해 DevOps 전환을 뒷받침할 수 있으며,

팀 전체가 동일한 언어, 동일한 도구로 작업하며

Dockerfile, Docker Compose 파일로 작업하게 된다.

 

더 나아가

CALMS (Cultrue, Automation, Lean, Metrics, Sharing)이라는

강력한 DevOps 구현 프레임워크가 있다.

• Culture: DevOps는 단순히 프로세스나 개발에 대한 접근 방식이 아니라 문화를 변화하는 것
• Automation: 컨테이너 실행의 핵심
• Lean: 분산 애플리케이션은 Lean(린) 원칙에 따라 구축됨
• Metrics: 프로덕션 앱과 배포 프로세스에서 얻은 Metrics를 쉽게 publish할 수 있음
• Sharing: Docker Hub를 통해 중복된 노력 없는 Sharing(공유)가 가능함

CALMS에 대해서 더 자세히 알고 싶으시다면,
아래 링크를 참고하세요!
https://www.atlassian.com/devops/frameworks/calms-framework

 

 

---

2. 누가 읽어야 할 책인가?

위 다섯 가지 시나리오와 같은 문제를 도커로 해결하고 싶은 사람을 위해 작성되었다고 한다.

아무것도 모르는 상태에서 프로덕션급 클러스터에서 컨테이너로 앱을 실행할 수 있도록 안내가 되어있다고 한다.

하지만 그러면서도 작동 원리에 대해서는 너무 깊게 설명은 되어 있지 않다고 함..

 

Docker에 대한 작동 원리를 더 자세히 알고 싶다면,
Manning사의 Docker in Action, Second Edition (Jeff Nickoloff 저) 책을 추천한다고 한다!

 

---

3. 개발 환경 셋팅

3.1. 도커  데스크탑 설치

https://www.docker.com/products/docker-desktop/

Docker Desktop: The #1 Containerization Tool for Developers | Docker

 

설치 후 아래 커맨드가 정상적으로 실행되면, 설치가 제대로 완료된 것이다.

# Docker 버전 확인
docker version

# Docker Compose 버전 확인
docker-compose version

 

 

3.2. 책의 예시 코드 - GitHub

아래 명령어를 통해 예제 코드들을 복사할 수 있다.

git clone https://github.com/sixeyed/diamol.git