LOGBREW_PROJECT_ID를 프로젝트 UUID로 설정하세요. LOGBREW_API_URL을 https://api.logbrew.co로 설정하세요. 예제는 Bash, curl 7.76.0 이상, jq를 사용합니다.
계획된 교체라면 이전 키를 해지하기 전에 새 키를 만들고, 배포하고, 테스트하세요. 교체 주기는 보안 정책에서 정하세요. 키에 만료일이 있으면 그 전에 교체하세요.
1
새 키 만들기
POST /api/projects/{project_id}/ingest-keys는 120자 이하의 비어 있지 않은 label을 받습니다. kind는 cli, sdk, browser, server, artifact 중 하나입니다. artifact 키로는 텔레메트리를 보낼 수 없습니다. 선택 사항인 expires_at은 미래의 RFC3339 시각이어야 합니다.이전 키와 같은 kind를 사용하세요. CLI는 --kind를 생략하면 sdk를, --label을 생략하면 CLI-created SDK key를 사용합니다. CLI에는 만료 플래그가 없습니다. expires_at을 설정하려면 API를 사용하세요.CLI는 한 번만 표시되는 토큰을 소스 관리 밖에 있는, 소유자만 접근할 수 있는 새 파일에 저장합니다. 토큰이 아니라 메타데이터를 출력합니다.NEW_KEY_ID를 반환된 ingest_key.id로 설정하세요.결과가 불확실하면 같은 명령어를 그대로 다시 실행하세요. CLI는 대기 중인 재시도 키를 다시 사용합니다. 이 재시도에는 --abandon-retry를 사용하지 마세요.API를 직접 호출하는 클라이언트는 응답에서 토큰을 한 번만 받습니다. 재시도하려면 같은 본문과 함께 같은 Idempotency-Key 헤더를 보내세요. 24시간 동안 이 재시도는 같은 키를 반환합니다. 토큰을 출력하거나 커밋하거나 공유하지 마세요.2
이전 키를 활성 상태로 둔 채 새 키 배포하기
새 토큰을 보호된 배포 설정에 넣으세요. 앱을 배포하세요. 이전 키는 활성 상태로 두세요. 두 토큰 모두 소스, 빌드 출력, 로그에 들어가지 않게 하세요.
3
테스트 이벤트 1개 보내기
새 토큰을 읽기 결과에 같은
new_ingest_key 셸 변수에 불러오세요. 출력하지 마세요. 새 키로 테스트 로그 1개를 보낸 다음 다시 읽으세요.occurred_at을 가진 이 로그가 나올 때만 다음 단계로 넘어가세요. 이전에 보낸 교체 확인 로그로는 새 키가 작동한다는 것을 증명할 수 없습니다. 배포된 앱이 텔레메트리를 보내는지도 확인하세요. 명령어가 실패하면 멈추고 응답을 읽으세요. 이전 키가 노출되지 않았다면 활성 상태로 두세요.4
시크릿이 없는 키 메타데이터 나열하기
계정 인증 정보로 응답은 토큰이 없는 키 메타데이터 배열입니다. 상태는
LOGBREW_ACCOUNT_BEARER를 설정하세요. 이전 키 ID를 찾으세요. NEW_KEY_ID가 active인지 확인하세요.active, expired, revoked 중 하나입니다. expires_at 시각이 지나면 키는 expired가 됩니다.5
이전 키만 해지하기
목록에서 찾은 값으로
OLD_KEY_ID를 설정하세요. 이 명령어는 두 ID가 다를 때만 이전 키를 해지합니다.DELETE는 멱등입니다. status: "revoked"와 revoked_at이 설정된 키 메타데이터를 반환합니다. 응답이 불확실하면 안전하게 반복할 수 있습니다.unset new_ingest_key를 실행하세요. 키 파일은 시크릿 정책에 따라 처리하세요.안전하게 복구하기
그래도 교체에 실패하면 문제 신고하세요. 키 메타데이터만 공유하세요. 자격 증명, 헤더, 원본 텔레메트리, 고객 데이터, 로컬 경로, 소스 코드는 넣지 마세요.
