How to upload files on S3

[tonydspaniard]

It seems that this is only useful when having a unique server environment, how is this suppose to work on a multiple server environment that share assets?

Thanks in advance

[frankhefeng]

Hi, Antonio,

Sorry, I did not get you. If the multiple servers are running one same Yii
application, the assets folder should also be same. Then this extension
will still work.

Sent with MailTrack
https://mailtrack.io/install?source=signature&lang=en&referral=frankhe.cn@gmail.com&idSignature=22

Best Regards,
Frank He

On Thu, Dec 18, 2014 at 3:45 AM, Antonio Ramirez notifications@github.com
wrote:

It seems that this is only useful when having a unique server environment,
how is this suppose to work on a multiple server environment that share
assets?

Thanks in advance

—
Reply to this email directly or view it on GitHub
#2.

[tonydspaniard]

Hi thanks for replying... the problem @iamfrankhe is that CDN is pointing to a shared S3 bucket among all servers, that means that the assets should be registered on S3 prior providing the Url. The CDN is not pointing to any of the servers that hold the app.

Now, if something has been re-designed and CSS files updated (more than 4), how do you make sure the invalidation process occurs prior breaking design until CDN updates? how do you force update?

I have also seen that the hash is by filename always... that means that if the contents of a file has been changed, the file won't be updated. According to http://abhishek-tiwari.com/post/CloudFront-design-patterns-and-best-practices the only way to do it is by versioning and the best is using the md5_file to hash the contents so all servers do have the same hash (if you do it via filemtime, it is different among all servers)

We are currently having this issue and I know that if CDN is pointing to one of the servers would be fine but not on our case.

[frankhefeng]

Hi, Antonio,

Firstly, I do not use S3 with this extension. I set up CloudFront to point to Yii web app directly.

Yes, the hash is by filename, this is because we found this issue: we ignore assets folder in .gitignore, then required assets should be regenerated when user visits any page. But actually, when we run Yii app via Amazon Elastic Beanstalk, web instances will be automatically increased with traffic. Then, we notice for an web instance, especially the newly increased instance, some files do not always exist under assets folder. This is because the instance which handles PHP request, will generate all required files by current page under assets folder, but then the HTTP requests for those static files under assets, could be processed by another web server, in this case, maybe it is just the newly increased web server. Then we will notice lots of 404 Not Found exception.

To solve this issue, we changed hash to be generated by filename and also do not ignore assets folder in GIT. If anything changes in assets, we need to update these files manually in git repository.

Finally, if you check the source code for CloudFrontAssetManager::invalidate method, it will iterate all files under assets folder recursively and invalidate it in CloudFront.

I hope the explanation above helps to your problem.

[tonydspaniard]

@iamfrankhe thank you very much for the information, it was really helpful and it confirms that we couldn't use it to fit our requirements. Nevertheless, it help me greatly to find the right solution to it. My problem was that I couldn't point CDN to any Yii app but to a distributed S3 instance (thats how the architecture was set), and the invalidation of the assets was not good as it was taking 10-15 minutes to update cache on CDN.

What I finally did is the following:

• create a command that will be run on each deploy that, in conjunction with the asset manager, will publish the assets to S3 based on the new 'realpath' hash (is different on each deploy), this way we handle the 'static' files (or our app files).
• create an Asset manager replacement that will handle the publishing option of 'dynamic' files (vendor files)

Thank you very much again for your help and inspiring code.

PS: Will also propose your solution. Easier than my approach if they agree to use the assets folder of an instance instead.