Categories
Archive for category Rails
There is a much better solution available for implementing Cron Jobs in Rails application then editing the crontab file on your server.
Editing the file by hand requires knowing the cron syntax and what is worst that you need to update the cron file on every server where your application is running.
Here is better solution.
Install gem called – Whenever.
gem install whenever
#Wheneverize your application, which will create an schedule file - config/schedule.rb"
wheneverize .
#Set your cron jobs in the schedule file using ruby syntax
#The syntax is pretty self explanatory
every :reboot do
command "sudo mount /dev/sdf /mnt/data"
command "sudo /etc/init.d/mysql start"
end
every 1.day, :at => "1am" do
runner "Task.deadline_emails"
end
#After every change run this command to update the system cron
# whenever --update-crontab same_name_to_identify_the_job
#Update your deploy file (when using Capistrano)
after 'deploy', 'update_crontab'
task :update_crontab, :roles => :db do
run "cd #{release_path} && whenever --update-crontab #{application}"
end
Prevent user from accessing the app. after logout with back button (rails only)
26/12/10 No CommentsInserting this code into application controller.
setting the headers into the past should solve the problem as well as turning the cashe off.
def set_cache_buster
response.headers["Cache-Control"] = "no-cache, no-store, max-age=0, must-revalidate"
response.headers["Pragma"] = "no-cache"
response.headers["Expires"] = "Fri, 01 Jan 1990 00:00:00 GMT"
end
Inserts this code into every controller (where it make sense)
before_filter :set_cache_buster
I am someone who often forgets things or makes mistake. If you make mistake in the migrations inside your ROR project there is a easy and intuitive way how to put things back into the stage they have been before so you can fix stuff and then migrate the dtb again with the correct values.
Here is how you can cancel the latest migration. It basically executes the self.down part of your migration so do not forget to specify it when you creating your new migrations.
rake db:rollback
First of all lets define the environment I am using. I am using Amazon EC2 server which is running Ubuntu and I am going to use Capistrano to deploy my Rails application. I am also using GitHub as my code repository.
Let me describe in a humanly understandable way what will actually be happening. You will call the deployment by syntax such as “cap production deploy” and the whole clever magic will happen at the background. What magic? So here it comes. Capistrano will use your SSH key to connect to your EC2 instance, from there it will connect to your GitHub account and will pull the latest version of your code into a specific folder. Capistrano will afterwards simlink the running application with the latest version which has just been pulled from Git and woalla you have the app. deployed.
Before you can start deploying with Capistrano there are couple of things you need to do. You will need SSH key which use use to connect to your EC2. I actually think that Capistrano requires both the public and private keys to be stored on your computer. You will also need to generate SSH key while connected to you EC2 instance. You will need to store the public version of this key in your GitHub account details. These keys will allows us to connect to EC2 instance and GitHub. That is all we need for safe connections.
I have said that in this example I am running Ubuntu server on my EC2 instance. To generate and store the SSH key on the Ubuntu server you might need to run the commands over ssh agent. You will get there by executing the following command.
ssh-agent bash
Now you should be able to generated and “add” the SSH key. If you are not sure how, check my article about generating SSH keys.
The folder you need to use for you SSH key sits in here – /home/ubuntu/.ssh as you are connected as user: ubuntu
One important note. I have found out that you can’t specify your own name for SSH key and you need to leave the password blank (just hit enter). The key will get the default name.
After you copied the public version of the key to your GitHub account you can double check by using the following command.
ssh git@github.com
You should be invited with your name and you will also get an security note. Just ignore that for now.
Installing Capistrano
The capistrano gem can be installed from here.
After the gem is installed you will need to capify your application. Get into the root of your application and execute this command.
capify .
This will create the necessary files and folders. You will find a file called deployment inside of your config directory.
These is the configuration you will need to add in.
set :application, "the_name_of_your_application"
set :repository, "git@github.com:your_git_hub_name/the_name_of_your_application.git"
set :scm, :git
set :user, "ubuntu"
set :use_sudo, false
#environment = 'production'
ssh_options[:keys] = ["#{ENV['HOME']}/.ssh/ec2key.pem"] // This is the path to your EC2 ssh key
// Deploying to Production
task :production do
role :web, "YOUR_EC2_ADDRESS.compute-1.amazonaws.com"
role :app, "YOUR_EC2_ADDRESS.compute-1.amazonaws.com"
role :db, "YOUR_EC2_ADDRESS.compute-1.amazonaws.com", :primary => true
set :deploy_to, "/mnt/data/quantify/production/" // The folder where you will store your application on EC2. You will need to create these directories on your server before deployment. Note that my application sits in /mnt/data directory which is an Amazon elastic block. Do not deploy your app. in different directory otherwise you might loose all data if the instance experiences problems
set :rails_env, :production
set :current_path, "#{deploy_to}current"
environment = 'production'
end
// I am also running test server on the same machine
// The same task is used to deploy to test/staging environment. There are only two differences. The folder name where the app. will be deployed to and the name of the environment.
task :staging do
role :web, "YOUR_EC2_ADDRESS.compute-1.amazonaws.com"
role :app, "YOUR_EC2_ADDRESS.compute-1.amazonaws.com"
role :db, "YOUR_EC2_ADDRESS.compute-1.amazonaws.com", :primary => true
set :deploy_to, "/mnt/data/quantify/test/"
set :rails_env, :test
set :current_path, "#{deploy_to}current"
environment = 'test'
end
// This code will set permissions and restart the application after deployment
after 'deploy', 'set_permissions'
after 'deploy:setup', 'set_permissions'
task :set_permissions do
sudo "chown ubuntu #{deploy_to}"
sudo "chmod -R g+w #{deploy_to}"
end
namespace :deploy do
task :restart do
run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
end
end
If you are wondering how to setup test server or name servers for your domain name I will describe it in the next article so stay tuned.
Ruby on Rails is MVC environment. The C part of MVC goes for Controller. This is the place where you define your actions. The are couple of standard actions, such are Index, Show, Update, Destroy, but you can obviously create any other one you need. There are two handy parameters you might want to setup before you specify your actions. The first one is layout type and the second one is before_filter.
The project controller would start like this.
class ProjectsController < ApplicationController #you can have different versions of layout so here you specify which one you want this controller to use when it is rendered #there is layouts directory in the views directory, you would find the standard.htm.erb file sitting in there layout 'standard' #here you can setup if the page can be accessed for strangers (users who are not logged in) #as you can see in my case it is not possible before_filter :login_required # this is how you would define action in rails def index end end