카탈로그가 실제로 거절하는 것을 본다

이 실습은 Backstage 의 진짜 라이브러리에서 돕니다

VM 안에 Backstage 의 카탈로그·설정 라이브러리가 설치돼 있습니다.
catalog-info.yaml 을 넣으면 실제로 검증되고, 잘못된 것은 거절되고, 여러
app-config.yaml 이 실제로 병합됩니다.

Backstage 인스턴스를 통째로 띄우지 않습니다 — 그건 수백 MB 와 몇 분의
빌드가 걸립니다. 대신 카탈로그에 넣을 때 쓰는 바로 그 라이브러리를
직접 돌립니다. 검증도 병합도 관계 해석도 진짜입니다.

앞 모듈의 카탈로그 실습은 catalog-info.yaml 을 쓰는 연습까지였습니다.
그 YAML 이 실제로 통과하는지는 확인할 방법이 없었습니다.

처음 뜨는 데 4분쯤 걸립니다(npm install 이 인터넷을 탑니다).

준비된 것

프로젝트    /opt/cba (Backstage 라이브러리 설치됨)검증 도구   validate-entity <yaml파일>라이브러리  /opt/cba/lib.js (catalog-model·config·yaml)

단계

1. 엔티티 하나를 만들고 검증을 통과시켜 /root/cba/entity.txt 에 담으세요.
2. 잘못된 엔티티가 실제로 거절되는 것을 /root/cba/reject.txt 에 담으세요.
3. 엔티티 참조(parseEntityRef)로 관계가 어떻게 풀리는지 /root/cba/refs.txt 에 담으세요.
4. 소유자·시스템으로 여덟 종류 엔티티를 이어 /root/cba/graph.txt 에 담으세요.
5. 여러 app-config.yaml 을 병합해 무엇이 이기는지 /root/cba/config.txt 에 담으세요.
6. 환경 변수 치환(${...})이 어떻게 도는지 /root/cba/env.txt 에 담으세요.
7. 카탈로그 전체를 훑어 정합성을 진단해 /root/cba/audit.txt 에 담으세요.
8. /root/cba/report.md 에 valid=, rejected=yes, merge_winner= 세 줄과 설명을 쓰세요.

참고

• validate-entity good.yaml 로 검증합니다. 통과면 OK:, 실패면 REJECTED: 가 나옵니다.
• 스크립트는 node script.js 로 돌리고, 라이브러리는 require('/opt/cba/lib.js') 로 씁니다.
• 흔한 오해: 스키마가 통과하면 유효하다는 것. 정책(이름 형식·루트 필드)이 더 걸러 냅니다.
• 흔한 오해: 설정은 마지막 파일이 전부를 덮어쓴다는 것. 키 단위로 깊게 병합됩니다.

단계 8개

1. 카탈로그에 넣을 엔티티
2. 스키마만으로는 부족하다
3. 참조가 관계를 만든다
4. 여덟 종류를 잇는다
5. 설정은 깊게 병합된다
6. 설정 안의 환경 변수
7. 카탈로그는 시간이 지나면서 썩는다
8. 무엇을 배웠나