배치 가능한 아키텍처 작성

아키텍처 계획 및 디자인 단계를 수행하고 작성할 컴포넌트 유형을 결정 한 후에 아키텍처를 적용하는 자동화된 코드 작성을 시작할 수 있습니다. 이 주제에서는 모듈로 구성된 배치 가능한 아키텍처를 작성하는 과정을 안내합니다.

배포 가능한 아키텍처를 생성하려면 필수 파일을 정의하고 다음에서 릴리스를 생성해야 합니다. GitHub, 그런 다음 이를 개인 카탈로그에 등록하여 조직 내부 또는 외부의 다른 사람들과 공유할 수 있습니다.

배포 가능한 아키텍처를 만들기 위한 몇 가지 옵션이 있습니다:

직접 구축하세요: 다음 지침에 따라 배포 가능한 아키텍처를 처음부터 직접 구축하세요.
기존 코드를 수정합니다: 기존 아키텍처에서 코드를 다운로드하여 필요에 맞게 수정한 다음 변경 사항을 적용하여 배포 가능한 새 아키텍처를 만듭니다.
스택 아키텍처: 카탈로그에서 해당 아키텍처를 이미 사용할 수 있는 경우 프로젝트에서 배포 가능한 아키텍처를 함께 스택 할 수도 있습니다.

배치 가능한 아키텍처의 구조에 대해 학습합니다.

이 문서에서 설명하는 배치 가능한 아키텍처는 하나 이상의 모듈로 구성됩니다. 배치 가능한 아키텍처는 소스 저장소에서 다음으로 구성됩니다.

Terraform 코드: 소스 저장소에 Terraform 파일 이 포함되어 있습니다. 이러한 파일은 원하는 인프라 (종료 상태) 를 선언하고 인프라를 작성, 업데이트 및 삭제하기 위해 실제 API 요청을 수행하는 Terraform 제공자에 의존합니다. 사용되는 가장 일반적인 제공자 중 일부는 IBM Cloud® Terraform 제공자 및 Helm/Kubernetes/Rest API 제공자입니다.
스크립트 (선택사항): 존재하지 않을 수 있는 함수 (Bash/Python) 또는 임시 운영 태스크 (Ansible) 에 대한 중간 기착지 간격으로 사용됩니다. 자세한 정보는 배치 가능한 아키텍처에 대한 스크립트 작성 을 참조하십시오.
자동화된 테스트: 인프라를 배치, 확인 및 영구 삭제하는 데 사용되는 유효성 검증 테스트입니다. 예를 들어, sample-deployable-architecture 샘플 저장소에서 tests 디렉토리를 참조하십시오.
문서: 아키텍처 다이어그램 및 readme 파일을 소스 저장소에 포함해야 합니다.
카탈로그 Manifest 파일: IBM Cloud 카탈로그에서 배치 가능한 아키텍처가 노출되는 방법을 정의합니다. 일반 카탈로그 세부 정보(이름, 설명, 기능 등) 외에도, 기본 테라폼 구성을 참조하는 변형 정의, 카탈로그 등록 시 IBM Cloud® Security and Compliance Center Workload Protection 검증되는 규정 준수 클레임, 배포 가능한 아키텍처 실행에 필요한 IAM 권한을 포함합니다. 자세한 정보는 카탈로그 Manifest 로컬 편집 을 참조하십시오.
변형: 배치 가능한 아키텍처에는 기능 또는 복잡도의 변형이 포함될 수 있습니다. 예를 들어, 단순하고 저렴한 배치를 위한 기본 기능을 사용하여 빠른 시작 변형을 작성한 후 프로덕션에서 사용되는 보다 복잡한 아키텍처를 사용하는 표준 변형을 가질 수 있습니다. 이러한 각 변형은 자체적으로 배치 가능한 아키텍처이며, 카탈로그에 함께 표시되도록 온보딩되고 구성됩니다. 이러한 변형은 다른 작업 디렉토리의 동일한 저장소에서 발생하며 ibm_catalog.json 파일에 정의되어 있습니다. 자세한 내용은 변형 만들기를 참조하세요.

