배치 가능한 아키텍처를 작성하기 위한 우수 사례

배치 가능한 아키텍처 는 하나 이상의 클라우드 자원을 결합하여 공통 아키텍처 패턴을 제공하는 자체 포함된 모듈식 클라우드 자동화 단위입니다. 이를 사용하면 배치, 확장성 및 모듈성을 단순화하여 사용자가 인프라 리소스를 쉽게 프로비저닝하고 관리할 수 있습니다.

이 안내서에서는 Terraform으로 작성된 잘 디자인되고 유지보수 가능한 배치 가능한 아키텍처를 빌드하기 위한 우수 사례를 개략적으로 설명합니다. 범위, 구성 가능성, 소비가능성 및 품질 검사와 같은 주요 속성에 초점을 맞추면 강력하고 신뢰할 수 있는 솔루션을 보장하는 데 도움이 됩니다. 이 안내서의 마지막 섹션에서는 이러한 사례를 구현하는 데 도움이 되는 도구 및 템플리트에 대한 참조를 제공합니다.

이러한 우수 사례는 Terraform을 사용하여 배치 가능한 아키텍처를 작성하는 데 적용됩니다. 자세한 정보는 배치 가능한 아키텍처 작성 을 참조하십시오.

동영상 시청을 통한 학습

실제로 보고 싶으신가요? 배포 가능한 아키텍처에 대해 자세히 알아보려면 다음 동영상을 확인하세요.

동영상 대본

배포 가능한 아키텍처는 클라우드에 인프라와 소프트웨어를 배포하기 위한 자동화를 갖춘 아키텍처 패턴입니다. 이를 통해 조직은 인프라와 소프트웨어를 배포하고 구성하는 방식에서 일관성을 유지할 수 있습니다. 독단적인 아키텍처와 보안을 적용하여 전반적인 지원은 줄이고 장기적으로는 안정성을 높입니다.

이 패턴은 배포 가능한 아키텍처를 인스턴스화하는 자동화를 통해 실현됩니다. IBM Cloud 자동화는 서비스형 인프라 자동화를 위한 Terraform과 소프트웨어 구성을 위한 Ansible 을 통해 이루어집니다.

배포하기 전에 비용을 예측하고 아키텍처를 업데이트하거나 사용자 지정할 때 지출의 변화를 추적할 수 있습니다. 배포하기 전까지는 비용이 청구되지 않는다는 점을 기억하세요.

보안 및 조직 정책은 엔터프라이즈 배포에 있어 매우 중요합니다. 그렇기 때문에 배포 가능한 아키텍처는 일련의 정책 요구 사항을 준수하도록 사전에 검사되고 스캔되어 조직이 보안을 유지하는 데 도움이 될 수 있습니다. 표준화된 배포는 감사를 위한 증거 수집도 간소화합니다.

배포 가능한 아키텍처는 지원을 받는 방법과 아키텍처를 배포하는 데 필요한 권한에 대한 정보를 제공합니다.

마지막으로 비공개 카탈로그에서 배포 가능한 아키텍처를 조직의 다른 계정과 공유할 수 있습니다. 또한 카탈로그는 사용자를 배포 가능한 아키텍처의 특정 버전으로 제한할 수 있습니다. 이를 통해 모든 사람에게 일관성과 표준화를 보장합니다.

아키텍처 패턴은 도메인별 전문가가 만듭니다. 교차 도메인 아키텍처는 아키텍처를 서로 연결하여 보다 복잡한 배포 가능한 아키텍처를 만드는 방식으로 구축됩니다.

배포 가능한 아키텍처를 직접 만들거나 IBM Cloud 카탈로그 또는 커뮤니티 레지스트리에서 IBM Cloud 의 기성 아키텍처를 사용자 지정하여 시간을 절약할 수 있습니다.

배포 가능한 아키텍처는 아키텍처, 코드의 위치, 권한 및 비용, 지원, 설명, 아이콘 및 기타 세부 사항을 설명하는 매니페스트에 의해 코드로 정의됩니다. JSON으로 정의되며 리포지토리의 루트에 위치합니다.

콘솔에서 배포 가능한 아키텍처를 입력하거나 수정하고 매니페스트를 내보낼 수 있습니다. 릴리스 git 스냅샷에서 처음으로 배포 가능한 아키텍처를 만들 수 있습니다. 릴리스.tgz URL을 소스로 사용합니다.

