배포 가능한 아키텍처를 사설 카탈로그에 온보딩하기

배포 가능한 아키텍처를 조직의 다른 구성원과 공유할 준비가 되면, 이를 비공개 카탈로그에 추가할 수 있습니다. 또한 온보딩 흐름을 활용하여 아키텍처를 검증할 수 있습니다.

배포 가능 아키텍처를 사설 카탈로그에 등록하려면 소스 코드를 카탈로그에 추가한 후 배포 가능 아키텍처의 세부 정보를 편집하고 이를 검증해야 합니다. 그런 다음 배포 가능한 아키텍처에 대한 비용 추정 및 규정 준수 정보를 검토합니다. 작업이 완료되면 배포 가능한 아키텍처를 공유하거나 IBM Cloud 에 공개적으로 게시할 수 있습니다.

배포 가능한 아키텍처를 사설 카탈로그에 온보딩하기 배포 가능한 — 사설 카탈로그에 온보딩하기 위한 상위 프로세스

시작하기 전에

배포 가능한 아키텍처를 온보딩하기 전에 다음 필수 조건을 완료했는지 확인하십시오.

종량과금제 또는 구독 계정을 사용하고 있는지 확인하십시오. 자세한 내용은 계정 유형 보기를 참조하십시오.
개인 카탈로그 및 배포 가능 아키텍처 작업에 필요한 접근 권한을 보유하고 있는지 확인하십시오.
- IBM Cloud Schematics 서비스의 관리자 역할
- 카탈로그 관리 서비스에 대한 편집자 역할
- 계정의 모든 리소스 그룹에 대한 뷰어 역할
- SecretsReader 보안 값을 Secrets Manager 인스턴스에 저장할 계획이라면 Secrets Manager 서비스에서 역할을 수행하십시오
- Workload Protection 서비스의 리더 역할
- 사용자 정의 배포 가능 아키텍처에서 특정 리소스에 필요한 기타 역할
개인용 카탈로그를 작성합니다.
배포 가능한 아키텍처의 소스 코드가 GitHub 또는 GitLab 저장소에 저장되어 있는지 확인하십시오. 소스 코드를 저장소에 넣는 방법에 대한 도움말은 소스 코드 저장소 설정을 참조하십시오.

작동 방식을 확인하고 싶지만 즉시 사용할 수 있는 배포 가능한 아키텍처가 준비되어 있지 않으신가요? 당사의 샘플 배포 가능 아키텍처를 사용하십시오.

소스 코드 패키징

배포 가능한 아키텍처를 사설 카탈로그에 온보딩하는 데 필요한 파일을 .tgz 생성하려면 소스 코드의 릴리스 버전을 생성해야 합니다. 릴리스 생성에 대한 도움말은 저장소의 릴리스 관리 항목을 참조하십시오.

비공개 소스 코드 저장소를 사용하는 경우, Git 개인 액세스 토큰 또는 Secrets Manager.

사설 카탈로그에 배포 가능한 아키텍처 추가

배포 가능한 아키텍처를 개인 카탈로그에 추가하려면 다음 단계를 따르십시오.

카탈로그 항목 편집하기

배포 가능한 아키텍처를 개인 카탈로그에 성공적으로 등록한 후에는, 사용자가 해당 아키텍처를 사용하려고 할 때 표시될 정보를 반드시 지정해야 합니다. 해당 정보에는 제품 설명, 문서 링크, 그리고 제품을 쉽게 찾을 수 있도록 보장하는 키워드가 포함됩니다.

