Data Model Structure
Let's learn about the formatting standards, naming conventions, and dictionary hierarchy of the data model structure.
We'll cover the following
Like the investment and thought that went into the hosts
structure, a lot of up-front time and planning is required to build data
model structures. Some basic formatting standards, variable naming
conventions, and a variable dictionary hierarchy should be established
and followed rigidly.
group_vars
As part of the repository structure, there is a folder called
group_vars
. This is an Ansible-specific folder used to set up data
models for the groups configured in the hosts
file. Group
variables are applied to all common hardware platforms or logical
functions. If, for example, a common QoS policy is configured on all the
distribution switches, abstract the QoS policy data into a model in the
CAMPUS-DISTRIBUTION.yml group_vars
file.
[CAMPUS-DISTRIBUTION]
can be called a group_vars
by
creating a YAML file called CAMPUS-DISTRIBUTION.YML
inside the
group_vars
folder. This allows the data model to contain variables
that apply to all devices listed in hosts.ini
file subsections
creating a golden configuration by platform or logical function.
It is a recommended practice to prepend all variables created in
group_vars
with a common identifier such as platform_
,
group_
, or global_
. For example, platform_defaults
or
group_vlans
. Using this naming convention when writing dynamic
templates allows for the intent to become obvious to the operator. It
also points to a file in the group_vars
folder as the source of the
data and variable.
The data belonging to group_vars
or host_vars
should be
considered carefully. There are advantages and disadvantages to either
approach. Generally, group_vars
should contain as many platform or
logical function standards as possible and can be used to reflect a
solid network design adhering to best practices.
Sometimes using
group_vars
does not make sense. For example, in the case of a hostname or a management IP address which naturally fits as host_vars
. Include host information inside the group_vars
where it makes sense. For
example, as a standard, all distribution layer switches should have
port-channel 1 configured as the uplink port to the core. Port-channels are usually included as a host variable. But in this case, port-channel 1 will be listed under the CAMPUS-DISTRIBUTION.yml
group variable.
Some examples of group_vars
candidates:
-
Standard NTP, IP helper addresses for DHCP, SNMP, or syslog servers
-
Access-control lists at the distribution layer
-
QoS policies either by platform, logical function, or both
-
Banners
-
AAA configurations such as RADIUS or TACACS+ servers
-
Universal secret
-
Standard interfaces:
-
VSS configurations for core and distribution
-
Standardized uplinks
-
-
Domain name
-
Native VLAN
-
Multicast
-
Netflow
-
Platform type identifier
-
Other features with common code across a platform
host_vars
Similar to group_vars
, there is a folder in the repository called
host_vars
. In this folder, there is a YAML file per device.
DIST01.YML
is the host_vars
file for that specific network host.
Store information that is specific and unique to the device on the
network in the host_vars
YAML files. Depending on the size of the
fleet, it may take time to build complete coverage of the devices or
configurations. Over time it becomes a matter of cloning an existing
host_vars
YAML file and replacing the data unique to the device.
It is recommended to prepend host_vars
variables with hosts_
for ease of readability, and as a reference point for where the variable is
in the repository (in a host_vars
file).
Some examples of
host_vars
variables include:
-
Hostname
-
Management SVI IP address
-
VLANs
-
VRFs
-
Routing instances
-
Switch Virtual Interfaces (SVI)
-
Physical interfaces
-
Spanning-tree priorities
-
Unique secrets or passwords
-
DHCP servers
-
Switch stack configurations
-
Power stack configurations
Get hands-on with 1200+ tech skills courses.