관리 콘솔로만 볼 수 있는 자료가 있었는데 그 콘솔이 특정 브라우저에서만 열렸다. 그 브라우저를 쓸 수 없는 환경에서 급하게 확인할 일이 생겼고 그 자리에서 아무것도 못 했다.
Table of contents
Open Table of contents
문제 — 하나뿐인 줄 알았던 경로
방법이 하나뿐이라고 알고 있었는데 실제로는 찾아보지 않은 것이었다. 문서를 열어 보니 같은 자료에 접근하는 경로가 콘솔 말고도 REST API 와 CLI 와 SDK 셋이나 더 있었다.
접근 경로가 하나면 그것이 안 될 때 할 수 있는 일이 없어진다. 이 상황이 위험한 이유는 하필 급할 때 그 하나가 막히기 때문이다.
해결 — 스크립트로 접은 조회
콘솔에서 클릭으로 보던 목록을 curl 과 jq 를 묶은 list-instances 한 명령으로 만들어 두니 콘솔보다 빨랐다. 그리고 결과가 stdout 으로 나오므로 다른 명령에 파이프로 그대로 넘길 수 있었다.
jq 'select(.status != "running")' 로 이상한 것만 걸러 상세를 이어서 조회하는 일이 한 줄로 끝난다. 화면에서 하던 반복 작업이 조합 가능한 단위로 바뀐 것이 실제 이득이었다.
주의 — 토큰 캐시와 파일 권한
두 가지 방법이 있었는데 매 호출마다 토큰을 발급받는 것과 한 번 받아 ~/.cache/ 아래 파일로 두고 만료 전까지 재사용하는 것이다. 뒤쪽을 골랐다. 이유는 매 호출 발급은 느리고 발급 자체가 분당 제한에 걸려서다. 대신 토큰이 디스크에 남는 것을 감수하고 그 파일의 권한을 좁혔다.
umask(2) 매뉴얼대로 umask 는 open(2) 이 새 파일에 주는 권한에서 마스크 비트를 끄므로 스크립트 첫 줄에 umask 077 을 두어 생성 시점부터 600 이 되게 했다. 편의를 위해 만든 캐시가 노출 경로가 되면 원래 문제보다 나쁘다.
콘솔에만 있는 것의 목록
전부가 프로그래밍 경로로 되는 것은 아니어서 사용량 그래프와 청구 내역은 콘솔에만 있었다. 그래서 무엇이 콘솔 전용인지를 CONSOLE-ONLY.md 에 목록으로 적어 두었다.
적어 두니 이것도 자동으로 되지 않느냐는 물음을 다시 조사하지 않게 됐다. 없다는 것을 확인한 사실과 찾아보지 않은 상태는 겉보기에 같지만 다음 사람에게는 전혀 다르다.
권한이 다르면 대체가 아니다
경로를 넓히고 나서 권한이 같지 않다는 것을 확인했는데 발급한 토큰은 read-only 범위였다. 급할 때 설정을 바꿔야 하면 여전히 콘솔이 필요한 상태였다.
접근 경로가 여럿이어도 권한이 다르면 완전한 대체가 아니다. 그래서 평소 스크립트용 read-only 토큰과 따로 보관하는 write 토큰으로 나누고 write 토큰은 사용 기록을 남기게 했다.
정리
- 접근 경로가 하나면 그것이 막힐 때 아무것도 못 한다
- 하나뿐인 줄 알았던 것이 찾아보지 않은 것일 수 있다
- 자주 보는 조회를 명령으로 접으면 조합이 가능해진다
- 토큰을 캐시하되
umask 077로 파일 권한을 좁힌다 - 프로그래밍 경로로 안 되는 항목을 목록으로 적어 둔다
- 없다고 확인한 것과 안 찾아본 것은 다르다
- 경로가 여럿이어도 권한이 다르면 대체가 아니다
- 변경 권한은 따로 보관하고 사용 기록을 남긴다