I know this may seem trivial to some, other won't see the point, however - for me this would be great:
I am trying to work out how to quickly and efficiently commit updates to my Rails app, switch to an under construction style page while I restart the rails app and then test the changes, then when I am happy, switch back to the live public version.
At the moment, I follow the following pattern:
1, make changes to app
2, commit using Versions App for Mac to BeanstalkApp
3, deploy revision from BeanstalkApp to server
4, login to server and restart apache
5, wait a few seconds and then start to double check everything is A-OK
If it helps, I am using Passenger on a Turnkey Rails image VPS.
Thanks in advance for any advice, etc.
Thanks,
Danny
You have a few options:
Create a subdomain for 'testing' and deploy it to your production server and when it's vetted you can push it to your production code location.
You'll need to be able to add a subdomain to your DNS record to point to the same IP address as your main production server. You'll then also need to add a new VirtualHost with ServerName subdomain.host.com and DocumentRoot /data/host.com/testing/public so that it loads that code.
Using Passenger create a subfolder app. See section 3.2 of http://www.modrails.com/documentation/Users%20guide.html#_deploying_a_ruby_on_rails_application to see how to add RailsBaseURI directives to enable separate sites in subdirectories. This means you deploy your code to another directory and create the simlink.
I have personally done BOTH approaches. I prefer approach #1 but it's personal preference and the level of access you have to your hosts.
Related
I have been asked to make a few cosmetic changes to our production deployment. I have access to our linux box where I can see the files I need to change. I only need to change html.erb files, but when I add, for instance a simple <p> tag, it does not show up live.
I know I probably have to reset the server or redeploy the code, but I have no idea what to do.
Our production deployment is not fully live, so I am making changes on the fly (I know that this is not the best practice). Our app is running in a shared hosting environment for the moment.
I have seen threads where people use Capistrano to deploy but how? We do not currently use it.
Can anyone help?
Whenever you make changes in production files, you have to restart the server to see the changes.
In production environment cache_classes is set to true. One can disable it and changes will be reflected without restarting the server.
So to reflect the change restart the server.
thanks......
I found a good guide on the Capistrano github wiki and also used this guide # kris.me.uk about a complete rails setup, including the Capistrano deployment aspect. I used them when learning how to deploy rails apps effectively. They should tell you what you need to know to get a basic deployment setup up and running.
Just incase someone is looking for the answer:
When rails is in development mode it will automatically reload changed files. When in production I need to restart it.
I eventually found out that we use God (A proces monitoring framework for rails - link here).
I had to restart our app with the following command: 'god restart APP_NAME'
Hope that helps someone :)
I wrote a Capistrano // NGINX guide and posted it on my blog. It's 85% correct, and should help you understand the big picture of the server/Rails/SSH configurations.
http://westonplatter.com/blog/2012/08/19/rails-slash-nginx-rackspace-deployment/
Firstly, Happy New Year everyone.
I'm new to Rails, so please tolerate any incorrect use of terminology...
I have developed a simple Rails application, backed by a MySQL database.
I would now like to deploy this application to multiple, independent groups of users (i.e. it is a club application, and I would like to deploy it to a number of completely independent clubs).
I would like to use the same Rails Application code as much as possible, and just have a separate instance of the database for each club.
As each instance will be running on the same server (until server load proves to be an issue) I assume I can use a different port for each Rails server to steer users to the correct group?
I'd read that there are test and production modes, is it possible to have multiple [additional] instances of production modes, e.g. club1, club2, all sharing the same code, with unique databases?
My questions are how to support multiple separate database instances, and also how best to route to these?
Any advice on how to go about this much appreciated.
If you are using Git (I suggest you should be!) then you can keep a central version of your code in one place and then deploy it multiple times, changing only the database.yml file (it should not be checked in to your git repository in that case). http://git-scm.com/
Let's say you put all of your code up on github.com with username 'snips' and the project is called 'clubster'. Using something like Heroku you would then do:
git clone https://github.com/snips/clubster.git
cd clubster
heroku create boxingclub
Because Heroku auto-configures your database there is no need for a database.yml file
git push heroku master
And you'd have a version of your code deployed at boxingclub.heroku.com
When you make changes to your code you just go to each of your installations and do:
git pull origin master
git push heroku master
Which updates your code on that particular instance of your application.
And if you're getting a little more advanced you'd be looking at Chef to manage the whole setup for you. http://www.rubyinside.com/chef-tasty-server-configuraiton-2162.html
The other approach would be to have some kind of subdomain system, but I'll leave that to others to cover.
I have a client who wants to be able to add/delete/modify email addresses etc through cPanel, but I'd much rather add my own virtualhosts config for the actual site instead of a cPanel generated one. (A bunch of reasons. Don't want to install cPanel's ruby, would rather use passenger than mongrel, etc etc).
I don't have a whole lot of experience with cPanel, but by the look of things it takes over httpd.conf & auto-generates a virtualhost for the site - and overwrites stuff if I try to make any changes to the virtualhost settings. Is there a simple means to overwrite these settings without removing the rest of the site's functionality from cPanel?
Cheers...
You are correct in guessing that cPanel takes over a lot of things and auto-generates certain configs. To be honest, I have no idea what it does in regard to virtualhosts configs, but I do have recent experience in other areas which tends to confirm your suspicion:
So, to illustrate... cPanel comes stock with Rails 2.3.5. On the cPanel GemSet page, you can see Rails 3.0.6 shows as available, and even lets you install it via cPanel or SSH/BASH. This results in no error message at all (in fact, cPanel itself reports it as installed), but a rails --version command at SSH/BASH still shows version 2.3.5. After some research on on the cPanel forums, I discovered that this is because cPanel is hard coded for Mongrel support, and Mongrel doesn't support Rails past version 2.3.8. According to one of their moderators, they're looking at a possible Passenger solution, but it's still in the early stages of coding and months away.
So, while I realize my example doesn't specifically answer your question about virtualhosts, I think it confirms the validity of your suspicion that cPanel overrides certain settings, and may even be hard coded in ways that aren't immediately transparent...
I just look up at rails sources and find folder named "dispatches". There is four file in it. I want to know purpose of this files. I know I use this files on my production server, but I never used to think of their purpose. I know there is something about attaching Rails app to Apache server. On my production server rails appname command add this files to public folder automatically. Can I set up this behavior on my development machine?
The rails dispatcher is the entry point for a rails application and is used to bootstrap the environment.
They have a long history and in a lot of ways they are almost obsolete. In days gone by rails apps used to be powered using cgi or fastcgi, which was a way for the webserver to communicate with a rails process. The boot process would be initiated by dispatch.fcgi or dispatch.cgi. Nowadays people are more likely to use apache/nginx+passenger or apache/nginx+mongrel/thin. (Does anyone still use lighttpd?)
I'm a little fuzzy on how dispatch.rb is used, but I think it's used by upstream rails servers such as mongrel/thin to bootstrap the rails process. However, now that rails is rack compatible I'm not entirely sure if that has changed.
You don't need to pay the dispatch.* files any attention.
I hope this helps.
I'm kind of lost, I try to deploy my application on a shared dreamhost server.
Now everything works fine locally. It's my first try at Rails, and I'm not really a programmer or sysadmin, just hacking something together.
On Dreamhost, if I start webrick, it works fine on port 3000, but webricks gets killed pretty quickly, I guess that makes sense.
So what do I have to do to make it run?
I enabled fastcgi support and mod_rails.
Now, how do I get the app constantly running?
I keep reading about having to do things to .htaccess and to dispatch.fcgi.
But I can't find any dispatch file in my rails app (2.3.2).
Do I have to create that one manually? Doesn't really feeld very rails-like to me. I didn't really manage to find out what this dispatch file does, and why it's needed.
Any help would be greatly appreciated.
I looked at the DH Wiki, but couldn't figure it out (http://wiki.dreamhost.com/Rails)
Additions:
I enabled mod_rails and pointed to the public directory (I had already done that).
I keep getting an error: screencast.com/t/KamqVawk
Hm, server logs look like there is actually no request, so this might be a problem on dreamhosts end. It's strange I see that the access.log show a new change date, when I try to access the page, but there is no request noted, error.log is empty too.
Dreamhost Support Answer:
The server was up to date, so that wasn't the problem.
They proposed freezing the Gems, which I did (see: http://wiki.dreamhost.com/Freezing_Gems)
But it didn't help.
I guess I'm giving up, and looking into hosting which is specialized for rails.
Thx for all your help!
Changed to hostingrails.com
I got the app working on hostingrails.com, passenger on hostingrails.com showed me errors, which weren't shown by dreamhost or mongrel. By correcting these errors, I got the app working.
Dreamhost won't let you use webrick if you're using shared hosting. You can either use FastCGI or Passenger to host Rails on shared DH (mongrel is an option if you upgrade to DreamhostPS, but that's obviously more expensive).
For FastCGI, you will need a dispatch.fcgi file (older versions of Rails would generate one when you created a new Rails app, but that stopped around 2.2 if I remember correctly) as well as code in your .htaccess to send requests to the dispatcher. See the Dreamhost Ruby on Rails wiki page for details about setting up FastCGI.
The more preferable option is to set up your application to run on Phusion Passenger (aka mod_rails). It should be pretty simple through your Dreamhost panel, you just need to enable the domain to use mod_rails, and then set the directory for the domain to the public directory of your application. See the Passenger wiki page for more details.