그런 다음 배포 가능한 아키텍처에 대한 카탈로그 항목 세부 정보(예: 아이콘 및 이름)를 편집합니다. 종속성 및 자체 아키텍처와 잘 작동하지만 필수는 아닌 선택적 아키텍처를 추가할 수 있습니다.

배포 가능한 아키텍처에 대한 규정 준수 클레임을 관리할 수도 있습니다. 이러한 클레임은 게시하기 전에 카탈로그에서 배포 가능한 아키텍처의 유효성을 검사할 때 확인됩니다.

마지막으로 배포 가능한 아키텍처 버전을 온보딩한 후에는 카탈로그 매니페스트 파일을 내보내고 소스 리포지토리에 저장할 수 있습니다. 콘솔을 사용하면 카탈로그 매니페스트를 쉽게 내보내고 나중에 필요한 경우 편집할 수 있으므로 일반적으로 새로 배포 가능한 아키텍처를 온보딩하는 데 가장 적합한 방법입니다. 이렇게 하면 카탈로그 매니페스트 파일을 처음부터 새로 만들 필요가 없습니다.

IBM Cloud 카탈로그에서 배포 가능한 아키텍처 탭을 열어 IBM 에서 지원하는 아키텍처를 찾습니다.

커뮤니티 레지스트리의 배포 가능한 아키텍처는 자주 변경되거나 단기간에 중단될 수 있지만, 여전히 사용 및 사용자 지정에 좋은 출발점이 될 수 있습니다.

IBM Cloud 카탈로그에서 제공되는 VPC landing zone 배포 가능한 아키텍처를 고려하세요. 클라우드에서 워크로드를 실행하려는 경우 VPC가 필요하므로 일반적으로 배포 가능한 유용한 아키텍처입니다.

VPC landing zone 는 IBM Cloud Framework for Financial Services 프로필을 준수하도록 설계되었습니다. 관리 워크로드와 작업자 워크로드를 분리하고, 키 관리를 사용하여 클라우드 개체 저장소를 암호화하며, 통신에 비공개 엔드포인트를 사용합니다. 그대로 사용하거나 랜딩 존 요구 사항에 맞게 사용자 지정할 수 있습니다.

보다 복잡한 배포 가능한 아키텍처의 경우 보안 및 통합 가시성을 위한 Cloud 기반을 고려하세요. 배포 가능한 아키텍처는 IBM Cloud 카탈로그에서 여러 아키텍처를 서로 연결하여 만들었습니다. 이를 통해 IBM Cloud 에서 제공하는 모든 보안 서비스를 활용할 수 있습니다. 사용자 지정이 가능하므로 필요한 서비스만 포함하고 필요하지 않은 서비스는 제외할 수 있습니다.

이제 배포 가능한 아키텍처를 어디서 찾을 수 있는지 알았으니 계정 전체에 배포하고 유지 관리하려면 어떻게 해야 할까요? IBM Cloud 프로젝트를 사용합니다.

프로젝트에서 배포 가능한 아키텍처에 대한 입력 변수를 구성합니다. 비용, 리소스의 변동, 규정 준수 검사를 모니터링하고 카탈로그에서 배포 가능한 아키텍처의 최신 버전이 출시되면 이를 업그레이드할 수 있습니다. 프로젝트는 일반적으로 허브 계정에 위치하며, 대상 계정이라고도 하는 다양한 스포크 계정에 리소스를 배포합니다.

IBM Cloud 에서 보안 워크로드 실행에 대해 자세히 알아보려면 문서를 확인하세요. 또는, IBM Cloud 카탈로그를 살펴보며 귀사의 비즈니스에 적합한 배포 가능한 아키텍처를 발견해 보십시오.

디자인 원칙

범위, 구성 가능성 및 사용 가능성은 배치 가능한 아키텍처를 작성할 때 고려해야 하는 세 가지 기본 디자인 원칙입니다.

계획 및 조사 단계 에서는 오퍼링의 현재 에코시스템을 평가하고 비즈니스 유스 케이스 및 요구사항을 평가해야 합니다. 잘 설계된 프레임워크 및 아키텍처 디자인 프레임워크 를 사용하여 아키텍처의 필수 컴포넌트를 계획하고 설계하십시오.

범위

