Cisco Cisco Intelligent Automation for Cloud 4.3.2 Installation Guide
16
Configuring Puppet Labs for Cisco IAC Integration
Method for Sharing Facts Between Nodes and Stacks
Puppet is configured via an SSH/PSExec connection to the new node. A well-known root/Administrator (or equivalent)
user and password is required for cases where no password is specified in the order. All nodes requiring configuration
management should have the same root/Administrator user/password. This can be changed during or
post-configuration. Sudo is used for non-root users. The certificate authority for Puppet requires that clocks for master
and agent servers be synchronized with a common time source (for example, using the ntpd service).
user and password is required for cases where no password is specified in the order. All nodes requiring configuration
management should have the same root/Administrator user/password. This can be changed during or
post-configuration. Sudo is used for non-root users. The certificate authority for Puppet requires that clocks for master
and agent servers be synchronized with a common time source (for example, using the ntpd service).
Note:
For vCenter, Cisco IAC automatically configures new Puppet nodes to have VMware Tools synchronize the clock
with the ESXi host; therefore, the best way to achieve clock synchronization is to ensure that the ESXi hosts and the
Puppet Master use the same time authority to set the time.
Puppet Master use the same time authority to set the time.
If the Puppet master requires a private key file to connect, you will need to specify this with the Connect Cloud
Infrastructure or Update Cloud Infrastructure service. Check the Additional Options check box to specify this.
Infrastructure or Update Cloud Infrastructure service. Check the Additional Options check box to specify this.
If you need to use an alternative repository for the Puppet Enterprise Installer, you can override the default Puppet Labs
location with the Connect Cloud Infrastructure or Update Cloud Infrastructure service. Choose the Additional Options
check box to specify a different base URL. The installer files must match the Puppet Labs naming conventions exactly.
location with the Connect Cloud Infrastructure or Update Cloud Infrastructure service. Choose the Additional Options
check box to specify a different base URL. The installer files must match the Puppet Labs naming conventions exactly.
You can override the location for the hiera node classification files with the Connect Cloud Infrastructure or Update Cloud
Infrastructure service. Choose the Additional Options check box to specify an override. You use
Infrastructure service. Choose the Additional Options check box to specify an override. You use
$environment
as a
placeholder in the path. Be sure your hiera.yaml file is modified accordingly.
Method for Sharing Facts Between Nodes and Stacks
When using Puppet with the Application Stack Automation Pack (ASAP), it is often necessary for one node in a stack to
be able to reference the facts of another (for example, the IP Address). This is achieved by recording the stack instance
name and the role in a stack as external facts for each node that can be used as lookup criteria. To query facts about the
other nodes in a stack you need to first have installed the prerequisite puppetdbquery module from
be able to reference the facts of another (for example, the IP Address). This is achieved by recording the stack instance
name and the role in a stack as external facts for each node that can be used as lookup criteria. To query facts about the
other nodes in a stack you need to first have installed the prerequisite puppetdbquery module from
https://forge.puppetlabs.com/dalen/puppetdbquery
.
Facts that Cisco IAC automatically assigns to nodes include:
stack_instance
: Name of the Stack Instance (shared by all servers in the same stack)
stack_role
: Role Name or List of Role Names (comma-separated) for the server
iac_organization:
Name of the IAC organization (including tenant prefix) for customer who ordered the stack
In your puppet code, use the following as an example of retrieving facts about another node in the stack.
$db_host_ip = query_nodes(“stack_instance=‘$stack_instance’ and stack_role~’(,|^)mysql (,|$)’)”
The query above returns the IP address for the node that has the role mysql in the same stack as the current node running
this code.
this code.
Working With Class Parameter Overrides
The IAC integration with Puppet allows class parameter value overrides to be configured and exposed to users ordering
servers. This is done through special JSON files that reside in the same location as your profile module’s puppet code
(under manifests). Class override parameters are always defined in the profile module, and, if present, have the same
name as profile or profile subclass followed by “.params.json”.
servers. This is done through special JSON files that reside in the same location as your profile module’s puppet code
(under manifests). Class override parameters are always defined in the profile module, and, if present, have the same
name as profile or profile subclass followed by “.params.json”.
Below is a sample of “webserver.params.json” corresponding to the profile class called “webserver”. For each
parameter, you provide a friendly name, description, default value, and most importantly, what class parameter you are
overriding. You can alternatively define an externally defined fact for a node by specifying ‘fact’, ‘factor’ or an empty value
for the class_param attribute of the parameter.
parameter, you provide a friendly name, description, default value, and most importantly, what class parameter you are
overriding. You can alternatively define an externally defined fact for a node by specifying ‘fact’, ‘factor’ or an empty value
for the class_param attribute of the parameter.