콘솔의 관리 > 카탈로그 > 개인 카탈로그 페이지로 이동하십시오.
제품을 추가한 개인 카탈로그를 선택하세요. 카탈로그 상세 페이지가 열립니다.
이전에 등록한 제품을 선택하십시오.
카탈로그에 표시되는 항목의 표시 방식을 편집하세요.
1. 카탈로그 항목 세부 정보 섹션에서 편집을 클릭하세요.
2. 배포 가능한 아키텍처와 함께 가져온 정보를 검토하고, 필요한 경우 수정하십시오.
3. 카탈로그 항목 미리보기를 확인하여 항목이 예상대로 표시되는지 확인하십시오.
4. 선택을 완료한 후 저장을 클릭하세요.
제품의 정보 페이지를 편집하세요. 사용자가 카탈로그에서 귀사의 제품을 선택하면, 해당 제품과 제공되는 기능에 대해 자세히 알아볼 수 있는 '제품 소개' 섹션이 표시됩니다.
1. 작업 드롭다운 메뉴에서 '제품 페이지 편집'을 선택하세요.
2. 사용자에게 제품의 가치와 이점을 설명하는 제품 설명을 입력하세요.
3. 특정 기능 정보를 추가하려면 기능 > 기능 추가를 클릭하십시오.
4. 제품의 프로세스, 기능 및 결과를 설명하는 제품 수준 기능을 추가하십시오. 사용자는 제품 페이지 상단에서 버전이나 아키텍처 변형 차이와 관계없이 제품 전체에 적용되는 상위 수준의 제품 기능을 확인할 수 있습니다. 예를 들어, 제품이 가상 사설 클라우드(VPC)를 생성하는 경우, 기능 제목으로 를 추가하고 기능 Virtual Private Clouds are created for you with the necessary underlying network components. Creates Virtual Private Clouds 설명으로 를 추가할 수 있습니다. 특정 변형이나 버전에 대한 기능을 추가하려면 하이라이트를 추가하여 수행할 수 있습니다.
5. 업데이트 를 클릭하십시오.

콘솔을 통해 세부 사항 지정

사용자는 제품 카탈로그 항목의 일부로 정의한 버전 수준 정보를 확인합니다. 이 흐름의 일부로 제공되는 정보는 사용자가 해당 흐름과 연관된 개별 구성 요소의 기능을 이해하는 데 도움이 될 수 있습니다.

선택한 항목이 다음 릴리스로 이어지도록 하려면 매니페스트 파일을 생성할 수 있습니다. 매니페스트 파일은 카탈로그 항목의 진실의 근원입니다. ibm_catalog.json 이것은 귀하의 제품과 귀하가 선택한 모든 정보가 포함되어 있습니다. 파일을 생성한 후에는 반드시 소스 코드 저장소의 최상위 수준에 추가해야 합니다. 코드를 직접 수정하는 것을 선호한다면, 다음 섹션들은 매니페스트 파일을 통해 직접 구성할 수 있습니다. 파일 구조에 대한 자세한 내용은 '매니페스트 파일 로컬 편집'을 참조하십시오.

세부 사항에 들어가기

배포 가능한 아키텍처를 개인 카탈로그에 추가한 후에는 콘솔의 단계별 안내를 따라 제품의 일반 정보를 업데이트할 수 있습니다. 콘솔 페이지로 이동하려면 다음 단계를 따르십시오.

콘솔의 관리 > 카탈로그 > 개인 카탈로그 페이지로 이동하십시오.
제품을 추가한 비공개 카탈로그를 선택하세요. 카탈로그 상세 페이지가 열립니다.
이전에 등록한 제품을 선택하십시오.
버전 탭에서 정보를 제공하려는 제품 버전을 선택하십시오.
배포 가능한 아키텍처 세부 사항을 구성할 때 다음 정보를 가이드로 활용하십시오.

버전 정보 구성

구성 버전 탭에서 아키텍처의 특정 버전에 대한 정보를 검토하고 업데이트할 수 있습니다. 배포 세부 사항을 구성하고, 필요한 IAM 접근 권한을 정의하며, 사용자에게 알리고자 하는 변경 사항에 대한 안내를 상세히 기술합니다.

