내부 API에 새 엔드포인트를 배포하고 정말 떴는지 확인해야 했는데 검증 경로가 둘 다 막혔다. 이 서비스는 ALB 없이 내부 전용이라 밖에서 못 부르고 컨테이너 안에는 curl이 없어서 설치하려면 승인이 필요했다.
Table of contents
Open Table of contents
문제 — 태그가 증명하지 못하는 것
남은 것이 aws ecs describe-tasks 조회였고 태스크가 :latest 이미지로 돌고 있다는 결과가 나왔다. 이것으로 충분한지를 따져 보니 아니었다.
:latest가 옛 이미지를 가리킬 수 있기 때문이다. 빌드가 실패했거나 푸시가 안 됐는데 태그는 그대로 남아 있을 수 있다. 태그는 이름일 뿐 내용을 보장하지 않는다.
주의 — 재시작 시각도 증거가 아니다
방금 재시작했으니 새 코드일 것이라는 추론도 성립하지 않았다. 재시작은 이미지를 다시 받는 것과 다른 일이다.
캐시된 이미지로 뜰 수도 있고 태그가 옛것을 가리켜도 재시작 자체는 성공한다. 무언가 일어났다는 것과 의도한 것이 일어났다는 것은 다르다.
검증 — 다이제스트 3자 대조
두 가지 방법이 있었는데 설치 승인을 받아 컨테이너 안에서 직접 호출하는 것과 이미지의 sha256 다이제스트로 배포 사실을 증명하는 것이다. 뒤쪽을 골랐다. 이유는 승인을 기다리면 배포 확인이 하루 넘게 밀려서다. 대신 함수가 실제로 동작하는지는 이 방법으로 못 보는 것을 감수했다. describe-tasks의 imageDigest와 aws ecr describe-images의 최신 imageDigest를 각각 조회해 일치를 확인했다. AWS CLI 공식 문서가 두 명령 모두 그 필드를 내보낸다고 적고 있다.
여기에 하나를 더 이었는데 CI 빌드 기록에서 그 다이제스트를 만든 커밋을 git log로 찾아 내가 추가한 파일이 든 병합 커밋임을 확인했다. 셋이 이어지면 내 코드가 실행 중이라는 것이 증명되는데 각각은 약하고 셋을 이어야 강해진다.
제약 — 명시한 한계
여기서 멈추지 않고 한계를 적었다. 이 대조로 증명되는 것은 그 코드가 떠 있다는 것까지이고 그 함수가 정상 동작한다는 것은 아니다.
호출 검증은 주기 배치가 돌 때 사후에 로그로 실증된다. 그래서 보고에 내부 전용 서비스의 배포 검증은 다이제스트 대조까지가 도달 가능한 최대치라고 적었다. 함수 호출 검증은 주기 배치 실행 시 사후 실증된다고 덧붙였다. 한계를 안 적으면 검증 완료라는 말이 과대 진술이 된다.
조치 — 남긴 명령과 검증 순서
확인에 쓴 조회 명령을 그대로 기록에 남겼다. 특히 imagePushedAt으로 정렬해 마지막을 뽑는 --query 'sort_by(imageDetails,&imagePushedAt)[-1]' 표현식은 매번 다시 짜기 번거로운 것이라 그대로 붙여 뒀다.
검증 순서도 정리했는데 직접 호출이 최선이고 안 되면 로그로 검증한다. 그것도 안 되면 배포 사실을 다이제스트로 검증한 뒤 어디까지 검증됐는지를 명시한다. 마지막 단계가 있어야 앞의 셋 중 어디서 멈췄는지를 다음 사람이 알 수 있다. 검증 완료라고만 쓰면 어떤 검증인지 알 수 없다.
정리
:latest태그는 이름일 뿐 내용을 보장하지 않는다- 재시작 시각도 증거가 아니다
- 무언가 일어난 것과 의도한 것이 일어난 것은 다르다
- 증거는 이미지
imageDigest다 - 실행 중 태스크와 레지스트리 최신과 그 커밋을 3자 대조한다
- 각각은 약하고 셋을 이어야 강하다
- 어디까지 검증됐는지 한계를 명시한다
- 확인 명령을 남기면 다음에 다시 짜지 않는다