[번역] Infrastructure as Code and vRealize Automation

출처 : https://blogs.vmware.com/management/2020/01/infrastructure-as-code-and-vrealize-automation.html

스뎅님이 번역하신, 이 글도 함께 보시면 좋습니다.
불변 인프라란 무엇인가?? - What is immutable infrastructure?? : https://blog.leocat.kr/notes/2018/09/01/translation-what-is-immutable-infrastructure

코드로서의 인프라

코드로서의 인프라(Infrastructure as Code)는 소프트웨어 개발에 더 자주 사용되는 원칙을 적용하여 "클라우드 시대"에서 인프라 관리에 직면하고 있는 문제를 해결하기 위해 만들어진 개념이다.

현대적이고 클라우드 같은 인프라는 본질적으로 동적이며 서버의 무분별한 확장, 구성 드리프트 및 "스노우플레이크(snowflakes)"로 이어질 수 있다. 애플리케이션의 새 버전이 출시될 때 서로 다른 환경에 배포된 서버가 기능적으로 동일한지 어떻게 확인하십니까? 시간이 지남에 따라 환경에 대한 구성 변경이 일관되게 적용되지 않으며 각 환경은 고유한 특성으로 "스노우플레이크"가 된다. 이는 이러한 환경에서의 배치(deployment) 문제를 일관성이 없고 신뢰할 수 없으며 취약하게 만들 수 있다.

2020-01-22_16-04-51.png

코드로서의 인프라(Infrastructure as Code)는 원하는 최종 상태를 설명하는 코드 형식으로 인프라의 모든 구성 요소와 구성(예: 가상 시스템, 컨테이너, 네트워크, 로드 밸런서 및 토폴로지)을 캡처해서 이를 해결한다. 이 코드 형식은 제공자가 반복 가능하고 신뢰할 수 있으며 온디맨드 방식으로 인프라를 프로비저닝, 구성 및 관리하도록 해석할 수 있다. 코드 설명은 개발자가 애플리케이션의 소스 코드를 사용하므로 소스 제어 및 관리할 수 있다.

환경의 구성에 대한 변경은 공급자가 해석하고 이행하는 소스 코드(대상 환경이 아님)에서 이루어진다. 코드는 종료 상태를 설명하는 잘 알려진 형식이기 때문에 변경 내용은 자체 문서화된다. 이러한 변경은 여러 환경에서 스테이징하여 일관성을 보장할 수 있다. 환경은 또한 소스 제어 버전을 사용함으로써 환경에 해가 될 수 있는 경우 이전 상태로 롤백할 수 있다.

코드로서의 인프라는 일반적으로 선언적이다. 즉, 인프라의 원하는 상태를 설명하지만, 원하는 상태를 달성하는 방법을 반드시 기술하지는 않는다. 이는 코드 제공자로서 인프라에 맡겨진다. 선언 코드는 원하는 상태를 달성하기 위해 실행되는 일련의 단계 또는 명령을 설명하는 명령어 접근법과 다르다. 임시 코드는 일반적으로 선언적 접근방식과 동일한 확장성, 재사용성 또는 복원력을 가지고 있지 않다.

배포된 환경은 환경의 시작 상태와 관계없이 동일한 방식으로 구성되어야 한다. 이는 기존 환경을 원하는 상태로 수정(변경 가능한 인프라 - "폐쇄"되거나 변경될 수 있음)하거나, 현재 상태를 파괴하고 원하는 상태(불변형 인프라 - "폐쇄"하거나 변경할 수 없음)를 배포함으로써 달성할 수 있다.

코드 제공자로서 일부 인프라는 AWS CloudFormation이나 Azure Resource 매니저와 같이 플랫폼에 특정되어 있는 반면, 다른 인프라는 모듈화되어 있으며, 여러 플랫폼에 배치될 수 있다. 예를 들어 Hashicorp Terraform 또는 Pulumi.

vRealize Automation as a Infrastructure as Code Provider

vRealize Automation은 증가하는 범위의 클라우드 엔드포인트(AWS, Azure, GCP, vSphere 및 AWS의 VMware Cloud)에 배포할 수 있으며, vRealize Automation에서 생성된 Blueprint는 YAML에서 선언적으로 작성된다. Blueprint는 다음과 같이 충족되는 가상 머신, 네트워킹, 로드 밸런서 및 기타 인프라 구성 요소의 원하는 최종 상태를 설명한다. 다양한 클라우드 계정 및 통합. GitLab 및 GitHub 통합으로 YAML 설계는 설계도와 소스 제어 시스템 간에 버전 동기화를 통해 소스 제어 관리를 받을 수 있다. 이러한 방식으로 vRealize Automation은 코드 제공자로서 일반적인 인프라로 설명할 수 있다.

2020-01-22_14-37-33.png

소스 제어 통합

vRealize Automation의 배포 변경 관리는 코드 제공자로서 일반적인 인프라에서 기대할 수 있는 것과 약간 다른 방식으로 제공되며, 배포는 Blueprint와 직접 연결되어 있지 않으므로 Blueprint 코드가 변경될 경우 배포가 자동으로 업데이트되지 않는다. 2일차 "업데이트" 작업을 통해 배포의 입력 값을 업데이트할 수 있으며, 이는 Blueprint 구성 요소가 배포에서 배포, 다시 배포 또는 제거됨을 의미할 수 있다. 또한 업데이트 적용 시 작업 계획 단계에 따라 배포를 최신 버전으로 업데이트할 수 있으며, 그 예는 다음과 같다.

2020-01-22_15-05-00-768x212.png
배포 업데이트 계획

결론

클라우드 어셈블리의 Blueprint와 작업에서 서비스 브로커의 양식, CodeStream의 파이프라인, Orchestrator의 워크플로우에 이르기까지 vRealize Automation의 모든 콘텐츠는 널리 사용되는 소스 제어 엔드포인트에 사용할 수 있는 통합과 함께 버전 제어가 가능한 소스 코드로 사용할 수 있다. 클라우드 불가지론 구성요소를 통해 Blueprint는 인프라에 대해 선언적인 방식으로 설명할 수 있으며, 구축된 클라우드 환경에 관계없이 동일한 기능을 제공한다. 그리고 필수 접근법이 필요한 사용 사례에 대해서는 vRealize Orchestrator, Action Based Extensions 및 CodeStream Pipeline을 사용하여 원하는 상태를 구축할 수 있다.

vRealize Automation의 코드 기능으로 인프라를 더욱 확장할 수 있는 vRealize Automation Terraform Provider에 대한 소개에 관심이 있으신 경우 다음 블로그 게시물인 "Getting Started with the vRealize Automation Terraform Provider"를 보기 바란다.