I'm migrating my Rails apps to Heroku, but from what I read I should not save the images in the public/uploads folder.
I have figured out how to use the AWS buckets for saving new images, but how do I go about moving the existing images?
Also, is it absolutely necessary?
I have read it everywhere, but even after a month of my apps being online I haven't seen my images deleted/moved.
Thank you.
Existing files that are part of your repository will not be deleted.
But new images will get lost, because Heroku might reset the Dyno with a fresh version from the repository.
Related
I've done 2 Rails apps involving image uploads with paperclip. The first one I did a while ago worked fine locally but I had issues when I deployed to Heroku; I realized I needed to use AWS to enable image uploads.
I did that project a while ago. I recently started another project and tried to incorporate similar functionality. Before I enabled AWS with paperclip when I tried to deploy, I just wanted to test what would happen if I tried to upload an image. To my surprise, it worked without AWS! I was hoping to understand why it didn't work the first time and why it does work now. How does paperclip work with heroku and rails behind the scenes?
It's likely the first application was hosted on the legacy Bamboo stack, that had a read-only file system.
In the new Cedar stack, the file system is no longer read-only, so the upload will not fail. However, you should keep using AWS or any other external storage because Heroku distributes your compiled application across several machines, and it's not guaranteed that the image will be visible from another request. They call it ephemeral filesystem.
In other words, with the Bamboo stack it was easy to understand that you could not store files on the file system, because you were experiencing an immediate crash. With Cedar the upload succeeds, but the uploaded image will be unavailable at anytime in the future.
The moral of the story is: you should keep using AWS or any other storage outside Heroku file-system.
Hi I'm currently using carrierwave on my rails app without Amazon S3 or any storage, so the pictures I upload onto my heroku app keep disappearing. I was wondering if there was a way to migrate existing records beforehand(made in development mode) to heroku so that those pics would be stored forever in the local filesystem instead of disappearing?
If you only want to have some pics displaying, you can eventually manually add them in your public folder, at least they will display properly.
For example, you can add the picture "/public/uploads/recipe/photo/5/chicken-wings.jpg" to your git repo and push it to heroku.
Of course this is not the perfect solution as you add this image into your git repo which is not what you want when you will launch the application in production but as Heroku is a read-only file system this is the only way to store file on their filesystem.
You'll need the taps gem
gem install taps
Then do:
heroku db:push [options]
use --tables [array of tables you want pushed] if you need to upload specific tables only.
source
I would appreciate any feedback regarding what may be causing my issue, described below.
I have an application that allows users to upload images. Everything works fine in development and used to work fine in production.
Recently, my newer images have all broken. I can upload new images, but when I check back a few hours later, the images are broken again. This started happening about a week ago, and images that I've had up in production from before then are still ok.
I am using Rails with Bootstrap and SimpleForm, and using Paperclip for the images. I am using Postgres in both devleopment and production, and am deploying to Heroku.
The only hint I have is in the "blank_profile_pic.png" image that I use as a default when users don't have a profile picture uploaded.
User.all.each do |u|
if u.profile_pic.file?
image_tag(user.profile_pic)
else
image_tag("blank_profile_pic.png")
end
end
For users that don't have a profile_pic uploaded, a broken image appears if their profile was created in the last week, but the expected "blank_profile_pic.png" remains for people that created their account before the issues started surfacing a week ago. How can the same block of code return different results between recent and older users?
I really don't know where to start with this, so would appreciate any feedback regarding what possible causes could be, and if there are any other files that I can show here.
Thanks very much for your help!
Heroku is a read only system. So you most definitely have to upload your images either to S3 or some other cloud provided.
Your images might have been uploaded to /tmp in Heroku and then somehow it was cleared, hence the errors.
Here are the docs: https://devcenter.heroku.com/articles/read-only-filesystem
And configuring Paperclip with S3: https://github.com/thoughtbot/paperclip#storage
I am not sure if you have the imagemagick gem installed, but we had same issue with image_magic that was breaking our paperclip functionality in production, but not in development (weird, I know). Yet even after removing imagemagick from our gemfile and Gemfile.lock locally (running bundle install and all that stuff) and then deploying back to production on heroku, the error persisted in production! (weird, I know).
What ended up doing the trick was running:
$ heroku repo:purge_cache -a myAppName
(Taken from: https://github.com/heroku/heroku-repo#purge_cache)
When you deploy your app, Heroku caches some things like your assets and installed gems in order to speed up deployment. Although this is a great feature, it can have side-effects sometimes, and in this case, it seems that something about the imagemagick gem got "stuck" in production's cache, which is why purging solved the issue for us (since after purging, your app will rebuild itself from scratch on your next deployment)
I've got a website built on rails that uses paperclip to persist photos to S3. This works great. I'm using Heroku, so i've also got a staging server set up for future changes and user testing. Following the 12factor Dev/Prod parity http://www.12factor.net/dev-prod-parity in mind I've been using PGbackups to keep the same data in staging as in production. However I can't find a good way to sync my production S3 bucket to staging.
I don't want to use my production S3 bucket in staging for fear of accidentally deleting production photos. Having missing photos show up durring user testing is distracting and unacceptable. Is there an easy solution to push the same photo to two buckets while saving, or to set staging to be a "slave" to the production bucket in S3?
You can run a script to copy your production bucket to staging whevener you synchronize your database: Googling a bit I've found this one. You can wrap it in a rake task and run it from your staging app.
The most recent best answer is on a similar question:
Best way to move files between S3 buckets?
Scroll down until you see the answer by alberge
As the quantity of our pages increases, the number of images in the rails project has increased greatly. Does anyone have a good strategy for keeping track of these images?
We have experimented with a couple ideas but nothing seems to solve everything. Here are the high level requirements we have come up with:
Images should be available to any developer locally (given they have code access).
Updated images can be automatically sent to amazon s3 (and out to cloud front) on deploy
An easy way to "expire" an image when it changes forcing browsers to download instead of using a cached version
We actually deployed a Rake Task to archive this and keep all the files between our application and (in our case) Cloudfiles in sync.
The rake tasks checks for new files or files that have been changed and uploads them to Cloudfiles. If a developer adds an asset, they can just run the rake task and update the cloud. They also check in the file into our version control so other dev's have access to it.