기고 | 개발 환경의 혁신! '도커' 따라잡기
OSS
게시글 작성 시각 2015-09-08 14:57:41
2015년 09월 02일 (수)
ⓒ CIO Korea, Matthew Heusser | CIO
소프트웨어 시험 속도를 높이는 도커는 모든 규모의 개발팀에게 유용할뿐더러 이용하기도 쉽다. 여기 그 이유들을 정리한다.
![](http://files.idg.co.kr/ciokr/image/docker-100432103-primary_idge.jpg)
Credit: iStockphoto
테스트 환경에서 딱 맞는 빌드가 나올 때까지 기다리기란 여간 성가신 일이 아니다. 또한 개발, 테스트, 생산 사이의 간극은 결함을 야기했다. 가상 머신(Virtual Machine)을 이용하면 시스템 데이터 카피를 공유해 이런 문제들을 해결할 순 있기는 하다. 그러나 매우 느린데다 디스크 공간을 몇 기가바이트씩 차지한다.
그렇다. 가볍고 빠른 리눅스 가상화 툴 도커(Docker)가 활약할 타이밍인 것이다.
도커가 제안하는 기회들
어느 정도의 기술적 지식만 있다면 로컬 머신에 테스트 환경을 생성하는 것은 몇 초 걸리지 않는다. 기존 OS에 새 프로세스가 연결되므로 ‘부팅’할 필요가 없다. 이전 빌드가 저장돼 있는 상태일지라도 도커는 새로운 빌드에서 달라진 점들만을 로딩한다. 기특할 정도로 똑똑하다.
도커를 채택한 조직들에게 이러한 간결함은 특별한 경험이 아니다. 검증 단계의 아키텍처를 상용 단계로 확장하는 과정에서도 자동 연결을 통한 간결화의 혜택을 누릴 수 있다.
도커의 또 다른 훌륭한 기능 중 하나는 완전히 새로운, 십여 개의 가상 머신으로 구성된 서버팜용 가상 인프라스트럭처를 구성할 수 있다는 것이다. 이들은 ‘그린’ 빌드라 불린다.
그린 빌드에서는 그 어떤 최종 복귀 테스팅도 가능하다. 테스팅이 끝나면 배치 스크립트가 서버로 전달되고, 이제는 그린 빌드가 상용 코드의 역할을 맡게 된다. 하지만 이전 빌드인 ‘블루' 빌드 역시 필요할 경우를 대비해 삭제되지 않고 잔여 해 있기에 언제던 복귀가 가능하다.
여러 테크놀로지들에서 적용 가능한 이러한 방식을 블루/그린 배치라 부른다. 도커는 이런 기존의 방법론을 보다 용이하게 하는 솔루션일 뿐이다.
왜 도커인가?
하나의 인스톨러에 컴파일하는 윈도우 기반 소프트웨어와는 달리 웹 기반 소프트웨어는 서버 상에서 빌드를 구동하는 방식을 취한다. 웹사이트 배포를 관리하는 전통적인 방식은 일반적으로 3~4개의 층위(개발-테스트-(검증)-상용)로 구성되는데, 이 각각의 단계는 최소 한 개의 서버와, 일련의 승격 규정(promotion rules)을 지닌다. 소프트웨어가 다음 승격에 준비되면, 빌드가 다음 레벨 서버에 배치되는 방식이다.
그러나 가상 머신의 등장으로 이런 방식은 완전히 바뀌게 됐다. 메인 서버가 원하는 만큼 얼마든지 가상 서버를 생성할 수 있게 됐기 때문이다. 덕분에 이제는 모든 세부 브랜치(branch)가 각자의 테스트를 진행하고, 또 그것을 파이널 테스트로 통합할 수 있다. 신규 하드웨어 구입에 필요한 수 만 달러의 예산이 절감될 수 있게 된 것이다.
가상 머신의 등장의 등장으로, 개발자들이 상용 과정에서의 문제를 디버깅하는 시점에 테스터들이 2차 머신에서 패치 테스트를 진행하는 동시 운영 역시 가능해졌다. 한 명의 테스터는 배포를 앞둔 패치의 회귀를 확인하고, 다른 다섯의 테스터가 배포판의 기능을 테스트하고, 다섯의 개발자는 신규 브랜치 내 신기능을 작업하는 풍경이 최근 개발팀의 운영 방식이다.
가상 머신의 문제는 크기와 속도다. 각 VM은 전체 호스트 운영 체제를 포함하고 있으며 가상 머신을 생성한다는 것은 완전히 새로운 운영 체제를 만들어 내고, 수 GB의 공간을 할당하며, 그 운영 체제에 ‘빌드’를 인스톨 함을 의미한다. 그 운영 체제 역시 당신의 컴퓨터의 애플리케이션 공간에서 작동하므로 말 그대로 호스트 운영 체제 안에 또 하나의 운영 체제를 갖게 되는 것이다.
가상 머신의 부팅/인스톨 프로세스는 짧게는 수 분에서 길게는 한 시간까지 걸릴 수 있어 플로우를 방해하기에 충분하다. 심각한 속도 저하를 유발 하지 않고 호스트 할 수 있는 가상 머신의 개수는 데스크톱 하나 당 한두 개뿐이다.
네트워크 상에 온-디맨드로 가상 머신을 생성하려 하는 것은 그 자체로 하나의 ‘사설 클라우드 컴퓨팅’프로젝트다.
도커는 애플리케이션 공간 대신 커널에서 작동한다. 다시 말해 그 자체가 운영 체제의 일부가 되어 작동한다는 뜻이다. 물론 운영 체제의 일부가 되어 작동하다 보면 리눅스의 모던 커널들로 구동 범위의 제한이 있긴 하지만(호스트 머신과 콘테이너 모두), 운영 체제의 작업 전환 과정이 크게 간편해진다는 이점이 있다.
커널 내에 위치함으로써 도커는 일반적인 VM(콘테이너가 아닌 커널 단위로 그 필요 수량이 결정된다)이 지닐 수 있는 중복의 많은 부분을 제거할 수 있으며, 또한 도커 콘테이너들을 ‘부팅할' 일은 없어진다. 이미 부팅은 되어있는 상태기 때문이다.
이 모든 특성은 도커를 초고속 머신 생성 도구로 만들어줬다. 도커가 생성하는 머신은 기존 서버에 대한 패치가 아닌, 디스크 이미지에 기반해 즉시 활용이 가능한 복사본이다.
도커 환경에서는 파괴된 상태에서 콘테이너를 중단하고 저장한 뒤 추후 디버깅을 적용하는 방식을 통해 보다 간편하게 디버깅이 가능하다. 디버깅이 환경적 상황을 망가뜨리거나 그 일부를 ‘더럽히는' 경우에도 간편하게 이전 형태로의 복구가 가능하다.
도커는 또한 어떤 리눅스 서버 상에서도 애플리케이션을 수용하거나 구동할 수 있으며, 콘테이너를 신속하게 개시하고 처분할 수 있다는 특성을 지녔기에 배치 프로세싱 등의 과정에도 매우 유리하다.
도커 콘테이너와 함께 인프라스트럭처 전반을 설정하거나 나아가서는 모방할 수 있는 툴들 역시 시장에 다수 존재해 개발팀들의 활동을 지원하고 있다. 대표적인 툴인 도커 컴포즈(Docker Compose)는 고도의 복잡성을 지니는 설치 과정을 단일 명령으로 치환해준다.
생산 현장 단계에서의 도커
로컬 머신과 복수의 클라우드 서버들 상에 위치하는 도커를 현장에서의 활용 가능하게 하는 것은 또 다른 문제다. 초기 도커는 실제 활용 단계와 관련해선 황량한 서부와도 같았다.
흔히 ‘이야기되던 ‘콘테이너 조정(Container Orchestration)’이라는 표현은 도커화 된 앱과 서비스를 취해 그들을 컴퓨트 자원이 단일 클러스터에 포함시키는 활동을 의미한다. 이 방식에서 기업들은 콘테이너가 어디에서 구동되는 지를 신경 쓸 필요가 없다. 그들은 그저 올바른 리퀘스트를 구동하고 제공할 뿐, 그것이 웹 트래픽인지, 내부 서비스와 데이터베이스인지, 아니면 메시징 큐인지 판단하지 않아도 된다.
오늘날 조정 분야의 주요 업체로는 AWS EC2 콘테이너 서비스나 도커 스웜(Docker Swarm), 메소스(Mesos) 등이 있다. 일반적으로 조정 서비스는 콘테이너 관리 역시 수행해준다. 또 블루/그린 배치, 콘테이너 힐링(container healing), 로드 밸런싱, 서비스 검색, 인터-콘테이너 네트워킹(inter-container networking) 등 다른 부가 기능을 더하기도 한다.
활용 단계용 도커를 평가하는 과정에는 로깅이나 환경적 변수 설정 등의 여타 과제들이 존재한다. 당신의 팀이 도커로 전환해도 될 지를 판단할 수 있는 좋은 시작점은 당신의 팀이 최적의 12 인자 앱(12 Factor App)에 얼마나 가까운 지를 판단해보는 것이다.
돈 테일러(Don Taylor)가 코드매시(Codiash)에서 제작한 도커 튜토리얼을 참고하면 리눅스 머신 상에 도커를 설치하는 과정을 차근차근 따라가며 콘테이너를 생성하고 그 콘테이너에 명령을 실행할 수 있다. 하지만 당신이 따라 볼만한 최고의 자료는 역시 깃허브가 제공하는 랩이다.
정리하자면, 리눅스 가상 머신을 설치해 그 안에 도커를 배치하고, 콘테이너 제작법을 연구해보자. 그리고 이 테크놀로지가 당신의 조직에서 충분히 유용한지를 확실히 판단해보자. 그럴 만한 가치는 충분하다.
* Mattew Heusser는 엑실리온 디벨롭먼트(Excelon Development) 수석 컨설턴트다. 본 기고문에는 Jared Short 또한 기여했다.
![](http://files.idg.co.kr/ciokr/image/docker-100432103-primary_idge.jpg)
Credit: iStockphoto
테스트 환경에서 딱 맞는 빌드가 나올 때까지 기다리기란 여간 성가신 일이 아니다. 또한 개발, 테스트, 생산 사이의 간극은 결함을 야기했다. 가상 머신(Virtual Machine)을 이용하면 시스템 데이터 카피를 공유해 이런 문제들을 해결할 순 있기는 하다. 그러나 매우 느린데다 디스크 공간을 몇 기가바이트씩 차지한다.
그렇다. 가볍고 빠른 리눅스 가상화 툴 도커(Docker)가 활약할 타이밍인 것이다.
도커가 제안하는 기회들
어느 정도의 기술적 지식만 있다면 로컬 머신에 테스트 환경을 생성하는 것은 몇 초 걸리지 않는다. 기존 OS에 새 프로세스가 연결되므로 ‘부팅’할 필요가 없다. 이전 빌드가 저장돼 있는 상태일지라도 도커는 새로운 빌드에서 달라진 점들만을 로딩한다. 기특할 정도로 똑똑하다.
도커를 채택한 조직들에게 이러한 간결함은 특별한 경험이 아니다. 검증 단계의 아키텍처를 상용 단계로 확장하는 과정에서도 자동 연결을 통한 간결화의 혜택을 누릴 수 있다.
도커의 또 다른 훌륭한 기능 중 하나는 완전히 새로운, 십여 개의 가상 머신으로 구성된 서버팜용 가상 인프라스트럭처를 구성할 수 있다는 것이다. 이들은 ‘그린’ 빌드라 불린다.
그린 빌드에서는 그 어떤 최종 복귀 테스팅도 가능하다. 테스팅이 끝나면 배치 스크립트가 서버로 전달되고, 이제는 그린 빌드가 상용 코드의 역할을 맡게 된다. 하지만 이전 빌드인 ‘블루' 빌드 역시 필요할 경우를 대비해 삭제되지 않고 잔여 해 있기에 언제던 복귀가 가능하다.
여러 테크놀로지들에서 적용 가능한 이러한 방식을 블루/그린 배치라 부른다. 도커는 이런 기존의 방법론을 보다 용이하게 하는 솔루션일 뿐이다.
왜 도커인가?
하나의 인스톨러에 컴파일하는 윈도우 기반 소프트웨어와는 달리 웹 기반 소프트웨어는 서버 상에서 빌드를 구동하는 방식을 취한다. 웹사이트 배포를 관리하는 전통적인 방식은 일반적으로 3~4개의 층위(개발-테스트-(검증)-상용)로 구성되는데, 이 각각의 단계는 최소 한 개의 서버와, 일련의 승격 규정(promotion rules)을 지닌다. 소프트웨어가 다음 승격에 준비되면, 빌드가 다음 레벨 서버에 배치되는 방식이다.
그러나 가상 머신의 등장으로 이런 방식은 완전히 바뀌게 됐다. 메인 서버가 원하는 만큼 얼마든지 가상 서버를 생성할 수 있게 됐기 때문이다. 덕분에 이제는 모든 세부 브랜치(branch)가 각자의 테스트를 진행하고, 또 그것을 파이널 테스트로 통합할 수 있다. 신규 하드웨어 구입에 필요한 수 만 달러의 예산이 절감될 수 있게 된 것이다.
가상 머신의 등장의 등장으로, 개발자들이 상용 과정에서의 문제를 디버깅하는 시점에 테스터들이 2차 머신에서 패치 테스트를 진행하는 동시 운영 역시 가능해졌다. 한 명의 테스터는 배포를 앞둔 패치의 회귀를 확인하고, 다른 다섯의 테스터가 배포판의 기능을 테스트하고, 다섯의 개발자는 신규 브랜치 내 신기능을 작업하는 풍경이 최근 개발팀의 운영 방식이다.
가상 머신의 문제는 크기와 속도다. 각 VM은 전체 호스트 운영 체제를 포함하고 있으며 가상 머신을 생성한다는 것은 완전히 새로운 운영 체제를 만들어 내고, 수 GB의 공간을 할당하며, 그 운영 체제에 ‘빌드’를 인스톨 함을 의미한다. 그 운영 체제 역시 당신의 컴퓨터의 애플리케이션 공간에서 작동하므로 말 그대로 호스트 운영 체제 안에 또 하나의 운영 체제를 갖게 되는 것이다.
가상 머신의 부팅/인스톨 프로세스는 짧게는 수 분에서 길게는 한 시간까지 걸릴 수 있어 플로우를 방해하기에 충분하다. 심각한 속도 저하를 유발 하지 않고 호스트 할 수 있는 가상 머신의 개수는 데스크톱 하나 당 한두 개뿐이다.
네트워크 상에 온-디맨드로 가상 머신을 생성하려 하는 것은 그 자체로 하나의 ‘사설 클라우드 컴퓨팅’프로젝트다.
도커는 애플리케이션 공간 대신 커널에서 작동한다. 다시 말해 그 자체가 운영 체제의 일부가 되어 작동한다는 뜻이다. 물론 운영 체제의 일부가 되어 작동하다 보면 리눅스의 모던 커널들로 구동 범위의 제한이 있긴 하지만(호스트 머신과 콘테이너 모두), 운영 체제의 작업 전환 과정이 크게 간편해진다는 이점이 있다.
커널 내에 위치함으로써 도커는 일반적인 VM(콘테이너가 아닌 커널 단위로 그 필요 수량이 결정된다)이 지닐 수 있는 중복의 많은 부분을 제거할 수 있으며, 또한 도커 콘테이너들을 ‘부팅할' 일은 없어진다. 이미 부팅은 되어있는 상태기 때문이다.
이 모든 특성은 도커를 초고속 머신 생성 도구로 만들어줬다. 도커가 생성하는 머신은 기존 서버에 대한 패치가 아닌, 디스크 이미지에 기반해 즉시 활용이 가능한 복사본이다.
도커 환경에서는 파괴된 상태에서 콘테이너를 중단하고 저장한 뒤 추후 디버깅을 적용하는 방식을 통해 보다 간편하게 디버깅이 가능하다. 디버깅이 환경적 상황을 망가뜨리거나 그 일부를 ‘더럽히는' 경우에도 간편하게 이전 형태로의 복구가 가능하다.
도커는 또한 어떤 리눅스 서버 상에서도 애플리케이션을 수용하거나 구동할 수 있으며, 콘테이너를 신속하게 개시하고 처분할 수 있다는 특성을 지녔기에 배치 프로세싱 등의 과정에도 매우 유리하다.
도커 콘테이너와 함께 인프라스트럭처 전반을 설정하거나 나아가서는 모방할 수 있는 툴들 역시 시장에 다수 존재해 개발팀들의 활동을 지원하고 있다. 대표적인 툴인 도커 컴포즈(Docker Compose)는 고도의 복잡성을 지니는 설치 과정을 단일 명령으로 치환해준다.
생산 현장 단계에서의 도커
로컬 머신과 복수의 클라우드 서버들 상에 위치하는 도커를 현장에서의 활용 가능하게 하는 것은 또 다른 문제다. 초기 도커는 실제 활용 단계와 관련해선 황량한 서부와도 같았다.
흔히 ‘이야기되던 ‘콘테이너 조정(Container Orchestration)’이라는 표현은 도커화 된 앱과 서비스를 취해 그들을 컴퓨트 자원이 단일 클러스터에 포함시키는 활동을 의미한다. 이 방식에서 기업들은 콘테이너가 어디에서 구동되는 지를 신경 쓸 필요가 없다. 그들은 그저 올바른 리퀘스트를 구동하고 제공할 뿐, 그것이 웹 트래픽인지, 내부 서비스와 데이터베이스인지, 아니면 메시징 큐인지 판단하지 않아도 된다.
오늘날 조정 분야의 주요 업체로는 AWS EC2 콘테이너 서비스나 도커 스웜(Docker Swarm), 메소스(Mesos) 등이 있다. 일반적으로 조정 서비스는 콘테이너 관리 역시 수행해준다. 또 블루/그린 배치, 콘테이너 힐링(container healing), 로드 밸런싱, 서비스 검색, 인터-콘테이너 네트워킹(inter-container networking) 등 다른 부가 기능을 더하기도 한다.
활용 단계용 도커를 평가하는 과정에는 로깅이나 환경적 변수 설정 등의 여타 과제들이 존재한다. 당신의 팀이 도커로 전환해도 될 지를 판단할 수 있는 좋은 시작점은 당신의 팀이 최적의 12 인자 앱(12 Factor App)에 얼마나 가까운 지를 판단해보는 것이다.
돈 테일러(Don Taylor)가 코드매시(Codiash)에서 제작한 도커 튜토리얼을 참고하면 리눅스 머신 상에 도커를 설치하는 과정을 차근차근 따라가며 콘테이너를 생성하고 그 콘테이너에 명령을 실행할 수 있다. 하지만 당신이 따라 볼만한 최고의 자료는 역시 깃허브가 제공하는 랩이다.
정리하자면, 리눅스 가상 머신을 설치해 그 안에 도커를 배치하고, 콘테이너 제작법을 연구해보자. 그리고 이 테크놀로지가 당신의 조직에서 충분히 유용한지를 확실히 판단해보자. 그럴 만한 가치는 충분하다.
* Mattew Heusser는 엑실리온 디벨롭먼트(Excelon Development) 수석 컨설턴트다. 본 기고문에는 Jared Short 또한 기여했다.
※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지
[원문출처 : http://www.ciokorea.com/news/26442]
번호 | 제목 | 조회수 | 작성 |
---|---|---|---|
공지 | [Open UP 활용가이드] 공개SW 활용 및 개발, 창업, 교육 "Open UP을 활용하세요" | 316104 | 2020-10-27 |
공지 | [Open UP 소개] 공개SW 개발·공유·활용 원스톱 지원 Open UP이 함께합니다 | 305704 | 2020-10-27 |
4501 | 레드햇, '포럼 2015' 개최…오픈소스 기술 솔루션 강조 | 3486 | 2015-09-10 |
4500 | 오픈소스로 무장한 스마트드론, 솔로(SOLO) 한국 출시 | 3240 | 2015-09-10 |
4499 | 오픈스택 한국커뮤니티, 첫 지방투어 세미나 | 3543 | 2015-09-08 |
4498 | '오픈 소스' 가정용 로봇 버디, 내년 7월 출시 | 3226 | 2015-09-08 |
4497 | 기고 | 개발 환경의 혁신! '도커' 따라잡기 | 3699 | 2015-09-08 |
4496 | SW 교육 교사들께 제안하는 학습 도우미 | 3873 | 2015-09-08 |
4495 | 제트컨버터, ‘오픈스택’ 호환성 인증 취득 | 3219 | 2015-09-08 |
4494 | 티켓몬스터, 신입 개발자 공개채용 | 3232 | 2015-09-08 |
4493 | 스위프트 2.0으로 iOS 앱 제작한다 | 3447 | 2015-09-08 |
4492 | 오픈소스 소프트웨어로 돈 버는 방법 | 3713 | 2015-09-08 |
0개 댓글