배포 가능한 아키텍처를 확장하려면 다른 아키텍처와 함께 스태킹하여 수행할 수 있습니다. 아키텍처에 필요한 종속성을 포함할 수 있으며, 특정 사용 사례를 위해 솔루션을 확장하는 데 도움이 되는 선택적 아키텍처도 포함할 수 있습니다. 자세한 내용은 온보딩 중 배포 가능한 아키텍처 확장하기를 참조하십시오.

배포 가능한 아키텍처에 특정 Terraform 런타임 버전이 필요한 경우 기본 버전을 재정의할 수 있습니다. 소스 코드 저장소 내에 입력 변수로 를 TF_VERSION 포함시켰다면, 카탈로그 항목을 생성할 때 자동으로 업데이트되었어야 합니다.

입력 변수는 사용자가 제품을 사용할 때 지정하는 매개변수입니다. 소스 코드와 함께 가져온 입력 및 출력 변수를 검토하고 수정할 수 있으며, 이 단계의 일환으로 배포 가능한 아키텍처에 변수를 추가할 수도 있습니다. 변수를 추가할 때, 해당 변수가 필수 항목인지, 표시되는지, 또는 제공되어야 하는 형식을 업데이트할 수 있습니다.

제품의 새 버전을 출시할 때, 사용자가 새 버전을 사용하기 전에 알려주고 싶은 변경 사항이 있을 수 있습니다. 정보를 세 가지 범주로 구분할 수 있습니다: 중대한 변경 사항, 신규 기능, 일반 업데이트입니다.

중대한 변경 사항: 이전 버전을 사용하는 사용자에게 방해가 될 수 있는 새 버전의 코드 변경 사항을 상세히 기술하십시오.
새로운 기능: 사용자가 활용할 수 있는 새 버전에 제공된 모든 새로운 기능을 강조합니다.
업데이트: 새 버전에 적용된 일반적인 업데이트 사항을 설명하십시오. 예를 들어, 버그 수정이나 기존 기능에 대한 개선 사항 등입니다.

서문 및 후기를 포함하여

배포 가능한 아키텍처에 대해 검증, 배포 및 배포 해제 전후에 사전 스크립트 또는 사후 스크립트를 실행할 수 있습니다. 스크립트는 카탈로그 매니페스트 파일에 명시된 배포 가능 아키텍처의 특정 버전에 맞춰 구성되며, 프로젝트를 통해 실행 및 검증되어야 합니다.

스크립트는 오퍼링에 선택적으로 포함될 수 있으나, 사용될 경우 저장소 내. scripts 라는 이름의 디렉터리에 반드시 포함되어야 합니다. 스크립트 파일 자체는 다음 명명 규칙을 준수해야 <action>-<stage>-ansible-playbook.yaml 합니다. 옵션으로는, validate, action 및 deploy 이 있습니다 undeploy. 옵션에는 및 stage 이 pre``post 포함됩니다. 현재 플레이북 형식의 Ansible 스크립트만 지원됩니다.

모든 스크립트는 실패 없이 여러 번 실행될 수 있어야 합니다. 예를 들어, 배포 전 또는 배포 후 스크립트는 여러 번 실행되더라도 올바르게 작동해야 합니다. 배포 후 스크립트는 카탈로그 관리 데이터베이스에 리소스를 추가할 수 있으며, 여러 번 실행될 경우 중복 리소스가 추가되지 않도록 반드시 확인해야 합니다.

예제를 포함한 자세한 내용은 배포 가능한 아키텍처를 위한 스크립트 생성을 참조하십시오.

배포 가능한 아키텍처 세부 사항 추가

클라우드에서 배포 가능한 아키텍처를 다른 사용자에게 제공할 때는 다음 정보를 반드시 제공해야 합니다:

배포 가능한 아키텍처 내 구성 요소들이 어떻게 함께 작동하는지 상세히 설명하는 아키텍처 다이어그램.
사용자가 자신의 요구에 가장 적합한 아키텍처 버전이나 변형을 구분하는 데 도움이 될 만한 주요 특징들.

