chef deployment?

耗尽温柔 提交于 2019-12-02 18:51:11

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!