I'm in the process of doing several major improvements to my main production app on Heroku
This includes : using PostgreSQL in development, upgrading to the latest Rails, move to a dedicated database with Crane, and using thin as a webserver. The "last" thing I wanted to do as a logical step was to upgrade my app to Cedar stack instead of Bamboo. I've followed most of the instructions and have an ok "clone" app.
I'd like to move forward and use this new cedar app instead of the bamboo one.
The problem is that this app main use is as a backend serving API requests to an iOS app. These requests are in the format : xxx.heroku.com/...
It was probably a bad idea to use this url in the first place, but this is it and can't be changed on all our current iOS users.
I can find a way to rename my cedar app xxx. The problem is that it will be xxx.herokuapp.com . I know there is an automatic redirect on heroku, but it seems to be only for GET requests. So all my API requests won't return the XML responses I need for the iOS app.
Any suggestions ? I thought I would be able to use xxx.heroku.app going forward and I'm a bit stuck now.
Simple thing is to replace your bamboo app with a simple app that redirects requests to your new URL.
I would suggest never using the heroku domains as production domains - always put your own domain in front of them.
Related
In my application, I have used caching. This is the code, I have used. In after_filter, I called the method which include this one line code.
Rails.cache.write("properties", #properties.to_xml)
I try to get this in another action in before_filter like
#hotels = Rails.cache.fetch("properties")
this all working fine in development machine. But in server it returns null value. the application run in same development mode in server. Can you please anyone suggest me the right way. Thanks in advance.
It sounds like you haven't configured a backend for the store, so it will use ActiveSupport::Cache::MemoryStore
From the documentation:
If you're running multiple Ruby on Rails server processes (which is the case if you're using mongrel_cluster or Phusion Passenger), then this means that Rails server process instances won't be able to share cache data with each other.
This works in development since you are likely using a single server instance, so the cache is only stored in one process. For production you need to configure an alternative shared store. I'd recommend running a memcached instance, and installing and using the Dalli Gem as per the README.
I have had a quick look on google to no avail.
I am looking for a way to write a rails app that can deploy another rails app using nginx unicorn and what ever else is necessary to get the job done.
Ideal the user would be presented with a screen where they would enter username password, email and sitename.
Then the app would create the site and give it the url sitename.appname.com
Thanks
Ash
They are called engineyard, and heroku.
Rails probably wouldn't do much but give you the control panel, all the magic would be behind the scenes. If you are just subdomaining an existing app, rails can do that too and you wouldn't need a new nginx/unicorn on each subdomain either.
The typical answer of "it depends on your app and there is not enough information to go on" applies as well.
I have a rails app hosted on heroku and a mobile app made with rhodes.
I'd like to send images from the mobile app to my rails app using an HTTP POST request. Since heroku doesn't allow you to store files, I'm using amazon s3.
I can't send the file from heroku to s3 because it takes more than 30 seconds and causes a timeout. I've seen plenty of examples of uploading a file direct to s3 when the user has a form, but this obviously won't work in this case.
I tried using the suggestion here:
rails 3, heroku, aws-s3, simply trying to upload a file to S3 that is POSTed (http/multipart) to our app
but I still get a 503 request timeout.
I don't want to put my amazon s3 keys on the app.
Right now, I feel like my only option is to host my app on EC2 which I would rather not do as I like the simplicity of Heroku.
Also, it seems strange that these uploads would take so long regardless. I'm only posting images from a mobile phone camera, so they're not huge files.
I was getting the same error in a project in my job. Some people says that the only way to solve this is by uploading files directly to the S3 bucket. This is difficult in our case, because we are using Paperclip Gem for Rails and different size versions of the image.
Some other people says that "The Heroku timeout is a set in stone thing that you need to work around. Direct upload to S3 is the only option, with some sort of post-upload processing required", so I recomend to do the next:
Maybe this is not a solution but, it could be very useful, it was for me in a Rails App:
Worker Dynos, Background Jobs and Queueing
Perhaps you should move this heavy lifting into a background job which can run asynchronously from your web request.
Regards!
So I finally figured out how to do this.
After lots of back and forth with AWS reps and Cloudfiles reps and pulling my hair out, I realized it would be a lot less work to just get another rails server that could write to the filesystem.
So, I started another rails app on openshift. It's just as easy as Heroku to get started (in fact, I might consider moving my rails app there, but it's too new for my taste right now and doesn't have the community around it that Heroku does).
Then, I just had to have communications between my two rails apps.
I know it's not the best/scalable/elegant fix, but it got the job done, and that's what matters in the end!
I'm building a Rails application that deals with file uploads through CarrierWave. Currently, larger file uploads block the server for a significant amount of time. I have seen solutions like the s3-swf-upload-plugin gem that skip the local server and send files straight from the browser to S3, but this would require some modifications for pre-generating unique filenames and synchronizing them with the database. I'm sure it wouldn't be too much trouble, but Heroku's new Cedar stack gave me the idea of offloading these long running requests to a node.js instance running in the same app. I'm not very experienced with these kinds of things, so excuse my wording if it's a bit off.
Would something like this be possible? How would you configure things such that certain requests (ones involving file uploads, in this case) would be handled by a node app bundled in the same heroku repository as the main rails app?
I don't think it's possible to mix Rails and Node in the same app. However, you could get roughly the same functionality by using two separate apps that communicate with each other.
You can use ENV['DATABASE_URL'] to determine your database connection string. Use the heroku console to set it as an ENV variable for your Node app (e.g. heroku config:add OTHER_DB=your_connection_string) should then be able to use the same connection string to connect to the same database from your other heroku app. You could even access it outside of heroku if you have a dedicated database, see: http://devcenter.heroku.com/articles/external-database-access
For seamless integration between the two apps, you could have a form rendered by the Rails app post to a URL of the Node app. In addition to the file upload, include in that form via hidden input fields any other variables you need to communicate to the Node app. When the upload to the Node app is done, it could redirect the client back to the Rails app, passing any status or variables as get parameters.
Run the two apps under two subdomains of the same domain and you could even share cookies between them.
You need two apps. I am doing exactly what's described in this question. I wanted large streaming uploads, and since Rack writes downloads to a temp file before passing them through to the handler, it is not possible to do this with Rails.
Node.js, on the other hand, does this beautifully. So there are two Heroku apps, the Rails web app and the Node.js (Express) web app. The Rails web app uses SWFUpload as the client-side solution. The Rails app and the Node.js app both have a secret key as a Heroku config variable. When it's time for the user to upload, client-side Javascript requests an upload URL from the Rails server. The Rails server forms an upload URL with an Expires parameter and computes a signature using the secret key. The client-side Javascript handler passes this URL along to SWFUpload (upload_url property). The user selects the files to upload, and SWFUpload starts posting them to the upload_url. The Node.js app verifies that the URL is not expired and that the signature is valid. It processes the form data with the formidable library.
One other detail. Flash requires the Node.js app to serve a crossdomain.xml that permits the cross-site request.
My Node.js app doesn't touch the database; but if it did I would share DATABASE_URL as previously suggested. Note that you can't share a DATABASE_URL outside of Heroku unless you have a dedicated DB. The DATABASE_URLs for shared databases are not reachable from outside Heroku (unlike some other services like RedisToGo).
I have a client who wants to migrate his Rails app to Heroku. However the client also has a blog associated with his domain that runs on WordPress. Currently, the WordPress blog is running happily alongside the Rails app, but once we migrate to Heroku, that clearly won't be possible.
The url for the app is like http://mydomain.com, and the url for the blog is like http://mydomain/blog.
I realize that the best long-term solution is to redo the blog in a Rails format like Toto or Jekyll. But in the short term, what is the best way to continue hosting the WP blog where it is (or somewhere) but use Heroku to run the app? The client doesn't want the blog to be on a subdomain, but to remain at mydomain/blog for SEO reasons and also since there is traffic to the blog. I have two ideas:
Use rack_rewrite or refraction (or just a regular old 301 and Apache mod_rewrite) on the old (non-Heroku) server to redirect the main url from the old site to Heroku. In this case, I can just leave the Wordpress blog running happily where it is. I think?? Is there a reason to choose one of those options (rack_rewrite, refraction, or mod_rewrite) over the others if I do it this way?
Switch the DNS info to point to the Heroku site, and then use a 301 redirect from the blog to the old site. But then I'll have to get the old (non-Heroku) site on a subdomain and use some kind of rewrite rules anyway so it looks like it isn't a subdomain.
Are either of these approaches preferable, or is there another way to do it that's easier that I'm missing?
The only tenable long term/scalable solution would be to host the blog permanently on a sub-domain or different domain and add a redirect from mydomain.com/blog to the new location (ie: blog.mydomain.com).
You would need a single server running a front-end like Apache/nginx on mydomain.com to serve up mixed back-ends like Rails and Wordpress and that is not possible on Heroku.
Sadly, this is where you need to dig in as a consultant and be stern with your client about the technical limitations.
Why does you client want to migrate to Heroku? Is there a larger goal behind that you could accomplish with different hosting where you control the front-end and can mix in different back ends?
Another solution is to set heroku to http://app.example.com, and Wordpress to http://example.com. You put your Wordpress-landing page in the root , and blog on /blog. When the user click "login" or "signup" on the landing-page, they're linked to the heroku-app.
This will be optimal in a SEO-perspective, but require some DNS-knowledge.
Winfield's answer is not correct. You can run a reverse proxy on your rack server (via Heroku) to direct to the blog, wherever it may be.
See https://github.com/jaswope/rack-reverse-proxy
After you install the gem and set up your app according to the docs, your ./config.ru file will have something like this:
use Rack::ReverseProxy do
reverse_proxy(/^\/blog(\/.*)$/,
'http://<app-name>.herokuapp.com$1',
opts = {:preserve_host => true})
end