왜
이 박스의 Alloy 설정이 배포와 무관하게 옛 상태로 남는다. provision-observability.sh 가 이미 필요한 일(infra 공통 블록 fetch → SSM 자격 로드 → 자기 박스 값으로 호출)을 전부 하지만, 배포 워크플로가 그것을 호출하지 않아 박스에서 사람이 수동 실행할 때만 반영된다.
2026-08-13 TeamPiKi/infra#44 로 Alloy config 를 감축(수집 주기 60s·카디널리티 누수 차단·collector 41→12)했는데, 이 박스는 재배포를 해도 그대로였다. 실측:
| 박스 |
collector 수 |
| piki-core / dev (core 배포가 Alloy 프로비저닝을 포함) |
12 (반영) |
| 이 박스 |
41 (미반영) |
core 는 deploy.yml 이 provision-runtime.sh 를 통해 매 배포 Alloy 를 갱신하는데, 이 repo 에는 그 단계가 없어 생긴 비대칭이다. 그 결과 공용 config 를 고쳐도 5개 박스 중 2개(core dev·prod)에만 퍼진다.
무엇을
deploy.yml 에 기존 provision-observability.sh 실행 단계를 추가한다.
Upload blocks 의 source 에 이 스크립트를 더해 박스로 올린다.- 앱 배포 앞에 실행 단계를 둔다 — core 와 같은 순서(provision → deploy)이고, 관측이 깨진 채 앱만 올라가는 상태를 막는다.
스크립트는 자기 완결적이라(공용 블록을 raw.githubusercontent 에서 직접 fetch) 추가 인자나 secret 이 필요 없다. 이후 infra 의 config 변경은 이 박스의 다음 배포에 자동으로 반영된다.
왜
이 박스의 Alloy 설정이 배포와 무관하게 옛 상태로 남는다.
provision-observability.sh가 이미 필요한 일(infra 공통 블록 fetch → SSM 자격 로드 → 자기 박스 값으로 호출)을 전부 하지만, 배포 워크플로가 그것을 호출하지 않아 박스에서 사람이 수동 실행할 때만 반영된다.2026-08-13 TeamPiKi/infra#44 로 Alloy config 를 감축(수집 주기 60s·카디널리티 누수 차단·collector 41→12)했는데, 이 박스는 재배포를 해도 그대로였다. 실측:
core 는
deploy.yml이provision-runtime.sh를 통해 매 배포 Alloy 를 갱신하는데, 이 repo 에는 그 단계가 없어 생긴 비대칭이다. 그 결과 공용 config 를 고쳐도 5개 박스 중 2개(core dev·prod)에만 퍼진다.무엇을
deploy.yml에 기존provision-observability.sh실행 단계를 추가한다.Upload blocks의 source 에 이 스크립트를 더해 박스로 올린다.스크립트는 자기 완결적이라(공용 블록을
raw.githubusercontent에서 직접 fetch) 추가 인자나 secret 이 필요 없다. 이후 infra 의 config 변경은 이 박스의 다음 배포에 자동으로 반영된다.