작성할 컴포넌트의 종류를 결정하는 방법은 무엇입니까?

모듈을 만들지, 배포 가능한 아키텍처를 만들지, 배포 가능한 아키텍처를 함께 쌓을지 어떻게 결정하나요? 차이점을 비교하고 다음 섹션의 유스 케이스를 평가하여 결정하는 데 도움을 줍니다.

배포 가능한 아키텍처와 모듈 비교하기

다음 표에서는 모듈과 배치 가능한 아키텍처 유형 간의 주요 차이점에 대한 비교 및 빠른 요약을 제공합니다.

개념 비교
메소드 범위 커플링(coupling) 배치 가능 작성자
모듈 작성 좁음 가까움 아니오 개발자
배포 가능한 아키텍처 만들기 중간에서 넓음 가까움 예 개발자
스택 배치 가능 아키텍처 광범위 느슨한 예 모든 사용자

다음 표는 사용 사례에 따라 모듈, 배포 가능한 아키텍처 또는 스택 배포 가능한 아키텍처를 함께 사용할지 여부를 결정하는 데 도움이 될 수 있습니다.

사용할 컴포넌트를 선택하도록 도와주세요
용도 권장 방법 참고
코딩 자동화 가속화 모듈 사용 모듈은 재사용 가능하고 큐레이트된 자동화를 제공하여 배치 가능한 아키텍처의 개발자가 더 빠르게 코딩할 수 있도록 합니다. 모듈은 이용자가 아닌 개발자용입니다.
클라우드가 안전하고 규정을 준수하는지 확인 배포 가능한 아키텍처 사용 배치 가능한 아키텍처는 아키텍처에 대한 보안 및 준수를 적용합니다. 배치 가능한 아키텍처의 범위가 너무 작으면 준수를 강제 실행할 수 없습니다. 예를 들어, 가상 서버 인스턴스만 배치하는 배치 가능한 아키텍처는 네트워크 보안을 보장할 수 없습니다.
가드레일을 사용하여 사용자에게 선택사항 제공 배포 가능한 아키텍처를 함께 쌓기 배포 가능한 아키텍처를 스태킹하여 배포 가능한 아키텍처를 교체하거나 배포 가능한 아키텍처를 추가하여 사용자에게 더 많은 선택권을 제공할 수 있습니다. 배치 가능한 아키텍처는 보안 및 준수를 적용하므로 스태킹은 전체 솔루션이 준수 상태를 유지하도록 보장하는 데 도움이 됩니다. 배포 가능한 아키텍처를 스태킹하는 것은 사용할 데이터베이스 선택과 같은 작업에 탁월한 접근 방식입니다.
사용자 작성 솔루션 또는 아키텍처 배포 가능한 아키텍처를 함께 쌓기 스태킹 배포 가능한 아키텍처를 사용하면 안전하고 규정을 준수하는 배포 가능한 아키텍처로 구성되므로 사용자는 반복 가능한 자신만의 패턴을 만들어 게시할 수 있습니다.
분리된 아키텍처 컴포넌트 배포 가능한 아키텍처를 함께 쌓기 배포 가능한 아키텍처는 독립적으로 개발 및 버전 관리할 수 있지만, 배포를 위해 함께 쌓을 수도 있습니다.
단순화된 사용자 경험 배포 가능한 아키텍처 사용 배치 가능한 아키텍처는 크거나 복잡한 아키텍처의 경우에도 사용자에게 작거나 단순한 입력 목록을 제공할 수 있습니다. 배치 가능한 아키텍처는 이해하고 배치하기가 간단합니다. 이에 비해 배치 가능한 아키텍처를 스태킹하는 것은 배치 가능한 아키텍처가 노출될 때 약간 더 복잡합니다.

IBM Cloud 프로젝트 는 리소스가 카탈로그에서 배치 가능한 아키텍처를 통해 배치되고 조직의 보안 및 준수 가드레일 내에서 작동하는지 확인합니다. 또한 이러한 자원이 최신 상태로 유지되고 변경되지 않도록 합니다.

배포 가능한 아키텍처에 대한 종속성

배포 가능한 하나의 아키텍처에서 프로비저닝된 리소스가 다른 아키텍처에서 필요할 때 종속성이 발생합니다. 즉, 다음 이미지에 설명된 것처럼 하나의 배포 가능한 아키텍처가 프로비저닝하는 리소스는 다른 아키텍처를 배포하는 동안 사용됩니다.

종속성이 있는 배포 가능한 아키텍처의 시각적 표현입니다. 배포 가능한 아키텍처 A는 배포 가능한 아키텍처 B의 입력으로 사용되는 리소스를 출력합니다.
배포 가능한 아키텍처 종속성

