프로젝트 구성 및 관리를 위한 우수 사례
이러한 모범 사례는 IBM Cloud® 에서 성공적이고 안전한 프로젝트를리소스와 인프라스트럭처를 코드 배포로 정의하고 관리하는 아티팩트 모음입니다. 관리하기 위한 기본 구성 요소를 제공합니다. 프로젝트는 코드 기반 배치를 최상으로 관리하는 동시에 규정 준수를 유지하고 계정 전체에서 팀 구성원과 협업하는 방법으로 규제된 엔터프라이즈에 유용합니다.
기본 프로젝트 계정 작성
IBM Cloud 프로젝트의 주요 이점은 Infrastructure as Code 배치를 중앙에서 관리하고 협업하는 기능입니다. 엔터프라이즈를 사용하는 경우 모든 프로젝트를 저장하기 위해 기본 또는 홈 계정을 설정하면 한 위치에서 프로젝트를 관리하고 추적하는 데 도움이 됩니다.
기본 계정 설정의 유용성은 엔터프라이즈 구조에 따라 다릅니다. 프로젝트는 계정에서 작성할 수 있으며 자원을 다른 계정에 배치할 수 있습니다. 사용자는 현재 로그인한 계정 내에 있는 프로젝트만 볼 수 있습니다. 또한 동일한 계정 내의 프로젝트에 대해서만 여러 프로젝트에 대한 보고서를 생성할 수 있습니다. 이는 엔터프라이즈의 모든 프로젝트 또는 유사한 비즈니스 라인이 있는 모든 프로젝트에 대해 공통 홈 계정을 설정하는 또 다른 유용한 이점입니다. 프로젝트를 기본 계정으로 유지하고 각 환경 (개발, 테스트 및 프로덕션) 에 대한 별도의 계정으로 배치하여 엔터프라이즈 관리를 단순화합니다.
모든 사용자가 계정 내에서 목적 및 프로젝트를 쉽게 식별할 수 있도록 계정에 사람이 읽을 수 있는 이름을 지정하십시오. 예를 들어, Front-end UI team 및 Back-end API team 입니다.
인증 메소드 정의
배치 가능한 아키텍처를 구성할 때 인증 방법을 추가해야 합니다. 인증 방법은 리소스가 배포되는 대상 계정을 식별하고 배포를 승인합니다. 신뢰할 수 있는 프로파일 또는 기존 시크릿을 통해 인증하도록 선택할 수 있습니다.
신뢰할 수 있는 프로파일 사용
일부 서비스는 신뢰할 수 있는 프로파일을 사용하여 아키텍처를 완전히 구성하고 배치할 수 없습니다. 자세한 정보는 프로젝트에 대해 알려진 문제 및 제한사항 을 참조하십시오.
신뢰할 수 있는 프로파일을 사용하여 자신의 계정 또는 다른 계정에 아키텍처를 배치할 수 있습니다. 조직에 따라 아키텍처를 배치하려면 신뢰할 수 있는 프로파일을 사용하고 여러 계정의 관리자와 조정하여 다른 계정에 대한 액세스가 필요할 수 있습니다. 다른 계정의 IBM Cloud 프로젝트 서비스에서 아키텍처를 배치하기 위해 사용자 계정에 액세스해야 하는 경우 신뢰할 수 있는 프로파일 및 서비스 ID를 사용하여 계정의 배치에 권한을 부여하십시오. 프로젝트의 신뢰할 수 있는 프로파일 작성에 대한 자세한 정보는 신뢰할 수 있는 프로파일을 사용하여 프로젝트에 아키텍처 배치 권한 부여 를 참조하십시오.
IBM Cloud® Secrets Manager 사용
인프라를 코드로 배포할 때( IaC ) API 키, SSH 키, SSL 인증서 등 인프라를 구성하는 데 필요한 비밀이 있는 경우가 많습니다. 이러한 경우 이러한 비밀을 인스턴스 내에 저장하는 것이 좋습니다 Secrets Manager 인스턴스 내에 저장하는 것이 좋습니다. 프로젝트는 배포 가능한 아키텍처의 입력으로 Secrets Manager 에 저장된 API 키 참조를 직접 지원합니다. 자세한 내용은 Secrets Manager 에서 API 키를 사용하여 프로젝트 배포를 승인하는 방법을 참조하세요.
프로젝트 생성 전에, 해당 계정 내 모든 프로젝트에서 사용할 수 있는 기본 프로젝트 계정에 ' Secrets Manager ' 서비스 인스턴스를 생성하십시오.
작성할 수 있는 몇 가지 다른 시크릿 유형이 있습니다. 임의의 시크릿 인스턴스를 사용하여 프로젝트에 대한 API키를 저장하십시오. 자세한 정보는 UI에서 임의의 시크릿 작성 을 참조하십시오.
일반적으로 단일 Secrets Manager 인스턴스가 계정의 모든 프로젝트에 사용됩니다. 해당 인스턴스의 시크릿은 액세스 제한사항에 맞는 시크릿 그룹으로 구성될 수 있습니다. 예를 들어, 프로젝트별로 또는 관련 프로젝트 세트에 대해 시크릿 그룹을 사용할 수 있습니다.
환경을 사용하여 배치 제어
프로젝트 내에서 환경을 사용하여 관련 구성을 함께 그룹화할 수 있습니다. 환경에는 입력 값 및 인증 세부 정보와 같은 속성도 포함될 수 있습니다. 이러한 특성은 환경을 선택할 때 구성에 자동으로 추가되며, 이는 대상 계정에 대한 정확한 배치를 보장하는 데 도움이 됩니다. 구성을 편집할 때 세부사항 정의 섹션에서 사용할 구성에 대한 환경을 선택할 수 있습니다.
환경 사용의 이점
환경을 사용하면 배치를 더 쉽게 제어할 수 있습니다. 환경을 지정하고 특성을 추가하여 해당 환경을 사용하는 구성에서 동일한 값이 공유됨을 알 수 있습니다. 구성 내에서 환경이 자동으로 제공하는 모든 값을 재정의할 수 있습니다.
환경은 프로젝트 내에서 관련 구성을 함께 그룹화하는 방법을 제공합니다. 개발 계정과 동일한 대상 계정에 배치할 구성 세트가 있다고 가정합니다. 개발 환경을 작성하고 대상 계정에 대한 인증 세부사항을 해당 환경에 추가할 수 있습니다. 인증 메소드는 개발 환경을 사용하는 각 구성에 추가됩니다.
원하는 수의 환경을 작성할 수 있지만 프로젝트의 환경 수를 낮게 유지하는 것이 좋습니다. 계정 전체에서 배치에 표준 환경 세트를 사용하면 아키텍처를 더 쉽게 구성하고 배치할 수 있습니다.
자세한 정보는 환경 작성 을 참조하십시오.
구성 구성
모든 관련 구성을 단일 프로젝트로 구성하는 것을 고려하십시오. 이러한 방식으로 한 위치에서 배치를 관리하고 안전하고 준수하는지 확인할 수 있습니다. 이는 필요한 인프라를 작성하기 위해 하나 이상의 배치 가능한 아키텍처로 구성될 수 있으며, 개발, 테스트 및 프로덕션과 같은 여러 지역 및 환경을 지원하기 위해 복제해야 합니다.
사용자가 각 구성의 기능을 이해할 수 있도록 구성에 대한 이름 지정 규칙을 사용하십시오. 예를 들어, VPC Base 배치 가능 아키텍처 및 VPC Base에 의존하는 Kubernetes 클러스터 배치 가능 아키텍처를 사용하는 배치에서 구성 이름을 다음과 같이 지정할 수 있습니다.
| 이름 | 배치 가능 아키텍처 | 환경 | 참고 |
|---|---|---|---|
| Dev-VPC-글로벌 | VPC 기본 | 개발 | 개발 환경에 대한 기본 VPC 작성 |
| Dev-Kub-댈러스 | Kubernetes 클러스터 | 개발 | 개발을 위해 댈러스에서 클러스터 작성 |
| 데브-쿠브-런던 | Kubernetes 클러스터 | 개발 | 개발을 위해 런던에서 클러스터 작성 |
| Prod-VPC-글로벌 | VPC 기본 | 프로덕션 | 프로덕션 환경에 대한 기본 VPC 작성 |
| 프로덕션-Kub-댈러스 | Kubernetes 클러스터 | 프로덕션 | 프로덕션을 위해 댈러스에서 클러스터 작성 |
| 프로덕션-Kub-런던 | Kubernetes 클러스터 | 프로덕션 | 프로덕션을 위해 런던에서 클러스터 작성 |
| 프로덕션-Kub-도쿄 | Kubernetes 클러스터 | 프로덕션 | 프로덕션을 위해 Tokyo에서 클러스터 작성 |
| 프로덕션-Kub-시드니 | Kubernetes 클러스터 | 프로덕션 | 프로덕션을 위해 시드니에서 클러스터 작성 |
project.json 파일에서 개발 구성을 복제하고 필요에 따라 수정하여 테스트된 개발 배치에서 프로덕션 배치를 빠르게 작성할 수 있습니다.
프로젝트에 대한 액세스 그룹 작성
프로젝트에 대한 액세스는 Identity and Access Management (IAM)에서 제어합니다. 프로젝트당 두 개 또는 세 개의 액세스 그룹을 작성하고 프로젝트에 대해 작업하는 사용자를 해당 액세스 그룹 중 하나에 지정하는 것이 좋습니다. 예를 들어* 프로젝트 이름*- 비용이나 가용성을 모니터링해야 하는 사용자에게 프로젝트에 대한 읽기 전용 액세스를 제공하는 독자 액세스 그룹* 프로젝트 이름*-프로젝트를 변경하고 리소스를 배포해야 하는 운영 사용자를 위한 작성자 액세스 그룹입니다. 필요한 경우 두 개의 작성자 액세스 그룹을 작성할 수 있습니다. 하나는 구성을 추가하고 입력 값을 완료할 수 있는 사용자를 위한 것이고 다른 하나는 자원을 배치할 수 있는 사용자를 위한 것입니다.
| 액세스 그룹 | 역할 |
|---|---|
| 프로젝트 이름-리더 | 독자, 뷰어 |
| 프로젝트 이름-작가 | 관리자, 운영자 |
새 프로젝트를 작성하려면 사용자에게 특정 액세스 권한을 지정해야 합니다. 자세한 정보는 프로젝트에 대한 사용자 액세스 지정 을 참조하십시오.
모니터링에 주의 항목이 필요함
주의 필요 항목은 유효성 검증, 승인, 실패 및 버전 업데이트를 모니터하는 데 가장 잘 사용됩니다. 정기적으로 필요한 주의 항목을 확인하여 프로젝트 및 구성이 최신 상태이고 준수하는지 확인할 수 있습니다.
프로젝트에서 생성된 리소스 배포 취소
구성을 배치할 때 작성된 자원을 프로젝트 내에서 그룹으로 관리할 수 있습니다. 이러한 리소스는 Terraform 플랜을 기반으로 작성되며 Schematics 작업공간에서 개별적으로 관리할 수 있습니다.
Schematics 작업공간에서 개별 리소스를 영구 삭제할 수 있지만, 프로젝트를 사용하여 작성되는 리소스에 대해서는 이를 수행하지 않는 것이 좋습니다. 이 경우 드리프트가 발생하기 때문입니다. 대신, 한 번의 클릭으로 프로젝트 UI에서 구성과 연결된 모든 리소스를 한 번에 배포 취소할 수 있습니다. 이렇게 하면 구성이 배치된 대상 환경에서 배치가 제거됩니다. 나중에 구성을 다시 배포해야 하는 경우 구성을 삭제하지 않고 리소스 배포를 취소하는 것이 도움이 될 수 있습니다.
기본적으로 프로젝트 또는 구성을 삭제하면 배포된 모든 리소스가 자동으로 배포 취소됩니다. 이 설정을 사용으로 유지하는 것이 좋지만 프로젝트를 열고 관리 > 설정으로 이동하여 사용 안함으로 설정할 수 있습니다. 이 설정을 사용 안함으로 설정하면 구성 또는 프로젝트를 삭제할 때 자원이 배치된 상태로 유지되지만 프로젝트 내에서 해당 자원을 쉽게 관리할 수 있는 기능이 유실됩니다. 배치된 자원은 프로젝트 또는 구성이 삭제된 후에도 사용 가능한 상태로 남아 있는 경우 대상 계정에 대한 비용을 계속 발생시킬 수 있습니다. 자세한 내용은 다음을 참조하세요.리소스 배포 취소.