라이센스 계약 추가

사용자가 IBM Cloud Services Agreement 이상의 라이센스 계약에 동의해야 하는 경우 각 계약에 대한 URL을 제공하십시오.

Readme 파일 편집

배포 가능한 아키텍처 설치 지침을 readme 파일에 문서화하십시오.

버전 검증

검증할 대상을 선택하십시오. 제품이 검증되면 리소스가 배포됩니다. 독립형 배포 가능 아키텍처의 경우, 대상은 현재 계정의 통합 개발 환경( Schematics ) 작업 공간이거나 특정 프로젝트일 수 있습니다. 배포 가능한 아키텍처 스택을 위해서는 프로젝트를 사용해야 합니다. 선택한 옵션에 따라 추가 구성 정보가 필요할 수 있습니다. 대상 시스템 구성이 완료된 후에는 아키텍처가 대상 시스템에 성공적으로 배포되기 위해 필요한 입력 및 출력 변수의 값을 제공해야 합니다. 변수를 구성한 후에는 버전을 검증할 수 있습니다.

보안 및 규정 준수 관리 섹션에서 규정 준수 평가를 실행한 후까지 계정의 리소스를 정리하지 마십시오.

버전이 CRA 스캔으로 인해 유효성 검사에 실패할 경우, 계정 관리자는 실패를 무시하고 배포를 강행할 수 있습니다. 검증에 실패하는 다른 사유가 있는 경우, 오퍼링을 게시하기 전에 발견된 문제를 반드시 수정할 것을 강력히 권장합니다.

비용 검토

아키텍처 배포와 관련된 비용을 완전히 이해하도록 하십시오. 예상 비용을 생성하기 전에 버전을 검증해야 합니다.

준수 관리

조직 내 다른 구성원에게 배포 가능한 아키텍처를 제공할 때, 기본 설치를 통해 아키텍처가 충족하는 특정 규정 준수 제어 항목을 지정할 수 있습니다. 규제 통제에 대한 준수 여부는 IBM Cloud® Security and Compliance Center Workload Protection 에서 평가합니다.

컨트롤 추가 를 클릭하십시오.
Workload Protection 인스턴스와 정책을 선택하십시오. 사전 정의된 정책을 선택하거나 Workload Protection 로 이동하여 직접 정책을 생성할 수 있습니다.
배포 가능한 아키텍처가 정책의 모든 통제 항목을 충족하는지, 아니면 통제 항목의 일부에 대한 요구 사항만 충족할 수 있는지 명시하십시오.
아키텍처가 제어 사항의 일부만 충족할 수 있다면, 충족 가능한 제어 사항을 선택하여 추가해야 합니다.
Workload Protection 를 사용하여 식별한 통제 항목에 대한 준수 여부를 확인하십시오. Workload Protection 은 재고 목록을 활용하여 준수 상태를 추적합니다. 재고 결과는 매일 업데이트됩니다. 아키텍처가 생성한 리소스를 배포하고, 인벤토리 결과가 업데이트될 때까지 기다리십시오. 자세한 내용을 확인하려면 ‘검토 및 시정 조치 우선순위 지정’으로 이동하십시오.
카탈로그 UI의 '규정 준수 관리' 탭에서 '결과 추가'를 클릭합니다.
인스턴스를 선택하고 적용을 클릭하여 최신 인벤토리 결과를 적용하십시오.

요구사항 검토

워크스루를 완료한 후에는 선택 사항을 검토하고 제품을 카탈로그에 공유할 준비가 되었는지 확인해야 합니다. 준비되면 '공유 준비'를 클릭하세요.

매니페스트 다운로드하기

콘솔을 통해 제품 구성을 변경할 때마다, 변경 사항이 향후 제품 릴리스에 반영되도록 매니페스트 파일을 생성하고 다운로드하는 것이 권장됩니다.

매니페스트를 다운로드하려면 다음 단계를 따르십시오.

