ARM 템플릿(Azure Resource Manager 템플릿)의 관리를 모듈화하면 반복을 줄이고, 인프라 개발에서 모범 사례를 모델링하며, 일관된 표준 배포를 수행할 수 있습니다.
이러한 종류의 모듈화를 구현하기 위한 예제 사용 사례는 티셔츠 크기의 은유를 사용하여 VM(가상 머신)을 배포하는 것입니다. 수십 또는 수백 개의 VM을 배포했다고 가정합니다. 이러한 배포는 템플릿 버전 1.0.0을 사용하며 이전 시리즈의 표준 중간 크기를 갖습니다. 새 시리즈로 전환하려면 단순히 새 템플릿을 배포한 경우 짧은 서비스 중단이 필요할 수 있습니다. 그러나 버전 1.5.0을 빌드하고 모듈화를 사용하면 이전 인프라를 배포 가능한 상태로 유지하면서 업데이트된 표준으로 새 인프라를 배포할 수 있습니다. 이전 버전의 인프라를 사용할 수 있게 함으로써 제품 및 애플리케이션 팀은 시간이 지남에 따라 새 버전으로 업그레이드하는 동안 사용할 수 있는 알려진 좋은 구성을 갖게 됩니다.
리포지토리의 계층 케이크: 기업의 예
템플릿이 이동하는 위치, 템플릿 업데이트 방법 등에 대한 강력한 기본 설정을 원하는 이유에 관해서는 분기 및 내부 소싱이라는 두 가지 주요 고려 사항이 있습니다.
분기. 이 예제 시나리오는 Gitflow 및 GitHub 흐름을 지원하는 Git 분기 모델을 용이하게 합니다. Gitflow에 대한 자세한 내용은 Jeff Kreeftmeijer의 블로그 게시물인 Git-flow를 사용하여 Git 분기 워크플로 자동화를 참조하세요. GitHub 흐름에 대한 자세한 내용은 GitHub 설명서의 GitHub 흐름을 참조하세요.
내부 소싱. 두 번째는 내부 소싱으로, 오픈 소스 소프트웨어 개발의 공동 작업 사례를 사내 개발에 제공합니다. 이러한 시나리오에서는 배포 모델 자체에 대한 권한에 대해 걱정할 필요 없이 다른 템플릿 및 모듈 소스 코드를 보다 자신 있게 공유할 수 있습니다. 내부 원본 개발에 대한 자세한 내용은 GitHub의 내부 원본 소개를 참조하세요.
Bicep은 Azure 리소스를 배포하기 위한 선언적 언어입니다. Bicep의 재사용 가능한 코드는 버전이 지정된 ARM 템플릿을 호스팅하기 위한 프라이빗 레지스트리로 Azure Container Registry를 사용할 수 있습니다. 이러한 방식으로 Container Registry를 사용하면 기업에서 인프라에 대한 CI/CD(연속 통합 및 지속적인 업데이트) 프로세스를 가질 수 있습니다. CI 프로세스의 일부로 통합 및 단위 테스트를 실행할 수 있으며, 컨테이너 레지스트리는 성공적으로 빌드된 후 모듈을 수신할 수 있습니다. 앱 팀은 업그레이드할 준비가 될 때까지 이전 버전을 계속 사용하거나 최신 버전의 템플릿에서 기능을 활용하도록 업데이트할 수 있습니다.
이러한 Container Registry 사용 외에도 이 모델을 Azure 확인된 모듈과 결합할 수 있습니다. 구현은 퍼블릭 레지스트리에서 사용하거나 퍼블릭 리포지토리를 모니터링하고 추가 사용을 위해 프라이빗 레지스트리로 변경 내용을 끌어올 수 있습니다. 변경 내용을 사용자 고유의 컨테이너 레지스트리로 끌어들이면 퍼블릭 모듈에 대한 테스트를 실행하는 동시에 품질 및 보안 사례가 통합될 때까지 프로덕션에서 사용되지 않도록 할 수 있습니다.
레이어
이 예제 시나리오에서 제안된 모델은 스택형 모델입니다. 스택 상단에 가까울수록 더 자주 배포되고 더 맞춤화된 배포가 있습니다. Bicep 코드는 일관된 배포를 제공합니다. 기여를 위해 계층에서 작업하는 개발 팀은 아래 계층에 제공되는 서비스 및 인프라에서 빌드합니다. 하위 계층의 어떤 항목도 위의 계층에 있는 리소스에 의존해서는 안 됩니다. 계층 0에서 3까지 전역 라이브러리, 전역 인프라(전역 공유 서비스), 제품 플랫폼(공유 서비스), 애플리케이션이 있습니다.
이 모델은 맞춤을 사용하여 자율성을 만듭니다. 즉, 다음을 수행합니다.
엔터프라이즈 용이성을 위한 일반적인 도구. 예를 들어 모든 사용자는 소스 제어에 Git을 사용하고 모든 사용자는 CI/CD에 GitHub Actions를 사용합니다. 그러나 우리는 지나치게 접근하지 않습니다. 예를 들어 모든 팀이 Bicep을 사용하도록 의무화하지는 않습니다. Terraform, ARM 템플릿, 기타 도구를 사용할 수 있습니다.
모범 사례를 공유하는 기능. ARM 템플릿, 골든 이미지 또는 코드 조각의 형태를 취할 수 있습니다. 모범 사례는 특정 기술에 대한 설명서일 수도 있습니다. 예를 들어 사용자 환경에서 키를 회전하는 방법과 코드를 테스트하는 방법이 있습니다.
일부 서비스는 스택에서 아래쪽으로 이동합니다. 예를 들어 앱 팀은 처음에 Kubernetes 클러스터를 배포하기 위한 템플릿을 개발할 수 있습니다. 이 템플릿은 나중에 제품 플랫폼으로 공유 서비스로 가져옵니다. 이 템플릿은 매우 유용하여 샘플 라이브러리로 가져올 수 있습니다.
계층 0 - 전역 라이브러리
아래쪽 계층은 프로덕션에 배포되지 않은 유용한 잡담의 리포지토리인 전역 라이브러리입니다. 액세스 제어의 관점에서 읽기 액세스는 요청하는 회사의 모든 사용자에게 제공되어야 합니다. 변경, 제안 등에 대해 CCoE(Cloud Center of Excellence)는 PR을 승인하고 다른 제품인 것처럼 백로그를 관리합니다.
계층 0에는 다음이 포함되지 않아야 합니다.
- 프로덕션에 배포되는 템플릿.
- 비밀 또는 환경별 구성.
계층 0 에는 다음이 포함되어야 합니다 .
- 코드 조각(Python, C#등).
- Azure Policy 샘플.
- 샘플로 사용할 수 있는 ARM 템플릿, Bicep 템플릿 또는 Terraform 파일.
이 예제는 회사에서 환경별 정보 없이 3계층 애플리케이션에 대한 배포를 작성하는 방법에 대한 샘플 아키텍처입니다. 이 샘플 아키텍처에는 태그, 네트워크, 네트워크 보안 그룹 등이 포함될 수 있습니다. 모든 항목을 모듈에 넣을 수 있거나 모듈에 배치해야 하는 것은 아니므로 환경에 대한 특정 정보를 제외하는 것이 유용합니다. 이렇게 하면 과도한 매개 변수화가 발생할 수 있습니다.
또한 계층 0은 Terraform 레지스트리 또는 Azure 리소스 모듈과 같은 샘플 코드의 다른 알려진 좋은 원본에 연결할 수 있습니다). 조직에서 이러한 소스 중 하나에서 코드 또는 패턴을 채택하는 경우 퍼블릭 원본에서 직접 끌어와야 하는 대신 코드 또는 패턴을 사용자 고유의 계층 0으로 끌어오는 것이 좋습니다. 계층 0에 의존하여 고유한 테스트, 조정, 보안 구성을 작성할 수 있습니다. 퍼블릭 원본에 의존하지 않으면 예기치 않게 삭제될 수 있는 항목에 의존하는 위험을 줄일 수 있습니다.
좋은 샘플 코드로 간주되려면 템플릿 및 모듈은 보안 및 조직 요구 사항에 대한 입력 유효성 검사를 포함하여 좋은 개발 방법을 따라야 합니다. 이 수준의 엄격함을 유지하려면 기본 분기에 정책을 추가하여 PR(끌어오기 요청) 및 제안된 변경 내용에 대한 코드 검토를 요구해야 합니다. 그러면 병합된 경우 기본 컨테이너 레지스트리로 변경 내용이 전달됩니다.
계층 0은 Azure Pipelines 또는 GitHub Actions에 피드하여 Azure Container Registry에 버전이 지정된 아티팩트만 자동으로 만듭니다. Git 커밋 메시지에 대한 자동화를 빌드하여 아티팩트의 의미 체계 버전 지정을 구현할 수 있습니다. 올바르게 작동하려면 시간이 지남에 따라 자동화를 유지 관리할 수 있도록 <service>.bicep과 같은 결정적 명명 표준이 있어야 합니다. 적절한 분기 정책을 사용하면 코드 검토를 위한 필수 구성 요소로 통합 테스트를 추가할 수도 있습니다. Pester와 같은 도구를 사용하여 계측할 수 있습니다.
이러한 정책과 보호가 적용되면 컨테이너 레지스트리는 사용할 준비가 된 엔터프라이즈의 모든 인프라 모듈에 대한 진실의 원본이 될 수 있습니다. 이 코드의 검색 가능성을 허용하려면 변경 로그 및 사용 가능한 코드 샘플의 인덱스를 표준화하는 것이 좋습니다. 알 수 없는 코드는 사용되지 않는 코드입니다!
계층 1 - 전역 인프라: 전역 공유 서비스
계층 1은 Azure 랜딩 존 구문에 대한 리포지토리입니다. Microsoft는 Azure 랜딩 존 배포를 위한 템플릿을 제공하지만 특정 구성 요소를 수정하고 매개 변수 파일을 제공해야 합니다. 이는 앞에서 설명한 대로 퍼블릭 레지스트리 및 모듈 리포지토리를 계층 0으로 끌어오는 방식과 유사합니다.
Azure Container Registry는 이 아키텍처의 중요한 부분입니다. 회사에 컨테이너를 사용할 계획이 없더라도 Bicep 템플릿의 버전 관리가 성공하려면 Container Registry를 배포해야 합니다. Container Registry는 엔터프라이즈급 보안 및 액세스 제어를 제공하면서 모듈에 상당한 유연성과 재사용성을 제공합니다.
계층 1에는 다음이 포함되어야 합니다.
- 관리 그룹 또는 구독 수준에서 적용되는 정책 할당 및 정의. 이러한 정책은 회사 거버넌스 요구 사항과 일치해야 합니다.
- ExpressRoute, VPN, 가상 WAN, 가상 네트워크(공유 또는 허브)와 같은 핵심 네트워크 인프라에 대한 템플릿입니다.
- DNS.
- 핵심 모니터링(로그 분석).
- 엔터프라이즈 컨테이너 레지스트리.
이 리포지토리에 변경 내용을 푸시하는 기능을 제한하도록 분기 보호를 구성해야 합니다. 다른 개발자의 PR 승인을 CCoE 또는 클라우드 거버넌스의 구성원으로 제한합니다. 이 계층에 대한 기여자는 주로 이 계층의 구성 요소와 역사적으로 연결된 그룹의 구성원입니다. 예를 들어 네트워킹 팀은 네트워크에 대한 템플릿을 빌드하고, 운영 팀은 모니터링을 구성하는 등의 작업을 수행합니다. 그러나 다른 그룹의 개발자가 핵심 인프라에 대한 변경 내용을 제안할 수 있도록 하려면 요청하는 개인에게 읽기 전용 액세스 권한을 부여해야 합니다. 승인 및 테스트 없이는 변경 내용을 병합할 수 없지만 개선에 기여할 수 있습니다.
이러한 파일은 표준 구성 요소에 대한 컨테이너 레지스트리의 모듈을 사용해야 합니다. 그러나 엔터프라이즈의 Azure 랜딩 존 구현 또는 유사한 거버넌스 구조에 맞게 사용자 지정된 Bicep 파일 또는 일련의 Bicep 파일도 있습니다.
계층 2 - 제품 플랫폼: 공유 서비스
특정 제품 라인 또는 사업부에 대한 공유 서비스로 계층 2, 제품 플랫폼을 고려할 수 있습니다. 이러한 구성 요소는 조직 전체에서 보편적이지는 않지만 특정 비즈니스 요구 사항에 맞게 조정됩니다. 이는 계층 1, 전역 인프라의 허브와 피어인 가상 네트워크에 적합한 계층입니다. 키 자격 증명 모음은 이 계층의 또 다른 예제 구성 요소입니다. 키 자격 증명 모음은 이 플랫폼 내의 다른 애플리케이션에서 공유하는 스토리지 계정 또는 데이터베이스에 공유 비밀을 저장할 수 있습니다.
계층 2에는 다음이 포함되어야 합니다.
- 제품별 요구 사항과 일치하도록 구독 또는 리소스 그룹에 적용되는 정책 할당.
- 키 자격 증명 모음, 로그 분석, SQL 데이터베이스에 대한 ARM 템플릿(제품 내의 다양한 애플리케이션이 데이터베이스를 사용하는 경우) 및 Azure Kubernetes Service.
이 리포지토리에 변경 내용을 푸시하는 기능을 제한하는 권한을 구현해야 합니다. 다른 계층과 마찬가지로 분기 보호를 사용하여 제품 리더 또는 소유자가 다른 개발자의 PR을 승인할 수 있도록 해야 합니다. 제품 플랫폼에 대한 읽기 액세스에 대한 고정된 규칙은 없지만 최소한 애플리케이션 팀의 개발자는 변경 내용을 제안할 수 있도록 읽기 권한을 부여받아야 합니다. 계층 2에는 일부 독점 아키텍처 또는 유사한 정보가 포함될 수 있으므로 플랫폼을 사용하는 조직의 사용자에 대한 액세스를 제한하도록 선택할 수 있습니다. 그러나 이 경우 이 리포지토리에서 모범 사례 및 조각을 수집하여 전역 라이브러리인 계층 0과 공유하는 프로세스를 빌드해야 합니다.
계층 3 - 애플리케이션
애플리케이션 계층인 계층 3에는 제품 플랫폼 위에 빌드된 구성 요소가 포함됩니다. 이러한 구성 요소는 비즈니스에서 요청하는 기능을 제공합니다. 예를 들어 스트리밍 플랫폼의 경우 하나의 앱이 검색 기능을 제공할 수 있지만 다른 앱은 권장 사항을 제공합니다.
계층 3에는 다음이 포함되어야 합니다.
- C#, Python 등의 애플리케이션 코드.
- 개별 구성 요소에 대한 인프라(즉, 이 애플리케이션에서만 사용됨): 함수, Azure Container Instances, Event Hubs.
이 리포지토리에 변경 내용을 푸시할 수 있는 권한은 제한됩니다. 분기 보호를 사용하여 이 애플리케이션의 팀 구성원이 다른 팀 구성원이 만든 PR을 승인할 수 있도록 해야 합니다. 팀 구성원은 자신의 변경 내용을 승인할 수 없습니다. 이 계층에는 독점 아키텍처, 비즈니스 논리 또는 유사한 정보가 포함될 수 있으므로 이 애플리케이션을 빌드하는 조직의 사용자에 대한 액세스를 제한하도록 선택할 수 있습니다. 그러나 이 경우 전역 라이브러리인 계층 0과 공유하기 위해 이 계층에서 모범 사례 및 조각을 수확하는 프로세스도 빌드해야 합니다.
계층 간 공통점
이 문서에서는 각 계층에 대한 몇 가지 특정 세부 정보를 설명하지만 고려해야 할 모든 계층에 대한 몇 가지 특성도 있습니다.
인프라는 애플리케이션인 것처럼 작동해야 합니다. 즉, 단위 테스트, 스모크 테스트, 통합 테스트를 통해 새로운 기능을 완전히 테스트하는 CI(연속 통합) 프로세스가 있어야 합니다. 이러한 테스트를 통과하는 코드만 기본 릴리스 분기에 병합해야 합니다.
또한 편의상 개인이 프로세스를 우회하지 못하도록 분기 정책을 마련해야 합니다. CI 프로세스가 장애로 간주되는 경우 처리해야 하는 기술적인 문제가 발생했음을 의미합니다. 정책 및 보호를 제거해야 한다는 의미는 아닙니다.
마지막으로, 모든 리포지토리의 인덱스와 해당 리포지토리 내 코드의 인덱스가 없을 수도 있지만 조직은 개인이 리포지토리에 대한 액세스를 요청하는 프로세스를 개발해야 합니다. 특정 규칙은 완전히 자동화될 수 있습니다. 예를 들어 검토 없이 해당 제품의 모든 애플리케이션에 대한 제품 팀에 있는 기여자에게 읽기 권한을 부여하는 규칙을 구현할 수 있습니다. 이러한 규칙은 사용자 환경에서 그룹 기반 멤버 자격 및 그룹 기반 역할 할당을 사용하여 구현할 수 있는 경우가 많습니다. 이러한 종류의 액세스를 구성하면 내부 소싱 및 조직 지식을 용이하게 하는 데 도움이 됩니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
- Tim Sullivan | 선임 클라우드 솔루션 설계자
기타 기여자:
- Gary Moore | 프로그래머/작가
다음 단계
- 디자인 영역: 플랫폼 자동화 및 DevOps
- 완성도 높은 팀 구조
- IaC(Infrastructure as Code)란?
- Azure/ResourceModules: 이 리포지토리에는 완성되고 큐레이팅된 Bicep 모듈을 위한 CI 플랫폼 및 컬렉션이 포함되어 있습니다. 이 플랫폼은 Azure Resource Manager 및 Bicep을 모두 지원하며 GitHub 작업 및 Azure Pipelines에서 해당 기능을 사용할 수 있습니다.
- Bicep 모듈에 대한 프라이빗 레지스트리 만들기