기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# S3를 사용하여 conda 채널 생성
작업이 [https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue-environment.html#conda-queue-environment](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue-environment.html#conda-queue-environment) 또는 [https://conda-forge.org/](https://conda-forge.org/) 채널에서 사용할 수 없는 애플리케이션을 실행해야 하는 경우 사용자 지정 conda 채널을 호스팅하여 자체 패키지를 제공할 수 있습니다. AWS Deadline Cloud(Deadline Cloud) 콘솔에서 대기열을 생성하면 콘솔은 기본적으로 conda 대기열 환경을 추가합니다. 패키지를 작업에 사용할 수 있도록 하려면 대기열 환경에 사용자 지정 채널을 추가합니다.
conda 채널은 파일 시스템 또는 Amazon Simple Storage Service(Amazon S3) 버킷을 포함하여 [다양한 방식으로](https://rattler-build.prefix.dev/latest/publish/) 호스팅할 수 있는 정적 호스팅 콘텐츠입니다. Deadline Cloud 팜이 자산에 공유 파일 시스템을 사용하는 경우 해당 팜의 모든 경로를 채널 이름으로 사용할 수 있습니다. AWS Identity and Access Management (IAM) 권한을 사용하여 더 광범위한 액세스를 위해 Amazon S3 버킷에서 채널을 호스팅할 수 있습니다.
[로컬에서 패키지를 빌드하고 테스트](build-test-packages-locally.md)한 다음 [채널에 게시할 수 있습니다](publish-packages-s3-channel.md). 로컬에서 패키지를 빌드하면 인프라 설정 없이 패키지 빌드 레시피에서 반복을 쉽게 시작할 수 있습니다. Deadline Cloud [패키지 빌드 대기열](automate-package-builds.md)을 사용하여 패키지를 빌드하고 채널에 게시할 수도 있습니다. 패키지 빌드 대기열은 여러 운영 체제 및 액셀러레이터 구성에 대한 패키지 유지 관리를 간소화합니다. 어디에서나 버전을 업데이트하고 패키지 빌드의 전체 세트를 제출할 수 있습니다.
스튜디오 및 Deadline Cloud 팜에 대한 채널을 여러 가지 방법으로 구성할 수 있습니다. 하나의 Amazon S3 채널을 사용하고 이를 사용하도록 모든 워크스테이션과 팜 호스트를 구성할 수 있습니다. 채널이 두 개 이상 있고 AWS DataSync (DataSync)를 사용하여 미러링을 설정할 수도 있습니다. 예를 들어 Deadline Cloud 패키지 빌드 대기열은 워크스테이션 및 온프레미스 팜 호스트를 위해 온프레미스에서 미러링되는 Amazon S3 채널에 게시할 수 있습니다.
**Topics**
+ [로컬에서 패키지 빌드 및 테스트](build-test-packages-locally.md)
+ [Amazon S3 conda 채널에 패키지 게시](publish-packages-s3-channel.md)
+ [사용자 지정 conda 패키지에 대한 프로덕션 대기열 권한 구성](#s3-channel-configure-permissions)
+ [대기열 환경에 conda 채널 추가](#s3-channel-add-channel)
+ [애플리케이션 또는 플러그인에 대한 conda 패키지 생성](conda-package.md)
+ [에 대한 conda 빌드 레시피 생성 Blender](create-conda-recipe-blender.md)
+ [에 대한 conda 빌드 레시피 생성 Autodesk Maya](create-conda-recipe-maya.md)
+ [Autodesk Maya to Arnold (MtoA) 플러그인용 conda 빌드 레시피 생성](create-conda-recipe-mtoa-plugin.md)
+ [Deadline Cloud를 사용하여 패키지 빌드 자동화](automate-package-builds.md)
# 로컬에서 패키지 빌드 및 테스트
Amazon S3에 패키지를 게시하거나 Deadline Cloud 팜에서 CI/CD 자동화를 설정하기 전에 로컬 파일 시스템 채널을 사용하여 워크스테이션에서 conda 패키지를 빌드하고 테스트할 수 있습니다. 이 접근 방식을 사용하면 레시피를 로컬에서 빠르게 반복하고 패키지를 확인할 수 있습니다.
`rattler-build publish` 명령은 레시피를 빌드하고, 결과 패키지를 채널에 복사하고, 한 번에 채널을 인덱싱합니다. 로컬 파일 시스템 디렉터리를 대상으로 지정하면 디렉터리가 없는 경우에서 자동으로 채널을 `rattler-build` 생성하고 초기화합니다.
다음 지침은 Blender의 [Deadline Cloud 샘플 리포지토리의 4.5 샘플](https://github.com/aws-deadline/deadline-cloud-samples) 레시피를 사용합니다GitHub. 샘플 리포지토리에서 다른 레시피를 대체하거나 자체 레시피를 사용할 수 있습니다.
## 사전 조건
시작하기 전에 워크스테이션에 다음 도구를 설치합니다.
+ **pixi** - 패키지를 설치하고 테스트`rattler-build`하는 데 사용하는 패키지 관리자입니다. [pixi.sh](https://pixi.sh) pixi를 설치합니다.
+ **래틀러 빌드 -** Deadline Cloud conda 레시피에서 사용하는 패키지 빌드 도구입니다. pixi를 설치한 후 다음 명령을 실행하여를 설치합니다`rattler-build`.
```
pixi global install rattler-build
```
+ **git** - 샘플 리포지토리를 복제하는 데 필요합니다. 에서 용 Windowsgit는 일부 Windows 샘플 레시피에 필요한 `bash`쉘도 제공합니다. [https://gitforwindows.org/](https://gitforwindows.org/)
## 로컬 채널에 패키지 빌드 및 게시
이 절차에서는 Deadline Cloud 샘플 리포지토리를 복제하고 `rattler-build publish`를 사용하여 패키지를 빌드하고 로컬 파일 시스템 채널에 게시합니다.
**로컬 채널에 패키지를 빌드하고 게시하려면**
1. Deadline Cloud 샘플 리포지토리를 복제합니다.
```
git clone https://github.com/aws-deadline/deadline-cloud-samples.git
```
1. 디렉터리를 `conda_recipes`로 변경합니다.
```
cd deadline-cloud-samples/conda_recipes
```
1. 다음 명령을 실행하여 Blender 4.5 레시피를 빌드하고 패키지를 로컬 채널 디렉터리에 게시합니다.
Linux 및에서 다음 명령을 macOS실행합니다.
```
rattler-build publish blender-4.5/recipe/recipe.yaml \
--to file://$HOME/my-conda-channel
```
Windows (cmd)에서 다음 명령을 실행합니다.
```
rattler-build publish blender-4.5/recipe/recipe.yaml ^
--to file://%USERPROFILE%/my-conda-channel
```
`rattler-build publish` 명령은 다음 작업을 수행합니다.
+ 레시피에서 패키지를 빌드합니다.
+ 디렉터리가 없는 경우 채널 디렉터리를 생성합니다.
+ 패키지 파일을 채널에 복사합니다.
+ 패키지 관리자가 패키지를 찾을 수 있도록 채널을 인덱싱합니다.
패키지 레시피가 [conda-forge](https://conda-forge.org/)와 같은 특정 채널의 패키지에 의존하는 경우 명령에 `-c conda-forge`를 추가합니다.
레시피를 변경한 후 패키지를 다시 빌드하려면 `--build-number=+1`를 추가하여 빌드 번호를 자동으로 증가시킵니다.
```
rattler-build publish blender-4.5/recipe/recipe.yaml \
--to file://$HOME/my-conda-channel \
--build-number=+1
```
에 대한 자세한 내용은 [래틀러 빌드 게시 설명서를](https://rattler-build.prefix.dev/latest/publish/) `rattler-build publish`참조하세요.
## 빌드 디버깅
빌드에 실패하면는 사용자가 조사할 수 있도록 빌드 디렉터리를 `rattler-build` 보존합니다. 다음 명령을 실행하여 모든 환경 변수가 빌드 중에 설정된 상태로 빌드 환경에서 대화형 셸을 엽니다.
```
rattler-build debug shell
```
디버그 쉘에서 파일을 수정하고, 개별 빌드 명령을 실행하고, 종속성을 추가하여 문제를 격리할 수 있습니다. 자세한 내용은 래틀러 빌드 설명서의 빌드 [디버깅](https://rattler-build.prefix.dev/latest/debugging_builds/)을 참조하세요.
## 패키지 테스트
패키지를 빌드하고 게시한 후 임시 pixi 프로젝트를 생성합니다. 프로젝트를 사용하여 로컬 채널에서 패키지를 설치하고 올바르게 작동하는지 확인합니다.
**패키지를 테스트하려면**
1. 임시 테스트 디렉터리를 생성하고 로컬 채널로 pixi 프로젝트를 초기화합니다.
Linux 및에서 다음 명령을 macOS실행합니다.
```
mkdir package-test-env
cd package-test-env
pixi init --channel file://$HOME/my-conda-channel
```
Windows (cmd)에서 다음 명령을 실행합니다.
```
mkdir package-test-env
cd package-test-env
pixi init --channel file://%USERPROFILE%/my-conda-channel
```
1. 프로젝트에 패키지를 추가합니다.
```
pixi add blender=4.5
```
1. 패키지가 올바르게 작동하는지 확인합니다.
```
pixi run blender --version
```
패키지에 만족하면 Amazon S3 conda 채널에 패키지를 게시하여 Deadline Cloud 작업자가 패키지를 설치할 수 있도록 할 수 있습니다. [S3 conda 채널에 패키지 게시를](publish-packages-s3-channel.md) 참조하세요.
## 정리
테스트 후 테스트 프로젝트와 로컬 채널을 제거할 수 있습니다.
**테스트 리소스를 정리하려면**
1. 테스트 프로젝트 디렉터리를 제거합니다.
Linux 및에서 다음 명령을 macOS실행합니다.
```
rm -rf package-test-env
```
Windows (cmd)에서 다음 명령을 실행합니다.
```
rmdir /s /q package-test-env
```
1. 로컬 conda 채널 디렉터리를 제거합니다.
Linux 및에서 다음 명령을 macOS실행합니다.
```
rm -rf $HOME/my-conda-channel
```
Windows (cmd)에서 다음 명령을 실행합니다.
```
rmdir /s /q %USERPROFILE%\my-conda-channel
```
1. (선택 사항) 빌드된 패키지 파일이 포함된 `rattler-build` 출력 디렉터리를 제거합니다.
Linux 및에서 다음 명령을 macOS실행합니다.
```
rm -rf deadline-cloud-samples/conda_recipes/output
```
Windows (cmd)에서 다음 명령을 실행합니다.
```
rmdir /s /q deadline-cloud-samples\conda_recipes\output
```
# Amazon S3 conda 채널에 패키지 게시
Amazon Simple Storage Service(Amazon S3) 버킷에 conda 패키지를 게시하여 AWS Deadline Cloud(Deadline Cloud) 작업자가 실행 작업을 위해 설치할 수 있습니다. `rattler-build publish` 명령은 로컬 파일 시스템 채널과 동일한 방식으로 Amazon S3에서 작동합니다. 명령은 레시피를 빌드하고 결과를 게시하거나 이미 빌드한 패키지 파일을 게시할 수 있습니다. 두 경우 모두 명령은 버킷에 패키지를 업로드하고 한 번에 채널을 인덱싱합니다.
`rattler-build publish` 명령은 표준 자격 증명 체인을 AWS 사용하여를 인증하므로 모든 AWS 도구처럼 AWS 구성을 사용합니다. 자격 증명 구성에 대한 자세한 내용은 *AWS Command Line Interface (AWS CLI) 사용 설명서*의 [구성 및 자격 증명 파일 설정을](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) 참조하세요.
## 사전 조건
Amazon S3에 패키지를 게시하기 전에 다음 사전 조건을 완료합니다.
+ **pixi 및rattler-build** - [pixi.sh](https://pixi.sh) pixi를 설치한 다음를 설치합니다`rattler-build`.
```
pixi global install rattler-build
```
+ **git** - 샘플 리포지토리를 복제하는 데 필요합니다. 에서 용 Windowsgit는 일부 Windows 샘플 레시피에 필요한 `bash`쉘도 제공합니다. [https://gitforwindows.org/](https://gitforwindows.org/)
+ **Amazon S3 버킷** - conda 채널로 사용할 Amazon S3 버킷입니다. Deadline Cloud 팜에서 작업 연결 버킷을 사용하거나 별도의 버킷을 생성할 수 있습니다.
+ **AWS 자격 증명** - `aws configure` 명령 또는 `aws login` 명령을 사용하여 워크스테이션에서 자격 증명을 구성합니다. 자세한 내용은 *AWS Command Line Interface 사용 설명서*에서 [AWS CLI설정](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html)을 참조하세요.
+ **IAM 권한** - (선택 사항) 자격 증명의 권한 범위를 줄이려면 Amazon S3 버킷 및 사용하는 채널 접두사(예: )에 대해 다음 권한만 부여하는 (IAM) 정책을 사용할 AWS Identity and Access Management 수 있습니다. `/Conda/*`
+ `s3:GetObject`
+ `s3:PutObject`
+ `s3:DeleteObject`
+ `s3:ListBucket`
+ `s3:GetBucketLocation`
## Amazon S3 채널에 패키지 게시
`s3://` 대상과 `rattler-build publish` 함께를 사용하여 Amazon S3 conda 채널에 패키지를 게시합니다. 채널이 버킷에 없는 경우는 채널을 자동으로 `rattler-build` 초기화합니다. 시작하기 전에 [사전 조건을](#publish-s3-prereqs) 완료했는지 확인합니다.
다음 예제에서는 Blender의 [Deadline Cloud 샘플 리포지토리에서 4.5 샘플](https://github.com/aws-deadline/deadline-cloud-samples) 레시피를 게시합니다GitHub. 샘플 리포지토리에서 다른 레시피를 대체하거나 자체 레시피를 사용할 수 있습니다.
**Amazon S3 채널에 패키지를 게시하려면**
1. Deadline Cloud 샘플 리포지토리를 복제합니다.
```
git clone https://github.com/aws-deadline/deadline-cloud-samples.git
```
1. 디렉터리를 `conda_recipes`로 변경합니다.
```
cd deadline-cloud-samples/conda_recipes
```
1. 다음 명령을 실행합니다. *amzn-s3-demo-bucket*을 버킷 이름으로 바꿉니다.
Linux 및에서 다음 명령을 macOS실행합니다.
```
rattler-build publish blender-4.5/recipe/recipe.yaml \
--to s3://amzn-s3-demo-bucket/Conda/Default
```
Windows (cmd)에서 다음 명령을 실행합니다.
```
rattler-build publish blender-4.5/recipe/recipe.yaml ^
--to s3://amzn-s3-demo-bucket/Conda/Default
```
`/Conda/Default` 접두사는 버킷 내에서 채널을 구성합니다. 다른 접두사를 사용할 수 있지만 접두사는 채널을 참조하는 모든 명령 및 대기열 구성에서 일관되어야 합니다.
업데이트된 패키지를 다시 빌드하고 게시하려면 `--build-number=+1`를 추가하여 빌드 번호를 자동으로 증가시킵니다.
```
rattler-build publish blender-4.5/recipe/recipe.yaml \
--to s3://amzn-s3-demo-bucket/Conda/Default \
--build-number=+1
```
패키지 레시피가 [conda-forge](https://conda-forge.org/)와 같은 특정 채널의 패키지에 의존하는 경우 명령에 `-c conda-forge`를 추가합니다.
로컬 빌드의 파일과 같이 이미 빌드한 패키지 `.conda` 파일을 게시할 수도 있습니다. *amzn-s3-demo-bucket*을 버킷 이름으로 바꿉니다.
```
rattler-build publish output/linux-64/blender-4.5.0-hb0f4dca_0.conda \
--to s3://amzn-s3-demo-bucket/Conda/Default
```
## 패키지 테스트
패키지를 게시한 후 임시 pixi 프로젝트를 생성하여 패키지가 올바르게 작동하는지 확인합니다. 프로젝트는 Amazon S3 채널에서 패키지를 설치합니다.
**패키지를 테스트하려면**
1. 임시 테스트 디렉터리를 생성하고 Amazon S3 채널을 사용하여 pixi 프로젝트를 초기화합니다. *amzn-s3-demo-bucket*을 버킷 이름으로 바꿉니다.
```
mkdir package-test-env
cd package-test-env
pixi init --channel s3://amzn-s3-demo-bucket/Conda/Default
```
1. 프로젝트에 패키지를 추가합니다.
```
pixi add blender=4.5
```
1. 패키지가 올바르게 작동하는지 확인합니다.
```
pixi run blender --version
```
## 정리
테스트 후 테스트 프로젝트 디렉터리를 제거합니다.
**테스트 리소스를 정리하려면**
+ 테스트 프로젝트 디렉터리를 제거합니다.
Linux 및에서 다음 명령을 macOS실행합니다.
```
rm -rf package-test-env
```
Windows (cmd)에서 다음 명령을 실행합니다.
```
rmdir /s /q package-test-env
```
## 빌드 디버깅
빌드에 실패하면는 사용자가 조사할 수 있도록 빌드 디렉터리를 `rattler-build` 보존합니다. 다음 명령을 실행하여 모든 환경 변수가 빌드 중에 설정된 상태로 빌드 환경에서 대화형 셸을 엽니다.
```
rattler-build debug shell
```
디버그 쉘에서 파일을 수정하고, 개별 빌드 명령을 실행하고, 종속성을 추가하여 문제를 격리할 수 있습니다. 자세한 내용은 래틀러 빌드 설명서의 빌드 [디버깅](https://rattler-build.prefix.dev/latest/debugging_builds/)을 참조하세요.
## 다른 플랫폼을 위한 패키지 빌드
명령은 `rattler-build publish` 명령이 실행되는 워크스테이션의 운영 체제에 대한 패키지를 빌드합니다. Deadline Cloud 플릿이 워크스테이션과 다른 운영 체제를 사용하거나 패키지에 다른 호스트 요구 사항이 있는 경우 다음 옵션을 사용할 수 있습니다.
+ 대상 운영 체제와 일치하는 호스트`rattler-build publish`에서를 실행합니다. 예를 들어 실행 중인 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스Linux를 사용하여 Linux플릿에 대한 패키지를 빌드합니다.
+ Deadline Cloud 패키지 빌드 대기열을 사용하여 대상 플랫폼에서 빌드를 자동화합니다. [패키지 빌드 대기열 생성을 참조하세요](automate-package-builds.md#s3-channel-create-queue).
+ (고급) 교차 컴파일을 사용하여 워크스테이션과 다른 플랫폼용 패키지를 빌드합니다. 자세한 내용은 래틀러 빌드 설명서의 [교차 컴파일](https://rattler-build.prefix.dev/latest/compilers/#cross-compilation)을 참조하세요.
## 다음 단계
Amazon S3 conda 채널에 패키지를 게시한 후 채널을 사용하도록 Deadline Cloud 대기열을 구성합니다.
+ [사용자 지정 conda 패키지에 대한 프로덕션 대기열 권한 구성](configure-jobs-s3-channel.md#s3-channel-configure-permissions) - 프로덕션 대기열에 Amazon S3 conda 채널에 대한 읽기 전용 액세스 권한을 부여합니다.
+ [대기열 환경에 conda 채널 추가](configure-jobs-s3-channel.md#s3-channel-add-channel) - Amazon S3 conda 채널에서 패키지를 설치하도록 대기열 환경을 구성합니다.
## 사용자 지정 conda 패키지에 대한 프로덕션 대기열 권한 구성
프로덕션 대기열에는 대기열의 S3 버킷에 있는 `/Conda` 접두사에 대한 읽기 전용 권한이 필요합니다. 프로덕션 대기열과 연결된 역할의 AWS Identity and Access Management (IAM) 페이지를 열고 다음을 사용하여 정책을 수정합니다.
1. Deadline Cloud 콘솔을 열고 패키지 빌드 대기열의 대기열 세부 정보 페이지로 이동합니다.
1. 대기열 서비스 역할을 선택한 다음 **대기열 편집**을 선택합니다.
1. **대기열 서비스 역할** 섹션으로 스크롤한 다음 **IAM 콘솔에서이 역할 보기를** 선택합니다.
1. 권한 정책 목록에서 대기열에 대한 **AmazonDeadlineCloudQueuePolicy**를 선택합니다.
1. **권한** 탭에서 **편집**을 선택합니다.
1. 다음과 같이 대기열 서비스 역할에 새 섹션을 추가합니다. *amzn-s3-demo-bucket* 및 *111122223333*을 자체 버킷 및 계정으로 바꿉니다.
```
{
"Effect": "Allow",
"Sid": "CustomCondaChannelReadOnly",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/Conda/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "111122223333"
}
}
},
```
## 대기열 환경에 conda 채널 추가
S3 conda 채널을 사용하려면 Deadline Cloud에 제출하는 작업의 `CondaChannels` 파라미터에 `s3://amzn-s3-demo-bucket/Conda/Default` 채널 위치를 추가해야 합니다. Deadline Cloud와 함께 제공된 제출자는 사용자 지정 conda 채널 및 패키지를 지정하는 필드를 제공합니다.
프로덕션 대기열의 conda 대기열 환경을 편집하여 모든 작업을 수정하지 않아도 됩니다. 다음 절차를 수행하세요.
1. Deadline Cloud 콘솔을 열고 프로덕션 대기열의 대기열 세부 정보 페이지로 이동합니다.
1. 환경 탭을 선택합니다.
1. **Conda** 대기열 환경을 선택한 다음 **편집**을 선택합니다.
1. **JSON 편집기**를 선택한 다음 스크립트에서에 대한 파라미터 정의를 찾습니다`CondaChannels`.
1. 새로 생성된 S3 conda 채널로 시작`default: "deadline-cloud"`하도록 선을 편집합니다.
```
default: "s3://amzn-s3-demo-bucket/Conda/Default deadline-cloud"
```
서비스 관리형 플릿은 기본적으로 conda에 대한 유연한 채널 우선 순위를 활성화합니다. Blender 4.2가 새 채널과 `deadline-cloud` 채널 모두에 `blender=4.2` 있는지 요청하는 작업의 경우 채널 목록의 첫 번째 채널에서 패키지를 가져옵니다. 지정된 패키지 버전을 첫 번째 채널에서 찾을 수 없는 경우 패키지 버전에 대해 후속 채널이 확인됩니다.
고객 관리형 플릿의 경우 Deadline Cloud [샘플 리포지토리의 conda 대기열 환경 샘플 중 하나를 사용하여 conda](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/queue_environments/README.md) 패키지 사용을 활성화할 수 있습니다. GitHub
# 애플리케이션 또는 플러그인에 대한 conda 패키지 생성
conda 패키지는 모든 언어로 작성된 소프트웨어의 압축된 아카이브입니다. Conda는 다양한 운영 체제 및 아키텍처 조합을 지원하므로 Python 및 기타 언어용 라이브러리와 Nuke 함께 BlenderMaya, 및와 같은 전체 애플리케이션을 패키징할 수 있습니다. conda 패키지에 대한 자세한 내용은 conda 설명서의 [패키지를 참조하세요](https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/packages.html).
conda 패키지를 사용하려면 가상 환경에 설치합니다. conda 가상 환경에는 패키지가 설치된 *접두사 디렉터리*가 있습니다. 패키지를 설치하면 지원되는 경우 파일의 하드링크 또는 리링크가 사용되므로 동일한 패키지로 여러 환경을 생성해도 상당한 추가 디스크 공간이 사용되지 않습니다. 가상 환경을 사용하려면 가상 환경을 활성화하여 환경 변수를 설정합니다. 활성화는 패키지가 제공하는 스크립트를 실행하여 각 패키지에 PATH 또는 기타 환경 변수를 수정할 수 있는 기회를 제공합니다. Conda 패키지에는 일반적으로 애플리케이션 또는 라이브러리가 포함되어 있지만 유연한 활성화를 통해 공유 파일 시스템에 설치된 애플리케이션을 가리킬 수도 있습니다.
사용자 지정 패키지를 만들려면 세 단계가 필요합니다. *레시피*에는 빌드 지침이 포함되어 있고, *패키지*는 빌드된 아티팩트(`.conda` 또는 `.tar.bz2` 파일)이며, *채널*은 설치를 위해 패키지를 호스팅합니다. `rattler-build publish` 명령은 세 단계를 모두 처리합니다. 즉, 레시피를 패키지에 빌드하고 채널에 게시하거나 패키지 아티팩트를 직접 가져와 게시할 수 있습니다.
[conda-forge](https://conda-forge.org/) 커뮤니티는 광범위한 오픈 소스 소프트웨어용 패키지 레시피를 유지 관리하고 `conda-forge` 채널에서 패키지 아티팩트를 호스팅합니다. 를 패키지 소스`conda-forge`로 포함하도록 대기열을 구성한 다음 실행할 conda-forge 패키지에 의존하는 사용자 지정 패키지를 빌드할 수 있습니다. Linux의 경우 conda-forge는 일관된 컴파일 및 연결 옵션이 선택된 상태로 CUDA 지원을 포함한 전체 컴파일러 도구 체인을 호스팅합니다. conda-forge 패키지를 자체 레시피의 종속성으로 사용하거나 동일한 환경에서 사용자 지정 패키지와 함께 설치할 수 있습니다.
종속성을 포함한 전체 애플리케이션을 conda 패키지로 결합할 수 있습니다. Deadline Cloud가 서비스 관리형 플릿의 [ 기한 클라우드 채널](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue-environment.html#conda-queue-environment)에 제공하는 패키지는이 바이너리 재패키징 접근 방식을 사용합니다. 이렇게 하면 conda 가상 환경에 맞게 설치와 동일한 파일이 구성됩니다.
**참고**
대규모 애플리케이션은 소스 아카이브, 추출된 파일 및 빌드 출력을 위해 수십 GB의 여유 디스크 공간이 필요할 수 있습니다. 패키지 빌드 출력을 위해 사용 가능한 공간이 충분한 디스크를 사용해야 합니다.
## 애플리케이션 패키징
conda용 애플리케이션을 다시 패키징할 때는 다음 두 가지 목표가 있습니다.
+ 애플리케이션의 대부분의 파일은 기본 conda 가상 환경 구조와 분리되어야 합니다. 그런 다음 환경은 애플리케이션을 [conda-forge](https://conda-forge.org/)와 같은 다른 소스의 패키지와 혼합할 수 있습니다.
+ conda 가상 환경이 활성화되면 PATH 환경 변수에서 애플리케이션을 사용할 수 있어야 합니다.
**conda용 애플리케이션을 다시 패키징하려면**
1. 애플리케이션을와 같은 하위 디렉터리에 설치하는 conda 빌드 레시피를 작성합니다`$CONDA_PREFIX/opt/`. 이렇게 하면 `bin` 및와 같은 표준 접두사 디렉터리와 구분됩니다`lib`.
1. symlink 또는 시작 스크립트를 `$CONDA_PREFIX/bin`에 추가하여 애플리케이션 바이너리를 실행합니다.
또는 `conda activate` 명령이 실행할 activate.d 스크립트를 생성하여 PATH에 애플리케이션 바이너리 디렉터리를 추가합니다. 에서 symlink를 생성할 수 Windows있는 모든 환경에서 지원되지 않는 경우 애플리케이션 시작 또는 activate.d 스크립트를 대신 사용합니다.
1. 일부 애플리케이션은 Deadline Cloud 서비스 관리형 플릿에 기본적으로 설치되지 않은 라이브러리에 의존합니다. 예를 들어 X11 창 시스템은 일반적으로 비대화형 작업에 필요하지 않지만 일부 애플리케이션에서는 그래픽 인터페이스 없이 실행해야 합니다. 생성한 패키지 내에서 이러한 종속성을 제공해야 합니다.
1. 애플리케이션이 플러그인을 지원하는 경우 플러그인 패키지가 가상 환경의 애플리케이션과 통합되기 위해 따라야 하는 명확한 규칙을 제공합니다. 예를 들어 [Maya 2026년 샘플 레시피](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes/maya-2026#instructions-for-maya-plugin-packages)는 Maya 플러그인에 대한이 규칙을 문서화합니다.
1. 패키징하는 애플리케이션의 저작권 및 라이선스 계약을 준수해야 합니다. Conda 채널에 프라이빗 Amazon S3 버킷을 사용하여 배포를 제어하고 팜에 대한 패키지 액세스를 제한하는 것이 좋습니다.
`deadline-cloud` 채널의 패키지에 대한 샘플 레시피는의 [Deadline Cloud 샘플](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes#readme) 리포지토리에서 사용할 수 있습니다GitHub.
## 플러그인 패키징
애플리케이션 플러그인은 자체 conda 패키지로 패키징할 수 있습니다. 플러그인 패키지를 생성할 때 다음 지침을 따릅니다.
+ 빌드 레시피에 호스트 애플리케이션 패키지를 빌드 및 실행 종속성으로 포함합니다`recipe.yaml`. 빌드 레시피가 호환되는 패키지에만 설치되도록 버전 제약 조건을 사용합니다.
+ 플러그인 등록에 대한 호스트 애플리케이션 패키지 규칙을 따릅니다.
## 어댑터 패키지
일부 Deadline Cloud 애플리케이션 통합은 애플리케이션 인터페이스를 확장하여 [작업 템플릿 작성](building-jobs.md)을 간소화하는 *어댑터*를 사용합니다. 어댑터는 백그라운드 데몬 실행, 상태 보고, 경로 매핑 적용을 지원하는 명령줄 인터페이스입니다. 자세한 내용은의 [Open Job Description Adaptor 런타임](https://github.com/OpenJobDescription/openjd-adaptor-runtime-for-python#readme)을 참조하세요GitHub. 예를 들어의 [deadline-cloud-for-maya](https://github.com/aws-deadline/deadline-cloud-for-maya/)GitHub에는 통합 작업 제출 GUI와 서비스 관리형 플릿에서 `maya-openjd` 패키지로 사용할 수 있는 Maya 어댑터가 포함되어 있습니다.
Deadline Cloud 제출자 GUIs의 작업 제출에는 작업을 실행하기 위한 가상 환경에 포함할 conda 패키지를 지정하는 `CondaPackages` 파라미터 값이 포함됩니다. 의 `CondaPackages` 파라미터 값은 Maya 일반적으로과 같`maya=2025.* maya-openjd=0.15.* maya-mtoa`으며 플러그인 패키지에 대한 대체 항목을 포함할 수 있습니다. 대기열 환경에서 작업 실행을 위한 conda 가상 환경을 설정하면 이러한 패키지 이름과 버전 제약 조건이 호환되도록 확인되고 실행해야 하는 모든 종속성 패키지가 추가됩니다. 각 어댑터 및 플러그인 패키지는의 버전, Python의 Maya버전 및 기타 종속성을 포함하여 호환되는 항목을 지정합니다.
의 [maya-openjd 레시피](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes/maya-openjd)와 같은 샘플을 사용하여 자체 어댑터 패키지를 빌드하려면 [conda-forge](https://conda-forge.org/)에서 제공하는 Python 및 기타 종속성을 위한 패키지를 기반으로 빌드GitHub할 수 있습니다. 종속성을 충족하려면 먼저 [기한](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes/deadline)과 [openjd-adaptor-runtime](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes/openjd-adaptor-runtime) 레시피를 빌드해야 할 수 있습니다.
# 에 대한 conda 빌드 레시피 생성 Blender
다양한 애플리케이션을 사용하여 conda 빌드 레시피를 생성할 수 있습니다. Blender는 무료로 사용할 수 있으며 conda로 간단하게 패키징할 수 있습니다. Blender Foundation은 여러 운영 체제에 대한 [ 애플리케이션 아카이브를](https://download.blender.org/release/Blender4.2/) 제공합니다. Windows .zip 및 Linux .tar.xz 파일을 사용하는 샘플 conda 빌드 레시피를 만들었습니다. 이 단원에서는 [Blender 4.2 conda 빌드 레시피](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes/blender-4.2)를 사용하는 방법을 알아봅니다.
[ deadline-cloud.yaml](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes/blender-4.2) 파일은 패키지 작업을 Deadline Cloud에 제출하기 위한 conda 플랫폼 및 기타 메타데이터를 지정합니다. 이 레시피에는 작동 방식을 보여주는 로컬 소스 아카이브 정보가 포함되어 있습니다. linux-64 conda 플랫폼은 가장 일반적인 구성과 일치하도록 기본 작업 제출에서 빌드되도록 설정됩니다. deadline-cloud.yaml은 다음과 비슷합니다.
```
condaPlatforms:
- platform: linux-64
defaultSubmit: true
sourceArchiveFilename: blender-4.2.1-linux-x64.tar.xz
sourceDownloadInstructions: 'Run "curl -LO https://download.blender.org/release/Blender4.2/blender-4.2.1-linux-x64.tar.xz"'
- platform: win-64
defaultSubmit: false
sourceArchiveFilename: blender-4.2.1-windows-x64.zip
sourceDownloadInstructions: 'Run "curl -LO https://download.blender.org/release/Blender4.2/blender-4.2.1-windows-x64.zip"'
```
`recipe` 디렉터리의 파일을 검토합니다. 레시피의 메타데이터는 [ 레시피/recipe.yaml](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes/blender-4.2/recipe/recipe.yaml)에 있습니다. conda build [meta.yaml](https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html) 설명서를 읽고 파일이 YAML을 생성하는 템플릿인 방법과 같은 자세한 내용을 알아볼 수도 있습니다. 템플릿은 버전 번호를 한 번만 지정하고 운영 체제에 따라 다른 값을 제공하는 데 사용됩니다.
에서 선택한 빌드 옵션을 검토하여 다양한 이진 재배치 및 동적 공유 객체(DSO) 연결 검사를 `meta.yaml` 끌 수 있습니다. 이러한 옵션은 임의의 디렉터리 접두사에서 conda 가상 환경에 패키지를 설치할 때 패키지가 작동하는 방식을 제어합니다. 기본값은 모든 종속성 라이브러리를 별도의 패키지로 패키징하는 것을 단순화하지만 애플리케이션을 바이너리로 다시 패키징할 때는 변경해야 합니다.
패키징하는 애플리케이션에 추가 종속성 라이브러리가 필요하거나 애플리케이션용 플러그인을 별도로 패키징하는 경우 DSO 오류가 발생할 수 있습니다. 이러한 오류는 종속성이 필요한 실행 파일 또는 라이브러리의 라이브러리 검색 경로에 없을 때 발생합니다. 애플리케이션에는 시스템에 설치할 `/usr/lib`때 `/lib` 또는와 같이 전역적으로 정의된 경로에 있는 라이브러리가 사용됩니다. 그러나 conda 가상 환경은 어디에나 배치할 수 있으므로 사용할 절대 경로는 없습니다. Conda는 Linux 및가 모두 macOS 지원하는 상대적 RPATH 기능을 사용하여 이를 처리합니다. 자세한 내용은 [ 패키지 재배치에 대한 conda 빌드 설명서를](https://docs.conda.io/projects/conda-build/en/latest/resources/make-relocatable.html) 참조하세요.
Blender 애플리케이션 아카이브는 이를 염두에 두고 빌드되었으므로 에서는 RPATH 조정이 필요하지 않습니다. 이를 필요로 하는 애플리케이션의 경우 Conda 빌드와 동일한 도구인 `patchelf` Linux 및 `install_name_tool`를 사용할 수 있습니다macOS.
패키지 빌드 중에 [build.sh](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes/blender-4.2/recipe/build.sh) 또는 [build\$1win.sh](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes/blender-4.2/recipe/build_win.sh)(에서 호출`bld.bat`) 스크립트가 실행되어 패키지 종속성으로 준비된 환경에 파일을 설치합니다. 이러한 스크립트는 설치 파일을 복사하고,에서 symlink를 생성하고`$PREFIX/bin`, 활성화 스크립트를 설정합니다. 에서는 symlink를 생성Windows하지 않고 대신 활성화 스크립트의 PATH에 Blender 디렉터리를 추가합니다.
conda 빌드 레시피의 Windows 부분에는 `cmd.exe` .bat 파일 `bash` 대신를 사용합니다. 이렇게 하면 빌드 스크립트 전반에서 일관성이 향상되기 때문입니다. 에서 사용에 대한 팁은 워크로드 이동성에 대한 [ Deadline Cloud 개발자 안내서의](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/what-is-a-deadline-cloud-workload.html#workload-portability) 권장 사항을 참조`bash`하세요Windows. 용 [git를 Windows](https://gitforwindows.org/) 설치하여 [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/) git 리포지토리를 복제한 경우 이미에 액세스할 수 있습니다`bash`.
[ conda 빌드 환경 변수](https://docs.conda.io/projects/conda-build/en/latest/user-guide/environment-variables.html) 설명서에는 빌드 스크립트에서 사용할 수 있는 값이 나열되어 있습니다. 이러한 값에는 소스 아카이브 데이터의 `$SRC_DIR` 경우 , 설치 디렉터리의 `$PREFIX` 경우 , 레시피의 다른 파일에 액세스하는 `$RECIPE_DIR` 경우 `$PKG_NAME` , `$PKG_VERSION` 패키지 이름 및 버전, 대상 conda 플랫폼의 `$target_platform` 경우가 포함됩니다.
## Blender 4.2 패키지 작업 제출
Blender 아카이브를 다운로드한 다음 패키지 빌드 대기열에 작업을 제출하여 작업을 렌더링하는 자체 Blender 4.2 conda 패키지를 빌드할 수 있습니다. 대기열은 연결된 플릿으로 작업을 전송하여 패키지를 빌드하고 conda 채널을 다시 인덱싱합니다.
이 지침은 bash 호환 쉘의 git을 사용하여 [Deadline Cloud 샘플 GitHub리포지토리](https://github.com/aws-deadline/deadline-cloud-samples)에서 OpenJD 패키지 빌드 작업과 일부 conda 레시피를 가져옵니다. 또한 다음 항목이 필요합니다.
+ 를 사용하는 경우 Windowsgit을 설치할 때 bash, git BASH 버전이 설치됩니다.
+ [Deadline Cloud CLI](https://github.com/aws-deadline/deadline-cloud)가 설치되어 있어야 합니다.
+ [Deadline Cloud 모니터](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/working-with-deadline-monitor.html)에 로그인해야 합니다.
1. 다음 명령을 사용하여 Deadline Cloud 구성 GUI를 열고 기본 팜과 대기열을 패키지 빌드 대기열로 설정합니다.
```
deadline config gui
```
1. 다음 명령을 사용하여 Deadline Cloud 샘플 GitHUb리포지토리를 복제합니다.
```
git clone https://github.com/aws-deadline/deadline-cloud-samples.git
```
1. `conda_recipes` 디렉터리의 `deadline-cloud-samples` 디렉터리로 변경합니다.
```
cd deadline-cloud-samples/conda_recipes
```
1. 라는 스크립트를 실행합니다`submit-package-job`. 스크립트는 스크립트Blender를 처음 실행할 때 다운로드하는 지침을 제공합니다.
```
./submit-package-job blender-4.2/
```
1. 다운로드 지침을 따릅니다Blender. 아카이브가 있으면 `submit-package-job` 스크립트를 다시 실행합니다.
```
./submit-package-job blender-4.2/
```
작업을 제출한 후 Deadline Cloud 모니터를 사용하여 실행 중인 작업의 진행 상황과 상태를 확인합니다.
모니터의 왼쪽 하단에는 작업의 두 단계가 표시되어 패키지를 빌드한 다음 다시 인덱싱합니다. 오른쪽 하단에는 각 작업의 개별 단계가 표시됩니다. 이 예제에서는 각 작업에 대해 한 단계가 있습니다.
![\[Blender 패키지를 빌드하는 작업의 진행 상황과 상태를 보여주는 Deadline Cloud 모니터입니다.\]](http://docs.aws.amazon.com/ko_kr/deadline-cloud/latest/developerguide/images/Conda-Figure3.png)
모니터 왼쪽 하단에는 작업의 두 단계, 즉 패키지를 빌드한 다음 conda 채널을 다시 인덱싱하는 단계가 있습니다. 오른쪽 하단에는 각 단계의 개별 작업이 있습니다. 이 예제에서는 각 단계에 대해 하나의 작업만 있습니다.
패키지 빌드 단계의 작업을 마우스 오른쪽 버튼으로 클릭하고 **로그 보기를** 선택하면 모니터에 작업자가 작업을 예약하는 방법을 보여주는 세션 작업 목록이 표시됩니다. 작업은 다음과 같습니다.
+ **첨부 파일 동기화** -이 작업은 작업 첨부 파일 시스템에 사용되는 설정에 따라 입력 작업 첨부 파일을 복사하거나 가상 파일 시스템을 탑재합니다.
+ **Conda 시작** -이 작업은 대기열을 생성할 때 기본적으로 추가된 대기열 환경에서 발생합니다. 작업은 conda 패키지를 지정하지 않으므로 빠르게 완료되고 conda 가상 환경을 생성하지 않습니다.
+ **CondaBuild Env 시작** -이 작업은 conda 패키지를 빌드하고 채널을 다시 인덱싱하는 데 필요한 소프트웨어가 포함된 사용자 지정 conda 가상 환경을 생성합니다. [conda-forge](https://conda-forge.org/) 채널에서 설치합니다.
+ **작업 실행** -이 작업은 Blender 패키지를 빌드하고 결과를 Amazon S3에 업로드합니다.
작업이 실행되면 Amazon CloudWatch에 구조화된 형식으로 로그를 전송합니다. 작업이 완료되면 **모든 작업에 대한 로그 보기를** 선택하여 작업이 실행되는 환경의 설정 및 해제에 대한 추가 로그를 확인합니다.
# 4.2 Blender 렌더 작업으로 패키지 테스트
Blender 4.2 패키지를 빌드하고 S3 conda 채널을 사용하도록 프로덕션 대기열을 구성한 후 패키지를 사용하여 렌더링할 작업을 제출할 수 있습니다. Blender 장면이 없는 경우 [Blender 데모 파일](https://www.blender.org/download/demo-files) 페이지에서 Blender 3.5 - 코지 키친 장면을 다운로드합니다.
이전에 다운로드한 Deadline Cloud 샘플 GitHub리포지토리에는 다음 명령을 사용하여 Blender 장면을 렌더링하는 샘플 작업이 포함되어 있습니다.
```
deadline bundle submit blender_render \
-p CondaPackages=blender=4.2 \
-p BlenderSceneFile=/path/to/downloaded/blender-3.5-splash.blend \
-p Frames=1
```
Deadline Cloud 모니터를 사용하여 작업 진행 상황을 추적할 수 있습니다.
1. 모니터에서 제출한 작업의 작업을 선택한 다음 옵션을 선택하여 로그를 봅니다.
1. 로그 보기의 오른쪽에서 **Conda 세션 시작** 작업을 선택합니다.
작업이 대기열 환경에 대해 구성된 두 개의 conda 채널에서 Blender 4.2를 검색했고 S3 채널에서 패키지를 찾았음을 확인할 수 있습니다.
# 에 대한 conda 빌드 레시피 생성 Autodesk Maya
상용 애플리케이션을 conda 패키지로 패키징할 수 있습니다. [ 용 conda 빌드 레시피 생성Blender](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/conda-package.html#create-conda-recipe-blender)에서 간단한 재배치 가능 아카이브 파일로 사용할 수 있는 애플리케이션을 오픈 소스 라이선스 조건에 따라 패키징하는 방법을 배웠습니다. 상용 애플리케이션은 설치 관리자를 통해 배포되는 경우가 많으며 사용할 라이선스 관리 시스템이 있을 수 있습니다.
다음 목록은 상용 [ 애플리케이션 패키징과 일반적으로 관련된 요구 사항이 있는 애플리케이션 또는 플러그인용 conda 패키지 생성](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/conda-package.html)에서 다루는 기본 사항을 기반으로 합니다. 하위 글머리표의 세부 정보는 지침을에 적용하는 방법을 보여줍니다Maya.
+ 애플리케이션의 라이선스 권한 및 제한을 이해합니다. 라이선스 관리 시스템을 구성해야 할 수 있습니다. 애플리케이션에 적용이 포함되지 않은 경우 권한에 따라 팜을 구성해야 합니다.
+ [Autodesk Cloud Rights에 대한 구독 혜택 FAQ](https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Subscription-Benefits-FAQ-Cloud-Rights.html)를 읽고 사용자에게 적용될 수 Maya 있는에 대한 클라우드 권한을 이해합니다. 필요에 따라 Deadline Cloud 팜을 구성합니다.
+ Autodesk 제품은 라는 파일을 사용합니다`ProductInformation.pit`. 이 파일의 대부분의 구성에는 시스템에 대한 관리자 액세스 권한이 필요하며, 이는 서비스 관리형 플릿에서 사용할 수 없습니다. 씬 클라이언트를 위한 제품 기능은 이를 처리할 수 있는 재배치 가능한 방법을 제공합니다. 자세한 내용은 [ Maya 및 MotionBuilder용 씬 클라이언트 라이선싱](https://www.autodesk.com/support/technical/article/caas/tsarticles/ts/2zqRBCuGDrcPZDzULJQ27p.html)을 참조하세요.
+ 일부 애플리케이션은 서비스 관리형 플릿 작업자 호스트에 설치되지 않은 라이브러리에 의존하므로 패키지에서 라이브러리를 제공해야 합니다. 애플리케이션 패키지 내에 직접 배치하거나 별도의 종속성 패키지에 배치할 수 있습니다.
+ Maya는 프리타입 및 fontconfig를 비롯한 여러 라이브러리에 따라 달라집니다. AL2023`dnf`용의와 같이 시스템 패키지 관리자에서 이러한 라이브러리를 사용할 수 있는 경우 이를 애플리케이션의 소스로 사용할 수 있습니다. 이러한 RPM 패키지는 재배치가 가능하도록 빌드되지 않았으므로와 같은 도구를 사용하여 Maya 설치 접두사 내에서 `patchelf` 종속성을 해결해야 합니다.
+ 설치하려면 관리자 액세스 권한이 필요할 수 있습니다. 서비스 관리형 플릿은 관리자 액세스를 제공하지 않으므로이 액세스 권한이 있는 시스템에서 설치를 수행해야 합니다. 그런 다음 패키지 빌드 작업이 사용하는 데 필요한 파일의 아카이브를 생성합니다.
+ 용 Windows 설치 관리자는 관리자 액세스 Maya 권한이 필요하므로 이를 위한 conda 패키지를 빌드하려면 먼저 이러한 아카이브를 생성하는 수동 프로세스가 필요합니다.
+ 플러그인 등록 방법을 포함한 애플리케이션 구성은 운영 체제 또는 사용자 수준에서 정의할 수 있습니다. Conda 가상 환경에 배치하는 경우 플러그인은 포함된 방식으로 애플리케이션과 통합할 수 있는 방법이 필요하며 가상 환경 접두사 외부에 파일 또는 기타 데이터를 쓰지 않습니다. 애플리케이션의 conda 패키지에서 이를 설정하는 것이 좋습니다.
+ 샘플 Maya 패키지는 환경 변수를 정의`MAYA_NO_HOME=1`하여 사용자 수준 구성에서 격리하고 별도로 패키징된 플러그인이 가상 환경 내에서 통합할 수 `MAYA_MODULE_PATH` 있도록에 모듈 검색 경로를 추가합니다. 샘플 MtoA 패키지는 이러한 디렉터리 중 하나에 .mod 파일을 배치하여 Maya 시작 시 로드합니다.
**레시피 메타데이터 작성**
1. 브라우저 또는 리포지토리의 로컬 복제본에 있는 텍스트 편집기에서 GitHub [ deadline-cloud-samples/conda\$1recipes/maya-2025](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes/maya-2025) 디렉터리를 엽니다.
파일은 용 패키지를 빌드할 conda 빌드 플랫폼과 애플리케이션을 가져올 위치를 `deadline-cloud.yaml` 설명합니다. 레시피 샘플은 Linux 및 Windows 빌드를 모두 지정하며, 기본적으로 만 제출Linux됩니다.
1. Autodesk 로그인에서 전체 Maya 설치 관리자를 다운로드합니다. Linux의 경우 패키지 빌드는 아카이브를 직접 사용할 수 있으므로 `conda_recipes/archive_files` 디렉터리에 직접 배치합니다. Windows의 경우 설치 관리자를 실행하려면 관리자 액세스 권한이 필요합니다. 설치 관리자를 실행하고 사용하려는 패키지 레시피의 아카이브에 필요한 파일을 수집해야 합니다. 레시피의 [ README.md](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/conda_recipes/maya-2025/README.md) 파일은이 아티팩트를 생성하기 위한 반복 가능한 절차를 문서화합니다. 이 절차에서는 새로 시작된 Amazon EC2 인스턴스를 사용하여 결과를 저장한 후 종료할 수 있는 깨끗한 설치 환경을 제공합니다. 관리자 액세스가 필요한 다른 애플리케이션을 패키징하려면 애플리케이션에 필요한 파일 세트를 결정한 후 유사한 절차를 따를 수 있습니다.
1. [ 레시피/recipe.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/conda_recipes/maya-2025/recipe/recipe.yaml) 및 [ 레시피/meta.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/conda_recipes/maya-2025/recipe/meta.yaml) 파일을 열어 래틀러 빌드 및 conda-build에 대한 설정을 검토하거나 편집합니다. 패키징하려는 애플리케이션의 패키지 이름과 버전을 설정할 수 있습니다.
**소스** 섹션에는 파일의 sha256 해시를 포함하여 아카이브에 대한 참조가 포함되어 있습니다. 예를 들어 새 버전으로 이러한 파일을 변경할 때마다 이러한 값을 계산하고 업데이트해야 합니다.
패키지가 사용하는 특정 라이브러리 및 바이너리 디렉터리에 대해 자동 메커니즘이 제대로 작동하지 않으므로 **빌드** 섹션에는 주로 기본 바이너리 재배치 옵션을 끄는 옵션이 포함되어 있습니다.
마지막으로 **정보** 섹션에서는 Conda 채널의 콘텐츠를 검색하거나 처리할 때 사용할 수 있는 애플리케이션에 대한 일부 메타데이터를 입력할 수 있습니다.
**패키지 빌드 스크립트 작성**
1. Maya 샘플 conda 빌드 레시피의 패키지 빌드 스크립트에는 스크립트가 수행하는 단계를 설명하는 설명이 포함되어 있습니다. 설명과 명령을 읽고 다음을 알아봅니다.
+ 레시피가의 RPM 파일을 처리하는 방법 Autodesk
+ 레시피가 적용되는 변경 사항은 레시피가 설치된 conda 가상 환경으로 설치를 재배치할 수 있도록 합니다.
+ 레시피가 소프트웨어가 실행 Maya 중인를 이해하는 데 사용할 수 `MAYA_VERSION` 있는 `MAYA_LOCATION` 및와 같은 유틸리티 변수를 설정하는 방법.
1. 의 경우 [ 레시피/build.sh](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/conda_recipes/maya-2025/recipe/build.sh) 파일을 Linux열어 패키지 빌드 스크립트를 검토하거나 편집합니다.
의 경우 [ recipe/build\$1win.sh](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/conda_recipes/maya-2025/recipe/build_win.sh) 파일을 Windows열어 패키지 빌드 스크립트를 검토하거나 편집합니다.
**Maya 패키지를 빌드하는 작업 제출**
1. GitHub [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples) 리포지토리의 복제본에 `conda_recipes` 디렉터리를 입력합니다.
1. Deadline Cloud 팜이 Deadline Cloud CLI에 맞게 구성되어 있는지 확인합니다. [ Amazon S3를 사용하여 conda 채널 생성](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/configure-jobs-s3-channel.html) 단계를 따른 경우 CLI에 맞게 팜을 구성해야 합니다.
1. 다음 명령을 실행하여 Linux 및 Windows 패키지를 모두 빌드하는 작업을 제출합니다.
` ./submit-package-job maya-2025 --all-platforms`
# Autodesk Maya to Arnold (MtoA) 플러그인용 conda 빌드 레시피 생성
상용 애플리케이션용 플러그인을 conda 패키지로 패키징할 수 있습니다. 플러그인은 애플리케이션에서 제공하는 애플리케이션 바이너리 인터페이스(ABI)를 사용하여 해당 애플리케이션의 기능을 확장하는 동적으로 로드되는 라이브러리입니다. Maya to Arnold (MtoA) 플러그인은 Arnold렌더러를 내에서 옵션으로 추가합니다Maya.
+ MtoA 샘플 빌드 레시피는 **Maya** 패키지에 따라 달라지며 버전에 대한 제약 `==` 조건을 사용합니다.
+ Maya 패키지는 `$PREFIX/usr/autodesk/maya$MAYA_VERSION/modules`플러그인이 `.mod` 파일을 배치할 수 있도록 가상 환경에서 Maya 모듈 경로를 구성합니다. MtoA 샘플 빌드 레시피는이 디렉터리`mtoa.mod`에 파일을 생성합니다.
**레시피 메타데이터 작성**
1. 브라우저 또는 리포지토리의 로컬 복제본에 있는 텍스트 편집기에서 GitHub [ deadline-cloud-samples/conda\$1recipes/maya-mtoa-2025](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes/maya-mtoa-2025) 디렉터리를 엽니다.
레시피는 Maya conda 빌드 레시피와 동일한 패턴을 따르며 동일한 소스 아카이브를 사용하여 플러그인을 설치합니다.
1. [ 레시피/recipe.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/conda_recipes/maya-mtoa-2025/recipe/recipe.yaml) 및 [ 레시피/meta.yaml](https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/conda_recipes/maya-mtoa-2025/recipe/meta.yaml) 파일을 열어 래틀러 빌드 및 conda-build에 대한 설정을 검토하거나 편집합니다. 이러한 파일은 패키지 빌드 `maya` 중 및 플러그인을 실행할 가상 환경을 생성할 때에 대한 종속성을 지정합니다.
**패키지 빌드 스크립트 작성**
+ MtoA 샘플 conda 빌드 레시피의 패키지 빌드 스크립트에는 스크립트가 수행하는 단계를 설명하는 설명이 포함되어 있습니다. 설명과 명령을 읽고 레시피가 Maya 패키지에 지정된 디렉터리`mtoa.mod`에 파일을 설치하고 MtoA 생성하는 방법을 알아봅니다.
Arnold 및는 동일한 라이선스 기술을 Maya 사용하므로 Maya conda 빌드 레시피에는에 필요한 정보가 이미 포함되어 있습니다Arnold.
Linux와 Windows 빌드 스크립트의 차이점은 Maya conda 빌드 레시피의 차이점과 유사합니다.
**Maya MtoA 플러그인 패키지를 빌드하는 작업 제출**
1. GitHub [deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples) 리포지토리의 복제본에 `conda_recipes` 디렉터리를 입력합니다.
1. 이전 섹션의 Maya 호스트 애플리케이션을 위한 패키지를 빌드했는지 확인합니다.
1. Deadline Cloud 팜이 Deadline Cloud CLI에 맞게 구성되어 있는지 확인합니다. [ Amazon S3를 사용하여 conda 채널 생성](https://docs.aws.amazon.com/deadline-cloud/latest/developerguide/configure-jobs-s3-channel.html) 단계를 따른 경우 CLI에 맞게 팜을 구성해야 합니다.
1. 다음 명령을 실행하여 Linux 및 Windows 패키지를 모두 빌드하는 작업을 제출합니다.
` ./submit-package-job maya-mtoa-2025 --all-platforms`
# Maya 렌더 작업으로 패키지 테스트
Maya 2025 및 MtoA 패키지를 빌드한 후 패키지를 사용하여 렌더링할 작업을 제출할 수 있습니다. 작업 번들이 [ 포함된 턴테Maya/Arnold](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/job_bundles/turntable_with_maya_arnold)이블 샘플은 Maya 및를 사용하여 애니메이션을 렌더링합니다Arnold. 또한이 샘플은 FFmpeg를 사용하여 비디오를 인코딩합니다. conda 대기열 환경의 기본 목록에 conda-forge 채널을 추가하여 `ffmpeg` 패키지의 소스를 제공할 수 `CondaChannels` 있습니다.
[deadline-cloud-samples](https://github.com/aws-deadline/deadline-cloud-samples)의 git 복제본에 있는 `job_bundles` 디렉터리에서 다음 명령을 실행합니다.
```
deadline bundle submit turntable_with_maya_arnold
```
Deadline Cloud 모니터를 사용하여 작업 진행 상황을 추적할 수 있습니다.
1. 모니터에서 제출한 작업의 작업을 선택한 다음 옵션을 선택하여 로그를 봅니다.
1. 로그 보기의 오른쪽에서 **Conda 세션 시작** 작업을 선택합니다.
작업이 대기열 환경에 대해 구성된 conda 채널maya-mtoa에서 maya 및를 검색했고 S3 채널에서 패키지를 찾았는지 확인할 수 있습니다.
# Deadline Cloud를 사용하여 패키지 빌드 자동화
CI/CD 워크플로의 경우 또는 여러 운영 체제용 패키지를 빌드해야 하는 경우 Deadline Cloud 패키지 빌드 대기열을 생성할 수 있습니다. 대기열은 패키지를 빌드하고 Amazon Simple Storage Service(Amazon S3) conda 채널에 게시하는 플릿의 빌드 작업을 예약합니다. 이렇게 하면 필요한 모든 구성에서 소프트웨어 릴리스를 위한 지속적인 패키지 빌드를 유지 관리할 수 있습니다.
AWS CloudFormation (CloudFormation) 템플릿을 사용하거나 Deadline Cloud 콘솔에서 수동으로 패키지 빌드 대기열을 생성할 수 있습니다. CloudFormation 템플릿은 프로덕션 대기열과 패키지 빌드 대기열이 이미 구성된 전체 팜을 배포합니다. 콘솔에서 대기열을 생성하면 개별 설정을 더 잘 제어할 수 있습니다.
## 를 사용하여 패키지 빌드 대기열 생성 CloudFormation
CloudFormation 템플릿을 사용하여 패키지 빌드 대기열이 포함된 Deadline Cloud 팜을 생성할 수 있습니다. 템플릿은 프라이빗 Amazon S3 conda 채널을 사용하여 프로덕션 대기열과 패키지 빌드 대기열을 구성합니다.
템플릿을 배포하기 전에 작업 첨부 파일과 conda 채널을 보관할 Amazon S3 버킷을 생성합니다. [Amazon S3 콘솔](https://console.aws.amazon.com/s3/)에서 버킷을 생성할 수 있습니다. 템플릿을 배포할 때 버킷 이름이 필요합니다.
**CloudFormation 템플릿을 배포하려면**
1. 의 [Deadline Cloud 샘플](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/cloudformation/farm_templates/starter_farm) 리포지토리에서 [deadline-cloud-starter-farm-template.yaml](https://github.com/aws-deadline/deadline-cloud-samples/raw/mainline/cloudformation/farm_templates/starter_farm/deadline-cloud-starter-farm-template.yaml) 템플릿을 다운로드합니다GitHub.
1. [CloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/)에서 **스택 생성을** 선택한 다음 **새 리소스 사용(표준)**을 선택합니다.
1. 옵션을 선택하여 템플릿 파일을 업로드한 다음 `deadline-cloud-starter-farm-template.yaml` 파일을 업로드합니다.
1. **StarterFarm**와 같은 스택의 이름을 입력하고 작업 연결을 위한 Amazon S3 버킷의 이름과 conda 채널을 제공합니다.
1. CloudFormation 콘솔 단계에 따라 스택 생성을 완료합니다.
템플릿 파라미터 및 사용자 지정 옵션에 대한 자세한 내용은의 Deadline Cloud 샘플 리포지토리에서 [스타터 팜 README](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/cloudformation/farm_templates/starter_farm)를 참조하세요GitHub.
## 콘솔에서 패키지 빌드 대기열 생성
*Deadline Cloud 사용 설명서*의 [대기열 생성](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/create-queue.html) 지침을 따릅니다. 다음과 같이 변경합니다.
+ 5단계에서 기존 Amazon S3 버킷을 선택합니다. 빌드 아티팩트가 일반적인 Deadline Cloud 연결과 분리**DeadlineCloudPackageBuild**되도록와 같은 루트 폴더 이름을 지정합니다.
+ 6단계에서는 패키지 빌드 대기열을 기존 플릿과 연결하거나 현재 플릿이 적합하지 않은 경우 완전히 새로운 플릿을 생성할 수 있습니다.
+ 9단계에서 패키지 빌드 대기열에 대한 새 서비스 역할을 생성합니다. 권한을 수정하여 대기열에 패키지를 업로드하고 conda 채널을 다시 인덱싱하는 데 필요한 권한을 부여합니다.
### 패키지 빌드 대기열 권한 구성
패키지 빌드 대기열이 대기열의 Amazon S3 버킷에 있는 `/Conda` 접두사에 액세스하도록 허용하려면 대기열의 역할을 수정하여 읽기/쓰기 액세스 권한을 부여해야 합니다. 이 역할에는 패키지 빌드 작업이 새 패키지를 업로드하고 채널을 다시 인덱싱할 수 있도록 다음 권한이 필요합니다.
+ `s3:GetObject`
+ `s3:PutObject`
+ `s3:ListBucket`
+ `s3:GetBucketLocation`
+ `s3:DeleteObject`
1. Deadline Cloud 콘솔을 열고 패키지 빌드 대기열의 대기열 세부 정보 페이지로 이동합니다.
1. 대기열 서비스 역할을 선택한 다음 **대기열 편집**을 선택합니다.
1. **대기열 서비스 역할** 섹션으로 스크롤한 다음 **IAM 콘솔에서이 역할 보기를** 선택합니다.
1. 권한 정책 목록에서 대기열에 대한 **AmazonDeadlineCloudQueuePolicy**를 선택합니다.
1. **권한** 탭에서 **편집**을 선택합니다.
1. 다음과 같이 대기열 서비스 역할에 새 섹션을 추가합니다. *amzn-s3-demo-bucket* 및 *111122223333*을 자체 버킷 및 계정으로 바꿉니다.
```
{
"Effect": "Allow",
"Sid": "CustomCondaChannelReadWrite",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/Conda/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "111122223333"
}
}
},
```
## 패키지 빌드 작업 제출
패키지 빌드 대기열을 생성하고 대기열 권한을 구성한 후 작업을 제출하여 conda 패키지를 빌드할 수 있습니다. 의 [Deadline Cloud 샘플](https://github.com/aws-deadline/deadline-cloud-samples/tree/mainline/conda_recipes#readme) `submit-package-job` 리포지토리에 있는 스크립트는 conda 레시피에 대한 빌드 작업을 GitHub 제출합니다.
다음 항목이 필요합니다.
+ 워크스테이션에 설치된 [Deadline Cloud CLI](https://github.com/aws-deadline/deadline-cloud)입니다.
+ 활성 [AWS Deadline Cloud Monitor(Deadline Cloud Monitor)](https://docs.aws.amazon.com/deadline-cloud/latest/userguide/working-with-deadline-monitor.html) 로그인 세션입니다.
+ [Deadline Cloud 샘플](https://github.com/aws-deadline/deadline-cloud-samples) 리포지토리의 복제본입니다.
**패키지 빌드 작업을 제출하려면**
1. Deadline Cloud 구성 GUI를 열고 기본 팜과 대기열을 패키지 빌드 대기열로 설정합니다.
```
deadline config gui
```
1. 샘플 리포지토리의 `conda_recipes` 디렉터리로 변경합니다.
```
cd deadline-cloud-samples/conda_recipes
```
1. 레시피 디렉터리를 사용하여 `submit-package-job` 스크립트를 실행합니다. 다음 예제에서는 Blender 4.5 레시피를 빌드합니다.
```
./submit-package-job blender-4.5/
```
레시피에 아직 다운로드하지 않은 소스 아카이브가 필요한 경우 스크립트는 다운로드 지침을 제공합니다. 아카이브를 다운로드하고 스크립트를 다시 실행합니다.
작업을 제출한 후 Deadline Cloud 모니터를 사용하여 작업의 진행 상황과 상태를 확인합니다.
![\[Conda 패키지를 빌드하는 작업의 진행 상황과 상태를 보여주는 Deadline Cloud 모니터입니다.\]](http://docs.aws.amazon.com/ko_kr/deadline-cloud/latest/developerguide/images/Conda-Figure3.png)
모니터는 작업의 두 단계, 즉 패키지를 빌드한 다음 conda 채널을 다시 인덱싱하는 단계를 보여줍니다. 패키지 빌드 단계의 작업을 마우스 오른쪽 버튼으로 클릭하고 **로그 보기를** 선택하면 모니터에 세션 작업이 표시됩니다.
+ **첨부 파일 동기화** - 입력 작업 첨부 파일을 복사하거나 가상 파일 시스템을 탑재합니다.
+ **Conda 시작** - 대기열 환경 작업입니다. 빌드 작업은 conda 패키지를 지정하지 않으므로이 작업은 빠르게 완료됩니다.
+ **CondaBuild Env 시작** - conda 패키지를 빌드하고 채널을 다시 인덱싱하는 데 필요한 소프트웨어를 사용하여 conda 가상 환경을 생성합니다.
+ **작업 실행** - 패키지를 빌드하고 결과를 Amazon S3에 업로드합니다.
작업이 실행되면 Amazon CloudWatch(CloudWatch)로 로그를 전송합니다. 작업이 완료되면 **모든 작업에 대한 로그 보기를** 선택하여 환경 설정 및 해체에 대한 추가 로그를 확인합니다.