배치 가능한 아키텍처에 대해 잘 정의된 범위는 모든 필수 자원을 포함할 수 있을 정도로 포괄적이어야 하지만 불필요한 복잡도를 피할 수 있을 정도로 충분히 집중되어야 하므로 매우 중요합니다.

모범 사례는 일반적으로 하나의 단위로 함께 배포되며, 유사한 접근 및 권한이 필요하고, 동일한 수명 주기를 가진 인프라 리소스를 포함하는 것입니다. 예를 들어, VPC landing zone 배치 가능한 아키텍처 를 고려해 보겠습니다. 이 배치 가능한 아키텍처에는 다음 인프라 자원을 포함하는 잘 정의된 범위가 있습니다.

VPC 랜딩 영역 DA의 리소스
자원 설명
VPC 보안 VPC 토폴로지 작성
네트워크 인프라 서브넷, 퍼블릭 게이트웨이, ACL, 전송 게이트웨이 및 보안 그룹 포함
에지 네트워킹 공용 인터넷에 대한 트래픽을 격리합니다.
모니터링 및 로깅 VPC 트래픽의 관찰 가능성 및 감사를 위해 플로우 로그를 통합합니다.

이러한 리소스는 일반적으로 하나의 단위로 함께 배포되며, 유사한 네트워크 관리 권한이 필요하고 동일한 수명 주기를 가집니다. 즉, 이들은:

  • 새 VPC가 연관된 서브넷, 퍼블릭 게이트웨이 및 보안 그룹으로 프로비저닝되는 경우와 같이 함께 작성됩니다.
  • 서브넷, 퍼블릭 게이트웨이 및 보안 그룹에 대한 업데이트가 필요한 VPC의 네트워크 구성이 변경되는 경우와 같이 함께 업데이트됩니다.
  • VPC가 사용 중지되고 서브넷, 퍼블릭 게이트웨이 및 보안 그룹을 포함하여 연관된 모든 리소스가 제거되는 경우와 같이 함께 삭제됩니다.

구성 가능성

배포 가능한 아키텍처의 기본 원칙은 구성 가능성으로, 여러 배포 가능한 아키텍처를 함께 쌓아 더 광범위한 배포 가능한 아키텍처를 만들 수 있습니다. 이 모듈식 접근 방식을 사용하면 자동화 자원의 유연성과 재사용성을 극대화할 수 있습니다.

구성 가능성을 달성하려면 배치 가능한 아키텍처를 다음과 같이 설계해야 합니다.

  • 출력 값을 통해 표시되는 정보의 양을 최대화하지만 출력 유형은 단순하게 유지하십시오. 이 사례를 사용하면 배치 가능한 아키텍처 자동화를 광범위한 시나리오에서 재사용할 수 있으며 다양한 자동화된 솔루션을 위한 다양한 빌딩 블록으로 작성할 수 있습니다.

  • 자원 그룹, IBM® Key Protect for IBM Cloud® 또는 Hyper Protect Crypto Services 인스턴스 및 IBM Cloud Secrets Manager 인스턴스 등과 같은 기존에 배치된 자원에 대한 선택적 참조를 허용합니다. 그런 다음 사용자는 기존 인스턴스를 구성하거나 기존 자원 그룹에 배치하여 자동화의 다양성을 증가시킬 수 있습니다. Secrets Manager 배치 가능한 아키텍처 는 작동 중인 이 원칙의 좋은 예입니다. 사용자가 기존 Secrets Manager 인스턴스, 자원 그룹 및 KMS 암호화 키를 재사용할 수 있도록 허용하여 이 자동화는 높은 수준의 유연성과 적응성을 제공합니다. 예를 들어, 다음을 수행할 수 있습니다.

    • 해당 ID를 전달하여 기존 Secrets Manager 인스턴스를 구성하고 기존 인스턴스에서 시크릿 그룹을 작성하십시오.
    • Key Protect 또는 Hyper Protect Crypto Services와 같은 기존 키 관리 시스템과 통합하십시오.
    • 기존 자원 그룹에 배치하거나 사용자 정의할 수 있는 이름 지정 규칙을 사용하여 새 자원 그룹을 작성하십시오.

또는 이 배치 가능한 아키텍처를 사용하여 새 Secrets Manager 인스턴스, 새 리소스 그룹 및 기타 리소스를 처음부터 작성하여 독립형 솔루션을 제공할 수도 있습니다.

