Information Technology Reference
In-Depth Information
Recipes Specify Desired Configuration
Let's explore the concept that you only need to tell Chef
what
the desired configuration
should be, not
how
to achieve it, that we touched on earlier.
Figure 4-1
illustrates this
concept. Before Chef performs actions, it refers to the resources and attributes in a recipe to
answer the question "
What
do I care about?” Then Chef decides
how
to put the system in the
desired configuration by reasoning about the current state of the system. As a result, Chef
code tends to be more succinct than equivalent bash or PowerShell scripting code as you
only need to specify the desired configuration in your code, not how this configuration must
be achieved. Chef determines
how
automatically and autonomously.
Figure 4-1. Recipes specify desired configuration
Let's make this concept more concrete by writing some Chef code. Create a new recipe
alongside
hello.rb
called
stone.rb
following
Example 4-2
.
Similar to
hello.rb
,
stone.rb
does
not need to be in any specially named directory structure.
Example 4-2. stone.rb
file
"
#{
ENV
[
'HOME'
]
}
/stone.txt"
ddo
content
'Written in stone'
end
end
stone.rb
is just a slight modification of the earlier
hello.rb
recipe in
Example 4-1
.
The string
Written in stone
will be written to
stone.txt
. However, in this example, the
stone.txt
file will
be written to your home directory instead of the directory where you run
chef-apply
.
Why did we make this change? It is not safe to use implied relative paths like
stone.txt
with
Chef resources. On some platforms, behind the scenes, Chef could be running in a different
place than you expect. We constrained the things you did in the first
hello.rb
example, so it
was safe, but in general you must use absolute paths when specifying a filename to a re-
