English {#english}

Where to get and how to manage tenant_id and db_root_password when running Ansible. tenant_id comes from Control Plane/workflow, not Pulumi; db_root_password from secrets or generation. Ref: ansible-implementation-plan, provision-tenant-workflow-design, github-secrets. Full details: see Korean section below.

한국어 {#korean}

tenant_id·db_root_password 관리 가이드

목적: Ansible 실행 시 tenant_id, db_root_password를 어디서 가져오고, 어떻게 관리하면 좋은지 정리. 코드 생성 없음 — 운영·관리 관점만 안내.

Ref: ansible-implementation-plan, provision-tenant-workflow-design, github-secrets.

1. tenant_id

1.1 Pulumi에서 가져오면 될까?

아니요. Pulumi는 인프라만 다룹니다. 서버(IP), 방화벽, DNS, R2 등.
tenant_id는 “어떤 고객(테넌트)을 이 서버에 올릴지”를 나타내는 비즈니스/앱 식별자이므로 Pulumi에는 없습니다.

1.2 tenant_id는 어디서 오는가

상황	출처
자동화(워크플로)	Control Plane이 프로비저닝 요청을 만들 때 이미 정해진 값. `provision_jobs`·`tenants_master`에 있는 tenant_id를 workflow_dispatch 입력으로 넘김. 즉, 가입/오더 생성 시점에 부여된 테넌트 ID를 그대로 사용.
테스트/수동 실행	“이번에 프로비저닝할 테넌트”를 운영자가 정하면 됨. 예: 테스트용 `test-tenant-01`, 또는 실제 테넌트 UUID(Control Plane/D1에서 복사).

정리:

자동화: Control Plane(또는 가입·프로비저닝 플로우)이 만든 tenant_id를 워크플로 입력으로 전달.
수동: 테스트용은 임의 지정, 실제 테넌트는 D1/Control Plane/관리 화면에서 확인한 값을 사용.

1.3 관리 관점

tenant_id는 비밀값이 아님. 사이트명·canonical_hostname(tenant-xxxx.pregoi.com) 계산에 쓰일 뿐.
한 번에 하나의 테넌트만 프로비저닝하므로, 실행마다 “이번 job의 tenant_id” 하나만 정해지면 됨.
저장 위치: 워크플로 입력, D1 provision_jobs/tenants_master, 또는 수동 실행 시 터미널/스크립트 인자. 별도 시크릿 저장소에 넣을 필요는 없음.

2. db_root_password

2.1 역할

MariaDB root 비밀번호. Ansible이 bench new-site 할 때 원격 DB 서버에 접속하는 데 사용.
Phase 1에서는 DB 서버 한 대에 여러 테넌트가 DB(schema)만 나뉘어 있으므로, 한 개의 root 비밀번호로 모든 테넌트 사이트 생성에 공통 사용.

2.2 관리 측면에서 효율적인 방법

환경	권장 방식	이유
CI (GitHub Actions)	GitHub Secret `PREGO_DB_ROOT_PASSWORD`에 한 번 저장 → 워크플로에서 `-e db_root_password=${{ secrets.PREGO_DB_ROOT_PASSWORD }}` 로 전달	비밀번호가 코드·로그에 안 남음. 리전/스택이 같으면 하나의 시크릿으로 여러 테넌트 프로비저닝 가능.
로컬/테스트	(1) 환경 변수: `PREGO_DB_ROOT_PASSWORD`를 셸에만 설정하고, `-e db_root_password=$PREGO_DB_ROOT_PASSWORD` 로 전달. (2) ansible-vault: `group_vars` 등에 암호화된 변수 파일로 보관 후 `--ask-vault-pass`로 실행. (3) .env.local(prego-ansible 또는 공용 디렉터리)에만 두고 gitignore, 실행 스크립트에서 source 후 전달	히스토리/커밋에 안 넣기. 한 곳에서만 비밀번호 관리.
고급(선택)	HashiCorp Vault·AWS Secrets Manager 등에서 조회 후 `-e db_root_password=...` 로 주입	회사 정책상 시크릿 저장소를 쓸 때.

2.3 효율성 요약

한 DB 서버당 root 비밀번호 하나 → 시크릿도 리전/환경당 하나로 두면 됨. 테넌트 수만큼 비밀번호를 늘릴 필요 없음.
회전: 주기적으로 root 비밀번호 변경 시, MariaDB에서 비밀번호 변경 후 GitHub Secret(또는 사용 중인 저장소)만 갱신. Ansible 변수는 “그 시크릿을 읽어서 넘기는” 역할만 하면 됨.
노출 방지:
- -e db_root_password=... 를 직접 터미널에 치지 말고, 환경 변수나 시크릿에서 읽어서 넘기기.
- 로그·에러 메시지에 비밀번호가 찍히지 않도록 Ansible 측에서도 no_log: true 등 적용 권장(구현 시).

3. 요약 표

항목	어디서 가져오나	관리 방법
tenant_id	Pulumi 아님. Control Plane/가입·프로비저닝 플로우에서 정해진 값. 테스트는 임의 지정.	시크릿 아님. 워크플로 입력·D1·수동 입력으로만 전달하면 됨.
db_root_password	인프라/운영에서 정한 MariaDB root 비밀번호.	CI: GitHub Secret 1개(예: PREGO_DB_ROOT_PASSWORD). 로컬: env 또는 ansible-vault 또는 .env.local. DB 서버 단위로 하나만 두고 회전 시 해당 시크릿만 갱신.

이렇게 관리하면 tenant_id는 “이번에 프로비저닝할 테넌트”만 정하면 되고, db_root_password는 한 곳(시크릿/환경)에서만 관리하면서 재사용·회전이 쉬워집니다.