Ch 29: Introduction to Automation Tools Flashcards
T/F: Configuring network components by using the CLI is considered the fastest approach when dealing with a large number of devices.
False.
Configuring a large number of devices by using the CLI is not only time- consuming but also leads to an increase in human error, ultimately putting the business at risk.
Which of these tools are agentless in operation? (Choose three.)
- Ansible
- Puppet Bolt
- SaltStack
- Chef
- Salt SSH
A, B, and E.
Ansible, Puppet Bolt, and Salt SSH all are agentless tools.
Which of the following are features of Ansible? (Choose two.)
a. Manifests
b. Modules
c. Playbooks
d. Tasks
e. Recipes
C and D.
Ansible uses playbooks, plays, and tasks.
What configuration management software is built on Python? (Choose two.)
a. Ansible
b. Chef
c. Puppet
d. SaltStack
A and D.
Ansible and SaltStack are built on Python and can leverage Python to programmatically interact with the tool.
Which of the following is a YAML example?
a.
{
“user”: “root”, “user”: “Jason”, “user”: “Jamie”, “user”: “Luke”
}
b.
HR Employee record
Employee1:
Name: John Dough
Title: Developer
Nickname: Mr. DBug
c.
root
Jason
Jamie
Luke
d.
[users[root|Jason|Jamie|Luke]]
B. This is a YAML structure.
A YAML file can also begin with three dashes (—).
What is the language associated with Chef?
a. Python
b. C++
c. Ruby
d. Q-Basic
e. Tcl
C.
Chef uses Ruby DSL for its cookbooks.
What are some of the benefits of Puppet Forge and GitHub? (Choose all that apply.)
- Keeping track of various versions of code
- Knowing which developers are involved with code revisions
- Collaborating with other developers and sharing code
- Increasing the speed in working on software projects
- Accessing a real-time telemetry software database
- Automatically blocking malicious code
A, B, C, and D.
Puppet Forge and GitHub can help with many different aspects of software delivery, including code revisions, associated developers, sharing of code, and becoming more agile in the development process.
What are the PPDIOO lifecycle components?
- Prepare, Plan, Design, Implement, Observe, Optimize
- Prepare, Plan, Design, Implement, Operate, Optimize
- Prepare, Plan, Design, Implement, Operate, Optimize
- Plan, Prepare, Design, Implement, Observe, Optimize
- Prepare, Plan, Design, Integrate, Observe, Optimize
B.
PPDIOO consists of six components: Prepare, Plan, Design, Implement, Operate, and Optimize. Figure 29-9 provides more information.
T/F: Ansible uses the TAML syntax, which starts with three dashes (—), in the creation of playbook files.
B. Ansible uses Yet Another Markup Language (YAML) for the creation of playbook files. TAML doesn’t exist.
What is the proper command to execute a playbook using Ansible?
- ansible-playbook ConfigureInterface.yaml
- ansible ConfigureInterface.yaml
- play ansible-book ConfigureInterface.yaml
- play ansible-book ConfigureInterface.taml
A.
ansible-playbook FileName.yaml is the correct command to execute a playbook.
Playbooks are built from Yet Another Markup Language (YAML) files.
Which of these tools are agent-based in operation? (Choose two.)
- Ansible
- Puppet Bolt
- SaltStack
- Chef
- Salt SSH
B and C.
Chef and SaltStack are agent-based tools.
EEM applets are composed of multiple building blocks. Two of the primary building blocks that make up EEM applets are _______ and _______.
EEM applets are composed of multiple building blocks. This chapter focuses on two of the primary building blocks that make up EEM applets: events and actions.
EEM applets use a similar logic to the if-then statements used in some of the common program- ming languages (for instance, if an event happens, then an action is taken). The following example illustrates a very common EEM applet that is monitoring syslog messages on a router.
What is TcL?
The Cisco IOS Tcl shell was designed to allow customers to run Tcl commands directly from the Cisco IOS CLI prompt. Cisco IOS software does contain some subsystems such as Embedded Syslog Manager (ESM) and Interactive Voice Response (IVR) that use Tcl interpreters as part of their implementation. These subsystems have their own proprietary commands and keyword options that are not available in the Tcl shell.
Several methods have been developed for creating and running Tcl scripts within Cisco IOS software. A Tcl shell can be enabled, and Tcl commands can be entered line by line. After Tcl commands are entered, they are sent to a Tcl interpreter. If the commands are recognized as valid Tcl commands, the commands are executed and the results are sent to the tty. If a command is not a recognized Tcl command, it is sent to the Cisco IOS CLI parser. If the command is not a Tcl or Cisco IOS command, two error messages are displayed. A predefined Tcl script can be created outside of Cisco IOS software, transferred to flash or disk memory, and run within Cisco IOS software. It is also possible to create a Tcl script and precompile the code before running it under Cisco IOS software.
What does the attached EEM script do?
Example 29-1 shows an applet that is looking for a specific syslog message, stating that the Loopback0 interface went down. The specific syslog message is matched using regular expressions. This is a very powerful and granular way of matching patterns. If this specific syslog pattern is matched (an event) at least once, then the following actions will be taken:
- The Loopback0 interface will be shut down and brought back up (because of shutdown and no shutdown).
- The router will generate a syslog message that says, “I’ve fallen, and I can’t get up!”
- An email message that includes the output of the show interface loopback0 command will be sent to the network administrator.
NOTES:
Remember to include the enable and configure terminal commands at the begin- ning of actions within an applet. This is necessary as the applet assumes the user is in exec mode, not privileged exec or config mode. In addition, if AAA command authorization is being used, it is important to include the event manager session cli username username command. Otherwise, the CLI commands in the applet will fail.
It is also good practice to use decimal labels similar to 1.0, 2.0, and so forth when building applets. This makes it possible to insert new actions between other actions in the future. For example, you could insert a 1.5 action between the 1.0 and 2.0 actions. Remember that labels are parsed as strings, which means 10.0 would come after 1.0, not 9.0.
What is the command used to debug EEM?
Based on the output from the debug event manager action cli command, you can see the actions taking place when the applet is running.
Example 29-2 shows the applet being engaged when a user issues the shutdown command on the Loopback0 interface. It also shows that an error occurred when trying to connect to the SMTP server to send the email to the administrator. This is because the SMTP server being used for this test is not configured.
Notice that because the $_cli_result keyword was used in the configuration, the output will include the output of any CLI commands that were issued in the applet. In this case, the output of the show interface loopback0 command will be included in the debugging and in the email message.
What does the attached EEM script do?
Another very useful aspect of EEM applets is that CLI patterns can be matched as an event. This means that when certain commands are entered into the router using the CLI, they can trigger an EEM event within an applet. Then the configured actions can take place as a result of the CLI pattern being matched.
Example 29-3 uses another common EEM applet to match the CLI pattern “write mem.”. When the applet is triggered, the following actions are invoked:
- The router generates a syslog message that says “Configuration File Changed! TFTP backup successful.”
- The startup-config file is copied to a TFTP server.
NOTES:
- The file prompt quiet command disables the IOS confirmation mechanism that asks to confirm a user’s actions.
- The priority and facility of the syslog messages can be changed to fit any environ- ment’s alerting structure. For example, informational is used in Example 29-3
What does the attached EEM applet do?
Using an EEM applet to call Tcl scripts is another very powerful aspect of EEM. This chapter has covered multiple ways to use EEM applets. You have already seen multiple ways of executing actions, based on the automatic detection of specific events while they are happening. In this section, the focus is on how to call a Tcl script from an EEM applet.
Example 29-4 shows how to manually execute an EEM applet that, in turn, executes a Tcl script that is locally stored in the device’s flash memory. It is important to understand that there are many different ways to use EEM and that manually triggered applets are also very useful tools.
Example 29-4 shows an EEM script configured with the event none command, which means there is no automatic event that the applet is monitoring, and this applet runs only when it is triggered manually. To manually run an EEM applet, the event manager run applet-name command must be used, as illustrated in the second part of the output.
What does the attached EEM applet do?
Example 29-5 displays a snippet for the exact content of the ping.tcl script used in the manually triggered EEM applet in Example 29-4.
To see the contents of a Tcl script that resides in flash memory, issue the more command followed by the file location and filename. The more command can be used to view all other text-based files stored in the local flash memory as well.
T/F: Puppet allows for the management and configuration of multiple device types at the same time.
True.
To help you better understand how Puppet functions, Figure 29-2 illustrates the basic communications path between the puppet master and the puppet agents as well as the high-level architecture. The solid lines show the primary communications path, and the dotted lines indicate high availability (which is optional). With high availability, in the event that the master is unreachable, communications can go over the backup path to the master replica, which is a backup master server.
Puppet allows for the management and configuration of multiple device types at the same time. From a basic operation perspective, puppet agents communicate to the puppet master by using different TCP connections. Each TCP port uniquely represents a communications path from an agent running on a device or node. Puppet also has the capability to periodically verify the configuration on devices. This can be set to any frequency that the network operations team deems necessary. Then, if a configuration is changed, it can be alerted on as well as automatically put back to the previous configuration. This helps an organization standardize its device configurations while simultaneously enforcing a specific set of parameters that may be critical to the devices.
What is Chef?
Chef is an open source configuration management tool that is designed to automate con- figurations and operations of a network and server environment. Chef is written in Ruby and Erlang, but when it comes to actually writing code within Chef, Ruby is the language used.
Configuration management tools function in two different types of models: push and pull. Push models push configuration from a centralized tool or management server, while pull models check in with the server to see if there is any change in the configuration, and if there is, the remote devices pull the updated configuration files down to the end device.
Chef is similar to Puppet in several ways:
- Both have free open source versions available.
- Both have paid enterprise versions available.
- Both manage code that needs to be updated and stored.
- Both manage devices or nodes to be configured.
- Both leverage a pull model.
- Both function as a client/server model.
However, Chef’s structure, terminology, and core components are different from those of Puppet. Figure 29-4 illustrates the high-level architecture of Chef and the basic communica- tions path between the various areas within the Chef environment. Although this chapter doesn’t cover every component shown in this architecture, it is important to understand some of the elements that are available.
You can see from Figure 29-4 that Chef leverages a similar client/server functionality to Puppet. Although the core concepts of Puppet and Chef are similar, the terminology differs. Whereas Puppet has modules and manifests, Chef has cookbooks and recipes. Table 29-4 compares the components of Chef and Puppet and provides a brief description of each component.
What are the 4 types of Chef deployments?
Code is created on the Chef workstation. This code is stored in a file called a recipe. As mentioned previously, recipes in Chef are analogous to manifests in Puppet. Once a recipe is created on the workstation, it must be uploaded to the Chef server in order to be used in the environment. knife is the name of the command-line tool used to upload cookbooks to the Chef server. The command to execute an upload is knife upload cookbookname. The Chef server can be hosted locally on the workstation, hosted remotely on a server, or hosted in the cloud. In addition, all the components can be within the same enterprise network.
There are four types of Chef server deployments:
- Chef Solo: The Chef server is hosted locally on the workstation.
- Chef Client and Server: This is a typical Chef deployment with distributed compo- nents.
- Hosted Chef: The Chef server is hosted in the cloud.
- Private Chef: All Chef components are within the same enterprise network.
Like the puppet master, the Chef server sits in between the workstation and the nodes. All cookbooks are stored on the Chef server, and in addition to the cookbooks, the server holds all the tools necessary to transfer the node configurations to the Chef clients. OHAI, a ser- vice that is installed on the nodes, is used to collect the current state of a node to send the information back to the Chef server through the Chef client service. The Chef server then checks to see if there is any new configuration that needs to be on the node by comparing the information from the OHAI service to the cookbook or recipe. The Chef client service that runs on the nodes is responsible for all communications to the Chef server. When a node needs a recipe, the Chef client service handles the communication back to the Chef server to signify the node’s need for the updated configuration or recipe. Because the nodes can be unique or identical, the recipes can be the same or different for each node.
What is a control station in Ansible?
Ansible sends all requests from a control station, which could be a laptop or a server sitting in a data center. The control station is the computer used to run Ansible and issue changes and send requests to the remote hosts. Figure 29-8 illustrates the Ansible workflow.
What is a playbook in Ansible?
Administrators, developers, and IT managers like to use Ansible because it allows for easy ramp-up for users who aim to create new projects, and it sets the stage for long-term automa- tion initiatives and processes to further benefit the business. Automation, by nature, reduces the risk of human error by automatically duplicating known best practices that have been thoroughly tested in an environment. However, automation can be dangerous if it duplicates a bad process or an erroneous configuration. (This applies to any tool, not just Ansible.) When preparing to automate a task or set of tasks, it is important to start with the desired outcome of the automation, and then it’s possible to move on to creating a plan to achieve the outcome. A methodology commonly used or this process is the PPDIOO (Prepare, Plan, Design, Implement, Observe, Optimize) lifecycle, shown in Figure 29-9.
Ansible uses playbooks to deploy configuration changes or retrieve information from hosts within a network. An Ansible playbook is a structured sets of instructions—much like
the playbooks football players use to make different plays on the field during a game. An Ansible playbook contains multiple plays, and each play contains the tasks that each player must accomplish in order for the particular play to be successful. Table 29-5 describes the components used in Ansible and provides some commonly used examples of them.
What language are Ansible playbooks written in?
Ansible playbooks are written using YAML (Yet Another Markup Language). Ansible YAML files usually begin with a series of three dashes (—) and end with a series of three periods (…). Although this structure is optional, it is common. YAML files also contain lists and dictionaries. Example 29-9 shows a YAML file that contains a list of musical genres.
YAML lists are very easy to read and consume. As you can see in Example 29-9, it is pos- sible to add comments in YAML by beginning lines with a pound sign (#). As mentioned earlier, a YAML file often begins with — and ends with …; in addition, as you can see in Example 29-9, each line of a list can start with a dash and a space (- ), and indentation makes the YAML file readable.
T/F: YAML uses dictionaries that are similar to JSON dictionaries as they also use key/value pairs.
True.
YAML uses dictionaries that are similar to JSON dictionaries as they also use key/value pairs. Remember from Chapter 28, “Foundational Network Programmability Concepts,” that a JSON key/value pair appears as “key”: “value”; a YAML key/value pair is similar but does not need the quotation marks—key: value. Example 29-10 shows a YAML dictionary containing an employee record.
What is YAML Lint?
YAML Lint is a free online tool you can use to check the format of YAML files to make sure they have valid syntax. Simply go to www.yamllint.com and paste the contents of a YAML file into the interpreter and click Go. Lint alerts you if there is an error in the file. Figure 29-10 shows the YAML dictionary and list file from Example 29-11 in Lint, with the format- ting cleaned up and the comment removed.
What is an Ansible inventory file?
Ansible uses an inventory file to keep track of the hosts it manages. The inventory can be a named group of hosts or a simple list of individual hosts. A host can belong to mul- tiple groups and can be represented by either an IP address or a resolvable DNS name. Example 29-12 shows the contents of a host inventory file with the host 192.168.10.1 in two different groups.
What is an Ansible playbook?
Now let’s look at some examples of Ansible playbooks used to accomplish common tasks. Imagine using a playbook to deploy interface configuration on a device without having to manually configure it. You might take this idea a step further and use a playbook to configure an interface and deploy an EIGRP routing process.
Example 29-13 shows the contents of an Ansible playbook called ConfigureInterface.yaml, which you can use to configure the GigabitEthernet2 interface on a CSR 1000V router. By leveraging the ios_config Ansible module, this playbook adds the following configuration to the GigabitEthernet2 interface on the CSR1KV-1 router:
How do you execute an Ansible playbook?
To execute this playbook, the ansible-playbook command is used to call the specific playbook YAML file (ConfigureInterace.yaml).
Figure 29-11 shows the output from calling the playbook from the Linux shell. The important things to note in the output are the PLAY, TASK, and PLAY RECAP sections, which list the name of the play and each individual task that gets executed in each play. The PLAY RECAP section shows the status of the playbook that is executed.
The output in Figure 29-11 shows that one play, named CSR1KV-1, was launched, followed by a task called Configure GigabitEthernet2 Interface. Based on the status ok=1, you know the change was successful; the changed=1 status means that a single change was made on the CSR1KV-1 router.
