작업공간 사용 계획
다음 질문을 프롬프트로 사용하여 작업공간을 계획하고 디자인하십시오.
- 작업공간을 Git 저장소와 관련시키는 방법
- 내 애플리케이션 환경에 필요한 작업공간 수는 몇 개입니까?
- 환경과 작업 공간에 걸쳐 Terraform 구성 파일을 재사용하려면 어떻게 해야 합니까?
- 작업 공간에 대한 접근을 통제하고 관리하는 방법은 무엇입니까?
작업공간 및 Git 저장소
작업 공간은 GitHub
, GitLab
, Bitbucket
, Azure DevOps 와 같은 개인 또는 공용 Git 저장소의 Terraform 템플릿을 사용합니다. 다음 표에서는 저장소 소스의 형식을 제공합니다.
Git 저장소 | URL |
---|---|
GitHub |
https://github.com/<your_user_name>/<repo_name>/tree/<branch_name>/<folder_name> |
GitLab |
https://gitlab.com/<your_user_name>/<project_name>/tree/<branch_name>/<folder_name> |
Bitbucket |
https://bitbucket.org/<your_user_name>/<repo_name>/src/<branch_name>/<folder_name> https://<username>@bitbucket.org/<workspace_name>/tf_cloudless_sleepy/src/master |
Azure DevOps |
https://azure.com/<your_user_name>/<repo_name>/src/<branch_name>/<folder_name> https://visualstudio.com/<your_user_name>/<repo_name>/src/<branch_name>/<folder_name> |
내 애플리케이션 환경에 필요한 작업공간 수는 몇 개입니까?
IBM Cloud Schematics 에 필요한 작업공간의 수는 애플리케이션 또는 마이크로서비스를 개발, 테스트 및 공개하는 데 필요한 환경 및 애플리케이션의 구조에 따라 결정됩니다.
경험상, 마이크로서비스와 사용하는 환경별로 별도의 작업 공간을 고려하는 것이 좋습니다. 예를 들어, 검색, 결제, 리뷰 마이크로서비스 구성 요소로 이루어진 제품 앱이 있는 경우, 각 마이크로서비스 구성 요소와 개발, 스테이징, 프로덕션 환경을 위한 별도의 작업 공간을 만드는 것을 고려해 보십시오. 구성 요소와 환경별로 작업 공간을 분리하면 다른 구성 요소에 영향을 주지 않고 Terraform 구성 파일과 관련 클라우드 자원을 개발, 배포, 업데이트할 수 있습니다.
세 개의 마이크로서비스로 구성된 앱에 대한 작업공간 구조 IBM Cloud Schematics 을 관찰하여 다음 이미지를 검토하십시오.

