그렇게 생각하는 것 같아요 
이 PR이 병합되기를 기다린 후, 아래에 나열된 단계를 따르세요:
대략 100GB 정도입니다 
그렇게 하겠습니다
이 업그레이드를 자동화하는 방안을 검토하면서, 배포 후 스킵(skip-post-deployment) 처리를 언제 수행해야 하는지 판단하는 것이 상당히 복잡하다는 생각이 듭니다.
단일 컨테이너 설치의 경우, 이상한 마이그레이션(4년 동안 처음 듣는 경우입니다)이 없는 한 이 방식으로 수행할 이점이 없습니다. 대부분의 업그레이드는 마이그레이션이 적으며, 계산 집약적인 마이그레이션은 거의 없을 것입니다.
이중 컨테이너 설치의 경우, 마이그레이션이 실행 중인 컨테이너를 깨뜨리면 사이트를 비활성화할 수 있으므로 SKIP_POST_DEPLOYMENT_MIGRATIONS를 사용하는 것이 항상 좋은 아이디어입니다. 이는 구 컨테이너가 계속 실행되는 동안 새 컨테이너를 부트스트랩할 수 있다는 장점에서 오는 일부의 즐거움을 빼앗아 가지만요. 하지만 그렇다고 해서 모든 업그레이드가 문제를 일으키는 마이그레이션을 포함하는 것은 아니므로, 이(매우 환영할 만한) 커밋에서 제공하는 두 번 재부팅하는 솔루션은 단순히 위험을 감수하는 것보다 더 많은 다운타임(두 번의 재부팅 사이클)을 초래할 가능성이 큽니다.
현재 제 생각으로는, 더 나은 해결책은 부트스트랩이 항상 SKIP_POST_DEPLOYMENT_MIGRATIONS=1로 마이그레이션을 수행한 후 첫 번째 부팅 시 마이그레이션을 실행하는 것일 것입니다. 다만 이것이 어떻게 작동할지에 대한 우아한 해결책은 아직 없습니다. 마이그레이션이 대기 중인지 빠르게 확인할 수 있는 방법이 있을까요? unicorn을 시작하는 직후에 "마이그레이션이 대기 중이면 마이그레이션을 실행한다"는 로직을 부트 스크립트에 추가할 수 있을 것 같습니다. 하지만 이는 상당히 까다로우며, 대부분의 설치 환경에서 대부분의 시간 동안은 가치가 없을 가능성이 높습니다.
대부분의 경우 굳이 그럴 가치가 없지만, 소프트웨어 업그레이드가 드물지만 가끔 정상 시간의 10배나 걸리는 경우가 있다면, 이는 많은 사용자에게 실질적인 문제가 됩니다.
이 일을 겪은 후에는 최소한 릴리스 후 일주일까지는 디스코URS 업그레이드를 하지 않겠습니다. 물론 처음부터 기다리지 않은 건 내 실수라고 반박할 수 있고, 내가 자초한 거라며 더 잘 알았어야 한다고 할 수도 있습니다. 그리고 그 말은 전부 옳습니다! 그래도 업그레이드 시간을 더 일관되고 예측 가능하게 만드는 것은 나와 같은 다른 '바보들’에게 훌륭한 서비스일 것입니다.
대안으로, docker_manager를 통해 UI로 업그레이드를 수행하면 이 과정이 자동으로 처리됩니다.
정말 멋진데요! 저는 거의 그렇게 업그레이드하지 않아서 그런 방법을 생각조차 못 했어요. 감사합니다.
죄송합니다, 명확히 하자면, 이 환경 변수를 앱 컨테이너에 추가하면:
아래 중 하나:
SKIP_POST_DEPLOYMENT_MIGRATIONS: true
또는
SKIP_POST_DEPLOYMENT_MIGRATIONS: 1
런처를 실행할 때 재빌드 시 모든 DB 마이그레이션을 건너뛰게 되는 건가요?
이렇게 이해하는 것이 맞나요?
아니요. Introducing Post Deployment Migration 를 참조하세요.
안녕하세요, 이 방법(UI를 통해)으로 모든 것을 업데이트하는 데 성공했지만, 이후로 처음부터 건너뛴 마이그레이션 지침이 포함된 배포(deployment) 과정이 시작되고, 잠시 후 업그레이드가 성공하지 못했다는 오류 메시지와 함께 중단됩니다. 그러나 포럼은 정상적으로 작동하며, 관리자 대시보드에서도 모든 것이 업데이트된 것으로 표시됩니다.
질문은 이렇습니다: 제가 추가로 해야 할 일이 있나요? 특히 이 배포 과정에 대해, 충돌을 피하기 위해 명령줄을 통해 실행해야 하나요? 특정 명령어가 있으며, 실행 중 포럼이 중단될까요?
관련 로그가 아직 있나요? 마이그레이션을 실행하지 않으면 사이트에서 검색 기능이 정상적으로 작동하지 않습니다.
./launcher enter app
bundle exec rails db:migrate
로그는 없지만, 이 토픽에서 이전에 언급했던 것과 동일한 쿼리였습니다.
이 과정을 시작하고 그대로 실행을 계속할 경우, 웹사이트가 일시적으로 중단될까요(재구축처럼)? 아니면 "안전"한가요? 이 특정 문제에 대해 반복적으로 질문하는 것이 죄송하지만, 이는 운영 중인(production) 웹사이트이며 10~15분의 다운타임은 허용할 수 있지만, 하루 이틀은 허용할 수 없으며 다른 대안이 없다면 신중하게 고려해야 합니다.
이미 최신 버전으로 업그레이드했다면, 마이그레이션을 실행하더라도 사이트에 다운타임이 발생하지 않습니다. 여기서 '업그레이드’란 새로운 버전이 배포되었지만 이 주제에서 언급한 배포 후 마이그레이션이 실패한 상태를 의미합니다.
감사합니다. 결국 UI를 통해 업데이트를 다시 진행했는데, 한 번 더 시도하자 배포 후 데이터베이스 마이그레이션이 실제로 완료되었습니다. 몇 시간(그리고 CPU 사용량도 상당했죠 
)이 걸렸지만 모두 완료되었고, 이제 모든 것이 완전히 업데이트되었습니다! 