콘솔의 관리 > 카탈로그 > 개인 카탈로그 페이지로 이동하십시오.
이전에 온보딩된 제품을 선택하십시오. 상세 정보 페이지가 열립니다.
버전 탭에서 속성 정의 파일을 생성할 버전을 선택하십시오.
'작업' 드롭다운 메뉴에서 '매니페스트 생성'을 선택합니다.
소스 코드 저장소의 루트 폴더에 파일을. ibm_catalog.json 로 추가하십시오.

카탈로그 구성 다운로드

프로젝트에서 스택형 배포 가능 아키텍처를 온보딩하는 경우, 매니페스트 파일 외에도 추가 파일이 생성됩니다. 콘솔을 사용하여 카탈로그 구성을 업데이트한 경우, 변경 사항이 다음 릴리스로 이어지도록 파일을 다운로드하여 소스 코드 저장소에 추가하는 것이 권장되는 방법입니다.

콘솔의 관리 > 카탈로그 > 개인 카탈로그 페이지로 이동하십시오.
이전에 온보딩된 제품을 선택하십시오. 상세 정보 페이지가 열립니다.
버전 탭에서 속성 정의 파일을 생성할 버전을 선택하십시오.
'작업' 드롭다운 메뉴에서 '매니페스트 생성'을 선택합니다.
소스 코드 저장소의 루트 폴더에 파일을 추가하십시오.

변형 추가

기본 배포 가능 아키텍처의 기능을 기반으로 설계된 아키텍처의 새 버전인 더 많은 변형을 추가할 수 있습니다. 소스 저장소의 별도 작업 디렉터리에서 여러 변형을 생성하고 매니페스트 ibm_catalog.json 파일의 flavors 배열에 이를 명시했다면, 각 변형을 개별적으로 온보딩해야 합니다.

이 시점에서, 당신은 이미 첫 번째 변형을 온보딩했습니다. 이제 다음 변형을 온보딩하기 위해 배포 가능한 아키텍처를 추가하는 단계로 돌아갈 수 있습니다. 다음 변형을 온보딩하는 데 도움이 될 몇 가지 팁입니다:

리포지토리 릴리스의 소스( URL )는 해당 릴리스 내 모든 변형에 대해 동일하며, 동일한 버전 번호로 가져와야 합니다. 제품명과 버전 번호는 변형 제품들을 서로 연결하는 기준이 되며, 이를 통해 동일한 카탈로그 타일 상에 옵션으로 표시됩니다.
배포 가능 아키텍처 세부 정보 추가 페이지의 3단계에는 하이라이트 추가가 포함됩니다. 이것들은 매니페스트 ibm_catalog.json 파일에서 기능(feature)으로 알려져 있습니다. 이미 매니페스트에 추가했을 수도 있으니, 여기서 다시 확인해 보세요. 그렇지 않다면, 하이라이트를 추가하세요. 이것들은 이 특정 아키텍처의 짧은 능력, 프로세스, 용량 또는 기타 특징이어야 합니다. 모든 변형에 동일한 하이라이트 "이름"을 사용합니다. 설명 부분에 차이가 있어야 합니다. 이를 통해 사용자는 카탈로그 상세 페이지의 텍스트 하이라이트를 활용하여 아키텍처 간의 차이점을 평가할 수 있습니다.

다음 단계: 공유 및 게시

이제 배포 가능한 아키텍처가 개인 카탈로그에 추가되고 세부 사항이 설정되었으므로, 해당 제품을 조직의 다른 구성원과 공유할 준비가 되었습니다. 공유에 관한 도움말은 '제품 공유하기 '를 참조하십시오.

배포 가능한 아키텍처를 IBM Cloud 카탈로그에 게시하려면 파트너 센터를 통해 승인을 받고 게시하여 모든 사용자가 구축한 솔루션을 활용할 수 있도록 할 수 있습니다. 자세한 내용은 배포 가능한 아키텍처 게시를 참조하십시오.