chef deployment?
I'm interested in switching from Capistrano to Chef, but am having a few issues putting all the pieces together.
I've followed http://wiki.opscode.com/display/chef/Quick+Start and am able to start EC2 instances with knife
. As far as code deployment, it looks as though I want to be doing what's in http://wiki.opscode.com/display/chef/Deploy+Resource, the only problem is, nowhere on that page does it mention in what directory/file the deploy /to/path
code block should go.
Another issue I'm having is understanding how to deploy code changes after the server has been set up. Perhaps I'm just used to my current workflow (git push && cap deploy
), but the best I can tell is that after I commit my changes I'm supposed to ssh into the server and run sudo chef-client
? something about that feels wrong. Is there no cap equivalent, i.e. chef deploy
?
Finally (and perhaps this is a bit more difficult), I'm looking to deploy multiple rails apps to a single server. It seems prudent to keep some sort of chef config file in the repo of each app describing the particulars of its deployment, but I'm uncertain how that would then interact with the chef-repo / hosted server. Would each app be a role? And from my understanding of the way things work, I'm also a little uneasy with the idea that 'chef-client' would be trying to deploy all appli开发者_高级运维cations when run. With git push && cap deploy
I'm certain of what I'm deploying. Whereas some of the other application repos might not be in a deployable state. Would there be a way to deploy just a single app in this set up?
So knife is actually capable of doing capistrano-esque tasks - specifically, running a command across multiple servers.
To deploy your app to all of your app servers, assuming you followed the opscode rails application cookbook path, you could just do the following:
knife ssh role:t<appserver-role> chef-client -xroot -P<pass>
That will run chef-client as root on all of your app servers. It uses chef search API to find all the nodes with that role and run that command on them.
It's pretty powerful.
I wrote the following article describing how to go about deploying Ruby on Rails using chef.
http://tech.hulu.com/blog/2012/07/06/automating-system-provisioning-and-application-deployment-with-chef/
Well... this article is not just about Rails, but the lion share of the example is about deploying Rails.
There is also a community cookbook called "application" cookbook which can be used to deploy Ruby on Rails. Compared to that cookbook, the example in this article should be a little easier to understand for new people. However, once you get used to doing it using the example in the article, you should definitely look at the application cookbook to see if that makes more sense for you.
The suggestion about using knife ssh to deploy on demand is absolutely correct. If I could further elaborate on using Chef as a deployment solution (especially compared to tools like Capistrano). Chef is designed as a tool for config management and systems integration, part of what that implies is that everything running on a system should be idempotent.
There's sometimes confusion when using Chef deployment about re-running everything when a Chef run takes place. Keep in mind Capistrano works by telling the system "do this", Chef works by telling the system "be this", so what version of an application and what schema a database should be using will normally be defined in attributes and data bags. When Chef runs if the application is already deployed and the database already has the proper schema nothing should happen, actions should only be taken if the system is not already in the desired state. This is why even when deploying multiple applications re-running everything should not be a problem.
In my experience, it's better to keep capistrano as it has some RoR functionality that you will have to replicated with Chef. Chef is a very flexible tool and you can do a lot with it so it can be a replacement for many other tools. I personally find targeted tools more helpful.
Capistrano addons for Unicorn, Asset Syncs with S3 and others (like this https://github.com/bokmann/dunce-cap) are always very useful.
As an easier way to deploy and manage Ruby on Rails apps, I can also suggest http://www.cloud66.com
Disclaimer: I work for Cloud 66.
精彩评论