구성 가능성을 수용함으로써 배포 가능한 아키텍처를 다른 배포 가능한 아키텍처와 스택하여 더 복잡한 솔루션 아키텍처에 쉽게 통합할 수 있습니다. 예를 들어, 검색 증강 생성 패턴은 Secrets Manager 배포 가능한 아키텍처를 비롯한 여러 배포 가능한 아키텍처를 결합하여 복잡한 솔루션을 구축하는 방법을 보여줍니다. 구성 가능성을 염두에 두고 설계된 배포 가능한 아키텍처는 이러한 복잡한 솔루션의 기반을 제공합니다.

배포 가능한 아키텍처가 함께 스택된 경우 각 멤버 배포 가능한 아키텍처는 독립적인 구성 상태를 유지하므로 개별 배포, 업데이트 또는 배포 취소가 가능합니다. 이러한 모듈식 접근 방식을 통해 비용, 규정 준수, 지원 및 품질 보증을 포함된 배포 가능한 아키텍처에서 도출할 수 있으며, 전체 솔루션은 고유한 설명과 참조 아키텍처를 통해 고유한 버전으로 유지됩니다. 자세한 내용은 배포 가능한 아키텍처를 스택한다는 것은 무엇을 의미하나요?

소비 가능성(consumability)

배치 가능한 아키텍처는 사용자가 쉽게 이해하고 배치할 수 있도록 소비 가능성을 염두에 두고 설계해야 합니다. 이를 수행하려면 배치 가능한 아키텍처가 다음을 포함하는 포괄적인 문서를 제공해야 합니다.

전제조건
배치에 필요한 소프트웨어 종속성 및 인프라 요구사항입니다.
자세한 입력 변수 및 출력 값 설명
목적, 데이터 유형 및 기본값을 포함합니다.
필요한 최소 권한
배치 가능한 아키텍처 자동화를 실행하는 데 필요한 권한입니다.
다이어그램 및 아키텍처 맵
배치 가능한 아키텍처의 컴포넌트 및 관계를 시각적으로 표시합니다.
단순화된 구성
쉽게 배치하고 관리할 수 있습니다.
자원 요구사항 감소
배치 가능한 아키텍처를 최적화하여 낮은 CPU및 메모리 요구사항과 같은 하드웨어 및 자원 요구사항을 최소화하여 보다 저렴하고 효율적으로 만드십시오.
배포 간소화
빠르고 쉽게 시작할 수 있습니다.

배치 가능한 아키텍처를 쉽게 사용할 수 있도록 하는 또 다른 측면은 빠른 시작 변형을 포함하여 여러 변형을 제공하는 것입니다. 배치 가능한 아키텍처의 빠른 시작 버전이 제공되어야 하며, 이는 실행하기에 더 저렴하고 더 빠릅니다. 예를 들어, VPC landing zone 에서 Red Hat OpenShift Container Platform의 QuickStart 변형 배치 가능 아키텍처는 단일 지역에서 완전히 사용자 정의할 수 있는 VPC (Virtual Private Cloud) 환경을 작성하여 워크로드를 위한 보안 VPC에서 단일 Red Hat OpenShift 클러스터를 제공합니다. 이 빠른 시작 변형은 데모 및 개발 목적으로 설계되었으며 실행 비용이 월 $400미만입니다.

반대로, IBM Cloud Framework for Financial Services 참조 아키텍처를 기반으로 하는 Red Hat OpenShift Container Platform on VPC landing zone 배치 가능 아키텍처의 표준 버전은 보안 및 준수 Red Hat OpenShift 컨테이너 플랫폼 워크로드 클러스터를 VPC (Virtual Private Cloud) 네트워크에 작성하지만 실행하는 데 매월 $4,000이 넘는 비용입니다. 또한 관리 VPC 서비스, 워크로드 VPC 서비스, 관리 VPC및 워크로드 VPC의 격리, 고급 네트워크 보안 아키텍처 의사결정과 같은 고급 기능을 포함합니다.

입력 변수

사용자가 다음 우수 사례를 사용하여 배치 가능한 아키텍처의 입력 변수를 더 쉽게 구성할 수 있도록 하십시오.

