Week 6 recap

Monday

Nautobot Demo

• Menu and front page are generally structured the same
• Top of page drives the menu
• Bottom of page shows version and links to other
• Models are the same as content type are the same as tables in SQL
• Each model generally has a:
  • List View
  • Edit View
  • Create View
  • Update View
• REST API documented in swagger
• Graphql documented in the GraqphiQL interface
• Related objects are generally linkable
• Extensibility can be thought of in
  • In UI via the Extensibility menu
    • Config Context
    • Custom Fields
    • Custom links
    • Computed Fields
  • Plugins via Python code

Nautobot Build

• Leverages NTC cookiecutter
• Containers are immutable (shouldn't change)
• Containers are ephemeral (should be killed and rebuild)
• Invoke tasks help you to orchestrate it all
  • It all is generally a Docker running commands within the container
• Start wit prerequisites
  • Docker, invoke, poetry, cookiecutter
  • Build image (invoke build)
  • Start container (invoke debug/invoke start)
  • Stop container (invoke stop/invoke destroy - removes data too)
• In Docker, an image is different than a container
  • Don't forget to re-build after your changes!!!

Tuesday

Nautobot Organization Models

• Organization is a top level grouping of Nautobot Objects that are applicable to numerous apps & models inside of Nautobot
• Site is a model that is meant to represent a physical location and is a required pre-requisite before creating a Device in Nautobot
• Sites can (but not required) have a Region that it is a child of
• Regions are meant to be a logical grouping of Sites based on some form of a higher level location
  • A Region could be the Continent, Country, State, City, or any other meaningful location based identifier
• Regions are nestable
  • Example: North America (Region) -> United States (Region) -> New York (Region) -> New York City (Region) -> NYC01 (Site)
    • In this example NYC01 is a Site but is also a member of 4 Regions
• Tenants are commonly used to assign ownership to a object inside of Nautobot
• Tenants currently are a single Tenant per object in Nautobot (if the object/model has a tenant attribute)
  • Example: a single device can only be associated to a single tenant
  • Example: one rack holds 10 devices and each device is assigned to a different tenant.
    • The rack may contain multiple tenants BUT the tenant attribute can only be set to 1 which may not make sense to set
• Tenant Groups are a grouping of Tenants
• Tenant Groups are not directly assigned to objects other than Tenants BUT will be present on object create forms IF the object has a tenant attribute
  • Example: The Tenant Group field on the Device create form is solely for filtering the possible Tenants that can be assigned in the next field
• Location are a logical location attribute used for objects.
• Locations use Location Type to describe what the location is meant for
• Locations are nestable similar to Regions
• Locations provide a namespacing capability via the content_types attribute
  • Locations can only be associated to an object that is specified in the content_types attribute
  • Example: Location 123 only has dcim | device as an available content type, if you attempt to associate a Rack to that location it will not appear in the UI form unless you add dcim | rack to the location content_types
• Racks are well.... Racks. Devices can be placed inside of a Rack at a specified position on the Device object
• Rack Groups are a logical grouping of racks

Nautobot Devices

• Devices can model several things within Nautobot
  • Network Devices
  • Patch Panels
  • PDUs
• Devices require a Site, DeviceType, DeviceRole, Manufacturer (via DeviceType), and Status object to be created before attempting to create a Device
• Devices can be made up of several child objects, including but not limited to the following
  • Interfaces
  • Front Ports
  • Back Ports
  • Power Ports
  • Inventory Items
  • Device Bays
• Platform is an optional attribute for a Device BUT is most commonly used for providing connection type in automation that uses Nautobot as an inventory source
  • Example: Device123 is associated to platform IOS and the network_driver is cisco_ios which can be used in Netmiko as the devive_type

Wednesday

Nautobot IPAM

• Major subsections:
  • IP Addresses
  • Prefixes
  • Aggregates
  • VRFs
  • VLANs
  • Services
• Note: a concrete relationship means that there is a foreign key in the actual data base
  • Without one, these are run time queries "that guess" the relationship
• There is no "concrete relationship" within Prefixes
• There is no "concrete relationship" between Prefixes and IPs
• Device -> Interface -> IP

Nautobot Circuits

• Circuit Types defines things like LTE, DIA, MPLS, etc.
• Circuits can be connected to an interface
• Circuits and interface be "traced"
• Providers are related to Circuits and provide an ASN
• Provider Networks help differentiate between things like ATT-MPLS and ATT-LTE

Nautobot GraphQL

• The GraphiQL interface provides you a playground to build your query
• Provide only the data you want
• Automatically understands relationships, which provides "type-ahead" capabilities
• Quotes & case sensitivity matter
• Can provide filtering within query

Nautobot ReST APIs

• Documented in Swagger/Open API
• Based on Django DRF
• Supports standard HTTP verbs, GET, PATCH, POST, PUT, DELETE
• Accessible via icon on bottom right
• Provides rich filtering (n - not equal, ic - case-insensitive, etc..)
• Token based authentication
• Supports json

pynautobot

• install with pip install pynautobot
• Provides native "object-like" interface to RestAPIs
• Works for plugins/apps as well

Data Model 201

• The process should be iterable
• How to create an inventory?
  • Brownfield - CSV, excel, discovery tools
  • Greenfield - Design builder, curate data
• Data model worksheet
  • Create a Config Map
    • Classify into snippets -> features
    • Identify (and highlight) the variables vs the static template
  • Document the Systems of Record in the columns
  • Document the features in the rows
  • Add & remove columns and rows as needed
  • Use comments to describe other data
  • Detailed tabs provide schema level definitions such as data types
    • Use sparingly to get a shared understanding
• "find" the data model
  • Use the worksheet, but infer and present to customer
  • Use configuration compliance to let them understand what you are building
• Describe your intent in layers, such as
  • Design - The design level captures the intent of the network design.
  • Role - The role level captures what is identical across devices/interfaces of the same role
  • Component - The component level is what is particular to a specific the device
• Don't map data 1-to-1 from config
• Don't expect customer to define

Thursday

Nautobot Extensibility

• Change log - When objects in Nautobot are created, edited or deleted, the changes are recorded in the change log
• Custom Fields - Custom Fields are attribute-level data with which you can augment the existing data model
• Computed Fields - Run time evaluations of data (e.g. not stored)
• Custom links - Allow users to display arbitrary hyperlinks to external content within Nautobot object views
• Relationships - Define DQ level linking between data
• Export Templates - There is native CSV export, but can also create your own based on Jinja
• Dynamic Groups - Dynamic Groups provide a way to organize objects of the same Content Type by matching filters

Nautobot Ansible

• Dynamic Inventory allows you to get all of your data into your Ansible infra
• Ansible modules are built like resource objects
• Installed via Ansible collections

Data Model 202

• Different interfaces
  • UI
  • API
  • GraphQL
  • Django ORM
• customizable via extensibility features (in the UI/API)
  • Computed Fields, Custom Fields, Webhooks / Jobhooks, Statuses, Custom Links, Export Templates, Relationships, Config Context, Tags, GraphQL Queries
• Start small and iterate
  • Easier to start with YAML and build up
• Customizable via plugins