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