• All Courses

      Categories

      • Cisco Certifications
      • Juniper Certifications

      Recommended Courses

      Juniper JNCIA-DevOps – JN0-222 – Network Automation
      Cisco CCDA – 200-310 – Network Design Complete Course
      Cisco CCNA – 200-301 Complete Course
      Juniper JNCIA-Junos – NEW JN0-104 Complete Course
  • More
    • Become a Teacher
    • About Us
    • FAQs
  • Blog
  • Contact
  • Have any question?
  • (+1) 410 635 0231
  • help@ciscolessons.com
RegisterLogin

Login with your site account

Lost your password?

Not a member yet? Register now

Register a new account

Are you a member? Login now

CiscoLessons
  • All Courses

      Categories

      • Cisco Certifications
      • Juniper Certifications

      Recommended Courses

      Cisco CCNA – 200-301 Complete Course
      Juniper JNCIA-Junos – NEW JN0-104 Complete Course
      Juniper JNCIA-DevOps – JN0-222 – Network Automation
      Cisco CCDA – 200-310 – Network Design Complete Course
  • More
    • Become a Teacher
    • About Us
    • FAQs
  • Blog
  • Contact

    Ansible

    • Home
    • Blog
    • Ansible
    • Ansible Architecture and Capabilities

    Ansible Architecture and Capabilities

    • Posted by Ben Jacobson
    • Categories Ansible, JNCIA-DevOps, Lessons
    • Date May 14, 2022
    • Comments 0 comment

    In this lesson we’ll be taking a look at ansible’s architecture and capabilities, and doing a brief overview of its operation. Both in a standard deployment, as well as how it operates when interfacing with Juniper devices. The first thing I would like to do is to get a sense of where ansible falls within our automation stack, so let’s bring up the diagram of the Junos automation stack:

    Junos Automation Stack

    To point this out, Ansible resides up at the top, along with Salt, Puppet and Chef. Ansible is written in Python, and utilizes the PyEZ library for interfacing with Juniper devices.

    Now, PyEZ interfaces with our devices over netconf, which is interfacing with the XML API.

    The XML API is hosted by the mgd process, which is running on our juniper hardware. So Ansible is something that is written in Python, and it tries to abstract away a lot of the coding involved with automating our devices. This can make it more approachable, and can be quicker development and easier to get started. Our ansible Plays, which are what’s used to describe the tasks that are done in an automated fashion, are written in YAML. You are not actually interfacing by coding in any Python. You don’t need to know Python at all in order to use Ansible, however it is very handy if you do and we will be covering some python basics later in this course.

    Ansible badge icon

    So let’s take a look at some of Ansible’s features, and why we might want to use Ansible.

    Ansible accelerates the deployment and modification of infrastructure. It was originally created to manage compute devices or servers, but it has now been extended to support networking devices as well. It is used to automate our configuration management, and it provides idempotent operation.

    Now, what does idempotent mean? It means that changes are only made once, and it’s only made if they need to be made. So this is where our declarative structure comes into play. We, as the network engineers and network automation engineers, are declaring to Ansible what we want the final configuration state to be, and Ansible is figuring out the finer details of how to make that happen. When it’s figuring this out, it will not commit a configuration, unless it needs to be made.

    If we are creating a playbook that outlines a task to “add our lo0 interface to our OSPF configuration”, then that will only be done if the interface doesn’t exist in the OSPF configuration already. If it is already in our configuration, a commit will not occur, because no changes were needed.

    That’s something that’s a little unique and special about Ansible. It is not just running a set of instructions in an automated fashion, it is actually taking the state that we are providing, and determining what or if any changes need to be made to achieve that state.

    So let’s take a look at how ansible typically operates and then we’ll be looking at how ansible operates particularly when interfacing with Juniper devices.

    Standard Ansible operating model

    Ansible’s standard operation is that the modules are executed on our managed nodes. They are actually copied from our Ansible management node over to our managed nodes, being the servers or other compute devices that we are managing. Then the playbooks are also copied via SSH and they are executed by our management nodes.

    So, some requirements here are that:

    Python needs to be installed on our managed nodes in order for them to execute these Python modules.

    Now, this is great when you have the ability to copy your modules over to a device that can execute them locally, because that allows for a very scalable distributed system, right? You can copy over all of the playbooks and required modules and they can execute it and report back what happened. That allows for an extremely scalable operation, however in the case of our Juniper devices, that would put some requirements on our Juniper device that would be perhaps problematic.

    Having space to copy the modules over is not necessarily guaranteed with our network devices. Additionally, actually having Python available on our device to execute these modules is not necessarily the case. So, we changed this operation just a bit in the Junos Ansible operation.

    Junos Ansible operation

    When interfacing with Junos devices with Ansible, the modules are executed on the ansible management node. The playbook is read on the Ansible management node, the management server for Ansible, and those end up executing the modules. Those modules interface with our managed nodes via netconf over SSH, or could also potentially be serial or Telnet, and those execute RPCs or remote procedure calls on our managed devices.

    The files are not copied to our managed nodes, they are executed locally on our Ansible management server, which then interfaces with our managed nodes via netconf sessions.

    Let’s take a look at what the base environment is for Ansible.

    Ansible Base environment

    Ansible management server requires are that you be running Linux, MacOS or OSX, or BSD. Unfortunately there is not Ansible available for a Windows environment. You do need to have Python 2.6 or later installed, or Python 3.5 or later installed.

    Because Ansible is written in Python, it is itself a set of Python modules that it can be installed by pip. We can just do pip install ansible , and that will install Ansible for us on our server. The full information for the installation guide can be found at the official documentation for Ansible.

    The Juniper integration requirements are that you do need to have PyEZ installed, because a lot of the modules reference PyEZ for executing our netconf sessions and interacting with our devices. PyEZ must be installed separately using pip install junos-eznc .

    We also need to have jxmlease installed for interfacing with the XML API output, and this is installed using pip install jxmlease .

    The juniper.junos Ansible Galaxy role is not actually required for interfacing with our Juniper devices, as there are a fair number of modules built into Ansible which can interface with Juniper devices, though you will get a much richer experience and have much more information available to you if you use the juniper.junos Ansible Galaxy role.

    The juniper.junos Ansible Galaxy role that is written and supported by Juniper Networks. In order to install this role, you would execute the ansible-galaxy install juniper.junos .

    Finally, in order to interface with our device via netconf over ssh, it does need to be enabled on our device. That is done through the set system services netconf ssh configuration line.

    Let’s talk a little more here about the difference between the builtin and Ansible Galaxy Juniper modules.

    Builtin Ansible Juniper modules

    Our Ansible module library is what is officially supported by Ansible, and it is written by Ansible. It’s what comes with Ansible when you install it, and these are what are supported by Ansible Tower. Ansible Tower is the graphical interface for Ansible. It is a premium product that is generally sold to enterprises. Now, Ansible Galaxy is a community driven and community supported library of modules. Ansible Galaxy is the official community for sharing Ansible roles. There are other communities out there, but Ansible Galaxy is the official one that Ansible has created to allow the community to share custom-made roles. This is the home of Juniper’s own juniper.junos Ansible role.

    juniper.junos is written and supported by Juniper, not Ansible.

    juniper.junos role modules

    Tag:agentless, ansible, ansible galaxy, automation, devops, jncia, juniper, juniper.junos, netops, scripting, yaml

    • Share:
    author avatar
    Ben Jacobson

    Previous post

    YAML Ain't Markup Language
    May 14, 2022

    Next post

    Ansible Inventory
    June 4, 2022

    You may also like

    lab.png
    Using Ansible
    4 June, 2022
    example_playbook_run.png
    Ansible Playbooks
    4 June, 2022
    sample_usage.png
    Ansible Inventory
    4 June, 2022

    Leave A Reply Cancel reply

    Your email address will not be published. Required fields are marked *

    Popular Courses

    Cisco CCNA – 200-301 Complete Course

    Cisco CCNA – 200-301 Complete Course

    $39.99 $29.99
    Juniper JNCIA-DevOps – JN0-222 – Network Automation

    Juniper JNCIA-DevOps – JN0-222 – Network Automation

    $39.99 $19.99
    Juniper JNCIA-Junos – NEW JN0-104 Complete Course

    Juniper JNCIA-Junos – NEW JN0-104 Complete Course

    $39.99 $19.99

    Latest Posts

    What Businesses Can Expect as Carriers Invest Billions in Broadband Connectivity
    20Sep2022
    Using Ansible
    04Jun2022
    Ansible Playbooks
    04Jun2022
    • 410 635 0231
    • Owings Mills, MD USA
    • contact@ciscolessons.com

    Company

    • About Us
    • Blog
    • Contact
    • Become a Teacher

    Links

    • Courses
    • Events
    • FAQs

    Support

    • Documentation
    • Forums

    All rights reserved CiscoLessons®

    • Privacy
    • Terms
    • Sitemap
    • Purchase