종속성으로 작업하는 한 가지 방법은 배포 가능한 아키텍처를 스택하고 프로젝트에서 아키텍처 간에 참조를 추가하는 것입니다. 예를 들어, VSI on VPC landing zone VPC landing zone 배포 가능 아키텍처의 Red Hat OpenShift 컨테이너 플랫폼을 확장하는 변형이 포함되어 있습니다. 이러한 아키텍처를 프로젝트에 함께 스택하는 것을 고려해보세요. 이 접근 방식은 필수 구성 요소 아키텍처가 아직 배포되지 않은 경우에 적합합니다. 또한 배포 가능한 아키텍처를 스택하기 위해 코드를 편집할 필요가 없습니다.

배포 가능한 아키텍처 중 다수는 독립형이며 다른 아키텍처의 확장이 아니지만 배포 가능한 아키텍처 중 일부를 확장하도록 선택할 수 있습니다. 건축학 카탈로그 세부정보 페이지의 섹션입니다. 다음에서 옵션을 선택하세요. 이 아키텍처를 어떻게 구축하고 싶나요? 메뉴.

그러나 이미 배포한 경우 Red Hat OpenShift Container Platform과 VSI를 배포해야 하는 경우 VSI에 필요한 리소스가 이미 프로비저닝되어 있습니다. 배포할 필요가 없습니다. Red Hat OpenShift 컨테이너 플랫폼 아키텍처를 다시 살펴보겠습니다. VSI 아키텍처는 VSI 아키텍처의 확장이므로 Red Hat OpenShift 컨테이너 플랫폼에서는 VSI를 배포할 수 있으며 아키텍처는 Red Hat OpenShift 필요에 따라 컨테이너 플랫폼.

옵션 및 교체 가능한 배포 가능한 아키텍처

배포 가능한 아키텍처를 비공개 카탈로그에 온보딩하면 다른 아키텍처와 스택을 쌓아 확장할 수 있습니다. 이렇게 하면 사용자를 위해 더욱 맞춤화된 솔루션을 만들 수 있습니다.

온보딩 중에 스택을 쌓는 이유는 무엇인가요?
온보딩 중 아키텍처를 쌓는 것은 프로젝트에서 아키텍처를 쌓는 것과 유사합니다. 아키텍처를 온보딩할 때 필요한 아키텍처를 함께 스택하여 종속성을 포함할 수 있습니다. 그러나 프로젝트에서 아키텍처를 스태킹하는 것과 달리 온보딩 중 아키텍처를 스태킹하는 데는 다음과 같은 기능이 포함됩니다:
  • 다양한 사용 사례에 맞는 아키텍처를 옵션으로 추가할 수 있습니다.
  • 사용자가 선택할 수 있는 스왑 가능한 아키텍처를 추가할 수 있습니다.
선택적 아키텍처
배포 가능한 다른 아키텍처와 잘 작동하지만 종속성을 충족하거나 규정 준수를 충족하는 데 필요하지 않은 아키텍처가 있을 수 있습니다. 배포 가능한 아키텍처를 선택 사항으로 추가할 수 있으며, 사용자는 프로젝트에 배포 가능한 아키텍처를 추가할 때 이를 포함하도록 선택할 수 있습니다. 예를 들어 모니터링 아키텍처는 유용하지만 필수는 아닐 수 있습니다.
스왑 가능한 아키텍처
온보딩 중에 스택한 모든 아키텍처는 다른 아키텍처와 스왑할 수 있습니다. 스왑 가능한 아키텍처를 통해 사용자는 동일한 기능을 제공하는 여러 옵션 중에서 선택할 수 있습니다. 예를 들어 서로 다른 데이터베이스를 생성하는 두 개의 배포 가능한 아키텍처를 포함할 수 있으며, 사용자는 아키텍처에 어떤 데이터베이스 옵션을 사용할지 결정할 수 있습니다.

자세한 내용은 온보딩 중 배포 가능한 아키텍처 확장하기를 참조하세요.

배포 가능한 아키텍처를 비공개 카탈로그에 온보딩할 때 옵션 및 스왑 가능한 아키텍처를 추가할 수 있습니다. 현재 프로젝트에서 배포 가능한 아키텍처 스택은 옵션 또는 스왑 가능한 아키텍처를 지원하지 않습니다.

Terraform대 Ansible

IBM Cloud에서 배치 가능한 아키텍처는 Terraform을 사용하여 Ansible 에 시스템이 읽을 수 있는 인터페이스 정의가 없으므로 배치 가능한 아키텍처 (인터페이스) 의 입력 및 출력을 선언해야 합니다. 그렇지 않으면 배치 가능한 아키텍처의 작성자가 Ansible 사전 또는 사후 스크립트 및 Terraform의 조합을 사용하여 배치 가능한 아키텍처의 작업을 실행할 수 있습니다. 개발자가 사용할 기술과 사용할 기술을 결정하는 방법은 무엇입니까?