종속성 지정 및 아키텍처 확장

배포 가능한 아키텍처가 다른 아키텍처에 종속되어 있는 경우, 배포 가능한 아키텍처를 카탈로그에 온보딩할 때 해당 종속성에 대한 정보를 포함할 수 있습니다. 또한 다양한 사용 사례에 맞게 자체 아키텍처를 확장하는 옵션 아키텍처를 포함할 수도 있습니다. 그 결과 사용자가 원하는 아키텍처를 선택할 수 있으므로 맞춤형 솔루션이 제공됩니다. 자세한 내용은 온보딩 중 배포 가능한 아키텍처 확장하기를 참조하세요.

또한 배포 가능한 아키텍처에 대한 카탈로그 매니페스트 파일에 자신의 아키텍처와 함께 포함하려는 다른 아키텍처에 대한 정보를 온보딩하기 전에 제공할 수도 있습니다.

카탈로그 매니페스트 파일의 dependencies 섹션을 사용하여 선택 사항 및 필수 아키텍처로 사용자 지정 가능한 솔루션을 만들 수 있습니다. 카탈로그 매니페스트 파일에서 dependency_version_2 가 true 로 설정되어 있는지 확인합니다. 카탈로그 매니페스트 파일에서 종속성으로 작업하는 기존 방식은 계속 지원됩니다. dependency_version_2 을 false 으로 설정한 상태에서 install_type 을 extension 으로 설정하고 dependencies 섹션에 종속성 정보를 제공할 수 있습니다. 이렇게 하면 종속성 목록에 있는 각 아키텍처를 배포하는 데 필요합니다. 자세한 정보 및 이러한 값 설정은 카탈로그 매니페스트 로컬 편집을 참조하세요.

배치 가능한 아키텍처 작성

배치 가능한 아키텍처를 작성하는 동안 다음 상위 레벨 태스크를 완료할 수 있습니다.

소스 저장소를 작성하고 코드를 추가하십시오.
ibm_catalog.json Manifest 파일을 작성하여 카탈로그에서 타일 작성을 준비하십시오.
릴리스를 작성하십시오.
개인용 카탈로그를 검토하고 유효성을 검증하여 카탈로그 타일을 작성하기 위해 코드를 온보딩합니다.
배치 가능한 아키텍처를 공유하거나 공개할 위치를 선택하십시오.

배치 가능한 아키텍처를 작성하기 위한 다음 지시사항은 공용 샘플 저장소를 사용하여 예제별로 학습합니다.

소스 저장소 작성

조직에서 정의한 요구사항을 사용하여 배치 가능한 아키텍처의 소스 코드를 보유하는 데 사용할 수 있는 GitHub 저장소를 작성하십시오. 저장소 작성에 대한 도움말은 GitHub 문서를 참조하십시오. 사용하려는 저장소가 이미 있다면 이 단계를 건너뛸 수 있습니다. 다음과 같은 다른 조직을 사용하여 소스 코드를 호스팅하도록 선택할 수 있습니다. GitLab, 하지만 이 문서의 목적에 따라 GitHub 사용.

필수 Terraform 파일 작성

개인용 카탈로그에 배치 가능한 아키텍처를 온보딩하는 과정에서 필요한 .tgz 파일을 작성하기 위해 GitHub 소스 저장소에 필요한 기본 Terraform 파일을 이해하려면 다음 섹션을 검토하십시오.

`main.tf`

main.tf 파일은 작성할 자원을 프로비저닝하는 코드를 배치하는 위치입니다. terraform-ibm-modules 에서 모듈을 호출하거나 외부 모듈 또는 제공자 자원을 직접 호출할 수 있습니다.

다음 예를 참조하십시오.

`outputs.tf`

outputs.tf 파일에는 배치 가능한 아키텍처에 포함할 수 있는 출력 값이 포함되어 있습니다.

다음 예를 참조하십시오.

`provider.tf`

