At some time, you came to a point when you need to pick a solution for a deployment of your project, and you decided to pick Chef.
<\/p>\n\n\n\n
Okay, but I have to disappoint you from the start – if you don\u2019t have any experience with Chef, then you\u2019re going to spend much time trying to sort things out with Chef wiki and that wiki is a tricky one. Just visit its start page and you\u2019ll quickly understand that it is mind-blowing.<\/p>\n\n\n\n
Here are some suggestions to help you in lowering the barrier when working with Chef.<\/p>\n\n\n\n
First of all, you have to pick a proper flavor of Chef.<\/p>\n\n\n\n
Go Solo when:<\/p>\n\n\n\n
Go Server when:<\/p>\n\n\n\n
And finally, choose Hosted Chef Server if you need the second option, but don\u2019t want to deal with the server setup. Just to let you know, Chef Server will run nicely on AWS m1.small instance and will satisfy average demands.<\/p>\n\n\n\n
Chef offers two strategies for storing your entities like environments or roles. The recommended way is to keep these entities under version control. You\u2019ll have to upload your entities to Chef server anyway, but SCM protects you from mistakes in the configuration as you can always pick previous settings and re-upload them to server. Also, SCM should be treated as one of the backups for Chef configuration.<\/p>\n\n\n\n
Your setup will typically involve setting attributes via data bags, environments (Chef Server) or roles. It might not be obvious from the start, but it\u2019s better to keep the number of places where you set your attributes as low as possible for readability sake.<\/p>\n\n\n\n
If your choice is Chef Server, then it is good to make environments as a central place for this kind of job. In this case, your data bags will become very compact and will hold only general attributes, common across your environments.<\/p>\n\n\n\n
Although you can set environment-specific attributes in data bag, but it will become huge and unreadable very soon. Instead, placing such attributes into environment files puts you on the right track. You will always know where to look for a specific attribute.<\/p>\n\n\n\n
This way also provides you with the ability to access attributes directly inside recipes\/templates etc via node.attribute call. Data bags are required to be read inside recipe first. Then, proper template variable may be set inside resource definition.<\/p>\n\n\n\n
Environment sample:<\/p>\n\n\n\n
name \"myapp-staging\"\ndescription \"My App staging environment\"\ndefault_attributes(\n \"environment\" => \"staging\",\n \"resque\" => { \"workers_amount\" => 2 },\n \"resque_url\" => \"127.0.0.1:6379\",\n \"memcached_url\" => \"127.0.0.1:11211\",\n \"passenger_min_instances\" => 2,\n \"passenger_max_pool_size\" => 2,\n \"databases\" => [\n {\n \"name\" => \"staging\",\n \"host\" => \"db.myapp.com\"\n }, ...\n ],\n \"db_common\" => {\n \"database\" => \"myapp_staging\",\n \"username\" => \"myapp_user\", ... }\n)\n<\/pre>\n\n\n\nData bag sample:<\/p>\n\n\n\n
{\n \"id\":\"myapp\",\n \"home_dir\": \"\/var\/www\",\n \"deployment_dir\": \"\/var\/www\/myapp\",\n \"user\": \"www-data\",\n \"group\": \"www-data\", \"repository\":\"git@github.com:my_organisation\/myapp.git\",\n \"revision\":\"master\",\n \"resque_group\": \"myapp-resque\",\n \"resque_queues\": \"my,cute,resque,queues\"\n}\n<\/pre>\n\n\n\nThen, you can access environment attributes with node.environment or node.memcached_url. While for data bags, it will look like this:<\/p>\n\n\n\n
config = data_bag_item(\"deploy\", \"myapp\")\n\ntemplate '\/etc\/resque.d\/resque' do\n...\n variables(\n :project_root => \"#{config['deployment_dir']}\/current\",\n :queue => config['resque_queues']\n )\nend\n<\/pre>\n\n\n\nAttributes mess<\/h2>\n\n\n\n
Chef introduces no less than 4 types for attributes. It\u2019s an enormous amount for most of the projects. It would be wise to stick to one type and ignore the others if possible. Chef\u2019s Ohai plugin, which is responsible for gathering information about system, sets 4th type of attributes, and you don\u2019t have control over it – you can only read them.<\/p>\n\n\n\n
Check this page<\/a> and study well priorities for them. Don\u2019t miss the fact that attributes of \u201cdefault\u201d type set in roles will override ones set in environments while attributes of \u201coverride\u201d type are prioritised vice-versa.<\/p>\n\n\n\nCommunity cookbooks<\/h2>\n\n\n\n
While this is the great option to have something that should work out of the box, it would be better not to use these cookbooks. Remember that community cookbooks are written in such a way that covers the majority of use cases: different operating systems, different distributives for an operating system, different ways to install packages (compile them from source or just install assembled by distributive maintainers package) etc – all of this leads to huge, barely readable cookbooks.<\/p>\n\n\n\n
If you need some customization (and sure you will need it), you\u2019ll have to either modify it or to create your own cookbook, depending on community one, or hopefully just to override some of the defined attributes on the upper levels like environments, but you have to be aware of what cookbook does. If you know what it does, then why not to have your own small and simple cookbook?.. Use community cookbooks as a source of inspiration or get vital parts from them and keep your setup readable for yourself and others.<\/p>\n\n\n\n
Where the hell my changes are?<\/h2>\n\n\n\n
So… Your choice is Chef Server and your team works on the same cookbook simultaneously. Once the time has come and you decide to test your cookbook on staging. Chef client runs… and nothing changes. You\u2019re trying again and again, inserting some messages, trying to raise an exception in the middle of the process… Nothing happens. WTF with my Chef Server?!! You\u2019ve checked Server setup – url is correct, server is up and running (obviously)…<\/p>\n\n\n\n
It\u2019s time to check who\u2019s working on the same cookbook and talk about cookbook versions stored on the server. If someone else uploads cookbook with higher version than yours, then you\u2019ll not be able to see your changes applied during the chef-client run.<\/p>\n\n\n\n
This is Server specific problem and the solution would be to introduce some convention inside a team. Particularly, version should be modified when cookbook is in production ready state and is merged into master. It would be nice to notify everybody about this change. Of course, there are other ways to workaround this problem, but this one is simple and effective.
Also you can set explicit cookbook version in your run list, like this: \u201crecipe[deploy::myapp@1.0.0]\u201d. This approach might protect you from surprises. On the other hand, it introduces added complexity in cookbook management.<\/p>\n\n\n\n
Riding chef-client<\/h2>\n\n\n\n
Chef documentation proposes you two scenarios for chef-client. It might run either as a daemon or a cron task, but you don\u2019t have to follow these options. There\u2019s one more pretty attractive option. You may run chef-client only when you need to. Check out for more information article about Chef Server and Amazon Auto Scaling Group (ASG)<\/a>. Its suggestions also applicable for applications that do not utilize ASG.<\/p>\n\n\n\nSharper knife<\/h2>\n\n\n\n
Knife provides you all the necessary commands to communicate with Server, but some of them just require too many arguments, so daily usage of knife may become a little bit frustrating. So don\u2019t hesitate and sharpen that knife with your wrapper script!<\/p>\n\n\n\n
Just a few examples below of how knife commands are morphed into cute compact ones with our wrapper.<\/p>\n\n\n\n
1) SSH command (used to deploy changes)<\/strong><\/p>\n\n\n\nbefore:<\/p>\n\n\n\n
knife ssh \"chef_environment:myapp-production\" \\\n \"echo '{\\\"revision\\\":\\\"master\\\",\\\"migrate\\\":true}' > \/tmp\/json_attrs && sudo chef-client -j \/tmp\/json_attrs\" \\\n -x user_name -i config\/keys\/user_name.pem\n<\/pre>\n\n\n\nafter:<\/p>\n\n\n\n
wr d -e myapp-production -m\n<\/pre>\n\n\n\nwr<\/em> is a name of our shell script,
d<\/em> is a shortcut for \u201cdeploy\u201d,
-e<\/em> stands for environment name,
-m<\/em> – whether to run migration command during deployment or not<\/p>\n\n\n\n2) SSH command to perform across all instances of the given environment (generic)<\/strong><\/p>\n\n\n\nbefore:<\/p>\n\n\n\n
knife ssh \"chef_environment:myapp-production\" \"date\" \\\n -x user_name -i config\/keys\/user_name.pem\n<\/pre>\n\n\n\nafter:<\/p>\n\n\n\n
wr ssh -e myapp-production 'date'\n<\/pre>\n\n\n\n3) List commands<\/strong><\/p>\n\n\n\nbefore:<\/p>\n\n\n\n
knife node list\nknife environment list\nknife role list\n<\/pre>\n\n\n\nafter:<\/p>\n\n\n\n
wr n\nwr e\nwr r\n<\/pre>\n\n\n\nwhere n, e, r – shortcuts for \u201cnodes\u201d, \u201cenvironments\u201d, \u201croles\u201d respectively<\/p>\n\n\n\n
4) Opening SSH session to a specific instance<\/strong><\/p>\n\n\n\nbefore:<\/p>\n\n\n\n