core 박스를 공용 Alloy 블록으로 이전, 컨테이너 관측 라벨·이름 정리#748
Conversation
- Alloy config·기동의 SSOT 를 TeamPiKi/infra blocks/alloy 로 이관 (#743). deploy.yml 은 checkout 된 블록을 healthcheck 블록과 같은 패턴으로 SCP 하고(upload_alloy step id 유지로 실패 분기 무변경), provision-runtime.sh 4절은 인라인 docker run 을 블록 호출(--environment/--box piki-core)로 축소 — skip 가드·validate 게이트·호스트 마운트는 블록이 책임. core repo 의 infra/alloy/config.alloy 삭제 - 수집 대상이 컨테이너 label opt-in 으로 바뀌어 EXTRACTOR_METRICS_TARGET cross-box scrape 를 폐기(extractor prod 박스는 자체 Alloy 가 수집)하고, 앱 컨테이너에 piki.observe/piki.service=piki-core/piki.metrics.port(슬롯 포트)/piki.metrics.path 라벨 부여 - 컨테이너명 team3-blue/green → piki-core-blue/green. 슬롯 판별이 nginx upstream 포트 기반이라 이름과 무관하지만, 첫 배포 전환기에 구명 컨테이너가 슬롯 포트를 물거나(run 충돌) switch 후 살아남는(906Mi 박스 메모리 압박) 사각이 있어 구명 stop/rm 을 전환기 가드로 함께 둠 — 전 환경 개편 배포가 한 바퀴 돈 뒤 제거 가능. 구 수집기(team3-alloy)·/etc/alloy-team3 도 같은 방식으로 정리 - Loki container 라벨이 컨테이너명에서 파생되므로 대시보드 로그 쿼리 5곳을 (team3|piki-core)-(blue|green) 양쪽 매칭으로 전환 (#727 의 application 양쪽 매칭과 같은 결). nginx upstream 파일명·로그 디렉토리는 컨테이너명이 아니라 의도적으로 스코프 밖 - dev 동거 extractor 컨테이너 라벨은 core 에 기동 경로가 없어(수동 기동) 운영 절차로 분리 — PR 본문에 명시
|
Discord 스레드 연동용 메타데이터입니다. discord-pr-bot 워크플로가 자동 생성하며, 수정·삭제하면 PR 과 Discord 알림 연동이 끊깁니다. |
Walkthroughcore 배포가 공통 Alloy 블록을 사용하고 ChangesCore 관측 구조 전환
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant DeployWorkflow
participant ProvisionRuntime
participant ProvisionAlloy
participant AlloyContainer
participant CoreContainer
participant Grafana
DeployWorkflow->>ProvisionRuntime: 공용 Alloy 블록과 piki-core 배포 실행
ProvisionRuntime->>ProvisionAlloy: Alloy 프로비저닝 인자 전달
ProvisionAlloy->>AlloyContainer: 구성 적용 및 기동
DeployWorkflow->>CoreContainer: piki-core 슬롯 기동 및 관측 라벨 부여
Grafana->>CoreContainer: team3 또는 piki-core 로그 시계열 조회
연결 이슈 평가
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@infra/scripts/provision-runtime.sh`:
- Around line 137-143: Update the cleanup flow before the `provision-alloy.sh`
invocation to stop suppressing errors from `docker rm -f team3-alloy`. Allow
removal failures to fail provisioning, while preserving successful behavior when
the legacy container does not exist; ensure a previously existing `team3-alloy`
is confirmed removed before starting `piki-alloy`.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro Plus
Run ID: 081498a5-37ae-4994-b163-4a0220816732
📒 Files selected for processing (6)
.github/workflows/deploy.ymlinfra/alloy/config.alloyinfra/grafana/README.mdinfra/grafana/dashboard.jsoninfra/scripts/provision-runtime.shsrc/main/resources/application.yml
💤 Files with no reviewable changes (1)
- infra/alloy/config.alloy
| docker rm -f team3-alloy 2>/dev/null || true | ||
| sudo rm -rf /etc/alloy-team3 | ||
| bash /tmp/piki-blocks/alloy/provision-alloy.sh \ | ||
| --config /tmp/piki-blocks/alloy/config.alloy \ | ||
| --name piki-alloy \ | ||
| --environment "${ENVIRONMENT:?ENVIRONMENT 미주입 — deploy.yml envs 확인}" \ | ||
| --box piki-core |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
기존 Alloy 삭제 실패를 무시하지 마세요.
team3-alloy가 남은 상태에서 piki-alloy를 기동하면 두 수집기가 같은 로그·메트릭을 전송할 수 있습니다. Line 137의 || true는 Docker 오류까지 숨기므로, 컨테이너가 존재했다면 제거 성공을 확인하지 못할 경우 프로비저닝을 실패시켜야 합니다.
수정 예시
-docker rm -f team3-alloy 2>/dev/null || true
+if docker inspect team3-alloy >/dev/null 2>&1; then
+ if ! timeout 30 docker rm -f team3-alloy; then
+ echo "legacy team3-alloy 제거 실패"
+ exit 1
+ fi
+fiAs per path instructions, “데이터 정합성 — 트랜잭션 범위, 동시성(race, lost update), 상태 변경 원자성”과 운영 리스크를 우선 검토했습니다.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| docker rm -f team3-alloy 2>/dev/null || true | |
| sudo rm -rf /etc/alloy-team3 | |
| bash /tmp/piki-blocks/alloy/provision-alloy.sh \ | |
| --config /tmp/piki-blocks/alloy/config.alloy \ | |
| --name piki-alloy \ | |
| --environment "${ENVIRONMENT:?ENVIRONMENT 미주입 — deploy.yml envs 확인}" \ | |
| --box piki-core | |
| if docker inspect team3-alloy >/dev/null 2>&1; then | |
| if ! timeout 30 docker rm -f team3-alloy; then | |
| echo "legacy team3-alloy 제거 실패" | |
| exit 1 | |
| fi | |
| fi | |
| sudo rm -rf /etc/alloy-team3 | |
| bash /tmp/piki-blocks/alloy/provision-alloy.sh \ | |
| --config /tmp/piki-blocks/alloy/config.alloy \ | |
| --name piki-alloy \ | |
| --environment "${ENVIRONMENT:?ENVIRONMENT 미주입 — deploy.yml envs 확인}" \ | |
| --box piki-core |
🧰 Tools
🪛 ast-grep (0.44.1)
[warning] 138-138: Writing to or reading from a hardcoded, predictable path under /tmp is vulnerable to symlink and TOCTOU attacks: a local attacker can pre-create the file (or a symlink pointing elsewhere) and hijack or corrupt the contents. Generate a unique, unpredictable temporary file with mktemp instead, e.g. tmpfile="$(mktemp)" (or mktemp -d for directories) and reference "$tmpfile".
Context: /tmp/piki-blocks/alloy/provision-alloy.sh
Note: [CWE-377] Insecure Temporary File.
(predictable-tmp-file-bash)
[warning] 139-139: Writing to or reading from a hardcoded, predictable path under /tmp is vulnerable to symlink and TOCTOU attacks: a local attacker can pre-create the file (or a symlink pointing elsewhere) and hijack or corrupt the contents. Generate a unique, unpredictable temporary file with mktemp instead, e.g. tmpfile="$(mktemp)" (or mktemp -d for directories) and reference "$tmpfile".
Context: /tmp/piki-blocks/alloy/config.alloy
Note: [CWE-377] Insecure Temporary File.
(predictable-tmp-file-bash)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@infra/scripts/provision-runtime.sh` around lines 137 - 143, Update the
cleanup flow before the `provision-alloy.sh` invocation to stop suppressing
errors from `docker rm -f team3-alloy`. Allow removal failures to fail
provisioning, while preserving successful behavior when the legacy container
does not exist; ensure a previously existing `team3-alloy` is confirmed removed
before starting `piki-alloy`.
Source: Path instructions
Situation
infra/alloy/config.alloy, 서비스 열거 regex(team3-(blue|green)), cross-box scrape(EXTRACTOR_METRICS_TARGET).Task
team3-blue/green컨테이너명 잔재를piki-core-blue/green으로 정리하되, 첫 배포 전환기에 구명 컨테이너가 만드는 사각(슬롯 포트 충돌, switch 후 생존)을 막는다.Action
piki-infra/blocks/alloy/(config + 기동 스크립트) 업로드로 교체 (배포 이미지명을 piki-core 로 통일하고 헬스체크를 공용 블록으로 실배선 #723 healthcheck 블록과 같은 패턴,upload_alloystep id 유지라 실패 분기 무변경).provision-runtime.sh4절은 인라인docker run65줄을 블록 호출 5줄(--environment $ENVIRONMENT --box piki-core)로 축소. skip 가드·validate 게이트·호스트 마운트·Running 확인은 블록이 책임진다. repo 의infra/alloy/config.alloy는 삭제 (SSOT 는 infra repo).piki.observe/piki.service=piki-core/piki.metrics.port=<슬롯 포트>/piki.metrics.path=/actuator/prometheus부여.EXTRACTOR_METRICS_TARGETcross-box scrape 는 폐기 (extractor prod 박스는 자체 Alloy 가 수집).team3-blue/green→piki-core-blue/green, 수집기team3-alloy→piki-alloy(블록 기동). 슬롯 판별은 nginx upstream 포트 기반이라 이름 변경과 무관하다. 전환기 가드: 첫 배포에서 구명(team3-*) 컨테이너가 슬롯 포트를 물면 run 이 충돌하고, switch 후 살아남으면 906Mi 박스에 메모리 압박이 되므로, 구명 stop/rm 을 새 이름과 나란히 둔다 (없으면 no-op, 전 환경 개편 배포 한 바퀴 후 제거 가능 — 주석 명시).container라벨이 컨테이너명에서 파생되므로 대시보드 로그 쿼리 5곳을(team3|piki-core)-(blue|green)으로 (telemetry 식별자를 piki-core 로 rename, 전환기 대시보드 양쪽 매칭 #727 의 application 매칭과 같은 결). README·application.yml 의 낡은 표기(application="PIKI", team3 산문)도 정리.team3-upstream.conf)·로그 디렉토리(/var/log/team3)는 컨테이너명이 아닌 박스 로컬 경로라 유지 — 슬롯 판별의 source of truth 를 건드리면 전환기 오판(서빙 포트에 배포) 위험이 생겨서다.Result
piki.observe=true,piki.service=piki-extractor,piki.metrics.port=8090,piki.metrics.path=/actuator/prometheus)을 부여해야 메트릭·로그가 잡힌다. (2) 전환기 가드·대시보드 양쪽 매칭은 전 환경 개편 배포가 돈 뒤 정리. (3) 갱신된 dashboard.json 재import.연관 이슈
Summary by CodeRabbit
배포 개선
관측성 개선
문서