초기화되지 않은 TransferManager로 인한 백업 업로드 실패

지원 자체 호스팅
7

이 글에서 한 가지 생각해보는 점은, 이러한 임시 호환성 템플릿은 무기한으로 Discourse의 종속성을 덮어쓰는 것보다, 자체 만료/가드 조건이 있는 것이 더 안전할 수 있다는 것입니다.

예를 들어, 임시 소스 백포트를 위해 프로덕션에서 훅을 사용할 계획인데, 먼저 업스트림 수정 사항이 이미 존재하는지 확인하고, 여전히 필요한 경우에만 패치를 적용할 예정입니다.

이 경우, 다음과 같은 방식이 Discourse 자체가 더 새로운 SDK 기능을 의존하기 시작했을 때 오래된 aws-sdk-s3 1.177.0 고정(pin)이 계속 유지되는 것을 방지할 수 있었을 것입니다:

hooks:
  after_bundle_exec:
    - exec:
        cd: $home
        cmd:
          - |
            if grep -q "Aws::S3::TransferManager" lib/s3_helper.rb; then
              echo "Discourse now requires Aws::S3::TransferManager; skipping obsolete Backblaze aws-sdk-s3 downgrade"
            else
              echo "Applying temporary Backblaze aws-sdk-s3 compatibility pin"
              bundle config set frozen false
              sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
              bundle update aws-sdk-s3
              bundle add aws-sdk-core --version 3.215
            fi

해당 체크는 단순히 예시를 위한 것입니다. 더 일반적인 버전 체크나, Discourse가 예상 SDK 버전을 넘어갈 때 명시적으로 실패하도록 하는 것이 더 나은 방법이 될 것입니다.

Discourse가 기대하는 버전과 더 이상 일치하지 않는 gems를 가진 컨테이너를 조용히 생성하는 것보다, 크게 실패(fail loudly)하는 것이 훨씬 나을 것입니다.