LabHub
배우기 러닝패스 코스

CBA — Backstage 인증 어소시에이트 · 카탈로그 품질과 정합성 진단 · 실습

카탈로그에 올린 서비스가 조용히 사라진다

LabHub 에서 이어서 보기

목표

VM 안에 진짜 카탈로그 백엔드를 띄우고, 엔티티가 카탈로그에 들어오지 않는 네 가지 원인을 직접 만들어
어디에 흔적이 남는지 찾습니다. 정적 location 자동 수집, API 로 등록하는 location, 고아 엔티티 정리,
location 삭제까지 실제 API 응답으로 확인합니다.

왜 중요한가

"catalog-info.yaml 을 올렸는데 포털에 안 보여요" 는 Backstage 운영에서 가장 흔한 문의입니다.
검증 라이브러리로 YAML 한 개를 확인하는 것만으로는 부족합니다. 돌아가는 카탈로그에서는 실패가
API 응답에도, 기본 로그에도 드러나지 않는 경우가 있고, 한 엔티티의 문제가 같은 파일 전체를 막기도 합니다.
등록 API 가 201 을 돌려줘도 처리 단계에서 실패할 수 있습니다. 어디를 봐야 하는지 알아야 고칠 수 있습니다.

처음 VM 이 뜨는 데 4분쯤 걸리고, 1단계 설치는 인터넷에서 약 30초 걸립니다.
GitHub 같은 외부 시스템을 훑는 탐색(discovery) 공급자는 외부 계정이 필요해 다루지 않습니다.
여기서 "자동 수집" 은 설정에 적은 location 을 카탈로그가 주기적으로 다시 읽는 것입니다.

단계

1. /usr/local/cba-ingest 에 카탈로그 백엔드 패키지를 고정 버전으로 설치합니다.
2. 설정에 적은 파일 location 이 자동으로 수집되는 것을 확인합니다.
3. owner 가 빠진 엔티티가 흔적 없이 빠지는 것을 기록합니다.
4. 로그 모듈을 붙여 처리 오류를 warn 로그로 끌어냅니다.
5. 허용되지 않은 kind 가 파일 전체를 막는 것을 보고 location 별 규칙으로 풉니다.
6. API 로 url location 을 등록하고, 읽기 허용 목록 문제를 고칩니다.
7. 파일에서 뺀 엔티티가 고아가 됐다가 지워지는 것을 봅니다.
8. location 을 지우고 수집 장애 보고서를 씁니다.

참고

단계 8개

  1. 돌아가는 카탈로그의 재료를 고정 버전으로 받는다
  2. 설정에 적은 파일이 자동으로 수집된다
  3. owner 를 빠뜨린 엔티티는 흔적 없이 빠진다
  4. 처리 오류를 로그로 끌어낸다
  5. API 하나 때문에 파일 전체가 안 들어온다
  6. 등록은 201 인데 아무것도 들어오지 않는다
  7. 파일에서 뺀 엔티티는 고아가 됐다가 지워진다
  8. location 을 지우고 수집 장애 보고서를 쓴다