1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
I've been using [[http://www.opscode.com/chef/][Chef]] for some time
now, but it was always via [[http://vagrantup.com][Vagrant]], so a few
weeks ago I decided to get more familiar with it. A friend of mine had
set up a Chef server for his own use and was OK to let me use it for my
personal server. There was a four days weekend for Thanksgiving coming,
so it was the perfect occasion to take a better look at it, and to
re-install my Linode server with Chef. And since it was a really long
weekend, I also decided to take a look at
[[http://ansible.cc][ansible]], another tool to push stuff to your
server.
I'm not going to talk about installation, configuration, set up and all
that kind of stuff, there's enough material available around (blog
posts, articles, books, etc). Instead, I will talk about my experience
and share my (very valuable) opinion (because, clearly, the world
deserve to know what I think).
** Writing cookbooks for Chef
For the few of you who don't know, cookbooks, in Chef's world, are a
group of files (templates, static files) and code that are used to
automate your infrastructure. Usually, you'll create a cookbook for each
of your application (one for nginx, one for MySQL, etc).
I've a few services on my server (git, gitolite, Jenkins, graphite,
collectd, phabricator, ...), and I wanted a coobook for each of them.
I've started by looking for the one already existing (there's a lot of
them on GitHub, on the
[[https://github.com/opscode-cookbooks/][opscode's account]]), and I
tried to use them without any modification. Usually, a cookbook will let
you set some configuration details in your role or node to override the
defaults it provides (like the password for MySQL, or the path where to
put logs). So what I did was to set the interesting cookbook as a git
submodule in my cookbook repository. Unfortunately, for almost all of
them, I had to give up and import them in the repo, so I could edit and
modify them.
That's probably my biggest complaint with cookbooks: I doubt code
re-usability is possible. You can use a cookbook as a base for your own
version, but either they are too generic; or sometimes you need a
workaround; or they do way too many things. And as a result, you need to
edit the code to make them behave the way you want.
In my opinion, developers/ops should just publish
[[http://docs.opscode.com/essentials_cookbook_lwrp.html][LWRP]]
(Lightweight Resources and Providers) and templates, that's the only
thing that I can see as really re-usable (take a look at
[[https://github.com/dagolden/perl-chef][perl-chef]], I think that this
one is a good example).
** Using ansible
ansible was a new tool for me. A few friends mentionned it to me last
October when I was at the [[http://osdc.fr][OSDC.fr]] and it was also
suggested to me by a colleague at work.
This tool is definitely less known that Chef, so I'll give a quick
introduction. In ansible world, you write "playbooks", which are the
orchestration language for the tool. That sounds very similar with Chef,
but the main difference is they are not actual code, but a scenario with
actions.
On the web site of the project, there's a quote saying:
#+BEGIN_QUOTE
You can get started in minutes.
#+END_QUOTE
and for once, that's true. I only had to read the first page of the
documentation, and I was able to write a very simple playbook that I was
able to evolve very quickly to do something actually useful.
Another difference with Chef is that they don't incite you to share your
playbooks, but instead to share your modules. Modules could be compared
to Chef's LWRP. They are Python code to do something specific (like the
[[http://ansible.cc/docs/modules.html#pip][=pip=]] module, to install
Python package, or the
[[http://ansible.cc/docs/modules.html#template][=template=]]'s one).
** Chef vs Ansible
For now, I've decided to stick to this: use Chef for my supporting
application (nginx, MySQL, etc) and ansible for my own applications.
So far, I prefer ansible to Chef. There's definitely less available
material about ansible on the net, but the quality is better, and the
main documentation is very (I insist on the /very/) well organized. I've
never spend more than 10 minutes looking for something and to implement
it. I can't say the same with Chef: the wiki is confusing; there's way
too many cookbooks available; their quality is very disparate.
|