인프라 책임이 여러 팀에 분산되어 있는 조직에서는 하나의 작업공간을 사용하여 전체 스테이징 또는 프로덕션 환경을 관리하지 않는 것이 좋습니다. 단일 작업공간을 사용하여 모든 클라우드 자원을 배치하면, 다양한 팀이 업데이트를 조정하고 이러한 자원에 대한 액세스를 관리하기가 어려워질 수 있습니다. 원격 상태 데이터 소스를 사용하여 인프라 정의를 공유하는 별도의 작업공간은 별도의 책임 영역을 작성하는 메커니즘을 제공합니다.
Git 저장소를 구성하여 작업 공간을 매핑하는 방법은 무엇입니까?
Git 저장소를 구조화하여 마이크로 서비스를 구축하는 모든 Terraform 구성 파일에 대해 하나의 저장소를 확보하고, Schematics 또는 GitHub 브랜치 또는 디렉토리에서 입력 변수를 사용하여 개발, 스테이징 및 프로덕션 환경을 구분합니다.
Git 저장소를 구조화하여 여러 작업공간 환경을 맵핑하는 방법에 대한 옵션의 목록을 찾으려면 다음 표를 검토하십시오.
옵션 | 설명 |
---|---|
하나의 Git 저장소, 변수를 사용하여 환경 구별 | 마이크로서비스 컴포넌트를 구성하는 Terraform 구성 파일을 저장하는 하나의 Git 저장소를 작성합니다. 여러 환경에서 동일한 구성을 재사용할 수 있도록 Terraform 구성 파일을 가능한 일반적으로 작성하십시오. 개발, 스테이징 및 프로덕션 환경의 고유 정보를 구성하려면 구성 파일에서 Terraform 입력 변수를 사용하십시오. 작업공간을 작성할 때 입력 변수가 자동으로 IBM Cloud Schematics에 로드됩니다. 작업공간을 사용자 정의하려면 변수에 환경 특정 값을 입력합니다. 이 설정은 마이크로서비스 컴포넌트의 라이프사이클을 관리하는 하나의 팀이 있고 환경의 구성이 크게 다르지 않은 경우에 유용합니다. |
하나의 Git 저장소, 분기를 사용하여 환경 구별 | 마이크로서비스 컴포넌트에 대한 하나의 Git 저장소를 작성하고 여러 Git 분기를 사용하여 각 환경에 대한 Terraform 구성 파일을 저장합니다. 이 설정을 사용하면 환경을 명확히 구별하고 특정 구성에 액세스하여 변경할 수 있는 사용자에 대한 제어를 더 강화할 수 있습니다. 각 환경에서 서로 다른 구성을 사용하지 않도록 한 구성 파일의 변경사항이 분기 간에 채워지는 방법을 설정해야 합니다. |
하나의 Git 저장소, 디렉토리를 사용하여 환경 구별 | 일시적인 분기를 선호하고 구성이 환경마다 크게 다른 조직의 경우 환경의 여러 구성을 나타내는 디렉토리를 작성하는 것을 고려하십시오. 이 설정을 사용하면 모든 디렉토리가 master 분기에 커미트된 변경사항을 청취합니다. 각 환경에서 서로 다른 구성을 사용하지 않도록 한 구성 파일의 변경사항이 디렉토리 간에 채워지는 방법을 설정해야 합니다. |
환경당 하나의 Git 저장소 사용 | 각 환경마다 하나의 Git 저장소를 사용합니다. 이 설정을 통해 작업공간과 Git 저장소 간에 1:1 관계가 이루어지며 각 Git 저장소에 대해 별도의 권한을 적용할 수 있습니다. 팀이 다중 Git 저장소를 관리하고 동기화된 상태로 유지할 수 있는지 확인하십시오. |
환경 및 작업공간에서 구성 파일을 재사용할 수 있는 방법
표준화된 Terraform 템플릿을 만들고 필요에 따라 템플릿 사용을 맞춤화하기 위해 변수를 사용함으로써 관리해야 하는 Terraform 구성 파일의 수를 최소화하십시오.
이제 IBM Cloud용 Terraform 모듈 레지스트리에서 Terraform 모듈을 사용할 수 있습니다.
표준화된 Terraform 템플리트 또는 Terraform 모듈을 사용하면, 조직 내에서 개발 우수 사례를 따르고 모든 Terraform 구성 파일의 구조를 동일하게 할 수 있습니다. Terraform 구성 파일의 구조를 알면 개발자가 더 쉽게 파일을 이해하고, 변수를 선언하고, 코드에 컨트리뷰션하고, 오류를 해결할 수 있습니다.
작업공간에 대한 액세스를 제어하는 방법
IBM Cloud Schematics은(는) IBM Cloud® Identity and Access Management과(와) 완전히 통합됩니다. 작업공간에 대한 액세스와 IBM Cloud Schematics로 인프라 코드를 실행할 수 있는 사용자를 제어하려면 사용자 액세스 관리를 참조하십시오.
이전에 Terraform 독립형에서 사용된 저장소가 있는 경우 알아야 할 사항은 무엇입니까?
IBM Cloud Schematics 이 서비스형 Terraform을 제공하기 때문에, 작업 공간과 함께 기존의 Terraform 템플릿을 재사용할 수 있습니다. Terraform 템플리트가 작성되고 Git 저장소가 구조화되는 방법에 따라 IBM Cloud Schematics을 성공적으로 사용하도록 변경해야 할 수 있습니다.
- 제공자 블록 선언: IBM Cloud Schematics이(가) IBM Cloud® Identity and Access Management과(와) 통합되기 때문에 IBM Cloud API 키는 모든 IAM 사용 가능 리소스에 대해 자동으로 검색되며
provider
블록에 이 정보를 제공할 필요가 없습니다. 그러나 클래식 인프라 리소스에 대해서는 API 키가 검색되지 않습니다. 자세한 정보는provider
블록 구성을 참조하십시오. - Terraform 명령행 및 IBM Cloud 제공자 플러그인: IBM Cloud Schematics을(를) 사용하려면 Terraform 명령행 또는 IBM Cloud Provider Plug-in for Terraform을(를) 설치하지 않아도 됩니다. 리소스 프로비저닝을 자동화하려면 IBM Cloud Schematics 명령행 플러그인을 대신 사용해 보십시오.
작업공간의 지속적 딜리버리 도구 체인 설정
Terraform 구성 파일을 업데이트할 때마다 자동으로 Terraform 실행 플랜을 생성하고 IBM Cloud에서 Terraform 코드를 실행하려면 소스 저장소를 IBM Cloud의 지속적 딜리버리 파이프라인에 연결하십시오.
- 계정에 Continuous Delivery 서비스 인스턴스가 아직 없는 경우 이를 작성하십시오.
- IBM Cloud 카탈로그에서 Continuous Delivery 서비스를 여십시오.
- 서비스를 작성하려는 IBM Cloud 지역을 선택하십시오.
- 가격 플랜을 선택하십시오.
- 서비스 인스턴스의 이름을 입력하고 리소스 그룹을 선택한 후 서비스 인스턴스와 연관시킬 태그를 입력하십시오.
- 작성을 클릭하여 계정에 서비스 인스턴스를 작성하십시오.
- 작업 공간 대시보드 에서 작업 공간을 선택합니다.
- 설정 탭을 선택하십시오.
- 요약 섹션에서 지속적 딜리버리 사용을 클릭하십시오.
- 도구 체인을 구성하십시오.
- 도구 체인의 이름을 입력하고 이 도구 체인을 배치할 지역 및 리소스 그룹을 선택하십시오. 지역 및 리소스 그룹은 Schematics 작업공간에 사용한 지역 및 리소스 그룹과 다를 수 있습니다.
- Terraform 구성 파일이 저장된 소스 저장소의 유형을 선택하십시오 (예: GitHub).
- 소스 저장소에 대한 정보를 검토하십시오. 예를 들어, Terraform 파일이 GitHub에 저장된 경우 GitHub 서버 및 지속적 딜리버리 도구 체인을 작성할 저장소를 검토하십시오. 이러한 필드는 작업공간 구성을 기반으로 미리 채워집니다.
- 선택사항: 도구 체인에 대한 Git 문제 및 코드 변경 추적을 사용으로 설정할지 여부를 선택하십시오.
- Delivery Pipeline을 구성하려면 Delivery Pipeline 아이콘을 선택하십시오.
- 표시되는 작업공간 ID가 올바른지 확인하십시오.
- IBM Cloud API 키를 입력하십시오. API 키가 없는 경우 **새로 작성 +**을 클릭하여 작성하십시오.
- 작성을 클릭하여 도구 체인 설정을 완료하십시오. 도구 체인에 대해 구성된 도구의 개요가 표시됩니다.
- Delivery Pipeline을 여십시오. Delivery Pipeline에는 소스 저장소에서 업데이트 검색, Terraform 실행 플랜 작성, 이 플랜 적용 및 작업공간에 대한 상태 검사 실행 단계가 포함됩니다.
- 소스 저장소의 Terraform 파일을 업데이트하고 이 변경사항이 Delivery Pipeline에서 처리되는 방식을 검토하십시오. 단계 중 하나가 실패하는 경우 로그 및 히스토리 보기를 클릭하여 오류 문제점 해결을 시작하십시오. 로그와 기록을 보는 방법에 대한 자세한 내용은 작업 세부 사항 검토(Schematics)를 참조하십시오.