이 주제는 몇 가지 일반적인 S3 호환 Object Storage 제공업체(S3 클론)를 설정하는 방법에 대해 다룹니다. 공식적으로 지원되며 Discourse의 호스팅 서비스에서 내부적으로 사용되는 Amazon AWS S3 설정에 대한 자세한 내용은 Set up file and image uploads to S3 를 참조하세요.
| 제공업체 | 서비스 이름 | Discourse와 호환? |
|---|---|---|
| Amazon AWS | S3 | 예 |
| Digital Ocean | Spaces | 예 |
| Linode | Object Storage | 예 |
| Google Cloud | Storage | 예 |
| Scaleway | Object Storage | 예 |
| Vultr | Object Storage | 예 |
| BackBlaze | Cloud Storage | 예* |
| 셀프 호스팅 | MinIO | 예 |
| Azure Blob Storage | Flexify.IO | 예 |
| Oracle Cloud | Object Storage | 아니오 [1] |
| Wasabi | Object Storage | 가능 |
| Cloudflare | R2 | 예 |
| Contabo | Object Storage | 아니오 |
다른 서비스가 작동하도록 설정했다면, 이 위키에 추가해 주세요.
설정
Discourse 정적 자산을 Object Storage에 저장하려면 app.yml의 hooks 섹션에 다음 설정을 추가하세요:
after_assets_precompile:
- exec:
cd: $home
cmd:
- sudo -E -u discourse bundle exec rake s3:upload_assets
- sudo -E -u discourse bundle exec rake s3:expire_missing_assets
Object Storage를 사용할 경우, 버킷에 저장된 콘텐츠를 서빙하기 위해 CDN이 필요합니다. 테스트에서는 StackPath CDN을 사용했으며, 설정에서 Dynamic Caching By Header: Accept-Encoding을 설정해야 하는 것을 제외하고는 잘 작동했습니다.
DISCOURSE_CDN_URL은 Discourse 호스트 이름으로 가리키고 요청을 캐시하는 CDN입니다. 주로 가져올 수 있는 자산인 CSS 및 기타 테마 자산에 사용됩니다.
DISCOURSE_S3_CDN_URL은 Object Storage 버킷으로 가리키고 요청을 캐시하는 CDN입니다. 주로 푸시할 수 있는 자산인 JS, 이미지 및 사용자 업로드에 사용됩니다.
이 둘은 서로 다르게 설정하고 관리자가 모두 설정하는 것을 권장합니다.
CDN을 사용하지 않거나(또는 버킷 URL을 CDN URL로 입력하는 경우) 문제가 발생할 가능성이 높으며 지원되지 않습니다.
다음 예시에서 https://falcoland-files-cdn.falco.dev는 버킷 내 파일을 서빙하도록 구성된 CDN입니다. 예시에서 버킷 이름은 falcoland-files로 설정되었습니다.
이 설정을 app.yml의 환경 변수로 구성하는 것이 권장됩니다. 이는 CDCK가 인프라에서 이렇게 하기 때문에 잘 테스트되었기 때문입니다. 또한, 자산을 업로드하는 작업은 자산이 컴파일된 후에 수행되며, 이는 리빌드(rebuild) 중에 발생합니다. 처음부터 Object Storage와 올바르게 작동하는 Discourse를 구동하려면 사이트가 시작되기 전에 자산이 업로드되도록 환경 변수를 설정해야 합니다.
아래 목록에서 제공업체를 선택하고 app.yml 파일의 env 섹션에 이러한 설정을 추가하되, 값을 적절히 조정하세요:
AWS S3
공식적으로 지원하고 내부적으로 사용하는 것입니다. 그들의 CDN 제공인 Cloudfront도 버킷 파일을 프론트할 수 있습니다. 권한을 올바르게 구성하는 방법은 Set up file and image uploads to S3 를 참조하세요.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-west-1
DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
DISCOURSE_S3_BUCKET: falcoland-files
DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
DISCOURSE_BACKUP_LOCATION: s3
Digital Ocean Spaces
DO 제공은 좋으며 그대로 작동합니다. 파일 목록 제한을 활성화해도 괜찮습니다. 유일한 문제는 그들의 CDN 제공이 아주 잘 깨져 있습니다는 것이며, 따라서 파일에는 다른 CDN을 사용해야 합니다. 또한, 리빌드 때마다 재설치되므로 CORS 규칙을 설치할 필요가 없습니다.
예시 설정:
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: whatever
DISCOURSE_S3_ENDPOINT: https://nyc3.digitaloceanspaces.com
DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
DISCOURSE_S3_BUCKET: falcoland-files
DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_S3_INSTALL_CORS_RULE: false
Linode Object Storage
Linode에는 HTTP_CONTINUE_TIMEOUT이라는 추가 설정 매개변수가 필요합니다.
예시 설정:
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-east-1
DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
DISCOURSE_S3_ENDPOINT: https://us-east-1.linodeobjects.com
DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
DISCOURSE_S3_BUCKET: falcoland-files
DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
DISCOURSE_BACKUP_LOCATION: s3
Google Cloud Platform Storage
파일 목록 표시가 깨져 있으므로 자산이 작동하도록 이를 건너뛰기 위해 추가 ENV가 필요합니다. 또한 CORS를 건너뛰고 수동으로 구성하세요.
파일 목록을 표시할 수 없으므로 백업 목록도 표시할 수 없으며, 자동 백업이 실패하므로 백업에 사용하는 것을 권장하지 않습니다. 그러나 일부는 Storage Legacy Object Owner에서 Storage Legacy Bucket Owner로 역할을 변경하면 백업이 올바르게 작동한다고 제안합니다. Google Cloud 관련 토론은 이 주제를 참조하세요.
통합을 더 잘 만들기 위한 서드파티 플러그인이 Discourse GCS Helper 에 있습니다.
예시 설정:
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-east1
DISCOURSE_S3_INSTALL_CORS_RULE: false
FORCE_S3_UPLOADS: 1
DISCOURSE_S3_ENDPOINT: https://storage.googleapis.com
DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
DISCOURSE_S3_BUCKET: falcoland-files
#DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
#DISCOURSE_BACKUP_LOCATION: s3
Scaleway Object Storage
Scaleway 제공도 매우 좋으며, 대부분 모든 것이 잘 작동합니다.
Scaleway 멀티파트 업로드는 최대 1,000개 부분만 지원합니다. 이는 최대 10,000개 부분을 지원하는 Amazon S3와 일치하지 않습니다. 더 큰 인스턴스의 경우, 이로 인해 Discourse 백업이 실패할 수 있으며 추가 시도를 하기 전에 미완료 업로드를 수동으로 삭제해야 할 수 있습니다. 작은 인스턴스의 경우 이는 문제가 되지 않습니다. Scaleway는 피드백에 상당히 개방적이므로, 이 제한 사항을 변경하고 싶다면 그들에게 연락해야 합니다.
DISCOURSE_S3_ENDPOINT 매개변수의 경우, Discourse는 전체 리전의 엔드포인트인 https://s3.{region}.scw.cloud를 사용합니다. Scaleway 대시보드에서 찾을 수 있는 "Bucket endpoint"는 https://{bucketName}.s3.{region}.scw.cloud 형식입니다. 연결 오류를 방지하려면 버킷 이름 서브도메인을 생략하세요.
예시 설정:
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: fr-par
DISCOURSE_S3_ENDPOINT: https://s3.fr-par.scw.cloud
DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
DISCOURSE_S3_BUCKET: falcoland-files
DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
DISCOURSE_BACKUP_LOCATION: s3
Vultr Object Storage
Vultr에는 HTTP_CONTINUE_TIMEOUT이라는 추가 설정 매개변수가 필요합니다.
예시 설정:
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: whatever
DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
DISCOURSE_S3_ENDPOINT: https://ewr1.vultrobjects.com
DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
DISCOURSE_S3_BUCKET: falcoland-files
DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
DISCOURSE_BACKUP_LOCATION: s3
Backblaze B2 Cloud Storage
CORS를 건너뛰고 수동으로 구성해야 합니다.
BackBlaze와 함께 clean up orphan uploads가 올바르게 작동하지 않는다는 보고가 있습니다. 고아 정리(orphan cleanup)가 작동하려면 버킷에 대한 라이프사이클 규칙을 변경해야 합니다.
예시 설정:
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: "us-west-002"
DISCOURSE_S3_INSTALL_CORS_RULE: false
DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY: false
DISCOURSE_S3_ENDPOINT: https://s3.us-west-002.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
DISCOURSE_S3_BUCKET: falcoland-files
DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
DISCOURSE_BACKUP_LOCATION: s3
참고: B2로의 초기 마이그레이션 중에 일일 2,500회 무료 클래스 C 트랜잭션 제한에 도달할 수 있습니다. 한도를 제거하려면 결제 수단을 추가해야 합니다.
MinIO Storage Server
S3 대안으로 MinIO 저장 서버를 사용하기 전에 충족해야 하는 몇 가지 주의사항과 요구 사항이 있습니다:
- 완전히 구성된 MinIO 서버 인스턴스가 있어야 합니다.
- 도메인 기반 버킷 URL을 위해 MinIO 구성에서 Domain Support가 활성화되어 있어야 합니다. 이것은 MinIO와 Discourse에 대한 필수 설정 요구 사항입니다. MinIO는 더 이상 Discourse에서 지원되지 않는 레거시 S3 “path” 스타일을 여전히 지원하기 때문입니다.
- 버킷 서브도메인이 MinIO 서버로 올바르게 해석되도록 MinIO에 대한 DNS 구성이 올바르게 설정되어 있어야 하며, MinIO 서버는 기본 도메인(이 경우
minio.example.com)으로 구성되어야 합니다. discourse-data버킷이 MinIO 서버에 존재하고 “public” 정책이 설정되어 있어야 합니다.- 이 문서의 앞부분에서 설명한 대로, 버킷으로 가리키고 요청을 캐시하는 올바르게 구성된 CDN으로 가리키는 S3 CDN URL이 있어야 합니다.
- CDN이 데이터를 가져올 때 실제 “Host” 헤더로 코어 S3 URL을 사용하도록 구성되어야 합니다. 예를 들어,
discourse-data.minio.example.com- 그렇지 않으면 CORB 문제를 일으킬 수 있습니다.
위 주의사항과 전제 조건이 충족된다고 가정하면, 예시 설정은 다음과 같은 형태가 될 것입니다:
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: anything
DISCOURSE_S3_ENDPOINT: https://minio.example.com
DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
DISCOURSE_S3_CDN_URL: https://discourse-data-cdn.example.com
DISCOURSE_S3_BUCKET: discourse-data
DISCOURSE_S3_BACKUP_BUCKET: discourse-backups
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_S3_INSTALL_CORS_RULE: false
앱 리빌더가 규칙을 설치하지 않더라도 MinIO에서 CORS는 여전히 활성화됩니다. 기본적으로, MinIO에서 모든 HTTP 동사에 대해 CORS가 활성화되어 있으며, 결과적으로 MinIO는 BucketCORS(S3 API)를 지원하지 않습니다.
Azure Blob Storage with Flexify.IO
Azure Blob Storage는 S3 호환 서비스가 아니므로 Discourse와 함께 사용할 수 없습니다. 플러그인은 있지만 깨져 있습니다.
Azure Blob Storage에 S3 호환 인터페이스를 노출하는 가장 쉬운 방법은 Azure Storage 프로토콜을 S3로 _변환_하는 Flexify.IO 서버를 추가하는 것입니다.
이 글 작성 시점 기준으로, 이 서비스는 Azure에서 무료이며, 실행을 시작하려면 매우 기본적(저가)인 VM 티어만 필요합니다. 그러나 설정이 약간 필요합니다.
- Azure 포털에서
Flexify.IO - Amazon S3 API for Azure Blob Storage라는 새 리소스를 생성합니다. - 가벼운 사용의 경우, 최소 VM 구성이 잘 작동하는 것 같습니다. 대부분의 기본 구성을 받아들여도 됩니다. VM을 생성할 때 PEM 키 파일을 저장하는 것을 잊지 마세요.
- Flexify.IO VM 링크로 이동하여 시스템에 들어갑니다. Azure Blob Storage 데이터 제공자 및 생성된 S3 엔드포인트를 설정하는 방법에 대한 지시를 따르세요. 엔드포인트 설정인
Public read access to all objects in virtual buckets가 true인지 확인하세요. S3 엔드포인트 URL과 키를 복사합니다. - New Virtual Bucket을 눌러 가상 버킷을 생성합니다. Azure Blob Storage 컨테이너와 같은 이름이거나 다른 이름일 수 있습니다. 이 가상 버킷으로 병합할 컨테이너를 연결합니다. 이 가상 버킷은 S3를 통해 공개적으로 읽을 수 있는 버킷을 노출하는 데 사용됩니다.
- 기본적으로 Flexify.IO는 자체 서명된 SSL 인증서를 설치하지만, S3 엔드포인트에는 HTTPS가 필요합니다. 키 파일(기본 사용자 이름은
azureuser임)을 사용하여 VM에 SSH로 로그인하고, 다음 파일을 올바른 파일로 교체합니다:
-
/etc/flexify/ssl/cert.pem- 인증서 파일(PEM 인코딩)로 교체 -
/etc/flexify/ssl/key.pem- 개인 키 파일(PKCS#8 PEM 인코딩,BEGIN PRIVATE KEY로 시작하고 PKCS#1인BEGIN RSA PRIVATE KEY로 시작하지 않는 것)로 교체이 파일들은 root 소유이므로 교체하려면
sudo가 필요합니다. 교체된 파일이 원래 파일과 동일한 소유권과 권한(root:root및600권한)을 갖도록 하는 것이 가장 좋습니다.
- 기본적으로 Flexify.IO는 여러 버킷을 가진 루트 수준의 S3 서비스를 생성합니다. Discourse는 버킷에 대해 서브도메인 지원을 요구합니다.
<your Flexify.IO VM IP>/flexify-io/manage/admin/engines/configs/1로 이동하면 숨겨진 구성 페이지가 열립니다! Endpoint hostname필드에 S3 기본 도메인(예:s3.mydomain.com)을 지정합니다. 이 필드는 기본적으로 비어 있을 것입니다. Save를 눌러 설정을 저장합니다.- Azure 포털에서 Flexify.IO VM을 재시작합니다.
- DNS에서
s3.mydomain.com과*.s3.mydomain.com을 Flexify.IO VM IP로 매핑합니다. - Discourse에서 관리 페이지에 다음을 설정합니다(예, 설정을
app.yml에 둘 필요가 없습니다):
use s3: true
s3 region: anything
s3 endpoint: https://s3.mydomain.com
s3 access key: myaccesskey
s3 secret assess key: mysecret key
s3 cdn url: https://<azure-blob-account>.blob.core.windows.net/<container>
s3 bucket: <virtual bucket>
s3 backup bucket: <backup bucket> (공개 읽기 액세스가 필요하지 않고 Flexify.IO가 자동으로 노출하므로 어떤 컨테이너든 괜찮습니다)
backup location: s3
프로덕션과 스테이징에 동일한 버킷을 사용하는 것은 권장되지 않습니다. 그래도 그렇게 하려면, 스테이징 사이트가 프로덕션 자산을 삭제하지 않도록 조치를 취해야 합니다(최소한 s3 disable cleanup을 설정하고, 프로덕션 백업이 삭제되는지 주의하세요).
Wasabi
@pfaffman은 백업에 wasabi를 시도했지만, 간헐적이고 조용히 실패하는 것 같았고, 백업이 하드 드라이브에 남아 결국 디스크를 가득 채웠습니다. wasabi도 meta도 단서를 찾지 못했으므로, 권장하지 않지만 결과는 다를 수 있습니다. @pfaffman은 이 문제가 백업과 자동 재부팅이 어떻게든 동시에 예약된 때문이라고 확신합니다. 백업에만 사용되었지만 잘 작동하는 것 같았습니다. 누군가가 시도해 보고 여기에 보고한다면, 적어도 백업에는 작동해야 합니다.
Oracle Cloud
Oracle Cloud는 버킷에 대한 가상 호스트 스타일 액세스를 지원하지 않으며 작동하지 않습니다
Cloudflare R2
Cloudflare R2는 Cloudflare CDN을 사용할 때 S3 object storage와 호환됩니다. Cloudflare의 무료 플랜은 10GB의 저장소를 제공합니다 이는 대부분의 포럼의 필요보다 훨씬 많을 것입니다.
Cloudflare R2를 구성하려면, Cloudflare 대시보드의 R2 Object Storage에서 관련 설정을 구성해야 합니다.
요구 사항(업로드 또는 백업 또는 둘 다)에 따라, app.yml 파일이나 Admin-All site settings에서 S3을 검색하여 삽입해야 하는 관련 설정은 다음과 같습니다:
DISCOURSE_ENABLE_S3_UPLOADS: true
DISCOURSE_S3_REGION: auto
DISCOURSE_S3_ENDPOINT: https://<your-account-id>.r2.cloudflarestorage.com
DISCOURSE_S3_ACCESS_KEY_ID: "xxx"
DISCOURSE_S3_SECRET_ACCESS_KEY: "xxx"
DISCOURSE_S3_UPLOAD_BUCKET: your-upload-bucket-name
DISCOURSE_S3_CDN_URL: https://uploads.yourdomain.com
# DISCOURSE_S3_USE_CDN_URL_FOR_ALL_UPLOADS: true
DISCOURSE_ENABLE_DIRECT_S3_UPLOADS: true
DISCOURSE_S3_USE_ACLS: false
DISCOURSE_BACKUP_LOCATION: s3
DISCOURSE_S3_BACKUP_BUCKET: your-backup-bucket-name
app.yml을 편집하고 싶지 않다면, 관리 UI에서 이렇게 할 수 있습니다:
“Admin → All site settings” (S3 검색):
- Enable S3 uploads =
true - Enable direct S3 uploads =
true - S3 access key ID =
"xxx" - S3 secret access key =
"xxx" - S3 region =
any - S3 upload bucket =
your upload bucket name - S3 endpoint =
https://<your-account-id>.r2.cloudflarestorage.com - S3 CDN URL =
https://uploads.yourdomain.com - S3 use ACLs =
false(이것을 비활성화하세요!) - S3 backup bucket =
your backup bucket name - Backup location =
S3
Cloudflare R2 구성 시 중요한 참고 사항:
- Cloudflare R2를 위해
app.yml또는web_only.yml을 구성할 때, 오직DISCOURSE_S3_CDN_URL만 설정하세요.DISCOURSE_CDN_URL은 설정하지 마세요. Cloudflare를 통해 메인 도메인을 프록시하고 있다면, 이미 자동으로 앱 자산을 캐시하고 서빙하고 있습니다. Cloudflare DNS를 사용하여 별도의DISCOURSE_CDN_URL을 구성하려고 하면, Discourse의 엄격한 NGINX 호스트 라우팅이 요청을 거부하여 무한한 301 리디렉트 루프, CORS 정책 차단 및 깨진 사이트를 초래합니다.
DISCOURSE_CDN_URL은 주석 처리된 상태로 두세요.DISCOURSE_S3_CDN_URL: https://your-r2-custom-domain.com을 설정하세요.
-
API 토큰 권한: Discourse에는 자격 증명 필드가 한 세트만 있으므로, Cloudflare에서 생성하는 API 토큰은 업로드 버킷과 백업 버킷 모두에 액세스할 수 있는 권한이 있어야 합니다. 토큰을 생성할 때, "Apply to all buckets"를 선택하거나 "Apply to specific buckets"를 사용하여 둘 다 확인되어 있는지 확인하세요. 또한, API 키를 생성할 때
Object Read & Write를 확인하세요(기본값은Object Read only만 있음). -
Cloudflare에서 엔드포인트 URL을 복사할 때, URL 끝에 버킷 이름이 추가될 수 있습니다 - 붙여넣기되면
.yml파일(또는 관리 설정)의 문자열 끝에서 버킷 이름을 삭제해야 합니다. -
PDF및ZIP파일을 포함한 모든 업로드에 R2 업로드 버킷을 사용하려면# DISCOURSE_S3_USE_CDN_URL_FOR_ALL_UPLOADS: true의 주석을 해제하세요. (이 경우 모든 업로드된 파일이 직접 링크를 통해 공개적으로 사용 가능해집니다) -
DISCOURSE_ENABLE_DIRECT_S3_UPLOADS(true)를 활성화하는 경우DISCOURSE_S3_USE_ACLS(false)를 비활성화해야 합니다. 이는 Cloudflare R2가 버킷 수준 권한을 사용하기 때문이며, 업로드 버킷은 공개적이고 백업 버킷은 비공개여야 합니다. Cloudflare R2 업로드의 경우, 버킷 권한을 설정할 때 Cloudflare 대시보드에서 구성하므로 CORS 규칙 rake 작업을 구성하거나 IAM json을 작성할 필요가 없습니다. Cloudflare의 “Object Read & Write” 토큰은 자동으로 멀티파트 업로드 권한을 부여하며, 다음 CORS 규칙을 Cloudflare 대시보드의 R2 업로드 버킷 설정의CORS Policy아래에 직접 붙여넣으면 rake 작업이 필요 없습니다.
[
{
"AllowedOrigins": [
"https://forum.yourdomain.com"
],
"AllowedMethods": [
"GET",
"PUT",
"POST",
"DELETE",
"HEAD"
],
"AllowedHeaders": [
"*"
],
"ExposeHeaders": [
"ETag"
],
"MaxAgeSeconds": 3000
}
]
Cloudflare 설정에 대한 더 많은 정보는 이 주제도 참조하세요: Using Discourse with Cloudflare: Best Practices
Contabo
@tuxed는 S3 호환 업로드에 Contabo Object Storage를 작동시키려 시도했습니다. 업로드 시 URL에 저장소 이름이 접두사로 추가되는 것 같으며, 작동하게 만들지 못했습니다.
보안 업로드
보안 업로드는 AWS S3에서만 지원됩니다. rake uploads:migrate_to_s3가 실패하면, 보안이 필요하지 않다는 것을 알고 있다면, 먼저 계수하고 그런 다음 해당 업로드를 비보안으로 표시하기 위해 다음 명령을 입력해야 합니다. 이 경우 AWS S3를 사용해야 합니다.
./launcher enter app
rails c
Upload.where(secure: true).count
Upload.where(secure: true).update_all(secure:false)
Oracle Cloud는 버킷에 대한 가상 호스트 스타일 액세스를 지원하지 않으며 작동하지 않습니다 ↩︎
