Commit 56dcf812 authored by Robert Ricci's avatar Robert Ricci

Merge branch 'chef-tutorial' into 'master'

Chef tutorial: generalize, rename, and add to Emulab

See merge request !17
parents 1577e3a5 16097c89
Pipeline #2864 passed with stages
in 2 minutes and 3 seconds
......@@ -2,14 +2,21 @@
@(require "defs.rkt")
@title[#:tag "cloudlab-chef-tutorial" #:version apt-version]{CloudLab Chef Tutorial}
@title[#:tag "chef-tutorial" #:version apt-version]{@(tb) Chef Tutorial}
This tutorial will walk you through the process of creating and using
an instance of the Chef configuration management system on @(tb).
This tutorial will walk you through the process of creating and using
an instance of the Chef configuration management system on @(tb).
@margin-note{Chef is both the name of a company and the name of a popular modern configuration management system
@not-clab{
Since this tutorial was originally developed for CloudLab,
you will find the screenshots below that have the CloudLab name and logo in
them. When you use @(tb) to build Chef, the process is exactly the same;
the only difference is that you will see the @(tb) name and logo instead in the portal pages you will open and use.
}
@margin-note{Chef is both the name of a company and the name of a popular modern configuration management system
written in Ruby and Erlang. A large variety of tutorials, articles, technical docs and training opportunities
is available at the @link["https://learn.chef.io/"]{Chef official website}.
is available at the @link["https://learn.chef.io/"]{Chef official website}.
Also, refer to the @link["https://www.chef.io/customers/"]{Customer Stories} page to see how Chef is used
in production environments, including very large installations (e.g., at Facebook, Bloomberg, and Yahoo!).}
......@@ -19,7 +26,7 @@ In the process of taking this tutorial, you will learn to:
@itemlist[
@item{Create your own instance of Chef using a pre-defined profile}
@item{Explore profile parameters allowing to customize components of your Chef deployments}
@item{Explore profile parameters allowing to customize components of your Chef deployments}
@item{Access monitoring and management capabilities provided by Chef}
@item{Use Chef to perform two exercises:
@itemlist[
......@@ -34,13 +41,13 @@ In the process of taking this tutorial, you will learn to:
@section{Motivation}
This tutorial will demonstrate how experiments can be managed on @(tb), as well as show
how experiment resources can be administered using Chef.
how experiment resources can be administered using Chef.
By following the instructions provided below, you will learn how to take advantage of the powerful features of Chef
for configuring multi-node software environments.
The exercises included in this tutorial are built around simple but realistic
configurations. In the process of recreating these configurations on nodes running
default images, you will explore individual components of Chef and
follow the configuration management workflow applicable to more complex configurations and experiments.
The exercises included in this tutorial are built around simple but realistic
configurations. In the process of recreating these configurations on nodes running
default images, you will explore individual components of Chef and
follow the configuration management workflow applicable to more complex configurations and experiments.
@section{Prerequisites}
......@@ -48,7 +55,7 @@ This tutorial assumes that:
@itemlist[
@item{You have an existing account on @bold{either}: @itemlist[
@item{CloudLab (Instructions for getting an account can
@item{@(tb) (Instructions for getting an account can
be found @seclink["register"]{here}.)}
@item{The @link["https://portal.geni.net"]{GENI portal}.
(Instructions for getting an account can be found
......@@ -74,72 +81,79 @@ anything you store there will be lost when the experiment terminates.
has @seclink["hardware"]{large clusters} that can be used for larger-scale
experiments.}
For this tutorial, we will use a profile that launches a Chef cluster --- a set of
interconnected nodes running Chef components such as Chef server, workstation, clients.
The @(tb) staff have built this profile by scripting installation procedures for
For this tutorial, we will use a profile that launches a Chef cluster --- a set of
interconnected nodes running Chef components such as Chef server, workstation, clients.
The @(tb) staff have built this profile by scripting installation procedures for
these components. The developed scripts will run on the experiment nodes after they boot
and customize them (create necessary user accounts, install packages, establish authentication
between the nodes, etc.) to create a fully functional Chef cluster with a
between the nodes, etc.) to create a fully functional Chef cluster with a
multi-node, production-like structure.
See this manual's @seclink["profiles"]{section on profiles} for more
information about how they work.
@itemlist[#:style 'ordered
@instructionstep["Start Experiment"]{
@clab-screenshot["tutorial/start-experiment-menu.png"]
After logging in, you are taken to your main status
@link[@apt-url["user-dashboard.php"]]{dashboard}.
Select ``Start Experiment'' from
the ``Experiments'' menu.
}
@instructionstep["Select a profile"]{
After logging in, you will be taken to the
``@link["https://www.cloudlab.us/instantiate.php"]{Start an
Experiment}'' page automatically if you do not have any current,
running experiments. You can get back to this page at any time by
selecting the ``Start Experiment'' link from the ``Actions'' menu.
By default, this page suggests launching the OpenStack profile which
By default, the ``Start an Experiment'' page suggests launching the OpenStack profile which
is discribed in detail in the @seclink["openstack-tutorial"]{OpenStack tutorial}.
Go to the list of available profile by clicking ``Change Profile'':
@screenshot["chef-tutorial/change-profile.png"]
Go to the list of available profile by clicking ``Change Profile'':
@clab-screenshot["chef-tutorial/change-profile.png"]
Find the profile by typing @bold{ChefCluster} in the search bar. Then, select the profile with the
specified name in the list displayed below the search bar.
A 2-node preview should now be shown along with high-level profile information.
Click ``Select Profile'' at the bottom of the page:
specified name in the list displayed below the search bar.
A 2-node preview should now be shown along with high-level profile information.
Click ``Select Profile'' at the bottom of the page:
@clab-screenshot["chef-tutorial/find-chefcluster.png"]
@screenshot["chef-tutorial/find-chefcluster.png"]
After you select the correct profile, click ``Next'':
@screenshot["chef-tutorial/instantiate-next.png"]
@clab-screenshot["chef-tutorial/instantiate-next.png"]
}
@instructionstep["Set parameters"
#:screenshot "chef-tutorial/params-next.png"]{
#:screenshot "chef-tutorial/params-next.png"
#:screenshot-where "clab"]{
Profiles in CloudLab can have @emph{parameters} that affect how they are
Profiles in @(tb) can have @emph{parameters} that affect how they are
configured; for example, this profile has parameters that allow you to
set the number of client nodes, specify the repository with the infrastructure
code we plan to use, obtain copies of the application-specific infrastructure code developed
by the global community of Chef developers, etc.
code we plan to use, obtain copies of the application-specific infrastructure code developed
by the global community of Chef developers, etc.
For this tutorial, we will leave all parameters at their defaults and
just click ``Next''.
}
}
@instructionstep["Choose experiment name"]{
You may optionally give your experiment a meaningful name, e.g., ``chefdemo''.
This is useful if you have many experiments running at once.
@screenshot["chef-tutorial/experiment-name.png"]
@clab-screenshot["chef-tutorial/experiment-name.png"]
}
@instructionstep["Select a cluster"
#:screenshot "chef-tutorial/select-cluster.png"]{
#:screenshot "chef-tutorial/select-cluster.png"
#:screenshot-where "clab"]{
@(tb) has multiple clusters available to it. Some profiles can run
on any cluster, some can only run on specific ones due to specific hardware
constraints. @bold{ChefCluster} can only run on the x86-based clusters.
This excludes the CloudLab Utah cluster which is built on ARMv8 nodes.
This excludes the @(tb) Utah cluster which is built on ARMv8 nodes.
Refer to the @seclink["hardware"]{Hardware} section for more information.
@bold{Note:} If you are at an in-person tutorial, the instructor will
......@@ -158,16 +172,16 @@ information about how they work.
you selected.
}
@instructionstep["CloudLab instantiates your profile"]{
@instructionstep["@(tb) instantiates your profile"]{
@(tb) will take a few minutes to bring up your experiment, as
many things happen at this stage, including selecting suitable
hardware, loading disk images on local storage, booting bare-metal
machines, re-configuring the network topology, etc. While this is
happening, you will see the topology with yellow node icons:
@screenshot["chef-tutorial/booting.png"]
@margin-note{Provisioning is done using the
@clab-screenshot["chef-tutorial/booting.png"]
@margin-note{Provisioning is done using the
@link["http://groups.geni.net/geni/wiki/GeniApi"]{GENI APIs}; it
is possible for advanced users to bypass the @(tb) portal and
call these provisioning APIs from their own code. A good way to
......@@ -178,16 +192,16 @@ information about how they work.
able to log in until they have gone through the process of imaging and
booting.) While you are waiting for your resources to become available,
you may want to have a look at the
@link["http://docs.cloudlab.us"]{@(tb)
@link[apt-doc-url]{@(tb)
user manual}, or use the ``Sliver'' button to watch the logs of the
resources (``slivers'') being provisioned and booting.
}
@instructionstep["Your resources are ready!"]{
Shortly, the web interface will report the state as ``Booted''.
@screenshot["chef-tutorial/booted.png"]
@clab-screenshot["chef-tutorial/booted.png"]
@bold{Important:} A ``Booted'' status indicates that resources are
provisioned and booted; this particular profile runs scripts to
complete the Chef setup, and it will be a few more minutes before
......@@ -196,10 +210,10 @@ information about how they work.
you will likely see that the startup scripts (i.e. programs that run at the beginning
of the experiment to set it up) run longer on @tt{head} than on
@tt{node-0} --- a lot more work is required to install the Chef server than the client.
In the Topology View tab, mouse over the circle in the @tt{head}'s icon,
to confirm the current state of the node.
@screenshot["chef-tutorial/head-running.png"]
In the Topology View tab, mouse over the circle in the @tt{head}'s icon,
to confirm the current state of the node.
@clab-screenshot["chef-tutorial/head-running.png"]
}
]
......@@ -218,7 +232,7 @@ buttons in this area let you make a copy of the profile (so that you can
@seclink["creating-profiles"]{customize it}), ask to hold on to the resources
for longer, or release them immediately.
@screenshot["chef-tutorial/experiment-status.png"]
@clab-screenshot["chef-tutorial/experiment-status.png"]
Note that the default lifetime for experiments on @(tb) is less than a day;
after this time, the resources will be reclaimed and their disk contents will
......@@ -234,15 +248,15 @@ You can click on the title of the panel to expand or collapse it.
Profiles may contain written instructions for their use. Clicking on the title
of the ``Profile Instructions'' panel will expand or collapse it. In this
case, the instructions provide a link to the Chef server web console.
(Don't click on the link yet --- it is likely that Chef is still being configured;
case, the instructions provide a link to the Chef server web console.
(Don't click on the link yet --- it is likely that Chef is still being configured;
for now, let's keep exploring the @(tb) interface.)
Also, notice the list of private and public hostnames of the experiment nodes
included in the instructions. You will use the public hostnames (shown in bold)
in the exercise with the Apache web server and apache benchmark.
@screenshot["chef-tutorial/experiment-instructions.png"]
@clab-screenshot["chef-tutorial/experiment-instructions.png"]
@subsection{Topology View}
......@@ -254,9 +268,9 @@ the names assigned as part of the profile; this way, every time you instantiate
a profile, you can refer to the nodes using the same names, regardless of which
physical hardware was assigned to them. The green boxes around each node
indicate that they are up; click the ``Refresh Status'' button to initiate a
fresh check.
fresh check.
@margin-note{You can also run several networking tests
@margin-note{You can also run several networking tests
by clicking the ``Run Linktest'' button at the bottom of the page. The available tests include:
@itemlist[
@item{Level 1 --- Connectivity and Latency}
......@@ -267,13 +281,13 @@ by clicking the ``Run Linktest'' button at the bottom of the page. The available
Higher levels will take longer to complete and require patience.
}
@screenshot["chef-tutorial/topology-view.png"]
@clab-screenshot["chef-tutorial/topology-view.png"]
If an experiment has startup services, their statuses are indicated by small icons in
the upper right corners of the node icons. You can mouse over this icon to see a
description of the current status. In this profile, the startup services
on the client node(s), such as @tt{node-0}, typically complete quickly, but
the scripts on @tt{head} take much longer. The screenshot above shows the state of the
the scripts on @tt{head} take much longer. The screenshot above shows the state of the
experiment when all startup scripts complete.
It is important to note that every node in @(tb) has at least two
......@@ -298,7 +312,7 @@ authentication is supported, and you must have set up an @(ssh) keypair on your
account @bold{before} starting the experiment in order for authentication to
work.
@screenshot["chef-tutorial/list-view.png"]
@clab-screenshot["chef-tutorial/list-view.png"]
@subsection{Manifest View}
......@@ -307,14 +321,14 @@ The final default tab shows a
@seclink["rspecs"]{``request'' RSpec} that is used to define the profile,
annotated with details of the hardware that was chosen to instantiate your
request. This information is available on the nodes themselves using the
@link["http://groups.geni.net/geni/wiki/GeniGet"]{@tt{geni-get}} command,
@link["http://groups.geni.net/geni/wiki/GeniGet"]{@tt{geni-get}} command,
enabling you to do rich scripting that is fully aware of both the requested
topology and assigned resources.
@margin-note{Most of the information displayed on the @(tb) status page comes
directly from this manifest; it is parsed and laid out in-browser.}
@screenshot["chef-tutorial/manifest-view.png"]
@clab-screenshot["chef-tutorial/manifest-view.png"]
@subsection[#:tag "chef-tutorial-actions"]{Actions}
......@@ -325,32 +339,32 @@ access this menu; in the list view, it is accessed through the icon in the
and re-loading it with a fresh copy of its disk image (destroying all data on
the node). While nodes are in the process of rebooting or re-imaging, they
will turn yellow in the topology view. When they have completed, they will
become green again. The @seclink["chef-tutorial-web-shell"]{shell}
become green again. The @seclink["chef-tutorial-web-shell"]{shell}
action is described in more detail below and will be used as
the main method for issuing commands on the experiment nodes throughout this tutorial.
@screenshot["chef-tutorial/experiment-actions.png"]
@clab-screenshot["chef-tutorial/experiment-actions.png"]
@section{Brief Introduction to Chef}
While the startup scripts are running, let's take a quick look at the architecture of a typical
While the startup scripts are running, let's take a quick look at the architecture of a typical
Chef intallation. The diagram provided at the official @link["https://docs.chef.io/chef_overview.html"]{Overview of Chef} page
demonstrates the relationships between individual Chef components. While there is a number of optional, advanced
components that we don't use in this tutorial, it is worth noting the following:
@itemlist[
@item{Chef clients can run on a variety of resources: virtual and physical servers, cloud instances,
storage and networking devices, containers, etc. All clients connect and listen to
storage and networking devices, containers, etc. All clients connect and listen to
the central, infrastructure-wide Chef server.}
@item{The Chef server has a web interface. The server manages @bold{cookbooks}, which are fundamental
units of configuration management that define configurations and contain
everything that is required to instantiate those configurations. Additionally,
the server manages @bold{run lists}, which can be viewed as mappings between collections of cookbooks
@item{The Chef server has a web interface. The server manages @bold{cookbooks}, which are fundamental
units of configuration management that define configurations and contain
everything that is required to instantiate those configurations. Additionally,
the server manages @bold{run lists}, which can be viewed as mappings between collections of cookbooks
and the clients on which they need to execute.}
@item{A workstation represents a machine from which a Chef administrator
connects to and controls the server. It typically has a copy of @bold{chef-repo},
connects to and controls the server. It typically has a copy of @bold{chef-repo},
the repository which contains cookbooks and other code artifacts. The administrator
modifies cookbooks locally and submits them to the server to make them available
to all clients.}
......@@ -358,27 +372,27 @@ components that we don't use in this tutorial, it is worth noting the following:
@item{@bold{Recipes}, shown next to cookbooks on the workstation, are the "building blocks" from which
cookbooks are assembled. Recipes can be viewed as individual scripts accomplishing specific
fine-grained tasks, such as create a user, install a package, clone a repository, configure a network interface, etc.
Cookbooks, which include one or more recipes, are responsible for "bigger" tasks:
Cookbooks, which include one or more recipes, are responsible for "bigger" tasks:
install and configure a database, install and run a web server, and so on.}
@item{Another type of Chef code artifacts (not shown in the diagram) is called @bold{role}.
A role can include one or more cookbooks and specific recipes (each cookbook and recipe can be used
in several roles if necessary). Roles typically define complete node configurations;
for instance, in a simple case, one role corresponds to a master node on a cluster with a set of specific services,
for instance, in a simple case, one role corresponds to a master node on a cluster with a set of specific services,
while another role defines how the rest of the cluster nodes, so-called ``worker'' nodes, should be configured.
After being created on the workstation, these roles are submitted to the server by the administrator
After being created on the workstation, these roles are submitted to the server by the administrator
and then assigned to specific nodes via the run lists.}
]
In the experiment we have launched, @tt{head} runs all three: the server, the workstation, and the client
(there is no conflict between these components), while @tt{node-0} runs only the client. If this profile is instantiated
with the arbitrary number N of clients, there will be N ``client-only'' nodes
named @tt{node-0},@tt{node-1},...,@tt{node-(N-1)}.
Another profile parameter allows choosing the repository from which chef-repo is cloned;
named @tt{node-0},@tt{node-1},...,@tt{node-(N-1)}.
Another profile parameter allows choosing the repository from which chef-repo is cloned;
by default, it points to @link["https://github.com/emulab/chef-repo"]{emulab/chef-repo}.
The startup scrips in this profile also obtain and install copies of public cookbooks
hosted at the respository called @link["https://supermarket.chef.io"]{Supermarket}.
Specifically, the exercises in this tutorial rely on the @link["https://supermarket.chef.io/cookbooks/nfs"]{nfs}
hosted at the respository called @link["https://supermarket.chef.io"]{Supermarket}.
Specifically, the exercises in this tutorial rely on the @link["https://supermarket.chef.io/cookbooks/nfs"]{nfs}
and @link["https://supermarket.chef.io/cookbooks/apache2"]{apache2} cookbooks --- both
should be installed on your experiment now in accordance with the default value of the
corresponding profile parameter we have used.
......@@ -389,15 +403,15 @@ As soon as the startup scripts complete, you will likely recieve an email confir
@verbatim{Dear User,
Chef server and workstataion should now be
Chef server and workstataion should now be
installed on head.chefdemo.utahstud.emulab.net.
To explore the web management console, copy
this hostname and paste it into your browser.
Installation log can be found at /var/log/init-chef.log
To explore the web management console, copy
this hostname and paste it into your browser.
Installation log can be found at /var/log/init-chef.log
on the server node.
To authenticate, use the unique credentials
To authenticate, use the unique credentials
saved in /root/.chefauth on the server node.
Below are several Chef commands which detail the launched experiment:
......@@ -433,7 +447,7 @@ nfs
Happy automation with Chef!
}
In some cases, you will not be able to see this email ---
In some cases, you will not be able to see this email ---
email filters (e.g., if you are using a university email account) may classify it as spam.
This will not be a problem since the email is supposed to provide useful but noncritical information.
You can still access the Chef web console using the link included in the profile instructions
......@@ -478,7 +492,7 @@ While you are here, switch to the @italic{root} user by typing:
@verbatim{@bold{sudo su -}}
@screenshot["chef-tutorial/experiment-shell.png"]
@clab-screenshot["chef-tutorial/experiment-shell.png"]
Your prompt, the string which is printed on every line before the cursor,
should change to @tt{root@"@"head}.
......@@ -490,102 +504,102 @@ Type the following to print Chef credentials:
@verbatim{@bold{cat /root/.chefauth}}
You should see the unique login and password that have been
You should see the unique login and password that have been
generated by the startup scripts specifically for your instance of Chef:
@screenshot["chef-tutorial/shell-chefauth.png"]
@clab-screenshot["chef-tutorial/shell-chefauth.png"]
Expand the ``Profile Instructions'' panel and
click on the ``Chef web console'' link.
click on the ``Chef web console'' link.
@bold{Warning:} When your browser first points to this link, you will see a warning
@bold{Warning:} When your browser first points to this link, you will see a warning
about using a self-signed SSL certificate. Using self-signed certificates
is not a good option in production scenarios, but it is totally acceptable
in this short-term experimentation environment. We will ignore this warning and proceed to using the Chef console.
is not a good option in production scenarios, but it is totally acceptable
in this short-term experimentation environment. We will ignore this warning and proceed to using the Chef console.
The sequence of steps for ignoring it depends on your browser.
In Chrome, you will see a message saying "Your connection is not private". Click ``Advanced''
at the bottom of the page and choose ``Proceed to <hostname> (unsafe)''. In Firefox,
at the bottom of the page and choose ``Proceed to <hostname> (unsafe)''. In Firefox,
the process is slightly different: click ``Advanced'', choose ``Add Exception'', and
click ``Confirm Security Exception''.
When the login page is finally displayed, use the credentials you have printed in the shell:
@screenshot["chef-tutorial/chef-wui-login.png"]
@screenshot["chef-tutorial/chef-wui-nodelist.png"]
@clab-screenshot["chef-tutorial/chef-wui-login.png"]
@clab-screenshot["chef-tutorial/chef-wui-nodelist.png"]
If you see a console like the one above, with both @tt{head} and @tt{node-0} listed on the ``Nodes'' tab,
you have a working Chef cluster! You can now proceed to managing your nodes using
Chef recipes, cookbooks, and roles.
you have a working Chef cluster! You can now proceed to managing your nodes using
Chef recipes, cookbooks, and roles.
In the rest of the tutorial, we demonstrate how you can use several pre-defined cookbooks and roles.
Development of cookbooks and roles is a subject of another tutorial (many such tutorials can be
found online). Our goal in the following sections is to walk you through
the process of using existing cookbooks and roles --- the process which is the same for simple
and more complex configurations. You will learn how to modify run lists and
the process of using existing cookbooks and roles --- the process which is the same for simple
and more complex configurations. You will learn how to modify run lists and
apply cookbooks and roles to your nodes, run them, check their status,
and explore individual components of cookbooks and roles.
and explore individual components of cookbooks and roles.
@section{Configuring NFS}
Now that you have a working instance of Chef where both @tt{head} and @tt{node-0}
can be controlled using Chef, let's start modifying the software stacks
on these nodes by installing NFS and exporting a directory from @tt{head} to
@tt{node-0}.
Now that you have a working instance of Chef where both @tt{head} and @tt{node-0}
can be controlled using Chef, let's start modifying the software stacks
on these nodes by installing NFS and exporting a directory from @tt{head} to
@tt{node-0}.
@itemlist[#:style 'ordered
@instructionstep["Modify the run list on head"]{
Click on the row for @tt{head} in the node list (so the entire row is highlighted in orange),
and then click "Edit" in the Run List panel in the bottom right corner of the page:
@screenshot["chef-tutorial/head-edit-runlist.png"]
and then click "Edit" in the Run List panel in the bottom right corner of the page:
@clab-screenshot["chef-tutorial/head-edit-runlist.png"]
}
@instructionstep["Apply nfs role:"]{
In the popup window, find the role called @tt{nfs} in the Available Roles list on the left, drag and drop it into
the "Current Run List" field on the right. When this is done, click "Save Run List".
@screenshot["chef-tutorial/head-nfs-drag.png"]
the "Current Run List" field on the right. When this is done, click "Save Run List".
@clab-screenshot["chef-tutorial/head-nfs-drag.png"]
}
@instructionstep["Repeat the last two steps for node-0:"]{
@screenshot["chef-tutorial/node0-edit-runlist.png"]
@screenshot["chef-tutorial/node0-nfs-drag.png"]
@clab-screenshot["chef-tutorial/node0-edit-runlist.png"]
@clab-screenshot["chef-tutorial/node0-nfs-drag.png"]
At this point, @tt{nfs} role is assigned to both nodes, but nothing has executed yet.
}
@instructionstep["Check the status from the shell"]{
Before proceeding to applying these updates,
Before proceeding to applying these updates,
let's check the role assignment from the shell by typing:
@verbatim{@bold{knife status -r}}
The run lists for your nodes should be printed inside square brackets:
@screenshot["chef-tutorial/shell-knife-status.png"]
@clab-screenshot["chef-tutorial/shell-knife-status.png"]
The output of this command also conveniently shows when Chef applied changes to your
nodes last (first column) and what operating systems run on the nodes (last column).
nodes last (first column) and what operating systems run on the nodes (last column).
}
@instructionstep["Trigger the updates"]{
Run the assigned role on @tt{head} by typing:
Run the assigned role on @tt{head} by typing:
@verbatim{@bold{chef-client}}
@screenshot["chef-tutorial/head-chef-client.png"]
@clab-screenshot["chef-tutorial/head-chef-client.png"]
As a part of the startup procedure,
passwordless @tt{ssh} connections are enabled between the nodes.
passwordless @tt{ssh} connections are enabled between the nodes.
Therefore, you can use @tt{ssh} to run commands remotely,
on the nodes other than @tt{head}, from the same shell.
Execute the same command on @tt{node-0} by typing:
Execute the same command on @tt{node-0} by typing:
@verbatim{@bold{ssh node-0 chef-client}}
@screenshot["chef-tutorial/node0-chef-client.png"]
When nodes execute the ``@code{chef-client}'' command,
@clab-screenshot["chef-tutorial/node0-chef-client.png"]
When nodes execute the ``@code{chef-client}'' command,
they contact the server and request the cookbooks, recipes, and roles have been
assigned to them in their run lists. The server responds with those artifacts,
and the nodes execute them in the specified order.
assigned to them in their run lists. The server responds with those artifacts,
and the nodes execute them in the specified order.
}
@instructionstep["Verify that NFS is working"]{
......@@ -594,12 +608,12 @@ on these nodes by installing NFS and exporting a directory from @tt{head} to
@margin-note{The name of the NFS directory is one of the attributes that is set in the @tt{nfs} role.
To explore other attributes and see how this role is implemented, take a look at
the @code{/chef-repo/roles/nfs.rb} file on @tt{head}}
the @code{/chef-repo/roles/nfs.rb} file on @tt{head}}
The simplest way to test that this configuration is functioning properly
The simplest way to test that this configuration is functioning properly
is to create a file on one node and check that this file becomes
available on the other node.
Follow these commands to test it (the lines that start with the # sign are comments):
available on the other node.
Follow these commands to test it (the lines that start with the # sign are comments):
@verbatim{
# List files in the NFS directory /exp-share on head; should be empty
......@@ -615,27 +629,27 @@ on these nodes by installing NFS and exporting a directory from @tt{head} to
@bold{ssh node-0 ls /exp-share/}
}
@screenshot["chef-tutorial/nfs-is-working.png"]
@clab-screenshot["chef-tutorial/nfs-is-working.png"]
If you can see the created file on @tt{node-0}, your NFS is working as expected.
Now you can easily move files between your nodes using the @code{/exp-share} directory.
If you can see the created file on @tt{node-0}, your NFS is working as expected.
Now you can easily move files between your nodes using the @code{/exp-share} directory.