연습 - Azure CycleCloud에 사용할 cloud-init 스크립트 만들기
클러스터에 대한 노드를 프로비전할 때는 스케줄러 기반 변경 내용이 적용되기 전에 운영 체제 부팅 프로세스 중에 사용자 지정 구성 작업을 수행할 수 있습니다. 이러한 작업에는 경로 환경 변수 업데이트, DNS(도메인 이름 시스템) 이름 확인 설정 구성 또는 노드를 Microsoft AD DS(Entra Domain Services) 도메인에 바인딩하는 작업이 포함될 수 있습니다.
이 기능을 구현하기 위해 Azure CycleCloud 클러스터에서 cloud-init의 사용을 탐색하고 각 노드에서 로컬 파일의 콘텐츠를 수정하는 간단한 Bash 스크립트로 테스트하기로 결정합니다. 클러스터 노드에 연결하고 수정된 파일의 내용을 검토하여 결과의 유효성을 검사하려고 합니다.
비고
cloud-init 스크립트를 작성할 때 기존 셸 스크립팅, Python 및 YAML을 포함하여 대상 노드에서 실행되는 운영 체제가 인식하고 처리할 수 있는 모든 스크립팅 또는 구성 방법을 사용할 수 있습니다.
이 연습에서 수행하는 작업은 다음과 같습니다.
- 작업 1: Azure CycleCloud 클러스터 노드에 대한 SSH 기반 인증 구성
- 작업 2: 클러스터 노드에 cloud-init 스크립트 추가
- 작업 3: 스케줄러 노드에서 cloud-init 기능 확인
- 작업 4: 컴퓨팅 노드에서 cloud-init 기능 확인
- 작업 5: 연습 환경 정리
비고
이 연습을 시작하기 전에 이전 연습을 성공적으로 완료했는지 확인합니다.
작업 1: Azure CycleCloud 클러스터 노드에 대한 SSH 기반 인증 구성
cloud-init 스크립트 실행의 유효성을 검사하려면 Azure Cloud Shell에서 Azure CycleCloud CLI를 사용하여 클러스터 노드에 연결합니다. 이 연결은 SSH 키 기반 인증을 사용하므로 클러스터 노드에 배포된 공개 키에 해당하는 프라이빗 키를 Azure Cloud Shell 홈 디렉터리에 업로드해야 합니다.
Azure Portal로 이동하고 메시지가 표시되면 이 모듈에서 사용 중인 Azure 구독에서 기여자 또는 소유자 역할이 있는 Microsoft 계정 또는 Microsoft Entra 계정으로 인증합니다.
Azure Portal에서 검색 상자 옆의 도구 모음에서 해당 아이콘을 선택하여 Cloud Shell 을 열고 Bash 세션을 실행하고 있는지 확인합니다.
Azure Cloud Shell 창의 창 도구 모음에서 반대 방향을 가리키는 세로 화살표 쌍이 있는 페이지를 표시하는 네 번째 아이콘을 선택합니다. 그런 다음 드롭다운 메뉴에서 업로드를 선택합니다.
열기 대화 상자에서 프라이빗 키가 포함된 .pem 파일의 위치로 이동하고 열기를 선택합니다.
Cloud Shell에서 다음 명령을 실행하여 업로드된 .pem 파일을 올바른 위치로 이동하고 필요한 파일 수준 권한을 구성합니다(자리 표시자를
<private_key.pem>파일의 이름으로 바꿉 니다.).mkdir -p ~/.ssh mv private_key.pem ~/.ssh chmod 600 ~/.ssh/cc-ssh-keys.pem
작업 2: 클러스터 노드에 cloud-init 스크립트 추가
클러스터 노드에 스크립트를 추가하는 옵션은 Azure CycleCloud 그래픽 인터페이스에서 직접 사용할 수 있습니다. 이를 사용하여 스케줄러 및 컴퓨팅 노드에 동일한 cloud-init 스크립트를 할당하고 해당 기능을 확인합니다. 스크립트는 /etc/hosts 파일에 항목 10.10.10.10 cc.contoso.com 추가합니다.
Azure CycleCloud 웹 애플리케이션에 아직 연결되지 않은 경우 다른 브라우저 창을 열고 https://< IP_address> URL로 이동합니다. 메시지가 표시되면 계속 진행할지 확인합니다.
인증하라는 메시지가 표시되면 관리자 역할로 Azure CycleCloud 애플리케이션 사용자 계정의 자격 증명을 제공하여 로그인합니다.
Azure CycleCloud 그래픽 인터페이스에서 클러스터 페이지로 이동합니다. 클러스터 목록에서 contoso-custom-slurm-lab-cluster항목을 선택한 다음 편집을 선택합니다.
contoso-custom-slurm-lab-cluster 팝업 편집 창에서 Cloud-init 항목을 선택하고 Cloud-init 구성 섹션의 스케줄러 탭에서 다음 스크립트를 입력합니다.
#!/bin/bash echo "10.10.10.10 www.contoso.com" >> /etc/hosts
동일한 팝업 창 에서 Cloud-init 항목이 선택된 상태에서 나머지 탭( cuda, hpc 및 htc 포함)을 각각 선택하고 동일한 스크립트를 입력합니다. 저장을 선택합니다.
작업 3: 스케줄러 노드에서 cloud-init 기능 확인
스케줄러 노드에서 cloud-init 기능을 확인하려면 클러스터를 시작합니다. 그러면 스케줄러 노드의 프로비저닝이 트리거됩니다. 노드가 실행되면 Azure Cloud Shell에서 노드에 연결하고 /etc/hosts 파일에 항목 10.10.10.10 www.contoso.com이 포함되어 있는지 확인할 수 있습니다.
Azure CycleCloud 웹 애플리케이션을 표시하는 브라우저 창에서 contoso-custom-slurm-lab-cluster 페이지에서 시작 링크를 선택합니다. 확인하라는 메시지가 표시되면 확인을 선택합니다.
비고
클러스터가 이미 실행 중인 경우 업데이트된 구성을 적용하기 위해 클러스터를 종료하고 다시 시작해야 합니다. 그렇지 않으면 해당 구성이 후속 단계에서 표시되지 않습니다.
노드 목록에서 Scheduler 항목을 선택하고 세부 정보 창에서 해당 상태를 모니터링 하여 가져오기 에서 준비로 변경될 때까지 대기합니다.
비고
약 3분 정도 걸릴 수 있습니다.
세부 정보 창에서 연결을 선택합니다. 노드에 연결: 스케줄러 팝업 창의 CycleCloud CLI 사용 섹션에서 스케줄러 노드에 연결할 수 있는 명령이 포함된 항목을 선택하고 닫기를 선택합니다.
비고
명령에 형식이 있어야 합니다.
cyclecloud connect scheduler -c contoso-custom-slurm-lab-clusterCloud Shell 창을 사용하여 웹 브라우저 창으로 전환하고 이전 단계에서 복사한 명령을 실행합니다.
비고
명령은 다음 형식으로 출력을 생성해야 합니다.
m@Azure:~$ cyclecloud connect scheduler -c contoso-custom-slurm-lab-cluster Connecting to cc-admin@40.87.52.25 (contoso-custom-slurm-lab-cluster scheduler) using SSH [cc-admin@ip-0A000304 ~]$스케줄러 노드에 연결된 경우 다음 명령을 실행하여 /etc/hosts 파일에 항목 10.10.10.10
www.contoso.com이 포함되어 있는지 확인합니다.grep "10.10.10.10 www.contoso.com" /etc/hosts비고
명령은 다음 형식으로 출력을 생성해야 합니다.
[cc-admin@ip-0A000304 ~]$ grep "10.10.10.10 www.contoso.com" /etc/hosts 10.10.10.10 www.contoso.com
작업 4: 컴퓨팅 노드에서 cloud-init 기능 확인
이제 동일한 단계 시퀀스를 반복하여 컴퓨팅 노드에서 cloud-init 기능을 확인합니다.
중요합니다
컴퓨팅 노드에서 cloud-init 기능을 확인하는 동일한 절차를 적용하려면 해당 가상 머신 확장 집합을 제거하고 다시 할당해야 합니다. 이 단계는 Slurm 기반 클러스터와 관련이 있습니다. 이 경우 스케줄러 자동 크기 조정 통합을 사용하려면 Azure CycleCloud가 컴퓨팅 노드를 미리 채워야 하기 때문입니다. 따라서 이 연습에서 이전에 적용한 cloud-init 구성은 기존 노드에 영향을 주지 않습니다.
스케줄러 노드에 연결된 상태에서 Cloud Shell에서 다음 명령을 실행하여 Azure CycleCloud 클러스터에서 컴퓨팅 노드를 제거 및 다시 할당하고 스케줄러 노드에 대한 연결을 종료합니다.
sudo -i cd /opt/cycle/jetpack/system/bootstrap/slurm ./cyclecloud_slurm.sh remove_nodes ./cyclecloud_slurm.sh scale exit exit비고
다음 노드를 제거하려고 시도하다가 이 단계가 완료되면 클러스터 크기 조정이 완료되었다는 메시지가 표시됩니다.
컴퓨터에서 Azure CycleCloud 웹 애플리케이션의 contoso-custom-slurm-lab-cluster 페이지를 표시하는 웹 브라우저 창으로 전환합니다. 노드 탭에서 htc 행을 선택하고 세부 정보 창에서 htc-1 항목을 선택한 다음 작업 탭 머리글을 선택합니다. 드롭다운 메뉴에서 시작을 선택하고 확인하라는 메시지가 표시되면 확인을 선택합니다.
세부 정보 창에서 새로 시작된 노드를 모니터링하고 상태가 [획득]에서 [준비]로 변경될 때까지 기다립니다.
비고
약 3분 정도 걸릴 수 있습니다.
세부 정보 창에서 연결을 선택합니다. 노드에 연결: htc-1 팝업 창에서 스케줄러 노드에 연결하고 닫기를 선택할 수 있는 명령이 포함된 CycleCloud CLI 사용 섹션의 항목을 선택합니다.
비고
명령에는 형식
cyclecloud connect htc-1 -c contoso-custom-slurm-lab-cluster이 있어야 합니다.Cloud Shell 창으로 전환하고 이전 단계에서 복사한 명령을 실행합니다.
비고
명령은 다음 형식으로 출력을 생성해야 합니다.
m@Azure:~$ cyclecloud connect htc-1 -c contoso-custom-slurm-lab-cluster Connecting to cc-admin@10.0.3.5 (contoso-custom-slurm-lab-cluster htc-1) through SSH bastion at cc-admin@40.87.52.25 [cc-admin@ip-0A000305 ~]$htc-1 노드에 연결된 경우 다음 명령을 실행하여 /etc/hosts 파일에 항목 10.10.10.10
www.contoso.com이 포함되어 있는지 확인합니다.cat /etc/hosts | grep "10.10.10.10 www.contoso.com"비고
이 시점에 도달하면 이 모듈의 이전 연습에서 배포한 모든 리소스를 삭제해야 합니다. 이렇게 하면 Azure 구독에 대해 이러한 리소스를 유지 관리하는 것과 관련된 요금을 방지할 수 있습니다.
작업 5: 랩 환경 정리
Azure CycleCloud 애플리케이션을 사용하여 클러스터 사용자 지정 테스트를 완료합니다. Azure 리소스 사용과 관련된 불필요한 비용을 방지하기 위해 이제 클러스터를 종료하고 이 모듈의 연습 전체에서 프로비전한 모든 리소스를 제거합니다.
Azure CycleCloud 웹 애플리케이션의 그래픽 인터페이스를 표시하는 웹 브라우저에서 contoso-custom-slurm-lab-cluster 페이지에서 Terminate 링크를 선택하고 확인하라는 메시지가 표시되면 확인을 선택합니다.
종료 프로세스를 모니터링합니다.
비고
이 프로세스에는 클러스터의 헤드 노드 역할을 수행하는 Azure VM의 프로비전 해제가 포함됩니다. 5분 정도 걸릴 수 있습니다.
비고
이 랩에서 프로비전한 다른 모든 리소스를 삭제하려면 클러스터 리소스를 호스트하는 리소스 그룹을 삭제합니다.
Azure Portal에서 클러스터 리소스를 호스팅하는 리소스 그룹의 블레이드로 이동하고 도구 모음에서 리소스 그룹 항목 삭제 를 선택합니다. 리소스 그룹 이름을 입력하여 삭제 확인 텍스트 상자에 리소스 그룹의 이름을 입력하고 삭제를 선택합니다. 삭제를 다시 선택하여 삭제를 확인합니다.
비고
Slurm 리소스와 연결된 추가 리소스 그룹이 있을 수 있습니다. 추가 요금을 방지하려면 이러한 Slurm 관련 리소스 그룹 및 해당 리소스를 모두 삭제해야 합니다.
축하합니다! 이 모듈의 세 번째 및 마지막 연습을 성공적으로 완료했습니다. 이 연습에서는 Azure CycleCloud 클러스터에서 cloud-init의 사용을 탐색하고 각 노드에서 로컬 파일의 콘텐츠를 수정하는 간단한 Bash 스크립트로 테스트했습니다. 클러스터 노드에 연결하고 수정된 파일의 콘텐츠를 검토하여 결과의 유효성을 검사했습니다. 그 후 불필요한 비용을 방지하기 위해 클러스터를 종료하고 이 모듈에서 사용한 모든 클러스터 리소스를 삭제했습니다.