구성 언어 비교
첫 번째 열은 테라폼과 Ansible 비교하는 데 사용되는 카테고리입니다. 두 번째 열은 Terraform이 열 1의 세트 카테고리와 관련되는 방법에 대한 정보를 제공하고 세 번째 열은 Ansible 이 열 1의 세트 카테고리와 관련되는 방법에 대한 정보를 제공합니다.
Terraform Ansible
언어 선언 절차적
구문 HCL (JSON과 유사) YAML (및 다른 스크립트에 대한 콜아웃)
기본 접근 방식 변경 가능한 인프라 불변 인프라
초점 지정 인프라 구성
드리프트 원하는 상태와 비교 멱등원 태스크

Terraform은 인프라를 작성하고 관리하는 데 탁월한 반면, Ansible 은 해당 인프라에서 실행 중인 소프트웨어 및 운영 체제를 구성하는 데 탁월합니다. Ansible 은 프로시저이므로 일회성 조작을 스크립팅할 수도 있습니다. 백업에서 복원하는 것과 같은 유지보수 태스크는 Ansible에서 쉽습니다.

사용할 구성 언어를 선택하도록 도와주세요
용도 권장 구성 언어 참고
클라우드 인프라 또는 서비스 배치 Terraform Terraform은 이 유스 케이스를 대상으로 하며 변화하는 인프라를 처리하는 데 더 효과적입니다. IBM Cloud 은 Terraform 모듈 및 지원되는 배치 가능한 아키텍처를 제공하여 보안 및 준수 인프라 패턴을 가속화합니다. Terraform 상태 모델을 사용하면 개발자가 변경사항을 미리 볼 수 있습니다. 이러한 변경사항은 준수를 위해 스캔할 수 있습니다.
소프트웨어 설치 또는 구성 Ansible 사전 빌드된 컨테이너 또는 가상 머신 이미지가 유스 케이스에 적합하지 않은 경우 Ansible 은 소프트웨어 설치 및 구성을 처리하는 데 더 적합합니다. Ansible 은 구성 편집, 패키지 관리 및 프로세스 다시 시작과 같은 자동화된 조작을 광범위하게 지원합니다. Ansible 모듈 및 플레이북의 대형 라이브러리를 사용하여 일반적으로 사용되는 수천 개의 소프트웨어 패키지를 쉽게 구성할 수 있습니다.
CCDB 통합 Ansible CCDB와 같은 온프레미스 서비스에 대한 동적 호출은 Terraform 또는 Ansible 에서 수행할 수 있지만 프로시저 또는 스크립팅 언어로 수행하기가 더 쉽습니다.
입력 유효성 검증 Terraform 또는 Ansible Terraform은 입력 유효성 검증을 수행하는 기능이 제한되어 있지만 선언적이며 사용자 인터페이스에서 사용할 수 있습니다. Ansible 은 배치 가능한 아키텍처에 대한 입력이 원격 서비스에 대해 검사되는 동적 입력 유효성 검증을 수행하는 기능을 추가합니다.
2일째 유지보수 조치 Ansible 2일째 유지보수는 일반적으로 절차적이며 Ansible에서 가장 잘 완료되었습니다. 예로는 수동 백업, 복원 또는 키 순환이 있습니다.
드리프트 관리
  • 테라폼
  • Ansible
  • Terraform을 사용하여 드리프트가 발생했는지 여부 및 드리프트가 무엇인지 판별할 수 있습니다. 이는 드리프트를 관리하는 방법을 결정하는 데 도움이 될 수 있습니다. 드리프트 정보는 자동화에 변경사항을 추가할 수 있음을 표시할 수 있으므로 강력합니다.
  • Ansible 이 드리프트를 발견할 수 없습니다. 그러나 정기적으로 멱등원 ansible 스크립트를 다시 적용하여 드리프트를 방지할 수 있습니다.

배치 가능한 아키텍처에 사전 또는 사후 스크립트 포함에 대한 자세한 정보는 배치 가능한 아키텍처에 대한 스크립트 작성 을 참조하십시오.

다음 단계: 공개할 위치 결정

아키텍처를 계획하고 작성할 컴포넌트 유형을 결정한 후에는 다른 사용자가 사용자가 작성하는 솔루션을 이용할 수 있도록 솔루션을 공유하거나 공개할 위치를 고려 해야 합니다. 공유 또는 공개하려는 위치에 따라 완료할 요구사항 또는 승인 레벨이 다를 수 있습니다.