모듈
모듈 패키지는 Arkvory에 기능을 추가합니다. Arkvory는 서명을 검증할 수 있는 패키지만 설치합니다. 이 페이지의 명령은 설치가 있는 호스트에서 Linux에서는 root로, Windows에서는 관리자로 실행합니다. 콘솔과 HTTP API는 모듈을 설치하거나 키를 신뢰할 수 없으므로, 도난당한 콘솔 관리자 계정으로는 서버에서 코드를 실행할 수 없습니다.
서비스는 시작할 때마다 설치된 모듈을 다시 확인하고 로드합니다. 모듈은 활성화한 뒤에만 실행됩니다.
Arkvory Pro
Arkvory Pro는 무료 Arkvory 코어에 추가하는 선택적 유료 모듈 모음이며 ProAnimaStudio가 서명합니다. Pro 0.1.0은 Windows/Linux x64에서 Arkvory 0.6.3과 함께 작동합니다. 모듈 패키지와 라이선스는 ProAnimaStudio에서 받으며 코어와 별도로 설치합니다. 설치와 라이선스를 참고하세요.
- 중복 제거: 공유 청크를 한 번 저장하고 여러 객체에서 재사용합니다. 공유 카탈로그가 게시, 읽기, 백업과 가비지 수집을 조정합니다.
- 델타 전송: 호환 클라이언트에 이미 있는 내용을 재사용하고 없는 데이터나 패치를 전송합니다. 모음에는 서버 저장소·전송 모듈과 델타 클라이언트 모듈이 포함됩니다. 절감량은 데이터와 클라이언트에 따라 다르며 일반 HTTP 다운로드가 자동으로 델타 전송이 되지는 않습니다.
- 라이선스: 유료 쓰기와 최적화를 제어합니다. 라이선스가 만료되거나 사용할 수 없어도 기존 데이터는 읽을 수 있으며 새 업로드는 코어 저장소와 일반 전송을 사용합니다. Pro 할당량은 수락했지만 완료하지 않은 업로드를 포함한 Pro의 논리적 데이터 크기를 계산하며 중복 제거에 따른 할인은 없습니다. updatesUntil은 새 모듈 빌드를 사용할 권한을 제한합니다.
모듈은 서비스 시작 시 로드되며 Docker Compose 설치는 모듈을 로드하지 않습니다. 업그레이드 전 메타데이터와 모듈 데이터를 백업하세요. 공유 카탈로그를 처음 도입할 때 이전 API/worker 쓰기 프로세스를 중지하세요. 이전·새 쓰기 프로세스 혼용은 지원하지 않습니다. 데이터와 라이선스 상태를 함께 복원하고 복구를 기다린 후 새 Pro 업로드를 확인하고 정상 쓰기를 재개하세요.
큰 카탈로그 복구에는 시간이 걸립니다. 인수 환경에서는 공유 카탈로그가 이미 복원된 400만 청크가 재시작 없이 32분 43초 후 쓰기 가능해졌습니다. 이는 복구 시간 보장이나 4 TB 처리량 측정이 아닙니다. 단일 물리 호스트의 HA 검증은 실제 현장의 fencing 및 장애 도메인 검사를 대체하지 않습니다. Pro는 코어 라이선스 조건을 바꾸지 않습니다.
모듈 기능과 타사 플러그인
서명된 ProAnimaStudio 모듈은 저장소, 전송 프로토콜, HTTP 경로를 추가하며 역할에 따라 백그라운드 작업, 제한된 계산, 조정된 데이터 정리 서비스를 받습니다. 무료 모듈에는 유료 기능 라이선스가 필요하지 않으며 유료 모듈은 요구 사항을 선언합니다. 각 패키지는 코어 extension API와 호환되어야 하며 서명 및 무결성 검사를 통과해야 합니다.
이 버전에서는 타사 플러그인 설치와 실행을 지원하지 않습니다. 신뢰하는 작성자 키를 관리할 수 있지만 키 추가가 플러그인 설치를 활성화하지는 않습니다. 모듈 인터페이스를 임의 코드의 샌드박스로 취급하지 마세요.
패키지 설치
패키지 파일
arkvory-module-<id>-<version>.tgz를 호스트에 복사합니다.패키지를 확인하고 약관을 읽습니다.
bashsudo arkvory module install /root/arkvory-module-sample-1.0.0.tgz --root /opt/proanima-arkvory명령은 모듈, 역할, 모듈이 보관하는 데이터, 서명 키, 패키지의 SHA-256을 보여 주고 이어서 모듈의 약관을 보여 줍니다. 아직 아무것도 바뀌지 않습니다.
설치합니다.
bashsudo arkvory module install /root/arkvory-module-sample-1.0.0.tgz --root /opt/proanima-arkvory --yes
Arkvory는 다음 경우 패키지를 거부합니다.
| 이유 | 메시지의 코드 |
|---|---|
| 서명이 ProAnimaStudio 모듈 키로 만든 것이 아니거나 매니페스트가 변경됨 | unknown_key, wrong_key_class, signature_invalid |
| 파일이 없거나 변경되었거나 매니페스트에 없음 | file_missing, file_mismatch, file_unlisted |
| 아카이브에 링크, 장치, 패키지 밖 경로 또는 대소문자만 다른 이름이 있음 | link_entry, special_entry, unsafe_path, case_collision |
아카이브에 네이티브 애드온(.node)이 있음 | native_addon |
| 모듈에 다른 버전의 Arkvory가 필요함 | module_incompatible |
| ProAnimaStudio가 이 버전을 폐기함 | module_revoked, 대체 버전과 함께 |
| 현재 유효한 폐기 목록이 없음(아래 참조) | stale_revocations |
제한: 패키지당 1 GiB, 파일당 256 MiB, 파일 4096개. 더 큰 패키지는 데이터를 읽기 전에 거부됩니다.
같은 바이트로 이미 설치된 버전은 그대로 둡니다. 같은 버전이지만 바이트가 다르면 거부됩니다.
모듈 활성화와 로드
설치된 모듈은 활성화하기 전까지 비활성 상태로 남습니다. 서비스는 시작할 때만 모듈을 로드합니다.
모듈 파일(
ARKVORY_MODULES_FILE, 환경 변수 참고)에 모듈을 추가합니다. 모듈 설정은config에 넣습니다.json{ "format": 1, "modules": { "sample": { "enabled": true } } }모듈이 파일을 보관한다면
resources로 데이터 디렉터리의 크기를 승인합니다. 예를 들어enabled옆에"resources": { "dataMiB": 512, "dataFiles": 10000 }을 둡니다. 이 값은 패키지가 요청하는 크기를 대체합니다. 모듈의 데이터 디렉터리를 참고하세요.변경 사항 적용과 같이 서비스를 다시 시작합니다.
전역 관리자로 모듈을 확인합니다.
GET /api/v1/system/modules는 API와 각 읽기 게이트웨이에서 모듈을running: true,health.statusok로 보여 줍니다.
서명된 모듈은 선언한 역할에 따라 API, 읽기 게이트웨이, worker 및 백업 에이전트에서 실행됩니다. 각 프로세스는 해당 역할에 제공되며 uses에 선언된 서비스만 전달합니다. 라우트에는 routes가 필요합니다. Docker Compose는 아직 모듈을 로드하지 않습니다.
모듈 스토리지는 <module>.<name>으로 등록되며 새 업로드 대상으로 선택할 수 있습니다. 쓰기 수락을 중단하면 새 업로드는 default를 사용합니다. 코어는 조각에서 구성된 객체를 게시하기 전에 전체 바이트를 검증합니다. 데이터 정리는 활성 읽기, 모든 백업 고정 및 캡처 장벽이 해제될 때까지 기다립니다. 계산은 제한된 스레드에서 실행됩니다. 구독은 처리 성공 후 이벤트를 확인하며 실패 후 다시 전달할 수 있습니다.
서비스는 모듈의 코드를 가져오기 전에 패키지를 다시 확인합니다.
- 설치 디렉터리,
modules/, 모듈 집합, 폐기 목록과 그 디렉터리는 root(Windows에서는 SYSTEM과 Administrators) 또는 설치 디렉터리의 소유자만 변경할 수 있습니다. 설치 과정이 이렇게 설정합니다. 다른 계정이 변경할 수 있는 파일과 패키지 안의 링크는 거부됩니다(access_unsafe,access_link). - 서명, 모든 파일, Arkvory 버전을
module install과 같은 방식으로 확인합니다. - 폐기 목록. 폐기된 버전은 절대 로드되지 않습니다. 만료된 목록이나 목록이 없는 상태는 모듈을 멈추지 않습니다.
확인에 실패한 모듈은 로드되지 않으며, 다른 모듈과 Arkvory는 계속 동작합니다. GET /api/v1/system/modules는 해당 모듈을 running: false로 보여 줍니다.
health.status | 의미 | 코드 |
|---|---|---|
failed | 패키지가 거부되었거나 코드가 로드 또는 시작되지 않았습니다 | file_mismatch, unknown_key, module_incompatible, access_unsafe, config_invalid, start_failed 등 |
revoked | ProAnimaStudio가 이 버전을 폐기했습니다 | 폐기 목록의 사유 |
unavailable | 호스트에 패키지 디렉터리가 없습니다 | module_unavailable |
실패한 모듈은 다른 활성 모듈이 그 모듈을 필요로 할 때만 Arkvory를 준비되지 않은 상태로 만듭니다(/health/ready가 module_failed와 함께 503으로 응답). 게시된 파일의 바이트를 저장하는 모듈(데이터 layout)은 절대 그렇게 하지 않습니다. Arkvory는 그 데이터를 계속 제공하고 새 업로드를 모듈의 저장소 대신 자체 저장소에 기록합니다. 로그에는 module.refused와 module.failed가 errorCode의 코드와 함께 기록됩니다.
변경되었거나 없어진 패키지를 복구하려면 다시 설치하세요. 설치의 모든 서비스는 활성화 여부와 관계없이 같은 모듈을 보아야 합니다. 다른 모듈을 가진 읽기 게이트웨이나 워커는 준비되지 않습니다(module_plan_mismatch). 각 읽기 게이트웨이의 호스트에 같은 패키지를 설치하세요.
모듈의 데이터 디렉터리
자체 인덱스, 캐시 또는 상태를 보관하는 모듈은 데이터 볼륨에 디렉터리를 받습니다. default의 스토리지 디렉터리 안의 module-data/<id>/입니다. 그중 data 부분은 백업 대상이고 cache 부분은 그렇지 않습니다. Arkvory는 모든 쓰기를 두 부분을 합쳐 MiB와 파일 수로 승인된 크기에 대해 계산합니다. 이를 넘는 쓰기는 거부되며(module_quota_exceeded) 모듈은 계속 실행됩니다. 승인된 크기가 없으면 모듈은 읽기만 할 수 있습니다. 볼륨의 예비 영역도 적용됩니다. 읽기 게이트웨이에서 모듈은 같은 파일을 읽지만 변경할 수는 없습니다.
논리 백업은 설치된 모듈의 backup 역할을 통해 게시된 객체 바이트를 읽으며 모듈 디렉터리, 캐시, 내부 조정 상태를 파일 시스템 이미지로 복사하지 않습니다. 복사가 끝날 때까지 원본 모듈을 설치된 읽기 가능 상태로 유지하세요. --to-default-storage는 원본 모듈이나 유료 라이선스 없이 일반 코어 blob으로 객체를 복원합니다. 전체 논리 크기의 공간을 확보하세요. 설치 비밀 정보는 별도로 보관하고 유료 쓰기를 다시 켜기 전에 라이선스 복구 절차를 따르세요. 모듈을 제거해도 데이터 디렉터리는 삭제되지 않습니다. 게시된 객체가 참조하는 파일을 삭제하지 마세요.
extension API 0.7.0으로 업그레이드하기 전에 모듈 데이터를 쓰는 모든 이전 API 및 worker 프로세스를 중지하세요. 새 쓰기 프로세스는 설치의 PostgreSQL 조정자를 통해 할당량 계산을 공유하며 임시 파일도 할당량에 포함됩니다. 이전 프로세스와 새 프로세스의 혼합 쓰기는 지원하지 않습니다. 충돌 후 Arkvory는 필요에 따라 사용량을 다시 계산하고 이전 소유자의 데이터베이스 잠금을 획득한 뒤에만 새 프로토콜의 임시 디렉터리를 회수합니다. 기존 임시 파일은 자동 삭제되지 않으며 계속 할당량에 포함됩니다. 쓰기 프로세스를 중지한 상태에서 별도로 확인하세요. backup 프로세스는 읽기만 가능합니다.
모듈의 라우트
모듈은 자신의 접두사 /api/ext/<id>/v<major>/ 아래에 HTTP 라우트를 추가할 수 있습니다(예: /api/ext/sample/v1/). Arkvory는 모듈의 코드가 실행되기 전에 모든 요청을 확인합니다.
| 확인 | /api/v1과 동일 |
|---|---|
| 자격 증명 | 같은 키, 세션, 토큰을 사용하며, 라우트는 로그인한 모든 호출자 또는 전역 관리자에게만 열립니다 |
| 권한 | 라우트가 경로 속 리포지토리에 대해 지정한 권한(예: content.read, upload.create): 서비스 키에는 그 권한이, 계정에는 읽기 또는 쓰기 권한이 필요합니다 |
| 요청 본문 | 라우트의 크기 제한과 서버의 업로드 제한, 기한, 대역폭 |
| 파일 | Arkvory가 직접 보냅니다: ETag, Range, If-Range, 304, 다운로드 대기열과 다운로드 대역폭 |
오류는 API의 오류 형식을 따릅니다. 모듈은 자격 증명이나 다른 헤더를 보지 못합니다. 읽기 게이트웨이는 모듈의 읽기 라우트를 제공하고 나머지에는 read_only로 응답합니다.
각 모듈은 OpenAPI 문서로 라우트를 설명하고, Arkvory는 모듈이 시작될 때 둘을 대조합니다. 라우트가 규칙을 어기는 모듈은 시작하지 않고 아무것도 제공하지 않으며, Arkvory는 계속 동작합니다. GET /api/v1/system/modules는 이 모듈을 running: false와 health.status failed로 보여 줍니다.
| 코드 | 의미 |
|---|---|
routes_invalid | 라우트가 규칙을 어깁니다. 예: 모듈 접두사 밖의 경로, 로그인한 모든 호출자에게 열린 변경 |
openapi_invalid | OpenAPI 문서가 없거나 올바르지 않습니다 |
openapi_route_mismatch | 라우트에 문서상의 작업이 없거나, 작업에 라우트가 없습니다 |
transfer_invalid | 모듈이 제공할 수 없는 전송 프로토콜을 제공합니다 |
라우트 문서:
| 주소 | 읽을 수 있는 사람 | 내용 |
|---|---|---|
GET /api/ext/openapi.json | 로그인한 모든 호출자 | 이 서비스가 실행하는 모든 모듈의 라우트와 호출자가 호출할 수 있는 작업 |
GET /api/v1/system/modules/{id}/openapi | 전역 관리자 | 모듈 하나의 라우트 |
/api/v1/openapi.json은 모듈의 라우트를 나열하지 않습니다. 종류가 transfer인 모듈은 파일을 전송하는 다른 방법을 제공할 수 있으며, GET /api/v1/capabilities가 이를 transfer에 나열합니다. 클라이언트는 일치하는 확장이 있을 때만 이를 사용하고, 그렇지 않으면 평소처럼 파일을 전송합니다.
업데이트, 고정, 다운그레이드
새 버전의 파일을 --yes로 설치합니다. 이전 패키지는 다음 모듈 변경까지 호스트에 남아 있습니다.
| 작업 | 명령 |
|---|---|
| 설치된 버전 유지 | sudo arkvory module pin sample 1.0.0 --root … |
| 다른 버전 다시 허용 | sudo arkvory module pin sample --unpin --root … |
| 더 오래된 버전 설치 | sudo arkvory module install <file> --downgrade --yes --root … |
고정된 모듈은 고정을 해제할 때까지 다른 모든 버전을 거부합니다. 설치된 버전보다, 또는 패키지가 아직 호스트에 남아 있는 제거된 버전보다 오래된 버전에는 --downgrade가 필요합니다.
설치된 모듈 확인
sudo arkvory module list --root /opt/proanima-arkvory이 명령은 서비스가 로드하기 전에 하는 것과 같이 설치된 모든 패키지를 다시 검증합니다. 서명, 모든 파일, 아카이브를 확인합니다. 각 모듈은 하나의 상태를 표시합니다.
| 상태 | 의미 |
|---|---|
ok | 패키지가 온전함 |
refused: <code> | 파일이 변경되었거나 추가되었거나 링크로 바뀜(file_mismatch, file_unlisted, link_entry 등) |
revoked (<reason>) | ProAnimaStudio가 이 버전을 폐기함. read path only는 해당 데이터를 계속 읽을 수 있다는 뜻 |
거부된 패키지는 절대 사용되지 않습니다. 복구하려면 패키지 파일을 다시 설치하십시오.
모듈 제거
sudo arkvory module remove sample --root /opt/proanima-arkvory모듈은 설치에서 빠지고, 패키지는 다음 모듈 변경까지 호스트에 남습니다. 게시된 파일의 바이트를 저장하는 모듈(데이터 layout)은 제거할 수 없습니다. Arkvory는 데이터를 읽을 수 없게 되는 일이 없도록 module_owns_data로 거부합니다.
폐기 목록
ProAnimaStudio는 폐기된 모듈 버전의 서명된 목록을 게시합니다. 각 목록에는 번호가 있으며, Arkvory는 가지고 있는 목록보다 번호가 낮은 목록을 절대 받아들이지 않습니다. 모듈 패키지가 더 새로운 목록을 포함할 수 있으며, 패키지를 설치하면 Arkvory가 그 목록을 보관합니다. 허브에 접근할 수 없는 호스트에서는 목록 파일을 직접 저장합니다.
sudo arkvory module revocations /root/module-revocations.json --root /opt/proanima-arkvory각 목록은 만료 시각과 함께 서명됩니다. 기본 90일이며 180일을 넘지 않습니다. module install과 module pin <id> <version>에는 현재 유효한 목록이 필요하며, 만료된 목록이거나 목록이 없으면 stale_revocations로 거부됩니다. 현재 유효한 목록을 담은 패키지도 인정됩니다. 그래도 진행하려면 --allow-stale-revocations를 추가하십시오. Arkvory는 경고를 출력하고 결정을 modules/audit.jsonl에 기록합니다. 만료된 목록은 설치된 모듈을 멈추지 않습니다. 모듈은 계속 실행되고 데이터도 읽을 수 있으며, 버전을 멈추는 것은 폐기 항목뿐입니다. 번호가 더 큰 목록은 만료되었더라도 항상 저장된 목록을 대체합니다.
ProAnimaStudio가 모듈 서명 키를 교체할 때는 한 릴리스가 두 키를 모두 포함하고 다음 목록은 새 키로 서명됩니다. 이전 키는 그 이후 릴리스에서만 제거됩니다. 호스트가 이전 키로 서명된 목록을 아직 저장하고 있으면 그 릴리스로의 업데이트는 거부됩니다. 먼저 현재 유효한 목록을 저장하십시오. sudo arkvory module check-revocations --root …는 이 릴리스가 저장된 목록의 키를 신뢰하는지 보여 줍니다.
플러그인 작성자 신뢰
팀이나 다른 작성자의 플러그인은 작성자의 키로 서명됩니다. 이런 플러그인을 설치하기 전에 키를 호스트의 신뢰 목록에 추가하십시오. 신뢰 목록은 호스트에 속합니다. 서비스는 목록을 읽을 수 있지만 변경할 수는 없습니다.
작성자에게서 공개 키 파일(
.pub, minisign 형식)을 받고, 지문은 다른 경로로 받습니다.키를 표시하고 지문을 비교합니다.
bashsudo arkvory module trust add /root/acme.pub --label "Acme platform team" --plugins "op-acme-*" --root /opt/proanima-arkvory--yes로 추가합니다.
| 옵션 | 의미 |
|---|---|
--label | 키 보유자. 필수 |
--plugins | 키가 서명할 수 있는 플러그인 id(쉼표로 구분): 정확한 id 또는 *가 붙은 접두사. 기본값 op-* |
--expires | 2027-01-31T00:00:00Z 같은 UTC 시간. 이후에는 키로 새 설치를 받아들이지 않음 |
--allow-in-process | 키의 플러그인이 Arkvory 프로세스 안에서 실행되도록 허용. 이런 코드는 서비스의 모든 권한을 가짐 |
플러그인 id는 항상 op-로 시작합니다. 플러그인 키는 ProAnimaStudio 모듈에 서명하지 않으며, ProAnimaStudio 키는 op- 플러그인에 서명하지 않습니다. 호스트가 이미 다른 id 또는 다른 종류의 키로 알고 있는 키는 거부됩니다(duplicate_key). 서명은 현재 minisign 버전의 기본값인 prehash 방식이어야 하며, 레거시 서명은 signature_algorithm으로 거부됩니다.
sudo arkvory module trust list --root …는 신뢰하는 키를 보여 줍니다. sudo arkvory module trust remove <key id> --root …는 키 하나를 제거합니다.
이 릴리스는 신뢰 목록을 관리하며, 플러그인은 이후 릴리스가 설치합니다.
중단된 후
모듈 집합의 모든 변경은 업데이트 저널에 기록됩니다. 명령이 중간에 멈추면 다음 배포 명령이 Interrupted deployment로 거부됩니다. sudo arkvory recover --root …를 실행하십시오. 이전 모듈 집합을 복원합니다. 그때까지 무언가를 바꾸는 모든 모듈 명령은 거부되며, module trust와 module revocations도 마찬가지입니다.
모듈 요청의 수명
경로는 스트리밍을 포함한 응답이 끝날 때까지 호출자의 권한을 사용합니다. 취소 또는 완료 시 권한을 철회하고 읽기 리소스를 닫습니다. upload-read는 미완료 업로드의 수신이 확인된 부분을 읽고 소유자, upload.read, 범위 및 취소를 확인합니다. 모듈은 실행 중에 전송 제안을 철회할 수 있으며 이후 기능 조회에서는 제외됩니다. 기존 경로와 전송은 유지됩니다. 클라이언트에 이전 제안이 캐시될 수 있으므로 경로는 각 작업을 확인해야 합니다.
파생 캐시 복구
서명된 모듈은 derived-cache를 선언할 수 있습니다(extension API 0.9.0). API와 worker는 불변 세대를 생성하고 읽으며 reader는 읽기만 가능합니다. backup에는 서비스가 제공되지 않습니다. 요청마다 원본 권한을 확인해야 합니다. 자원 예산에는 기존 데이터/캐시와 보존된 세대가 모두 포함됩니다. 캐시 누락 시 재생성하거나 대체 경로를 사용해야 합니다.
PostgreSQL 세션 손실은 파일 I/O 중지를 증명하지 않습니다. 불확실한 owner의 예약과 영구 reader 참조는 계속 계산됩니다. 먼저 이 코어 버전의 DB 마이그레이션을 적용하세요. 복구 전에 모든 참여 호스트를 중지하고 프로세스와 I/O 종료를 확인하거나 정확한 owner 프로세스 인스턴스가 종료되어 재개할 수 없음을 증명하세요. 접근 불가 호스트에는 fencing이 필요합니다. 진단에서 정확한 owner UUID를 얻고 증거를 기록하세요. PID, 시간 초과, DB 잠금 부재만으로는 부족합니다.
ARKVORY_DATABASE_URL을 설정한 신뢰할 수 있는 호스트에서 이 코어 버전의 빌드된 패키지로 아래 명령을 실행하세요. 플래그는 물리적 중지를 확인하지만 활성 owner 잠금이 있으면 복구는 거부됩니다. 확인 없이는 동작하지 않습니다. 이후 reconciliation을 재개하고 회수를 확인하세요. 확인만으로 할당량이 즉시 반환되지는 않습니다. 이는 호스트 유지보수이며 모듈이나 원격 CLI 권한이 아닙니다.
node scripts/recover-derived-cache.mjs --owner UUID --confirm-owner-stopped모듈 조정 상태
Extension API 0.10.0은 서명된 모듈에 크기가 제한된 원자적 상태 저장소를 제공합니다. HA 장애 조치 후에도 유지되지만 이식 가능한 논리 백업에는 포함되지 않습니다. 복원 후에는 모듈의 명시적인 재초기화 절차를 따르세요. 저장된 객체의 읽기와 복원은 계속 가능해야 합니다. 이 상태는 객체 저장소와 분리되며 모듈 재설치로 초기화되지 않습니다.
전송 모듈은 프로토콜 제공을 일시 중단하고 정책 검증에 성공한 뒤 Arkvory를 재시작하지 않고 복원할 수 있습니다. 각 요청에는 계속 모듈의 현재 정책이 적용됩니다.
확장 API 0.12.0에서는 서명된 저장소 모듈이 논리 바이트 한도를 설정할 수 있습니다. 코어는 중복 제거에 따른 할인 없이 모든 저장소의 객체 전체 크기와 수락한 미완료 업로드를 계산합니다. 한도에 도달하면 새 업로드는 기본 저장소를 사용합니다. 이미 수락한 업로드의 대상은 유지되며 기존 객체도 계속 읽을 수 있습니다. 사용량은 정리가 완료된 후에만 줄어듭니다.
공유 리소스 카탈로그
Extension API 0.13.0은 서명된 모듈에 공유 리소스 카탈로그를 제공합니다. 업로드나 종속 리소스가 파일을 참조하는 동안 파일은 보호됩니다. 코어 정리만 업로드 참조를 해제할 수 있습니다. 물리적 삭제는 읽기와 백업이 끝날 때까지 기다리며, 실패하면 재시도를 위해 종속성을 유지합니다.
이 카탈로그를 사용하는 모듈로 처음 업그레이드하기 전에 모든 이전 API 및 worker 프로세스를 중지하세요. 이전 버전과 새 버전의 쓰기 프로세스를 혼용하지 마세요. 논리적 복원 후에는 모듈이 모든 레시피, 파일 및 종속성을 성공적으로 검사할 때까지 정리가 비활성화됩니다. 정리를 재개하기 전에 누락되거나 손상된 데이터를 복구하세요.