provider.tf 파일에는 제공자 이름, API키 및 코드가 예상하는 지역과 같은 제공자 구성이 포함되어 있습니다.

다음 예를 참조하십시오.

`README.md`

readme 파일에는 요구사항, 모듈, 자원, 필수 액세스, 입력 및 출력 섹션을 포함하여 배치 가능한 아키텍처에 대한 배경 및 사용법 정보가 포함되어 있습니다.

소스 저장소가 terraform-ibm-modules 조직에 있는 경우 대부분의 readme 파일이 생성됩니다. 따라서 입력 및 출력과 같은 정보를 수동으로 추가하지 않습니다. 변수 이름과 설명은 variables.tf 파일에서 readme 파일로 생성됩니다.

다음 예를 참조하십시오.

`variables.tf`

variables.tf 파일에는 배치 가능한 아키텍처에 대한 필수 및 선택적 변수가 포함되어 있습니다.

다음 예를 참조하십시오.

`version.tf`

version.tf 파일은 배치 가능한 아키텍처를 실행하는 데 필요한 Terraform 버전 및 제공자 버전에 대한 정보를 저장합니다.

배치 가능한 아키텍처에 대한 필수 Terraform 제공자는 배치 가능한 아키텍처와 일치하는 결과를 얻기 위해 범위를 사용하는 대신 정확한 버전으로 잠가야 합니다.

다음 예를 참조하십시오.

카탈로그 매니페스트 파일 생성

카탈로그 Manifest는 ibm_catalog.json 라는 저장소의 루트에 있는 파일입니다. 이 파일은 카탈로그에 타일을 생성하는 데 필요한 메타데이터를 정의합니다. 예를 들어 이름, 설명, 기능, 기본 테라폼 구성을 참조하는 변형 정의, 온보딩 과정에서 검증될 규정 준수 클레임, 아키텍처 배포에 필요한 IAM 권한 등이 포함됩니다 Workload Protection. 또한 사용자가 카탈로그에서 아키텍처를 배치하려고 시도할 때 기본적으로 선택할 구성을 정의합니다. 자세한 정보는 카탈로그 세부사항을 Manifest 파일에 맵핑 을 참조하십시오.

전체 스택 및 확장 유형 변형을 표시하는 샘플 저장소의 예제 를 확인하십시오.

두 가지 다른 방법을 사용하여 카탈로그 Manifest 파일을 작성할 수 있습니다.

템플리트 를 사용하여 처음부터 이 파일을 작성할 수 있습니다.

소스 저장소에서 다음 기본 샘플을 사용하여 온보딩 프로세스를 시작한 후 콘솔에서 온보딩 중에 변경하여 업데이트된 파일을 소스 저장소에 추가한 후 Manifest 파일을 다운로드 할 수 있습니다.

다음은 이 옵션을 시작하는 데 도움이 되도록 저장소에 추가하고 편집할 수 있는 기본 Manifest 파일입니다.

{
    "products": [
        {
            "flavors": [
                {
                    "architecture": {},
                    "compliance": {},
                    "install_type": "fullstack"
                }
            ],
            "label": "catalog-create-sample-da-0.0.1",
            "name": "catalog-create-sample-da-0.0.1",
            "offering_icon_url": "url",
            "product_kind": "solution",
            "provider_name": "Community",
            "short_description": "A simple deployable architecture.",
            "tags": [
                "dev_ops"
            ],
            "version": "0.0.1"
        }
    ]
}

다음 단계: 개인용 카탈로그에 배치 가능한 아키텍처 온보드

소스 저장소에 필수 파일을 포함하는 Git 릴리스가 작성되면 배치 가능한 아키텍처 버전 및 모든 포함된 변형을 온보드할 수 있습니다. 온보딩은 IBM Cloud에서 카탈로그 세부사항을 검토하고 테스트 배치 및 준수 청구의 유효성을 검증하여 개인용 카탈로그에서 카탈로그 타일을 작성하는 프로세스입니다. 단계별 프로세스는 배치 가능한 아키텍처 온보딩 을 참조하십시오.