공통적으로 수정된 인수만 표시
대부분의 사용자가 변경해야 할 변수만 노출하고, 사용자를 압도할 수 있는 다수의 입력 변수를 가진 배포 가능한 아키텍처를 피하십시오. 고급 사용자의 경우 추가 사용자 정의를 위해 단일 JSON 입력 필드를 제공하는 것을 고려하십시오. 예를 들어, VPC 랜딩 구역 배치 가능 아키텍처는 배치된 토폴로지의 고급 사용자에게 전체 제어를 제공하는 override_json_string 이라는 단일 필드를 표시합니다. 자세한 정보는 VPC 랜딩 구역 배치 안내서 를 참조하십시오.
기존 자원에 대해 명확하고 설명적인 이름 지정 사용
기존 자원을 참조할 때는 모호함을 피하기 위해 cluster_name 대신 existing_cluster_name 와 같이 참조하는 내용을 명확하게 표시하는 이름을 사용하십시오.
ID보다 이름 선호
기존 자원을 참조할 때 더 나은 사용자 이용을 위해 ID 대신 이름을 사용하십시오.
두문자어 금지
약어를 사용하는 대신 전체 제품 이름을 사용하여 제품 또는 서비스에 익숙하지 않은 사용자가 참조하는 내용을 더 쉽게 이해할 수 있도록 하십시오. 예를 들어, sm 대신 secrets_manager 또는 kms 대신 key_management 입니다.
고급 입력 기능 사용
IBM Cloud 프로젝트 서비스가 변수에 적합한 입력 위젯을 렌더링할 수 있도록 하여 사용자가 값을 더 쉽게 구성할 수 있도록 합니다. 예를 들어, 다음과 같습니다.
  • VPC 지역: IBM Cloud에서 사용 가능한 모든 VPC 지역의 드롭 다운 목록입니다.
  • VPC SSH키: SSH키 관리를 위한 보안 입력 필드입니다.
  • 클러스터: IBM Cloud에서 사용 가능한 클러스터의 드롭 다운 목록입니다.

자세한 정보는 카탈로그 적하 목록 값 로컬 편집 을 참조하십시오.

이러한 가이드라인에 따라 배치 가능한 아키텍처를 더 많이 이용할 수 있게 하여 사용자가 신속하게 이해하고 배치할 수 있도록 합니다.

품질

배치 가능한 아키텍처가 신뢰할 수 있고 일관되도록 하려면 품질 검사를 구현하고 자동화하는 것이 중요합니다. 이러한 검사에서는 코드 품질, 구성 유효성 검증, 테스트 및 지속적인 통합을 포함하여 배치 가능한 아키텍처의 다양한 측면을 다루어야 합니다.

코드 품질

선형 및 코드 형식을 활용합니다. 코드를 쉽게 읽고 유지보수할 수 있도록 일관된 코딩 스타일 및 형식화를 적용합니다. 배치 중에 문제를 방지하기 위해 코드에서 오류 및 경고를 발견합니다. Terraform 코드뿐만 아니라 배포 가능한 아키텍처의 모든 리소스와 관련된 도구(예: Bash 스크립트, Python 스크립트, YAML 및 JSON 파일, Golang 등)를 통합하는 것을 고려하세요.

예:

  • terraform_fmt-Terraform 코드를 형식화합니다.
  • go-fmt-Go 코드를 형식화합니다.
  • black- Python 코드를 형식화합니다.
  • isort: Python 가져오기를 정렬합니다.
  • flake8- Python 코드에서 오류 및 경고를 확인합니다.
  • shellcheck-쉘 스크립트에서 오류 및 경고를 확인합니다.
  • golangci-lint-이동 코드에서 오류 및 경고를 확인합니다.

구성 유효성 검증

정적 유효성 검증을 사용하여 배치 가능한 아키텍처의 구문 및 구성이 올바르고 일관성이 있는지 확인하십시오. 배치 중에 오류가 발생하지 않도록 배치 가능한 아키텍처의 구성을 유효성 검증하십시오. 다시 말하지만, Terraform 코드뿐만 아니라 배포 가능한 아키텍처의 모든 리소스와 관련된 도구(예: Bash 스크립트, Python 스크립트, YAML 및 JSON 파일, Golang 등)를 통합하는 것을 고려하세요.

예:

  • terraform_validate-Terraform 구성을 유효성 검증합니다.
  • checkov-Terraform 코드에서 보안 및 준수 문제를 확인합니다.
  • tflint-오류 및 경고를 확인합니다.
  • detect-secrets-코드에서 시크릿을 발견합니다.
  • hadolint- Docker 파일에서 오류 및 경고를 확인합니다.
  • helmlint- Helm 차트에서 오류 및 경고를 확인합니다.

