블로그

애플리케이션 서비스와 CD 파이프라인

로리 맥비티 썸네일
로리 맥비티
2016년 2월 25일 게시

데이터 센터에 대한 논의에서 주요 주제로 등장하는 모든 기술과 마찬가지로, DevOps는 현재 정의 피로에 시달리고 있습니다. 사실 이 시점에서는 피로라고 생각하지만 둘 사이의 경계를 정하는 것은 어렵습니다. DevOps는 클라우드와 SDN처럼 널리 받아들여지는 정의를 갖고 있지 않다고만 말할 수 있습니다.

하지만 DevOps는 복합적인 개념이 종종 혼동되고 뒤섞이는 점에서 독특합니다. 예를 들어, CD는 "지속적인 전달" 또는 "지속적인 배포"를 의미할 수 있습니다. 이 둘은 같지 않으므로, 혼동하거나 합쳐서는 안 됩니다. Puppet Labs는 블로그 게시물 에서 차이점을 잘 설명했습니다.

 

 

지속적인 전달 지속적인 배포

프로덕션에 대한 배포가 "수동"(지속적인 전달)인지 "자동"(지속적인 배포)인지의 정의적 차이점을 알 수 있습니다.  

문제는 "프로덕션에 배포"라는 라벨이 붙은 작은 주황색 상자에 자동화해야 할 작업이 상당히 많다는 것입니다. 이는 단순히 앱과 해당 종속성(데이터베이스, 다른 서비스, 인프라 등)을 배포하는 것이 아닙니다. 또한 최종 소비자에게 해당 애플리케이션을 제공하는 데 필요한 모든 네트워크 및 애플리케이션 서비스를 구축하는 것도 중요합니다.  바로 여기서 애플리케이션 서비스가 등장하며, 애플리케이션 제공(개발 측면이 아닌 프로덕션 측면)이 지속적 배포 파이프라인에 포함됩니다.

Continuous Deployment 파이프라인 내에서 "프로덕션에 배포" 단계를 자동화하려면 많은 움직이는 부분을 프로비저닝하고 구성하고 테스트해야 합니다. 이는 기본 네트워킹부터 보안(방화벽 등), 가용성(부하 분산), 성능(가속, 캐싱 등) 서비스까지 모든 것을 의미합니다. 평균적으로 기업들은 빠르고 안전하며 가용성이 뛰어난 애플리케이션에 대한 요구를 실현하기 위해 11개의 서로 다른 애플리케이션 제공 서비스를 사용합니다 . 각각 배포(프로비저닝 및 구성)되어야 하며 일부는 다른 배포에 따라 달라집니다.

이러한 서비스 각각(이것은 여러분이 따라하는 세인트 아이브스 수수께끼와 같습니다)에는 구성해야 하는 특성의 수가 다양하고, true 또는 false로 설정된 옵션, 선택된 알고리즘, 설정된 경로 등이 있습니다.

다시 말해, "수동"에서 "자동"으로 전환하는 것은 생각보다 쉽지 않습니다.

네트워크를 지연시키는 것은 무엇인가?

이러한 프로세스를 자동화하는 데 있어 큰 장애물은 공유 구성 요소와 앱별 구성 요소 간의 차이에서 발견될 수 있습니다. 앱 인프라 영역에서 코드로서의 인프라가 가능한 이유는 애플리케이션에 인프라(웹 서버나 로드 밸런서 등)를 전담할 수 있기 때문입니다. 즉, 해당 구성 파일은 일종의 마이크로 서비스와 같습니다. 즉, 로컬화되어 있으며 하나의 애플리케이션에 대한 서비스 제공에 집중합니다.

 

 

cd 생산 중

네트워크와 앱 서비스의 세계에서는 이런 일이 항상 일어나는 것은 아닙니다. 예를 들어 라우터나 스위치는 여러 애플리케이션에 대한 연결 및 전달 서비스를 제공하도록 설계되었습니다. 즉, 구성 파일은 필연적으로 여러 애플리케이션을 포함해야 합니다. 버전 관리가 여기서 도움이 될 수 있지만, 구성은 앱이 아니라 기기에 크게 묶여 있다는 것이 현실입니다. 앱 서비스와 보안도 마찬가지입니다.

API가 CLI인 세상으로 우리 모두가 움직이는 것은 좋은 일이지만, 구성을 애플리케이션 별로 관리할 수 있는 앱별(혹은 앱 중심이라고도 할 수 있는) 패러다임을 지원해야 할 필요성도 해결해야 합니다.

즉, 서비스가 앱별로 배포되고 구성되는 마이크로서비스 스타일의 네트워크 아키텍처로 전환된다는 의미입니다. 이는 전용 "장치"(가상 또는 하드웨어, 이 논의의 목적상 폼 팩터는 중요하지 않음) 또는 템플릿과 같은 앱별 구성의 형태를 취할 수 있습니다.

아직 거기까지 왔나요?

API를 사용하여 애플리케이션별로 템플릿(즉, 코드로서의 인프라)을 배포하는 프로비저닝 및 관리를 위한 선언적 모델을 통해 점점 더 가까워지고 있지만 아직은 그 수준에 도달하지 못했습니다. 성공적인 지속적 배포를 완벽하게 구현하는 데 필요한 자동화를 조율하는 방법을 알아내는 데는 아직 많은 작업이 남아 있습니다.

지속적인 배포에서 지속적인 배포로의 전환을 완료하는 데 중요한 "운영에 배포" 단계를 "수동"에서 "자동"으로 전환하려면 네트워크, 인프라, 앱 서비스 및 보안 사일로가 포함되어야 합니다. 즉, 궁극적으로 프로덕션에서 지속적인 배포를 추진하는 프로세스 를 완전히 자동화하는 데 필요한 자동화 계층과 포괄적인 오케스트레이션에서 더 많은 작업이 필요하다는 뜻입니다.