당사의 이전 글에서 Terraform을 사용한 코드형 인프라의 기본을 다루고 Jamf Pro 및 Jamf Protect 구성 관리 방법을 걷습니다. 아직 읽지 않았다면 Terraform 기본 사항, 프로젝트 구조 및 상태 관리를 다루므로 거기서 시작하는 것을 권장합니다.
이번에는 자주 듣는 질문에 대해 다루고 있습니다: "모두 좋게 들리지만 Jamf 환경에 이미 수백 개의 정책, 프로필, 스크립트 및 그룹이 있습니다. 정말 모두 손으로 다시 작성해야 합니까?"
짧은 대답은 아니오입니다. 정확히 이를 도와주기 위해 jamformer라는 도구를 구축했습니다 - 그러나 우리가 뛰어들기 전에 그것이 무엇이고 무엇이 아닌지 솔직하게 말하는 것이 중요합니다.
jamformer는 무엇입니까?
jamformer는 Terraform을 통해 Jamf를 채택하는 팀을 위한 역량 강화 및 가속화 도구입니다. 기존 Jamf 인스턴스에 연결하여 찾을 수 있는 모든 것을 발견하고 시작점으로 Terraform 프로젝트를 생성합니다. 오늘 있는 곳(콘솔을 통해 관리되는 완전히 구성된 Jamf 환경)과 가고 싶은 곳(해당 동일한 환경이 코드로 관리됨) 사이의 다리로 생각하세요 - 하지만 다리는 컨베이어 벨트가 아닙니다. 당신은 여전히 그것을 건너갑니다.
그것은 의도적으로 아닙니다:
- 프로덕션 코드 생성기입니다. 생성하는 HCL은 첫 번째 초안입니다. 실제 인프라를 관리하기 전에 모든 파일을 검토하고 자신의 모듈 구조로 리팩터링하고 명명 규칙을 적용하고 보안 처리를 강화하고 공급자 드리프트 문제를 처리할 것으로 예상합니다.
- Terraform 또는 Jamf 공급자 학습을 대체합니다. 학습 곡선을 평탄화합니다. 그것을 제거하지 않습니다.
- 원클릭 마이그레이션 단추입니다. 크거나 특이한 Jamf 환경은 항상 인간 판단이 필요합니다.
그것이 좋은 것입니다:
- 실제 Jamf 인스턴스에 있는 것을 보면, Terraform 공급자 자체의 리소스 모델(속성, 교차 참조, 생명 주기 특이성 등)로 표현됩니다.
- 프로덕션 사례, 데모, 워크숍, 내부 교육 및 마이그레이션 계획 세션을 부트스트래핑합니다.
- 엔지니어에게 빈 편집기를 바라보는 대신 IaC로 리팩터링할 수 있는 현실적인 스캐폴드를 제공합니다.
또한 읽기 전용입니다. jamformer는 Jamf 인스턴스에서 무엇이든 수정, 생성 또는 삭제하지 않습니다. 작성하는 유일한 것은 로컬 머신의 Terraform 파일 세트입니다.
이 글의 나머지 부분을 위해 이 프레임을 염두에 두십시오. 워크플로우를 걷고 예 출력을 표시할 때 인간 엔지니어가 리팩터링할 원시 재료를 보고 있습니다 - 완성된 기사가 아닙니다.
왜 terraform import를 사용하지 않습니까?
절대 할 수 있고 Protect 글을 읽었다면 terraform import 및 terraform query를 list 블록과 함께 기존 리소스를 관리하에 가져오는 방법을 이미 봤습니다.
그러나 콘솔을 통해 Jamf 환경을 어느 정도 관리하는 경우, 그 안에 많이 있습니다. 수동으로 모든 것을 가져오면 모든 리소스 유형을 인벤토리 처리하고 올바른 Jamf ID로 수백 개의 가져오기 블록을 작성하고 어느 정책이 어느 스크립트와 어느 그룹과 어느 범주를 참조하는지 알아내고 포함된 스크립트를 추출하는 것을 의미합니다. 독립 실행형 파일로의 구성 프로필 페이로드, 기본값 주위의 공급자 특이성을 다루고 있습니다.
그것은 많은 일입니다. 우리는 이를 더 쉽게 만들고 싶었습니다.
지원되는 것은 무엇입니까?
jamformer는 Jamf 제품군 전체에서 네 개의 Terraform 공급자와 함께 작동합니다:
| 공급자 | 발견 방법 |
|---|---|
| Jamf Pro (기본) | Jamf Pro API |
| Jamf Protect | terraform query |
| Jamf Platform | terraform query |
| Jamf Security Cloud(JSC) | Terraform 데이터 소스 |
Jamf Pro만 해도 정책, 스크립트, 구성 프로필, 스마트 그룹, 정적 그룹, 컴퓨터 프리스테이지, 모바일 장치 프로필, 확장 속성, 패키지, 범주, 건물, 부서 등을 다루며 - 클라이언트 체크인, 클라우드 배포 지점 및 자체 서비스 구성과 같은 설정을 포함합니다. 신뢰할 수 있는 항상 현재 목록은 jamformer -list-resources (필요에 따라 -provider로 필터링)입니다.
실행할 때 어떻게 됩니까?
jamformer를 Jamf 인스턴스에 지정하면 여러 단계를 거칩니다. 각 단계가 수행하는 작업을 이해하도록 각 단계를 진행합니다.
먼저 리소스를 발견합니다. Jamf Pro의 경우 인스턴스에 인증하고 지원되는 각 리소스 유형에 대해 API를 쿼리합니다. 의존성 순서로 환경을 단계별로 진행합니다 - 먼저 사이트 및 범주, 그 다음 스크립트 및 패키지, 그 다음 정책 및 프로필 - 리소스 간의 관계를 매핑할 수 있도록 합니다. Jamf Protect 및 Jamf Platform의 경우 terraform query를 list 블록과 함께 사용합니다(Protect 글에서 다룬 동일한 접근 방식). 리소스를 공급자를 통해 직접 발견합니다.
다음으로 가져오기 블록을 생성합니다. 발견된 각 리소스에 대해 jamformer는 리소스 이름에서 파생된 레이블로 Terraform import 블록을 작성합니다. 공백이 밑줄이 되고 특수 문자가 제거되며 두 리소스가 동일한 레이블로 끝나면 항목을 고유하게 유지하기 위해 숫자 접미사가 추가됩니다. 또한 provider.tf, variables.tf 및 terraform.tfvars를 올바른 공급자로 구성하여 생성합니다.
이 가져오기 블록이 어떻게 보일 수 있는지 예:
import {
to = jamfpro_policy.software_update_enforce
id = "142"
}
import {
to = jamfpro_script.install_rosetta
id = "87"
}
import {
to = jamfpro_category.productivity
id = "5"
}
그런 다음 Terraform에 HCL을 생성하도록 요청합니다. jamformer는 terraform plan -generate-config-out을 실행합니다(또는 Protect 및 Platform의 경우 terraform query -generate-config-out). 이를 통해 공급자는 각 가져온 리소스에 대한 HCL을 생성합니다. 공급자 자체가 무거운 작업을 수행하고 있으므로 생성된 구성은 항상 공급자가 예상하는 항목과 일치합니다.
특정 리소스가 가져오기 실패하는 경우 - 때로는 공급자가 특정 리소스를 제대로 읽을 수 없는 경우도 있습니다 - jamformer는 자동으로 실패한 가져오기 블록을 제거하고 다시 시도합니다. 나중에 처리할 수 있도록 건너뛴 리소스를 알 수 있는 메시지가 표시됩니다.
마지막으로 출력을 정리합니다. Terraform의 원본 출력은 리터럴 값이 있는 하나의 큰 파일입니다. jamformer는 이를 실제로 작업하고 싶은 것으로 변환합니다:
- jamformer는 리터럴 Jamf ID를 Terraform 참조로 다시 작성합니다. 범주 ID
5를 참조하는 정책은jamfpro_category.productivity.id가 되므로 Terraform이 리소스 간의 관계를 이해합니다 - 손으로 작성하는 것처럼 말입니다. - 포함된 스크립트는
support_files/scripts/아래의 개별 파일로 이동하고, 구성 프로필 페이로드는support_files/macos_configuration_profiles/로, 확장 속성 스크립트는support_files/extension_attributes/로, 모바일 장치 앱 구성은support_files/app_configurations/로 이동합니다. jamformer는 HCL을file()참조로 업데이트하므로 스크립트와 프로필이 독립적으로 diff, 검토 및 편집할 수 있는 적절한 파일입니다. 장치 등록 및 대량 구매 토큰은file(var.xxx)경로 변수를 사용합니다 - 토큰 파일(Apple Business Manager에서 다운로드)을 변수에서 지정한 경로에 배치합니다. - jamformer는 아이콘 리소스를 CDN URL로 확인합니다(아이콘은 로컬로 다운로드되지 않음) 그리고 첫 번째 적용에서 불필요한 파괴/생성 주기를 방지하는
lifecycle { ignore_changes }블록을 추가합니다. null로 반환되는 선택적 속성이 제거되고, 문제를 일으킬 것으로 알려진 값(예:category_id = -1의 미분류 리소스)이 제거되며, 단일 대형 파일이 리소스 유형별 파일로 분할됩니다 -policies.tf,scripts.tf,categories.tf등입니다.- 유효성 검사 통과는 조건부로 유효하지 않은 속성을 감지하기 위해
terraform validate를 실행합니다 (예: 특정 CDN 유형에만 유효한 속성) 그리고 자동으로 제거하므로 손으로 스키마 오류를 추적할 필요가 없습니다.
후처리 후 jamformer는 출력 스캔 비밀입니다. Jamf 환경에는 종종 구성 프로필, 스크립트 및 리소스 속성에 포함된 자격 증명이 포함됩니다 - LDAP 바인드 암호, SMTP 자격 증명, Wi-Fi 공유 보안 및 API 토큰과 같은 것입니다. jamformer는 gitleaks를 Jamf 관련 규칙과 함께 사용하여 실수로 Git에 커밋하기 전에 이를 찾습니다.
jamformer가 보안을 찾으면 리소스 및 속성별로 그룹화된 보고서를 표시합니다. 대화형 모드에서 모든 결과를 자동으로 복구하거나 개별적으로 진행하거나 복구를 완전히 건너뛰도록 선택할 수 있습니다. 복구는 보안을 민감한 Terraform 변수로 이동합니다 - .tf 파일의 경우 비밀 값이 var. 참조로 바뀝니다; 스크립트 및 프로필과 같은 지원 파일의 경우 파일이 templatefile()을 사용하는 .tpl 템플릿으로 변환됩니다. -skip-secret-scan을 사용하면 이 단계를 건너뛸 수 있습니다.
시작하기
소개 문서를 따라가시면 이미 Terraform 및 텍스트 편집기가 설정되어 있어야 합니다. 여기 단계는 간단합니다.
1. jamformer 설치
Homebrew:
brew install Jamf-Concepts/tap/jamformer
미리 빌드된 바이너리 및 .pkg 설치 관리자를 릴리스 페이지에서 사용할 수 있습니다.
Terraform을 별도로 설치할 필요가 없습니다 - jamformer는 자동으로 임시 디렉토리로 다운로드하므로 머신에 있는 기존 Terraform 설치와 충돌하지 않습니다.
2. 인스턴스에 대해 실행합니다.
시작하는 가장 쉬운 방법은 인수 없이 jamformer를 실행하는 것입니다:
jamformer
모든 것을 대화형으로 안내합니다 - 사용할 공급자, 인스턴스 URL 및 자격 증명입니다. 종료 입력으로 암호 및 클라이언트 보안을 입력하므로 터미널 기록에 표시되지 않습니다.
단축 URL도 여기서 작동합니다 - 그냥 입력할 수 있습니다 yourinstance하고 jamformer는 yourinstance.jamfcloud.com으로 확장합니다. Protect의 경우 your-tenant가 your-tenant.protect.jamfcloud.com으로 확장됩니다.
도구에 익숙해지거나 스크립팅하려면 환경 변수를 통해 자격 증명을 설정할 수 있습니다:
# OAuth2를 사용한 Jamf Pro
export JAMF_CLIENT_ID='your-client-id'
export JAMF_CLIENT_SECRET='your-client-secret'
jamformer -url https://yourinstance.jamfcloud.com
# Jamf Protect
export JAMF_CLIENT_ID='your-client-id'
export JAMF_CLIENT_SECRET='your-client-secret'
jamformer -provider jamfprotect -url https://your-tenant.protect.jamfcloud.com
jamformer는 환경 변수 또는 대화형 프롬프트에서만 자격 증명을 읽습니다 - CLI 플래그에서 절대 아닙니다 - 쉘 기록 및 프로세스 목록에서 보안을 유출하지 않습니다. 플래그로 URL을 전달할 수 있습니다(-url) 또는 JAMF_URL을 통해.
jamformer는 자격 증명을 terraform.tfvars에 작성하지 않으며 tfvars 파일, state 파일 및 .terraform/ 디렉토리를 제외하는 .gitignore를 생성합니다.
3. 한 번에 모두 가져오기는 선택 사항입니다.
환경이 크고 작게 시작하려면 특정 리소스 유형을 대상화할 수 있습니다:
# 정책, 스크립트 및 범주로 시작
./jamformer -include-resources "policies scripts categories"
# 패키지 및 아이콘을 제외한 모든 것
./jamformer -exclude-resources "packages icons"
# 사용 가능한 모든 필터 이름 보기
./jamformer -list-resources
의존성 유형이 포함되지 않으면(예: 범주를 제외하고 정책을 가져옴) 해당 유형에 대한 참조는 Terraform 표현식이 아닌 리터럴 ID로 유지됩니다. 나중에 더 많은 유형으로 다시 실행할 수 있습니다.
출력은 실제로 어떻게 보입니까?
jamformer가 완료되면 다음과 같은 디렉토리를 갖게 됩니다:
생성됨/
.gitignore
provider.tf
variables.tf
terraform.tfvars
policies.tf
policies_import.tf
scripts.tf
scripts_import.tf
categories.tf
categories_import.tf
...
support_files/
scripts/
install_rosetta.sh
set_wallpaper.sh
extension_attributes/
battery_health.sh
macos_configuration_profiles/
wifi_corporate.mobileconfig
filevault_enforce.mobileconfig
device_enrollment_tokens/ (비어 있음 - .p7m 파일 여기 배치)
volume_purchasing_tokens/ (비어 있음 - .vpptoken 파일 여기 배치)
app_configurations/
managed_browser.xml
각 리소스 유형은 자신의 .tf 파일과 해당 _import.tf 파일을 가져옵니다. support_files/ 디렉토리에는 추출된 스크립트, 프로필 및 앱 구성이 포함됩니다. jamformer는 토큰 디렉토리(device_enrollment_tokens/ 및 volume_purchasing_tokens/)를 Apple Business Manager 토큰 파일의 권장 위치로 만듭니다 - API가 토큰 데이터를 반환하지 않으므로 변수 경로를 지정합니다.
압축 모드
기본적으로 jamformer는 개체당 하나의 리소스 블록을 생성합니다 - 읽고 검토하기 쉬운 평면, 명시적 레이아웃입니다. 하지만 환경에 유사한 리소스(범주, 건물, 부서)가 수십 개 있으면 출력이 반복적으로 느껴질 수 있습니다.
-compact 플래그는 적격 리소스 유형을 for_each + locals 패턴으로 통합하며, 출력이 손으로 작성하는 것과 유사합니다:
jamformer -compact
압축 모드 없이 개별 블록을 얻을 수 있습니다:
resource "jamfpro_category" "productivity" {
name = "Productivity"
}
resource "jamfpro_category" "security" {
name = "Security"
}
압축 모드가 활성화되면 다음과 같이 됩니다:
locals {
categories = {
productivity = { name = "Productivity" }
security = { name = "Security" }
}
}
resource "jamfpro_category" "all" {
for_each = local.categories
name = each.value.name
}
jamformer는 새 주소 지정을 사용하도록 교차 리소스 참조를 자동으로 다시 작성합니다 - jamfpro_category.all["productivity"].id 대신 jamfpro_category.productivity.id - 모든 것을 연결된 상태로 유지합니다. 가져오기 블록도 동일한 방식으로 업데이트합니다.
jamformer는 런타임에 동적으로 적격성을 결정합니다. 리소스 유형은 파일에 두 개 이상의 리소스 블록이 포함되고 모두 같은 속성 집합을 공유하고 nested 블록이 없는 경우(생명 주기 제외) 적격입니다. 모든 인스턴스에서 동일한 속성은 리소스 블록의 리터럴 값이 되고, 변하는 값만 locals 맵으로 이동합니다. 이는 네 개의 공급자 모두에서 작동합니다.
더 세밀한 제어를 원하면 특정 유형을 대상화할 수 있습니다:
# 범주 및 건물만 압축
jamformer -compact -compact-include "categories buildings"
# 정책을 제외한 모든 것 적격
jamformer -compact -compact-exclude "policies"
다중 환경 지원
⚠️ 실험적이고 고도로 고급입니다. 이 기능은 이미 Terraform 모듈, 장기 분기 워크플로우 및 Jamf 공급자의 리소스 모델에 유창한 사람을 대상으로 합니다. 출력은 단일 환경 모드보다 더 스캐폴드 등급입니다 - 프로덕션 워크플로우로 사용되는 생성된 모듈, 환경별 루트 및 변수 추출을 편집하기를 기대합니다. 연구/역량 강화 기능으로 취급합니다. 지원되는 프로덕션 워크플로우가 아닙니다. Terraform 또는 여전히 첫 번째 단일 인스턴스 프로젝트를 시작하는 경우 거기서 시작하고 나중에 돌아옵니다.
여러 Jamf Pro 환경을 관리하는 경우 - 스테이징 및 프로덕션 또는 개발 및 프로덕션 - 이들을 동기화 상태로 유지하는 방법에 대해 생각했을 수 있습니다. jamformer는 각 장기 분기가 환경을 나타내는 Git 분기 워크플로우를 위해 설계된 공유 모듈과 환경별 루트 디렉토리를 중심으로 한 Terraform 프로젝트를 생성할 수 있습니다.
export JAMF_URL_STAGING=https://staging.jamfcloud.com
export JAMF_CLIENT_ID_STAGING=xxx
export JAMF_CLIENT_SECRET_STAGING=xxx
export JAMF_URL_PROD=https://prod.jamfcloud.com
export JAMF_CLIENT_ID_PROD=xxx
export JAMF_CLIENT_SECRET_PROD=xxx
jamformer -multi-env "staging prod"
jamformer는 각 환경에 대해 독립적으로 발견을 실행하고 이름별로 리소스를 일치시키며 다음과 같은 출력을 생성합니다:
생성됨/
modules/jamf/ # 모든 환경에 있는 공유 리소스 정의
policies.tf # 정책 리소스
scripts.tf
categories.tf
policies_staging_only.tf # 스테이징에만 있는 리소스
variables.tf # 모듈 입력 변수
providers.tf
support_files/ # 환경 전체에서 동일한 파일
scripts/
macos_configuration_profiles/
environments/
staging/
main.tf # 공급자 구성 + 모듈 호출
backend.tf # 상태 백엔드의 자리 표시자
variables.tf
terraform.tfvars # 환경 관련 값
imports.tf # module.jamf. 접두사가 있는 가져오기 블록
support_files/ # 다른 환경과 다른 파일
prod/
main.tf
backend.tf
variables.tf
terraform.tfvars
imports.tf
support_files/
modules/jamf/의 공유 모듈에는 모든 환경에 공통인 리소스 정의가 포함되어 있습니다. 환경 전체에서 속성 값이 다른 경우(정책이 다른 category_id 또는 프로필이 다른 description을 사용하는 경우) - jamformer는 해당 값을 모듈 변수로 추출하고 각 환경의 terraform.tfvars에서 환경별로 설정합니다. 교차 리소스 참조는 적절한 Terraform 표현식으로 유지됩니다(예: jamfpro_category.productivity.id), 리소스 간의 관계가 유지됩니다.
이는 의도적으로 환경을 동기 상태로 유지할 때 가장 잘 작동합니다 - 모든 인스턴스에 배포된 동일한 정책, 스크립트, 프로필 및 그룹입니다. 더 일치할수록 출력이 깨끗해집니다. 즉, jamformer는 일반적인 실제 차이를 처리합니다:
- 동일한 리소스, 다른 설정 (예: 스테이징과 프로덕션 간의 다른 범주 또는 빈도를 가진 정책) - 다양한 속성이 모듈 변수가 되며 각 환경의 값이 자신의
terraform.tfvars에 있습니다. jamformer는 변수를 알파벳순으로 정렬하고 가독성을 위해 리소스 유형별로 그룹화합니다. - 일부 환경에는 있고 다른 환경에는 없는 리소스 (예: 스테이징에만 있는 테스트 정책) - jamformer는
policies_staging_only.tf같은 모듈 내의 명확하게 레이블이 지정된 파일로 이를 분리합니다. 다른 환경의 분기에서 이 파일을 삭제합니다. - 다양한 지원 파일 (예: 인스턴스 간에 약간 다른 콘텐츠의 스크립트) - 모든 환경에서 동일한 파일은 공유 모듈의
support_files/디렉토리에 있습니다. 파일이 다르면 jamformer가 각 환경의 자신의support_files/디렉토리에 배치하고 모듈로 변수로 전달합니다.
각 환경 디렉토리에는 자신의 backend.tf 자리 표시자, 자신의 state 및 module.jamf. 접두사가 있는 자신의 가져오기 블록이 있습니다. 이는 각 환경에 대해 terraform plan 및 terraform apply를 독립적으로 실행할 수 있으며 한 환경의 state가 다른 환경에 간섭할 위험이 없다는 의미입니다.
jamformer는 공유 리소스 정의의 진원지로 나열된 첫 번째 환경을 사용합니다; 이를 재정의하려면 -source-env를 사용합니다. 이름별로 리소스를 일치시키므로 스테이징의 "Software Update - Enforce"라는 이름의 정책이 Jamf ID와 관계없이 프로덕션의 동일한 이름을 가진 정책과 일치합니다.
의도된 워크플로우는 저장소에 출력을 커밋하고 환경별로 장기 분기를 만들고 각 분기의 backend.tf를 적절한 state 백엔드로 구성하고 해당 분기에 코드가 도착할 때 CI를 설정하여 해당하는 environments/<env>/ 디렉토리에서 terraform apply를 실행합니다. 변경 사항은 기능 분기에서 첫 번째 환경으로 흐르고 나중에 끌어오기 요청을 통해 분기를 통해 홍보합니다.
환경이 더 갈라질수록 출력에는 변수 및 환경 관련 파일이 많아집니다. 인스턴스가 실질적으로 다르면 각 인스턴스에 대해 jamformer를 별도로 실행하고 독립적인 Terraform 프로젝트를 유지하는 것이 좋습니다.
생성된 출력으로 작업
우리는 이를 최상위에서 이야기했으며 여기서 다시 이야기합니다. 이는 가장 중요한 부분입니다: 생성된 구성은 프로덕션 준비 Terraform이 아닙니다. jamformer는 역량 강화 및 가속화 도구입니다. Jamf 환경 관리 코드로의 여정에서 현실적인 시작점을 제공합니다 - 즉시 그곳에 도착하는 지름길이 아닙니다. 실제 인프라 변경을 구동하기 전에 생성된 것을 검토, 리팩터링 및 이해하는 데 실제 시간을 투자할 계획을 세우십시오.
출력은 의도적으로 평면입니다 - 개체당 하나의 리소스 블록, 유형별 파일입니다. 실제로 모듈식 프로젝트 구조로 리팩터링하고, for_each 및 locals과 같은 HCL 기능을 활용하여 반복을 줄이고, 인스턴스 URL 및 일반적인 설정과 같은 환경에 대한 변수로 전환하고, 팀을 위해 의미 있는 방식으로 리소스를 구성할 수 있습니다. jamformer는 이를 수행할 원시 재료를 제공합니다; 형성 방법은 당신에게 달려 있습니다. 이 형성 작업은 대부분의 Terraform 학습이 실제로 발생하는 곳입니다 - jamformer가 그 형태로 존재하는 이유입니다.
이를 염두에 두고, 권장하는 워크플로우는 다음과 같습니다.
소개에서 배운 것과 동일한 명령이 여기에 적용됩니다:
cd generated
terraform plan # 가져오기 계획 검토, 공급자 오류 확인
첫 번째 계획에서 차이를 예상합니다. Terraform이 생성하는 것과 실제 Jamf 인스턴스 간에 차이를 보는 것이 정상입니다. 일부 속성은 콘솔에 표시되는 것과 일치하지 않는 값을 표시할 수 있으며, 일부 선택적 필드에는 공급자가 채우는 기본값이 라이브 구성과 다를 수 있으며, 공급자가 읽을 수 없는 쓰기 전용 필드로 인해 일부 리소스에 유효성 검사 오류가 있을 수 있습니다. 이는 jamformer의 버그가 아닌 공급자 수준의 특이성이며 수동 주의가 필요합니다.
계획 출력을 진행하여 오류를 수정하고 Terraform이 보고하는 것이 만족할 때까지 속성을 조정합니다. 이 검토 프로세스는 공급자가 리소스를 나타내는 방법에 대해 가장 많이 배우는 곳입니다 - Terraform에 제어를 건네기 전에 중요한 단계입니다.
계획이 깔끔해 보이면:
terraform apply # state에 리소스 가져오기(확인하라는 메시지가 표시됨)
terraform apply를 실행하면 기존 리소스를 Terraform state로 가져옵니다. Jamf에서 아무 것도 변경하지 않습니다 - Terraform에만 알려줍니다. "이러한 리소스가 이미 존재하고 다음과 같습니다."
성공적으로 적용한 후 가져오기 블록이 작업을 완료했습니다. 제거할 수 있습니다:
rm *_import.tf
그런 다음 terraform plan을 다시 실행합니다. 이상적으로 변경 사항이 없습니다. 차이가 나타나면 이는 공급자의 기본값이 실제로 Jamf에 있는 것과 정확히 일치하지 않는 경우입니다 - 깨끗한 계획을 얻을 때까지 생성된 HCL을 조정합니다.
이 시점에서 Jamf 환경을 나타내는 Terraform 프로젝트를 갖게 됩니다. Git에 커밋하고 실제 작업을 시작할 준비가 되었습니다: 구성을 리팩터링하고, 팀의 워크플로우에 맞게 구성하고, 콘솔을 통해 변경을 하는 대신 끌어오기 요청, 코드 검토 및 terraform apply를 통해 변경을 천천히 진행합니다.
기억해야 할 사항
기본적으로 jamformer는 Cloud Distribution Point에서 패키지를 다운로드합니다. 많은 패키지가 있는 대형 환경의 경우 시간이 걸릴 수 있습니다. 이 단계를 건너뛰고 패키지를 별도로 처리하려면 -skip-package-downloads를 사용하세요.
비밀 스캔은 생성 후 자동으로 실행됩니다. 직접 비밀 관리하거나 헤드리스 환경에서 실행하려면 -skip-secret-scan을 사용하세요. 기본 제공 스캔을 건너뛰더라도 Git에 커밋하기 전에 어떤 형태의 비밀 감지를 실행하는 것을 강력히 권장합니다.
압축 모드(-compact)는 순수 미용입니다 - HCL의 형태를 변경하지만 Terraform이 수행하는 작업은 변경하지 않습니다. 원하는지 확실하지 않으면 없이 시작하고 두 번째 실행에서 시도해보십시오. -compact-include 및 -compact-exclude를 사용하여 다른 항목을 평면으로 두고 특정 리소스 유형을 대상화할 수도 있습니다.
생성된 provider.tf에는 Terraform이 다운로드한 공급자 버전을 기반으로 한 최소 버전 제약(>= X.Y.Z)이 포함됩니다. 정확한 버전을 고정하려면 -provider-version 1.2.3을 사용하세요.
Jamf Protect 및 Jamf Platform은 terraform query 지원을 위해 Terraform 1.14+ 필요합니다. jamformer는 자동으로 다운로드하지만 자신의 Terraform 바이너리를 -terraform-path를 통해 제공하는 경우 알아두면 좋습니다.
다음은?
이 시리즈를 따라가셨다면 처음부터 Terraform을 작성하는 방법, 전용 공급자와 Jamf Protect 및 Jamf Platform 구성 관리 방법, 그리고 이제 기존 환경을 다시 시작하지 않고 Terraform 관리하에 가져오는 방법을 보셨습니다. 앞으로 더 있을 것입니다 - 공급자 및 도구가 계속 진화할 때 향후 글에서 추가 주제를 다룰 것입니다.
우리는 jamformer에 적극적으로 작업하고 있으며 피드백을 수집하고 있습니다. 시도해보신다면 작동하는 것과 작동하지 않는 것을 알려주고 싶습니다. GitHub 저장소에서 문제를 열거나 Jamf Nation에서 연락해주세요.