테스트

인프라 코드를 테스트하는 경우에는 애플리케이션 코드에 대해 생각할 수 있는 방식으로 순수한 단위 테스트가 없습니다. 대신, 테스트 전략에는 실제 환경에 인프라를 배치하고 작동하는지 유효성을 검증한 후 배치 취소하는 작업이 포함됩니다.

자동화된 유효성 검증 테스트 스위트

다음과 같은 기초를 다루는 기본 자동화된 테스트 스위트를 사용하는 것이 좋습니다.

배치 테스트
인프라 코드를 실제 환경에 성공적으로 배치할 수 있는지 확인하십시오. 필요한 모든 자원 (예: 가상 머신, 데이터베이스 및 네트워크) 을 작성하십시오. 이러한 테스트는 인프라 코드가 올바르고 실제 환경에 성공적으로 적용될 수 있는지 확인하는 데 도움이 됩니다. 이러한 테스트에서 배치 가능한 아키텍처의 입력 매개변수를 다양하게 하여 공통 사용법에 맞게 광범위하게 적용되도록 하는 것이 좋습니다.
영구 삭제 테스트
인프라 코드를 성공적으로 배치 해제하거나 영구 삭제하여 작성된 모든 자원을 제거할 수 있는지 확인하십시오. 이러한 테스트를 통해 고아 자원을 남겨두거나 의도하지 않은 결과를 초래하지 않고 실제 환경에서 인프라 코드를 안전하게 제거할 수 있습니다.
멱등원 검정
의도하지 않은 변경 또는 오류를 발생시키지 않고 인프라 코드를 여러 번 다시 적용할 수 있는지 확인하십시오. 즉, 코드는 적용되는 횟수에 관계없이 동일한 결과를 생성해야 합니다. 이러한 테스트는 IBM Cloud와 같은 환경에서 중요합니다. 여기서 플랫폼은 배치된 인프라와 진실의 소스 (자동화 코드) 간의 드리프트를 발견하기 위해 주기적으로 변경사항을 확인합니다. 멱등성 테스트는 인프라 코드가 문제를 일으키지 않고 반복되는 배치 또는 업데이트를 처리할 수 있도록 보장하는 데 도움이 됩니다. 또한 이러한 테스트는 드리프트 발견 기능이 의도한 상태와 인프라의 실제 상태 사이의 불일치를 정확하게 식별하고 수정할 수 있도록 보장하는 데 도움이 됩니다. 자세한 정보는 드리프트 관리 를 참조하십시오.
버전 업그레이드 테스트
오류 또는 의도하지 않은 변경사항을 발생시키지 않고 한 버전에서 다른 버전으로 인프라 코드를 성공적으로 업그레이드할 수 있는지 확인하십시오. 이러한 테스트를 통해 인프라 코드를 안전하게 업그레이드할 수 있습니다. 기존 자원을 방해하거나 제거하거나 의도하지 않은 결과를 초래하지 않습니다.

고급 테스트 케이스

고급 테스트 케이스에는 다음과 같은 시나리오가 포함되어 있습니다.

배치 가능한 아키텍처를 동일한 계정에 여러 번 배치
인프라 코드가 자원 이름 충돌 또는 기타 문제를 유발하지 않고 동일한 계정에서 여러 배치를 처리할 수 있는지 확인하십시오.
신뢰할 수 있는 프로파일을 사용하여 배치 가능한 아키텍처 배치
Cloud Identity and Access Management 신뢰할 수 있는 프로파일을 사용하여 인프라 코드를 배치할 수 있는지 확인하십시오. 자세한 정보는 인증 메소드 정의 를 참조하십시오.

자동화된 테스트 스위트에 이러한 테스트를 포함하여 인프라 코드가 신뢰할 수 있고 강력하며 프로덕션에 배치하기에 안전한지 확인할 수 있습니다.

지속적 통합

배치 가능한 아키텍처의 신뢰성, 일관성 및 유지보수성을 보장하기 위해 품질 검사 및 테스트가 개발 주기의 초기에 통합되는 shift-left 접근 방식이 권장됩니다. 이 접근 방식은 오류 및 결함을 조기에 발견하여 다운스트림 문제점의 가능성을 줄이고 전반적인 품질을 개선하는 데 도움이 됩니다.

이 접근 방식의 일부로 다음 품질 검사가 권장됩니다.

