도커를 사용하는 의의
1. 변화하지 않는 실행 환경으로 멱등성(연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질) 확보
2. 코드를 통한 실행 환경 구축 및 애플리케이션 구성
3. 실행 환경과 애플리케이션의 일체화로 이식성 향상
4. 시스템을 구성하는 애플리케이션 및 미들웨어의 관리 용이성
웹 서비스 개발을 예로 들자면, 도커를 사용하면 로컬 개발 환경에서 필요한 애플리케이션을 신속하게 갖출 수 있고
그대로 플랫폼과 상관없이 배포할 수 있습니다.
도커 컨테이너로 변화하지 않는 실행 환경을 구축해 실행 환경이 원인이 되는 말썽을 최소한으로 줄일 수 있습니다.
웹서비스의 프론트엔드에 아파치나 엔진엑스 같은 웹 서버를 두는 것도 복잡한 절차 없이 컨테이너로 설정할 수 있습니다.
도커를 도입하면 개발 및 운영 업무가 쉬워집니다.
장점
1. 환경 차이로 인한 문제 방지
모두 배포 대상 서버간에 차이가 있어 애플리케이션 이 기대했던 대로 동작하지 않는 상황인데, 이문제의 근본적인 원인은 인프라의 가변성을 허용하고 있기 때문입니다.
애플리케이션은 항상 뭔가에 의존성을 갖습니다.
각 서버에 배포된 애플리케이션이 동일하다면 애플리케이션이 의존하는 환경의 차이를 가능한 배제하는 것이 이 문제를 해결하는 지름길입니다.
2. 코드로 관리하는 인프라와 불변 인프라
환경 문제를 해결하기위해 최근 제안된 것이 코드로 관리하는 인프라와 불변 인프라 개념입니다.
코드로 관리하는 인프라는 코드 기반으로 인프라를 정의한다는 개념입니다.
서버를 어떻게 구성할 것인지, 어떤 라이브러리와 도구를 설치할지를 코드로 정의하고 셰프(Chef)나 앤서블(Ansible) 같은 프로비저닝 도구로 서버를 구축합니다.
수작업이 개입할 여지를 줄이고 코드 중심으로 바꿈으로써 쉽게 같은 구성의 서버 여러 대를 복제할 수 있습니다.
다만 코드로 관리하는 인프라가 만병통치약은 아닙니다. 예를 덜어, 프로비저닝 도구로 다음과 같은 코드를 실행한 경우를 살펴보겠습니다.
$ nodebrew install-binary stable
이것은 Node.js 버전 관리 도구인 nodebrew에서 안정 버전(stable)을 설치하도록 설정하는 명령어 입니다.
stable이 가리키는 버전은 생각보다 자주 변하기 때문에 이런 방식으로는 항상 같은 결과가 보장되지 않습니다.
환경 차이 문제를 피하러면 언제든 몇 번을 실행해 같은 결과가 보장되는 멱등성을 확보해야 합니다.
애플리케이션이 의존한느 런타임이나 라이브러리 모두가 확실하게 특정 버전으로 설치되도록 코드를 작성해아합니다.
그러나 코드 기반으로 인프라 구축을 관리한다고 해도 멱등성을 보장하기 위해 항구적인 코드를 계속 작성하는 것은 운영 업무에 부담을 주기 쉽습니다.
서버의 대수가 늘어날수록 모든 서버에 구성을 적용하는 시간도 늘어납니다.
이 문제에 대한 대첵이 불변 인프라 개념입니다.
불변 인프라는 어떤 시점의 서버 상태를 저장해 복제할 수 있게 하자는 개념입니다.
제대로 설정된 상태의 서버를 항상 사용할 수 있다는 점이 가장 큰 장점입니다.
서버에 변경을 가하고 싶은 경우에는 기존 인프라를 수정하는 대신 새로운 서버를 구축하고 그 상태를 이미지로 저장한 다음 그 이미지를 복제합니다.
한번 설정된 서버는 수정 없이 파기되므로 멱등성을 신경쓸 필요조차 없습니다.
도커를 사용하면 코드로 관리하는 인프라와 불변 인프라의 두 개념을 간단하고 낮은 비용으로 실현할 수 있습니다.
인프라 구성이 Dockerfile로 관리되므로 코드로 관리하는 인프라는 도커의 대원칙입니다.
도커는 컨테이너형 가상화 기술을 사용합니다.
호스트형 가상화에서 가상머신의 OS를 재현하는 것과 달리, 컨테이너형 가상화는 운영 체제 대부분을 호스트 운영 체제와 공유합니다.
그만큼 실행에 걸리는 시간이 수초 가까이 짧아집니다.
실행에 걸리는 시간이 적은 만큼 구성을 수정하지 않고 인프라를 완전히 새로 만드는 불변 인프라와 궁합이 잘 맞습니다.
도커는 도커 이미지(Docker) 로 서버 구성을 코드로 관리할 수 있습니다.
그러므로 기존 컨테이너를 빠르게 폐기하고 새로이 구축할 수 있습니다.
코드로 관리하는 인프라와 불변 인프라라는 두 개념 모두를 쉽게 실현할 수 있는 도구라고 할 수 있습니다.
3. 애플리케이션과 인프라 묶어 구축하기
도커에서 제공하는 인프라 관리와 애플리케이션 배포 개념도 도커의 장점 중 하나입니다.
기존 방법에서 어플은 이미 구축된 서버에 배포되는 것이므로, 인프라 복제와 배포는 별개의 작업입니다.
이러한 경계도 환경의 차이가 생기는 주요 원인입니다.
도커컨테이너는 운영체제와 어플을 함께 담은 상자 같은 개념입니다. 도커 이미지 빌드는 인프라와 어플을 함께 묶는 과정일 수 밖에 없기 때문에 그 경계가 없어진 만큼 작업 환경의 차이도 줄었습니다.
컨테이너는 도커 이미지 형태로 저장하고 재사용 할 수 있습니다.
어플과 인프라를 함께 관리한 결과로 얻는 높은 이식성도 도커의 매력입니다.
생성해 둔 도커 이미지는 도커가 설치된 머신이라면 어디서든 실행할 수 있습니다.
로컬 환경에서 도커를 실핼 수 있다면 서버에서 실행되는 도커 컨테이너를 개발자의 로컬 도커 환경에서도 똑같이 실행할 수 있습니다.
Saas aas 스타일의 CI 서비스에서도 도커가 널리 쓰이는데요.
Travis CI 나 CircleCI 2.0, Codeship 같은 서비스에서도 도커를 사용한 CI를 지원하면서 도커이미지로 E2E 테스트를 수행하는 일이 가능해졌습니다.
여러 서버에 걸쳐 있는 여러 컨테이너를 관리하는 기법 ----> 오케스트레이션 (Docker Swarm, Kubernetes이 여기에 해당한다)
'Doker' 카테고리의 다른 글
도커 이미지 다루기 (0) | 2020.08.17 |
---|---|
도커 컨테이너 배포 (0) | 2020.08.17 |