Getting Started with the App¶
This document provides a step-by-step tutorial on how to get the App going and how to use it.
Install the App¶
To install the App, please follow the instructions detailed in the Installation Guide.
First steps with the App¶
Backup Configuration¶
Follow the steps below to get up and running for the configuration backup element of the app.
-
Enable the feature in the
PLUGIN_SETTINGS
. The configuration should have"enable_backup": True
set in thePLUGINS_CONFIG
dictionary fornautobot_golden_config
. -
Add any git repositories that will be used to house the backup configurations.
- In the UI
Extensibility -> Git Repositories
. Click Add. - Populate the Git Repository data for the backup. Git Settings
- Make sure to select the Provides called
backup configs
. - Click Create.
- In the UI
-
Next, make sure to create new or update existing Apps Settings with the backup details.
- Navigate to
Golden Config -> Settings
under the Golden Configuration Section. - Create new or select one of the existing
Settings
objects - Fill out the Backup Repository. (The dropdown will show the repository that was just created.)
- Fill out Backup Path Template. Typically
{{obj.location.name|slugify}}/{{obj.name}}.cfg
, see Setting Details - Select whether or not to do a connectivity check per device.
- Click Save.
- Navigate to
-
Create Configuration Removals and Replacements.
-
Execute the Backup.
- Navigate to
Golden Config -> Home
under the Golden Configuration Section. - Click on the
Execute
button and selectBackup
. - Select what to run the backup on.
- Run the Job by clicking "Run Job" button.
- Navigate to
For in-depth details see Navigating Backup
Intended Configuration¶
Follow the steps below to get up and running for the intended configuration element of the app.
Note
Intended Configuration requires the enable_intended
and enabled_sotAgg
app features to be used.
Note
If Secret Group is used for the Repositories the secrets type HTTP(S) is required for this app.
-
Enable the feature in the
PLUGIN_SETTINGS
. The configuration should have"enable_intended": True
set in thePLUGINS_CONFIG
dictionary fornautobot_golden_config
. -
Add any git repositories that will be used to house the intended configurations.
- In the UI
Extensibility -> Git Repositories
. Click Add. - Populate the Git Repository data for the intended. Git Settings
- Make sure to select the Provides called
intended configs
. - Click Create.
- In the UI
-
Add the git repository that will be used to house the Jinja2 templates.
- In the UI
Extensibility -> Git Repositories
. Click Add. - Populate the Git Repository data for the jinja2 templates. Git Settings
- Make sure to select the Provides called
jinja templates
. - Click Create.
- In the UI
-
Next, make sure to create new or update existing Apps Settings with the intended and jinja2 template details.
- Navigate to
Golden Config -> Settings
under the Golden Configuration Section. - Create new or select one of the existing
Settings
objects - Fill out the Intended Repository. (The dropdown will show the repository that was just created.)
- Fill out Intended Path Template. Typically
{{obj.location.name|slugify}}/{{obj.name}}.cfg
, see Setting Details - Fill out Jinja Repository. (The dropdown will show the repository that was just created.)
- Fill out Jinja Path Template. Typically
{{obj.platform.network_driver}}.j2
.
- Navigate to
-
Determine what data(variables) the Jinja2 templates need from Nautobot.
- See Source of Truth Agg Details
- In the UI
Extensibility -> GraphQL Queries
. Click Add. - Populate the GraphQL data.
- Make sure to follow the format specified in the GraphQL section in Source of Truth Agg Details
- Click Create.
- Navigate to
Golden Config -> Settings
under the Golden Configuration Section. - Select a SoTAgg Saved Query. (The dropdown will show the GraphQL query that was just created.)
-
Execute the Intended.
- Navigate to
Golden Config -> Home
. - Click on the
Execute
button and selectIntended
. - Select what to run the intended generation on.
- Run the Job.
- Navigate to
For in-depth details see Navigating Intended
Compliance¶
Compliance requires Backups and Intended Configurations in order to be executed.
- Enable the feature in the
PLUGIN_SETTINGS
. The configuration should have"enable_compliance": True
set in thePLUGINS_CONFIG
dictionary fornautobot_golden_config
. - Follow the steps in Backup Configuration.
- Follow the steps in Intended Configuration.
-
Create a Compliance Feature.
- Navigate to
Golden Config -> Compliance Feature
. - Click Add and give the feature a name. Typically this is based on the configuration snippet or section. E.g. "aaa".
- Navigate to
-
Create a Compliance Rule.
- Navigate to
Golden Config -> Compliance Rules
. - Click Add and populate the fields, make sure the rule is linked to the feature created previously. See Configuration Compliance Settings for details.
- Navigate to
-
Execute Compliance Check.
- Navigate to
Golden Config -> Configuration Compliance
. - Click on the
Execute
button and selectCompliance
. - Select what to run the compliance on.
- Run the Job.
- Navigate to
For in-depth details see Navigating Compliance
Config Remediation¶
Follow the steps below to get up and running for the configuration remediation element of the app.
- Navigate to
Golden Config -> Compliance Rules
. - Select the rules in which you'd like to enable remediation on.
- Edit the
Compliance Rule
and turn on theRemediation
toggle button. - Run the
Compliance
job again which will generate the initial remediation plan for the feature. - Navigate to
Golden Config -> Config Compliance
, select the device and notice a remediation section is not present for the compliance details for the feature.
For in-depth details see Navigating Config Plans
Config Plans¶
Follow the steps below to get up and running for the configuration plans element of the app.
- Enable the feature in the
PLUGIN_SETTINGS
. The configuration should have"enable_plan": True
set in thePLUGINS_CONFIG
dictionary fornautobot_golden_config
. - Follow the steps in Compliance.
- Compliance is necessary if ConfigPlans will be generated utilizing any of the attributes provided by a Compliance object.
- This step may be skipped if only
manual
ConfigPlans are going to be generated.
-
Create a ConfigPlan
- Navigate to
Golden Config -> Config Plans
- Click on
ADD
button. - Fill out the plan details and plan filters.
- The options dynamically change in the form based on the
plan type
selected. - If the
plan type
is Intended, Remediation, Missing.- Select the Compliance Features to use to generate the plan. If none are selected all features will be in scope.
- If the
plan type
is Manual.- Create a manual plan to accomplish the goal. Note: Access to
obj
is available to dynamically populate fields via Jinja2 syntax.
- Create a manual plan to accomplish the goal. Note: Access to
- The options dynamically change in the form based on the
- Click
Generate
- Navigate to
For in-depth details see Navigating Config Plans
Config Deploy¶
Follow the steps below to get up and running for the configuration deployment element of the app.
- Enable the feature in the
PLUGIN_SETTINGS
. The configuration should have"enable_deploy": True
set in thePLUGINS_CONFIG
dictionary fornautobot_golden_config
. - Follow the steps in Config Plans.
- Navigate to the specific ConfigPlan to deploy, or multi-select them from the ConfigPlan list view.
- If deploying from a specific ConfigPlan object. Click
Deploy
button and accept the warnings. - If deploying from the ConfigPlan list view. Click
Deploy Selected
button and accept the warnings.
- If deploying from a specific ConfigPlan object. Click
- Interpret the results from the popup modal and navigate to the job result as needed for more details.
Config Deployments utilize the dispatchers from nornir-nautobot just like the other functionality of Golden Config. See Troubleshooting Dispatchers for more details.
Load Properties from Git¶
Golden Config properties include: Compliance Features, Compliance Rules, Config Removals, and Config Replacements. They can be created via the UI, API, or alternatively you can load these properties from a Git repository, defined in YAML files following the this directory structure (you can skip any of them if not apply):
├── golden_config
│ ├── compliance_features
│ ├── compliance_rules
│ ├── config_removes
│ ├── config_replaces
The files within these folders can follow any naming pattern or nested folder structure, all of them will be recursively taken into account. So it's up to you to decide how to you prefer to organize these files (within the previously stated directory structure):
├── golden_config
│ ├── compliance_features
│ │ └── all.yml
│ ├── compliance_rules
│ │ ├── my_rule_for_cisco_ios
│ │ │ ├── some_rules.yml
│ │ │ └── some_other_rules.yml
│ │ └── juniper_junos.yml
│ ├── config_removes
│ │ ├── cisco_ios.yml
│ │ └── juniper_junos.yml
│ ├── config_replaces
│ │ ├── cisco_ios.yml
│ │ └── juniper_junos.yml
The YAML
files will contain all the attributes necessary to identify an object (for instance, a ComplianceRule
is identified by the feature_slug
and the platform_network_driver
together) and the other attributes (the ones that are not used to identify the object). For example:
compliance_features
example:
compliance_rules
example:
---
- feature_slug: "aaa"
platform_network_driver: "Cisco IOS"
config_ordered: true
match_config: |
aaa
line
username
role
tacacs
config_type: "cli"
config_removes
example:
---
- platform_network_driver: "Cisco IOS"
name: "Build config"
regex: '^Building\s+configuration.*\n'
config_replaces
example:
---
- name: "username"
platform_network_driver: "Cisco IOS"
description: "username"
regex: '(username\s+\S+\spassword\s+5\s+)\S+(\s+role\s+\S+)'
replace: '\1<redacted_config>\2'
CustomField data can be added using the _custom_field_data
attribute, that takes a dictionary mapping custom_field names to their values:
---
- name: "aaa"
slug: "aaa"
description: "aaa feature"
_custom_field_data:
custom_field_a: "abc"
custom_field_b: 123
Note
For Foreign Key references to ComplianceFeature
and Platform
we use the keywords feature_slug
and platform_network_driver
respectively.
-
Add the Git repository that will be used to sync Git properties.
- In the UI
Extensibility -> Git Repositories
. Click Add. - Populate the Git Repository data for the GC properties. Git Settings
- Make sure to select the Provides called
Golden Config properties
. - Click Create (This step runs an automatic sync).
- In the UI
-
Run
sync
and all the properties will be created/updated in a declarative way and following the right order to respect the dependencies between objects. The import task will raise awarning
if the dependencies are not available yet (for instance, a referencedPlatform
is not created), so thesync
process will continue, and you could then fix these warnings by reviewing the mismatch (maybe creating the required object) and run thesync
process again.
Constance Settings¶
Golden config uses the dispatch_params()
function in conjunction with the constance settings DEFAULT_FRAMEWORK, GET_CONFIG_FRAMEWORK, MERGE_CONFIG_FRAMEWORK, and REPLACE_CONFIG_FRAMEWORK. This allows you to define in this order of precedence:
- For a specific method, such as get_config, which framework do I want to use, netmiko or napalm for a specific network_driver such as
cisco_ios
? - For a specific method, such as get_config, which framework do I want to use, netmiko or napalm for all network_drivers?
- By default, which framework do I want to use, netmiko or napalm for a specific network_driver such as
cisco_ios
? - By default, which framework do I want to use, netmiko or napalm for all network_drivers?
Info
These settings are not considered when using a custom_dispatcher as described below.
Each of the constance settings allow for the usage of either a key named exactly as the network_driver
or the key of all
, anything else will not result in anything valid. The value, should only be napalm or netmiko at this point, but subject to change in the future.
Let's take a few examples to bring this to life a bit more.
Using the previous example, everything will use the napalm dispatcher, this is in fact the default settings
Using the previous example, everything will use the napalm dispatcher except fortinet, which would use netmiko.
# DEFAULT_FRAMEWORK
{
"all": "napalm",
"fortinet": "netmiko"
}
# GET_CONFIG_FRAMEWORK
{
"arista_eos": "netmiko",
"cisco_nxos": "netmiko"
}
Using the previous example, everything will use the napalm dispatcher except fortinet and when using the get_config
method for arista_eos
and cisco_nxos
, use netmiko.
As you can see, you now have the flexibility to control which network_driver will use which framework for every method, as each constance setting is sanely named to match the method name (e.g. GET_CONFIG_FRAMEWORK
maps the get_config
method). Additionally, if the current network_driver
and associated network_driver_mappings
is not sufficient as is, you can extend the NETWORK DRIVER settings as well.
Golden Config leverages the config framework from constance, please refer to that documentation for how to use. You can access your configurations from your name in the top right of the UI, followed by Admin -> Configuration -> Config
and locate your setting.
What are the next steps?¶
You can check out the Use Cases section for more examples.