2018.12.07

도커와 MS의 최신 오픈소스 표준 'CNAB'를 아십니까?

Tamlin Magee | Computerworld UK
도커와 마이크로소프트가 분산 컴퓨팅을 크게 단순화하는 ‘보편적 표준’을 위해, 그리고 아직 정체불명인 3~4곳의 상대방과 클라우드 네이티브 재단을 설립하기 위해 서로 힘을 합쳤다. 
 
Credit: Docker

도커의 최고 제품 임원인 스캇 존스턴은 ‘클라우드 네이티브 애플리케이션 번들('Cloud Native Application Bundle)’, 즉 CNAB가 개발자 커뮤니티에 지대한 영향을 줄 것으로 믿는다고 말했다. 도커 컨테이너가 처음에 그랬던 것처럼 말이다. 

CNAB는 마이크로소프트와 제휴하여 개발되었고, 다수의 서비스를 패키지로 묶어 실행의 복잡성을 단순화하는 것을 목표로 한다. 쿠버네티스 YAML, 헬름 차트(Helm charts), 도커 컴포즈 파일(Docker Compose files), 클라우드포메이션(CloudFormation), 테라폼(Terraform), ARM 템플릿 등을 단일 패키지로 묶어 처리할 수 있고, 실행 환경 측면에서 클라우드 종류를 구분하지 않는다고 한다. 

존스턴은 바르셀로나에서 열린 도커콘 유럽 2018 중 기자들과 만난 자리에서, 도커는 고객 및 개발자 커뮤니티의 피드백을 바탕으로, 상당 기간 이 문제에 대처하기 위해 연구해왔다고 밝혔다. 그러던 중 약 1년 전 마이크로소프트가 복잡성의 처리를 둘러싼 비슷한 문제를 놓고 도커와 접촉하였다. 

두 회사는 상이한 고객 기반, 그리고 심지어 인-하우스 애저 서비스 팀조차 근접한 난제를 직면하고 있어서 규격에 관해 공동으로 대처하는 것이 합리적임을 깨달았다. 

존스턴은 “시간이 가면서 이의 도입이 더욱 늘어날 것이다”면서 “도커 컨테이너뿐 아니라, 분산 애플리케이션의 보편적 표준이 될 것이다. 그리고 정말 중요한 것은, 이는 도커의 전유물도, 마이크로소프트의 전유물도 아니라는 점이다. 컴포즈 파일을 입력으로 취할 수 있고, 헬름 차트를 입력으로 취할 수 있고, 쿠버네티스 YAML을 입력으로 취할 수 있고, 서버리스 아티팩트(artifacts)를 입력으로 취할 수 있다”고 말했다. 

그러면서 “이는 분산 애플리케이션 컴포넌트라면 무엇이든지 수용할 수 있도록, 그리고 이들을 불변으로 서술할 수 있도록 의도적으로 설계되었다. 따라서 도커 컨테이너의 혜택을 취할 수 있다. 그러면서도 다중 컴포넌트 분산 애플리케이션에 적용될 수 있다”고 설명했다. 

출시 후 ‘다음 목표’는 CNAB를 공동 거버넌스에 의한 파운데이션 모델로 만드는 것이다. 

존스턴은 “이는 애플리케이션 정의 표준이기 때문에, 오픈소스로 만들어 널리 보급하는 것은 모두에게 이익이다”고 말했다. 이어 “따라서 마이크로소프트와 도커는 이를 아파치 2 라이선스 하의 오픈소스로 만들기로 합의하였다”고 밝혔다. 

이 파운데이션은 마이크로소프트와 도커 외에도 업계 내의 더 많은 개체가 참여할 것이다. 개발 및 운용의 단순성에 대한 갈망과, 도커가 세일즈포스 같은 업체와 협력한 최근의 이력을 고려하면 여기에는 개발자 진영에서 거대 업체로 추정되는 아직 이름이 거론되지 않은 3~4개 업체가 포함될 것이다. 

CNAB: 도커 측의 설명 
오픈소스 컨테이너 회사인 도커는 CNAB를 “분산 애플리케이션을 패키징하고 운영하기 위한 오픈소스, 클라우드 무관 규격”이라고 설명한다. 

“CNAB는 상이한 툴 체인에 걸쳐 다중 서비스 분산 애플리케이션의 운영을 일률적 패키징 포맷으로 통일한다. CNAB 규격은 도커를 비롯해 어떤 런타임 환경 및 툴의 조합으로도 전개될 수 있도록 리소스를 정의할 수 있게 해준다.” 

존스턴은 분산 컴퓨팅의 주요 문제는 단일 컨테이너라면 관리하고 전개하기가 쉽지만, 여러 컨테이너에 의해 정의된 애플리케이션이라면 여러 종류의 의존성으로 인해 심각한 복잡성이 야기될 수 있다는 것이라고 설명한다. 

이어 그는 “우리는 수천 개의 컴포즈 파일을 관리하고 있는 조직들을 방문한다. 이들은 ‘버전 관리 측면에서 정말 힘들다’고 호소한다”고 말했다. 그러면서 “이들은 테스팅 환경에서 한 컴포즈 파일 세트를 관리하면서, 정작 프로덕션 환경에서는 별개의 컴포즈 파일 세트를 관리하고 있다. ‘이를 운영할 수는 있는데, 더 쉽게 하는 방법이 없는가?’라고 문의한다”고 말했다.  

실무에서, CNAB 워크플로우는 오늘날의 도커 워크플로우와 비슷할 것이다. 즉 단일 컨테이너에 의해, 최소한 이론적으로, 애플리케이션을 구축하고, 출하하고, 운영한다는 개념이다. 

존스턴은 “동일한 워크플로우, 동일한 수명 단계가 도커 앱 아티팩트나 CNAB 아티팩트에 작용한다”면서 “여기서 진짜 중요한 것은 이게 도커 컴포즈로 한정되지 않는다는 점이다. 이는 불변이다. 그러면서도 매개변수를 외부화시켰기 때문에 환경에 따라 변화시킬 수 있다. 동일 앱이 환경에 따라 다른 사본을 갖는 경우가 없어진다”고 설명했다. 

그는 “이는 수명 주기에 걸쳐 애플리케이션을 전개하고 관리하는 훨씬 더 단순한 방법이다”고 말했다. 

정리하자면, 파일이나 구성이 아무리 복잡하더라도, 이들 분산 애플리케이션이 애플리케이션의 디테일과 의존성에 대해 운영팀이 일일이 알 필요 없이 운영을 위해 출하될 수 있다는 것이다. 
 
효과가 있을까?
개발자 또는 클라우드 인프라 컨퍼런스에서 ‘복잡성’이라는 말을 들을 때마다 총을 맞는다면 수 분 내는 아니더라도 수 시간 내에는 죽을 것이라는데 대부분이 동의할 것이다. 전문가가 중요하기는 하지만, 복잡한 환경을 전문가에 의존하지 않으면서 전개하고 관리하는 것에 대한 절실함이 있는 듯하다. 

비교적 새롭게 오픈소스와 친근해진 마이크로소프트가 이 프로젝트에 확고한 의지를 가지고 있다는 것은 도커의 지금까지의 이력, 그리고 도커가 업계 지형을 변화시켰다는 사실로 미루어볼 때, 앞으로 애플리케이션이 대규모로 전개되고 모니터 되는 방식이 크게 변할 수 있을 것을 시사한다.   

포레스터의 부사장인 랜디 헤프너는 애플리케이션 개발 및 구축 전문가에게 서비스하는 수석 애널리스트로서 <컴퓨터월드UK>에게 이 발표는 “우리가 필요로 하는 종류”라고 말했다. 

그는 “CNAB가 정답인지 그렇지 않은지는 앞으로 밝혀질 것이다. 그러나 현재 로켓 과학에 해당하는 마이크로서비스의 복잡성을 보편화하는데 필요한 여러 가지 가운데 하나다. 그리고 이는 그들이 이를 설명하는 그대로다”고 말했다. 

그러면서 “따라서 지켜보는 것은 흥미로울 것이다. 유망해 보인다”고 말했다. ciokr@idg.co.kr



2018.12.07

도커와 MS의 최신 오픈소스 표준 'CNAB'를 아십니까?

Tamlin Magee | Computerworld UK
도커와 마이크로소프트가 분산 컴퓨팅을 크게 단순화하는 ‘보편적 표준’을 위해, 그리고 아직 정체불명인 3~4곳의 상대방과 클라우드 네이티브 재단을 설립하기 위해 서로 힘을 합쳤다. 
 
Credit: Docker

도커의 최고 제품 임원인 스캇 존스턴은 ‘클라우드 네이티브 애플리케이션 번들('Cloud Native Application Bundle)’, 즉 CNAB가 개발자 커뮤니티에 지대한 영향을 줄 것으로 믿는다고 말했다. 도커 컨테이너가 처음에 그랬던 것처럼 말이다. 

CNAB는 마이크로소프트와 제휴하여 개발되었고, 다수의 서비스를 패키지로 묶어 실행의 복잡성을 단순화하는 것을 목표로 한다. 쿠버네티스 YAML, 헬름 차트(Helm charts), 도커 컴포즈 파일(Docker Compose files), 클라우드포메이션(CloudFormation), 테라폼(Terraform), ARM 템플릿 등을 단일 패키지로 묶어 처리할 수 있고, 실행 환경 측면에서 클라우드 종류를 구분하지 않는다고 한다. 

존스턴은 바르셀로나에서 열린 도커콘 유럽 2018 중 기자들과 만난 자리에서, 도커는 고객 및 개발자 커뮤니티의 피드백을 바탕으로, 상당 기간 이 문제에 대처하기 위해 연구해왔다고 밝혔다. 그러던 중 약 1년 전 마이크로소프트가 복잡성의 처리를 둘러싼 비슷한 문제를 놓고 도커와 접촉하였다. 

두 회사는 상이한 고객 기반, 그리고 심지어 인-하우스 애저 서비스 팀조차 근접한 난제를 직면하고 있어서 규격에 관해 공동으로 대처하는 것이 합리적임을 깨달았다. 

존스턴은 “시간이 가면서 이의 도입이 더욱 늘어날 것이다”면서 “도커 컨테이너뿐 아니라, 분산 애플리케이션의 보편적 표준이 될 것이다. 그리고 정말 중요한 것은, 이는 도커의 전유물도, 마이크로소프트의 전유물도 아니라는 점이다. 컴포즈 파일을 입력으로 취할 수 있고, 헬름 차트를 입력으로 취할 수 있고, 쿠버네티스 YAML을 입력으로 취할 수 있고, 서버리스 아티팩트(artifacts)를 입력으로 취할 수 있다”고 말했다. 

그러면서 “이는 분산 애플리케이션 컴포넌트라면 무엇이든지 수용할 수 있도록, 그리고 이들을 불변으로 서술할 수 있도록 의도적으로 설계되었다. 따라서 도커 컨테이너의 혜택을 취할 수 있다. 그러면서도 다중 컴포넌트 분산 애플리케이션에 적용될 수 있다”고 설명했다. 

출시 후 ‘다음 목표’는 CNAB를 공동 거버넌스에 의한 파운데이션 모델로 만드는 것이다. 

존스턴은 “이는 애플리케이션 정의 표준이기 때문에, 오픈소스로 만들어 널리 보급하는 것은 모두에게 이익이다”고 말했다. 이어 “따라서 마이크로소프트와 도커는 이를 아파치 2 라이선스 하의 오픈소스로 만들기로 합의하였다”고 밝혔다. 

이 파운데이션은 마이크로소프트와 도커 외에도 업계 내의 더 많은 개체가 참여할 것이다. 개발 및 운용의 단순성에 대한 갈망과, 도커가 세일즈포스 같은 업체와 협력한 최근의 이력을 고려하면 여기에는 개발자 진영에서 거대 업체로 추정되는 아직 이름이 거론되지 않은 3~4개 업체가 포함될 것이다. 

CNAB: 도커 측의 설명 
오픈소스 컨테이너 회사인 도커는 CNAB를 “분산 애플리케이션을 패키징하고 운영하기 위한 오픈소스, 클라우드 무관 규격”이라고 설명한다. 

“CNAB는 상이한 툴 체인에 걸쳐 다중 서비스 분산 애플리케이션의 운영을 일률적 패키징 포맷으로 통일한다. CNAB 규격은 도커를 비롯해 어떤 런타임 환경 및 툴의 조합으로도 전개될 수 있도록 리소스를 정의할 수 있게 해준다.” 

존스턴은 분산 컴퓨팅의 주요 문제는 단일 컨테이너라면 관리하고 전개하기가 쉽지만, 여러 컨테이너에 의해 정의된 애플리케이션이라면 여러 종류의 의존성으로 인해 심각한 복잡성이 야기될 수 있다는 것이라고 설명한다. 

이어 그는 “우리는 수천 개의 컴포즈 파일을 관리하고 있는 조직들을 방문한다. 이들은 ‘버전 관리 측면에서 정말 힘들다’고 호소한다”고 말했다. 그러면서 “이들은 테스팅 환경에서 한 컴포즈 파일 세트를 관리하면서, 정작 프로덕션 환경에서는 별개의 컴포즈 파일 세트를 관리하고 있다. ‘이를 운영할 수는 있는데, 더 쉽게 하는 방법이 없는가?’라고 문의한다”고 말했다.  

실무에서, CNAB 워크플로우는 오늘날의 도커 워크플로우와 비슷할 것이다. 즉 단일 컨테이너에 의해, 최소한 이론적으로, 애플리케이션을 구축하고, 출하하고, 운영한다는 개념이다. 

존스턴은 “동일한 워크플로우, 동일한 수명 단계가 도커 앱 아티팩트나 CNAB 아티팩트에 작용한다”면서 “여기서 진짜 중요한 것은 이게 도커 컴포즈로 한정되지 않는다는 점이다. 이는 불변이다. 그러면서도 매개변수를 외부화시켰기 때문에 환경에 따라 변화시킬 수 있다. 동일 앱이 환경에 따라 다른 사본을 갖는 경우가 없어진다”고 설명했다. 

그는 “이는 수명 주기에 걸쳐 애플리케이션을 전개하고 관리하는 훨씬 더 단순한 방법이다”고 말했다. 

정리하자면, 파일이나 구성이 아무리 복잡하더라도, 이들 분산 애플리케이션이 애플리케이션의 디테일과 의존성에 대해 운영팀이 일일이 알 필요 없이 운영을 위해 출하될 수 있다는 것이다. 
 
효과가 있을까?
개발자 또는 클라우드 인프라 컨퍼런스에서 ‘복잡성’이라는 말을 들을 때마다 총을 맞는다면 수 분 내는 아니더라도 수 시간 내에는 죽을 것이라는데 대부분이 동의할 것이다. 전문가가 중요하기는 하지만, 복잡한 환경을 전문가에 의존하지 않으면서 전개하고 관리하는 것에 대한 절실함이 있는 듯하다. 

비교적 새롭게 오픈소스와 친근해진 마이크로소프트가 이 프로젝트에 확고한 의지를 가지고 있다는 것은 도커의 지금까지의 이력, 그리고 도커가 업계 지형을 변화시켰다는 사실로 미루어볼 때, 앞으로 애플리케이션이 대규모로 전개되고 모니터 되는 방식이 크게 변할 수 있을 것을 시사한다.   

포레스터의 부사장인 랜디 헤프너는 애플리케이션 개발 및 구축 전문가에게 서비스하는 수석 애널리스트로서 <컴퓨터월드UK>에게 이 발표는 “우리가 필요로 하는 종류”라고 말했다. 

그는 “CNAB가 정답인지 그렇지 않은지는 앞으로 밝혀질 것이다. 그러나 현재 로켓 과학에 해당하는 마이크로서비스의 복잡성을 보편화하는데 필요한 여러 가지 가운데 하나다. 그리고 이는 그들이 이를 설명하는 그대로다”고 말했다. 

그러면서 “따라서 지켜보는 것은 흥미로울 것이다. 유망해 보인다”고 말했다. ciokr@idg.co.kr

X