I use capistrano to deploy my app to a machine that uses memcache. I want capistrano to clear memcache when it deploys a new version of the site.
Something like that?
Take a look at this GIST solves the problem: https://gist.github.com/matthuhiggins/668744
Don't know capistrano, but can't you just kill the memcached process and spawn a new one?
Better probably for removing fragmentation also.
This, by Susan Potter looks pretty good https://gist.github.com/rays/154570
# 2007 Copyright Susan Potter <me at susanpotter dot net>
# You can read her software development rants at: http://geek.susanpotter.net
# Released under CreativeCommons-attribution-noncommercial-sharealike license:
# http://creativecommons.org/licenses/by-nc-sa/1.0/
namespace :memcached do
desc "Restart the Memcache daemon"
task :restart, :roles => :app do
deploy.memcached.stop
deploy.memcached.start
end
desc "Start the Memcache daemon"
task :start, :roles => :app do
invoke_command "memcached -P #{current_path}/log/memcached.pid -d", :via => run_method
end
desc "Stop the Memcache daemon"
task :stop, :roles => :app do
pid_file = "#{current_path}/log/memcached.pid"
invoke_command("killall -9 memcached", :via => run_method) if File.exist?(pid_file)
end
end
Related
I'm using Capistrano 3. How can I delete failed releases on deploy:failed without writing my own task? The point is that failed releases stay in the releases directory and accidentally I can rollback to broken release by typing cap deploy:rollback
UPD:
For now I'm using this task but still looking for a better solution.
namespace :deploy do
desc 'Delete failed release'
task :rm_failed do
on roles(:all) do
execute(:rm, "-rf #{release_path}")
end
end
end
after 'deploy:failed', 'deploy:rm_failed'
My limited experience with Capistrano indicates that there is no built-in mechanism to perform the action you want. Writing a task that is triggered using deploy:failed is the proper way to handle the situation as it can be application specific.
A better solution that addresses the potential for deploy:clean to fail after the deploy:symlink:release --
namespace :deploy do
desc 'Delete failed release'
task :rm_failed do
on roles(:web) do
if test "[ -d #{current_path} ]"
current_release = capture(:readlink, current_path).to_s
if current_release != release_path.to_s
execute :rm, "-rf #{release_path}"
end
end
end
end
end
after 'deploy:failed', 'deploy:rm_failed'
The Capistrano page on rollbacks has a larger discussion on handling rollbacks and failures.
We are using an AWS OpsWorks stack with Chef Version 11.10. with the default HAProxy Layer. We would like to upgrade the HAProxy to the latest version 1.6-stable (from the default 1.4-stable).
There seems to be a dedicated PPA for our Ubuntu version.
But where can we make OpsWorks use this PPA to install HAProxy?
In the default cookbook there is a default attributes file that has the following lines:
default[:haproxy][:version] = '1.4.22'
default[:haproxy][:patchlevel] = '1'
default[:haproxy][:rpm] = "haproxy-#{node[:haproxy][:version]}-#{node[:haproxy][:patchlevel]}.#{rhel_arch}.rpm"
default[:haproxy][:rpm_url] = "#{node[:opsworks_commons][:assets_url]}/packages/#{node[:platform]}/#{node[:platform_version]}/#{node[:haproxy][:rpm]}"
Overwriting the file in our cookbooks and naïvely changing the version number here does not have the desired effect.
We ended up overwriting the recipe haproxy/recipes/default.rb like so:
#Install software-properties-common if not installed
package 'software-properties-common' do
action :install
end
#Add PPA for haproxy 1.6 and update repo
execute "add-ppa-update" do
command "add-apt-repository ppa:vbernat/haproxy-1.6 && apt-get update -y"
action :run
end
package "haproxy" do
retries 3
retry_delay 5
version '1.6.4-3ppa1~trusty'
action :install
end
if platform?('debian','ubuntu')
template '/etc/default/haproxy' do
source 'haproxy-default.erb'
owner 'root'
group 'root'
mode 0644
end
end
include_recipe 'haproxy::service'
template '/etc/haproxy/haproxy.cfg' do
source 'haproxy.cfg.erb'
owner 'root'
group 'root'
mode 0644
notifies :restart, "service[haproxy]"
end
template "/etc/haproxy/server.pem" do
source "server.pem.erb"
owner 'root'
group 'root'
mode 0600
notifies :restart, "service[haproxy]"
end
service 'haproxy' do
action [:enable, :start]
end
Additionally we needed to update the haproxy.conf to work with the new version.
Everything runs beautifully now.
Upgrading to capistrano 3, the following no longer seems to work:
namespace :project do
desc "Prevents executing by creating lockfile"
task :disable do
on roles(:app) do
execute "touch /tmp/proj_lockfile"
end
on_rollback do
execute "rm /tmp/proj_lockfile"
end
end
end
...
NoMethodError: undefined method `on_rollback' for main:Object
config/deploy.rb:34:in `block (2 levels) in <top (required)>'
Tasks: TOP => deploy:starting => transformer:disable
(See full trace by running task with --trace)
Is there a new task etc to do this?
There is no Capistrano 3 equivalent of on_rollback.
In Capistrano 3, if any command fails, the deployment stops, and the release that was being deployed is left in place (possibly working and deployed, possibly not working and deployed, or not deployed - Capistrano no longer attempts to clean up at all).
Note that this also means that :on_error => :continue is unsupported with no replacement; you have to begin/rescue any exceptions yourself.
The rollbacks section of the documentation is completely empty.
Take a look at the "Rollback flow" documentation: http://capistranorb.com/documentation/getting-started/flow/
deploy:starting
deploy:started
deploy:reverting - revert server(s) to previous release
deploy:reverted - reverted hook
deploy:publishing
deploy:published
deploy:finishing_rollback - finish the rollback, clean up everything
deploy:finished
I am trying to deploy my first webapp to EC2 using capistrano and the repo is on github. But I am facing issues with "cap deploy:cold". The deploy.rb is pasted below. Following are the steps I followed.
1) Logged into ec2 instance using ssh from my local machine. Generated keys using ssh-keygen without any passphrase.
2) Took the contents of id_rsa.pub and copied to the github repo settings deploy keys.
3) Then from my local machine, ran "cap deploy:cold". I get the following error
user1#laptop:~/MyExample$ cap deploy:cold
* 2013-03-01 19:08:06 executing deploy:cold'
* 2013-03-01 19:08:06 executingdeploy:update'
** transaction: start
* 2013-03-01 19:08:06 executing `deploy:update_code'
updating the cached checkout on all servers
executing locally: "git ls-remote git#github.com:user1/MyExample.git HEAD"
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
* [deploy:update_code] rolling back
* executing "rm -rf /var/www/MyExample.com/releases/20130301133835; true"
servers: ["181.73.124.219"]
[181.73.124.219] executing command
command finished in 1186ms
set :application, "MyExample.com"
set :scm, "git"
set :repository, "git#github.com:thisuser/example.git"
default_run_options[:pty] = true
set :user, 'ubuntu'
set :use_sudo, true
set :deploy_to, "/var/www/#{application}"
set :deploy_via, :remote_cache
role :web, "181.73.124.219"
role :app, "181.73.124.219"
role :db, "181.73.124.219", :primary => true
after "deploy", "deploy:bundle_gems"
after "deploy:bundle_gems", "deploy:restart"
namespace :deploy do
task :bundle_gems do
run "cd #{deploy_to}/current && bundle install vandor/gems"
end
task :start do ; end
task :stop do ; end
task :restart, :roles => :app, :except => { :no_release => true } do
run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
end
end
What am I missing here? Also any pointers to a URL/blog that can provide detailed steps would help.
Thanks.
I managed to get it working. As seen in the log,
executing locally: "git ls-remote git#github.com:user1/MyExample.git HEAD"
the capistrano is trying to run the above command local machine and not on the server. Running the above command on the terminal also returned the same error - Permission denied (Public Key).
So I had to copy the generated id_rsa and id_rsa.pub from the deploy server to the local machine. And after copying, add it to the ssk keys being used by running "ssh-add /path/to/keys".
After adding those keys, I was able to move ahead.
I'm struggling to get Sphinx back up and running after deploying a rails app to my VPS.
Specifically, I'm thrown this error:
** [out :: myapp.com] => Mixing in Lockdown version: 1.6.4
** [out :: myapp.com]
** [out :: myapp.com] Failed to start searchd daemon. Check /var/www/myapp/releases/20100227224936/log/searchd.log.
** [out :: myapp.com] Failed to start searchd daemon. Check /var/www/myapp/releases/20100227224936/log/searchd.log
However, a log file isn't created!
This is the deploy.rb I am using (with thanks to Updrift :) )
namespace :deploy do
desc "Restart the app"
task :restart, :roles => :app do
# This regen's the config file, stops Sphinx if running, then starts it.
# No indexing is done, just a restart of the searchd daemon
# thinking_sphinx.running_start
# The above does not re-index. If any of your define_index blocks
# in your models have changed, you will need to perform an index.
# If these are changing frequently, you can use the following
# in place of running_start
thinking_sphinx.stop
thinking_sphinx.index
thinking_sphinx.start
# Restart the app
run "touch #{current_path}/tmp/restart.txt"
end
desc "Cleanup older revisions"
task :after_deploy do
cleanup
end
end
I'm using the Thinking Sphinx gem, v 1.3.16, passenger 2.2.10. Any thoughts you have would be greatly appreciated.
Many thanks!
Greg
UPDATE: Further to some more google searching, I've found a couple of other people with similar errors - seemingly related to port listening errors eg here and [I'm not allowed to link to the other one]. My production.sphinx.conf similarly has used port 9312, despite me specifying in sphinx.yml to use 3312.
Does anyone have any idea what might be causing this? Thanks.
I should have rung up the IT Crowd: "Have you tried turning it off and on again?"
http://groups.google.com/group/thinking-sphinx/browse_thread/thread/dde565ea40e31075
Rebooting the server released the port.