클라이언트측 품질 제어
클라이언트 측 Git 커미트 후크 는 코드를 커미트하기 전에 개발자 시스템에서 검사를 실행하는 데 사용해야 합니다. 여기에는 코딩 표준, 구문 오류 및 민감한 데이터에 대한 검사가 포함됩니다. 사전 커미트 와 같은 도구를 사용하여 이 프로세스를 자동화할 수 있습니다.
CI 사례
지속적 통합 (CI) 에 대한 우수 사례를 따라야 합니다. 소프트웨어 엔지니어링 제품의 일반 사례는 다음을 포함하여 배치 가능한 아키텍처 개발에 적용됩니다.
  • 소규모의 집중된 가져오기 요청 (PR) 에 대한 작업을 수행하여 시기 적절한 검토를 용이하게 하고 병합 충돌을 줄입니다.
  • 코드 변경사항을 정기적으로 기본 분기에 통합하여 수명이 긴 기능 분기를 방지하고 병합 복잡도를 줄입니다.
  • 자동화된 테스트 및 코드 검토를 구현하여 코드 품질 및 일관성을 보장합니다.
  • 배치 가능한 아키텍처의 구성 및 구문을 지속적으로 유효성 검증하여 정확성 및 일관성을 보장합니다.
CI 파이프라인
이러한 사례를 자동화하도록 CI 파이프라인을 설정하여 배치 가능한 아키텍처의 모든 코드 변경사항이 체계적으로 테스트되고 유효성 검증되도록 해야 합니다. 이 파이프라인은 배치 가능한 아키텍처가 올바르고 일관되게 작동하고 오류 또는 결함이 조기에 발견되도록 합니다.

도구 및 자원

고품질의 배치 가능한 아키텍처를 쉽게 작성할 수 있도록 포괄적인 도구 및 자원 세트가 제공됩니다. 큐레이트된 Terraform 모듈은 다양한 인프라 요구사항을 포함하는 60개이상의 재사용 가능하고 안전하며 유효성 검증된 모듈이 있는 핵심 부분입니다. 이러한 모듈은 GitHub 에서 사용 가능하며 개방형 소스 컨트리뷰션 모델을 통해 지원되고 최신 상태로 유지되며 IBM Cloud 개발 조직의 컨트리뷰션으로 지원됩니다.

배치 가능한 아키텍처 및 모듈 작성을 지원하기 위해 큐레이트된 Terraform 모듈 외에 우수 사례 및 템플리트도 제공됩니다. 여기에는 문서, 작성 우수 사례에 맞게 조정된 GitHub 배치 가능한 아키텍처 저장소 템플리트, Terraform 모듈 및 Terraform 기반 배치 가능한 아키텍처 모두에 적용되는 모듈 작성 가이드라인 이 포함됩니다. 이러한 자원을 사용하여 새로 배치 가능한 아키텍처를 빠르게 시작할 수 있습니다.

또한 자동화된 테스트 프레임워크가 제공되며 Terratest 라이브러리를 기반으로 하며 Go로 작성된 테스트가 포함되어 있습니다. 이 프레임워크는 비활성 테스트, 업그레이드 테스트 및 GitHub, 다루며 https://github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper 라이브러리의 테스트 도우미 함수를 사용합니다. 자세한 정보는 테스트 문서를 참조하십시오.

CI 파이프라인 개발을 지원하기 위해 다음과 같은 다양한 도구 및 자원을 사용할 수 있습니다.

  • 재사용 가능한 GitHub 조치.
  • 자동화된 문서 생성.
  • IBM Cloud에 자동 온보딩.
  • 사용자 정의 renovate를 사용하여 자동화된 종속성 업데이트.
  • 로컬 개발 설정 도구 및 사전 커미트 후크 구성에 대한 자세한 정보는 로컬 개발 설정 문서 를 참조하십시오.

이러한 도구 및 자원은 고품질의 배치 가능한 아키텍처를 빠르고 쉽게 작성할 수 있도록 설계되었습니다.

다음 단계

이제 배치 가능한 아키텍처를 빌드하기 위한 우수 사례를 이해했으므로 자동화 코드를 개발하기 전에 도구 및 자원을 사용하고 다음 IBM Cloud 문서를 검토할 수 있습니다. 이는 IBM Cloud에서 공유할 솔루션을 철저히 계획하고 디자인하는 데 도움이 됩니다.