S3 버킷을 EC2 인스턴스에 마운트하고 PHP로 작성하려면 어떻게해야합니까?

S3 버킷을 EC2 인스턴스에 마운트하고 PHP로 작성하려면 어떻게해야합니까?

---

Amazon Web Services에서 호스팅되는 프로젝트를 진행 중입니다. 서버 설정은 두 개의 EC2 인스턴스, 하나의 Elastic Load Balancer 및 웹 애플리케이션이 상주하는 추가 Elastic Block Store로 구성됩니다. 이 프로젝트는되어 가정 사용자가 업로드 한 파일의 저장 S3를 사용합니다. 이 질문을 위해 S3 버킷을static.example.com

나는 s3fs( https://code.google.com/p/s3fs/wiki/FuseOverAmazon ), RioFS( https://github.com/skoobe/riofs ) 및 s3ql( https://code.google.com/p / s3ql / ). s3fs파일 시스템을 마운트하지만 버킷에 쓸 수는 없습니다 (이 질문은 SO : FUSE를 사용하여 적절한 권한으로 S3 볼륨을 마운트 할 수있는 방법). RioFS파일 시스템을 마운트하고 쉘에서 버킷에 쓸 수 있지만 PHP를 사용하여 저장된 파일은 버킷에 나타나지 않습니다 (GitHub에서 프로젝트 관련 문제를 열었습니다). s3ql버킷을 마운트하지만 이미 버킷에있는 파일은 파일 시스템에 나타나지 않습니다.

다음은 내가 사용한 마운트 명령입니다.

s3fs static.example.com -ouse_cache=/tmp,allow_other /mnt/static.example.com
riofs -o allow_other http://s3.amazonaws.com static.example.com /mnt/static.example.com
s3ql mount.s3ql s3://static.example.com /mnt/static.example.com

또한이 S3 클래스를 사용해 보았습니다 : https://github.com/tpyo/amazon-s3-php-class/ 및이 FuelPHP 특정 S3 패키지 : https://github.com/tomschlick/fuel-s3 . 사용 가능한 버킷과 파일을 나열하기 위해 FuelPHP 패키지를 얻을 수 있었지만 버킷에 파일을 저장하는 데 실패했습니다 (오류는 없었습니다).

로컬 Linux 파일 시스템에 S3 버킷을 마운트하고 PHP를 사용하여 버킷에 파일을 성공적으로 기록한 적이 있습니까? 어떤 도구를 사용하셨습니까? 위에서 언급 한 도구 중 하나를 사용한 경우 어떤 버전을 사용하셨습니까?

편집RioFS GitHub에서 열었던 문제 가 해결되었다는 알림을 받았습니다 . 버킷을 볼륨으로 마운트하는 대신 S3 REST API 를 사용하기로 결정했지만 RioFS요즘에는 실행 가능한 옵션 일 수 있습니다.

---

로컬 Linux 파일 시스템에 S3 버킷을 마운트 한 적이 있습니까?

아니요. 테스트하기에는 재미 있지만 프로덕션 시스템 근처에는 두지 않을 것입니다. 라이브러리를 사용하여 S3와 통신하는 것이 훨씬 좋습니다. 그 이유는 다음과 같습니다.

1. 오류를 숨기지 않습니다. 파일 시스템에는 문제를 나타 내기 위해 보낼 수있는 몇 가지 오류 코드 만 있습니다. S3 라이브러리는 Amazon의 정확한 오류 메시지를 제공하므로 진행 상황을 이해하고 기록하고 코너 케이스를 처리하는 등의 작업을 수행 할 수 있습니다.
2. 라이브러리는 더 적은 메모리를 사용합니다. 파일 시스템 계층은 많은 사람들이 다시는 사용하지 않는 임의의 항목을 많이 캐시합니다. 라이브러리를 사용하면 캐시 할 항목과 캐시하지 않을 항목을 결정할 수 있습니다.
3. 확장. 멋진 작업을 수행해야하는 경우 (파일에 ACL 설정, 서명 된 링크 생성, 버전 관리, 수명주기, 내구성 변경 등) 파일 시스템 추상화를 덤프하고 어쨌든 라이브러리를 사용해야합니다.
4. 타이밍 및 재시도. 요청의 일부는 임의로 오류가 발생하여 다시 시도 할 수 있습니다. 때때로 많은 재 시도를 원할 수 있으며 때로는 오류를 빠르게 처리 할 수 ​​있습니다. 파일 시스템은 세분화 된 제어를 제공하지 않지만 라이브러리는 가능합니다.

결론은 FUSE 아래의 S3가 유출 된 추상화라는 것 입니다. S3에는 디렉터리가 없거나 필요하지 않습니다. 파일 시스템은 수십억 개의 파일을 위해 구축되지 않았습니다. 해당 권한 모델이 호환되지 않습니다. S3를 파일 시스템에 통합하려고함으로써 S3의 많은 힘을 낭비하고 있습니다.

S3와 통신하기위한 두 개의 임의 PHP 라이브러리 :

https://github.com/KnpLabs/Gaufrette

https://aws.amazon.com/sdkforphp/-S3를 사용하는 것 이상으로 확장하거나 위에서 언급 한 멋진 요청을 수행해야하는 경우에 유용합니다.

---

종종 EBS 볼륨에 파일을 쓴 다음 파일에 대한 후속 공개 요청이 CloudFront CDN을 통해 라우팅되도록하는 것이 좋습니다.

이러한 방식으로 앱이 파일에 대한 변환을 수행해야하는 경우 로컬 드라이브 및 시스템에서 수행하는 것이 훨씬 더 쉬워 진 다음 변환 된 파일에 대한 요청을 CloudFront를 통해 오리진에서 강제로 가져옵니다.

예를 들어 사용자가 아바타에 대한 이미지를 업로드하고 아바타 이미지에 크기 및 자르기에 대해 여러 번 반복해야하는 경우 앱에서 로컬 볼륨에이를 만들 수 있지만 파일에 대한 모든 공개 요청은 cloudfront origin-pull을 통해 발생합니다. 의뢰. 이러한 방식으로 원본 파일 (또는 파일의 최적화 된 버전)을 유지할 수있는 최대의 유연성을 갖게되며, 이후의 모든 사용자 요청은 클라우드 프런트 에지에서 기존 버전을 가져 오거나 클라우드 프런트가 요청을 앱으로 다시 라우팅 할 수 있습니다. 필요한 반복을 만듭니다.

위의 기본 예는 원본을 유지하는 것 외에도 업로드 된 모든 그래픽 이미지의 여러 크기 / 자른 버전을 생성하는 WordPress입니다 (파일 크기 제한 및 / 또는 플러그인 변환 적용). W3 Total Cache와 같은 CDN 지원 WordPress 플러그인은 CDN을 통해 가져 오기 요청을 다시 작성하므로 앱은 고유 한 첫 번째 요청 반복 만 생성하면됩니다. 브라우저 캐싱 URL 버전 관리 ( http : //domain.tld/file.php? x123 )를 추가하면 CDN 기능이 더욱 개선되고 활용됩니다.

EBS 볼륨 파일 크기 또는 inode의 급속한 확장이 우려되는 경우 거의 요청되지 않는 파일이나 오래된 파일에 대한 정리 프로세스를 자동화 할 수 있습니다.

참조 URL : https://stackoverflow.com/questions/16428552/how-can-i-mount-an-s3-bucket-to-an-ec2-instance-and-write-to-it-with-php