Cloud Computing

How you can Use Ansible with CML

Spread the love


How can Ansible assist folks constructing simulations with Cisco Modeling Labs (CML)?

Much like Terraform, Ansible is a typical, open-source automation software usually utilized in Steady Integration/Steady Deployment (CI/CD) DevOps methodologies. They’re each a kind of Infrastructure as Code (IaC) or Infrastructure as Information that help you render your infrastructure as textual content information and management it utilizing instruments resembling Git. The benefit is reproducibility, consistency, pace, and the data that, once you change the code, folks approve, and it will get examined earlier than it’s pushed out to your manufacturing community. This paradigm permits enterprises to run their community infrastructure in the identical method they run their software program and cloud practices. Afterall, the infrastructure is there to help the apps, so why handle them in a different way? 

Though overlaps exist within the capabilities of Terraform and Ansible, they’re very complementary. Whereas Terraform is best on the preliminary deployment and making certain ongoing consistency of the underlying infrastructure, Ansible is best on the preliminary configuration and ongoing administration of the issues that stay in that infrastructure, resembling techniques, community gadgets, and so forth. 

In a typical workflow through which an operator needs to make a change to the community, let’s say including a brand new community to be marketed through BGP, a community engineer would specify that change within the code or extra doubtless as configuration knowledge in YAML or JSON. In a typical CI workflow, that change would have to be accredited by others for correctness or adherence to company and safety considerations, as an example. Along with the eyeball assessments, a sequence of automated testing validates the info after which deploys the proposed change in a take a look at community. These assessments may be run in a bodily take a look at community, a digital take a look at community, or a mixture of the 2. That circulation would possibly appear like the next: 

Workflow example

The benefit of leveraging digital take a look at networks is profound. The fee is dramatically decrease, and the power to automate testing is elevated considerably. For instance, a community engineer can spin up and configure a brand new, advanced topology a number of occasions with out the probability of outdated assessments messing up the accuracy of the present testing. Cisco Modeling Labs is a superb software for one of these take a look at. 

Right here’s the place the Ansible CML Assortment is available in. Much like the CML Terraform integration lined in a earlier weblog, the Ansible CML Assortment can automate the deployment of topologies in CML for testing. The Ansible CML Assortment has modules to create, begin, and cease a topology and the hosts inside it, however extra importantly, it has a dynamic stock plugin for getting details about the topology. That is essential for automation as a result of topologies can change. Or a number of topologies may exist, relying on the assessments being carried out. In case your topology makes use of dynamic host configuration protocol (DHCP) and/or CML’s PATty performance, the data for the way Ansible communicates with the nodes must be communicated to the playbook. 

Let’s go over a few of the options of the Ansible CML Assortment’s dynamic stock plugin. 

First, we have to set up the gathering: 

ansible-galaxy assortment set up cisco.cml 

Subsequent, we create a cml.yml within the stock with the next contents to inform Ansible to make use of the Ansible CML Assortment’s dynamic stock plugin: 

plugin: cisco.cml.cml_inventory 

group_tags: community, ios, nxos, router

As well as to specifying the plugin title, we are able to additionally outline tags that, when discovered on the gadgets within the topology, add that gadget to an Ansible group for use later within the playbook: 

As well as to specifying the plugin title, we are able to additionally outline tags that, when discovered on the gadgets within the topology, add that gadget to an Ansible group for use later within the playbook:

  • CML_USERNAME: Username for the CML consumer
  • CML_PASSWORD: Password for the CML consumer
  • CML_HOST: The CML host
  • CML_LAB: The title of the lab 

As soon as the plugin is aware of methods to talk with the CML server and which lab to make use of, it might probably return details about the nodes within the lab: 

okay: [hq-rtr1] => { 

    "cml_facts": { 

        "config": "hostname hq-rtr1nvrf definition Mgmt-intfn!naddress-family ipv4nexit-address-familyn!naddress-family ipv6nexit-address-familyn!nusername admin privilege 15 secret 0 adminncdp runnno aaa new-modelnip domain-name mdd.cisco.comn!ninterface GigabitEthernet1nvrf forwarding Mgmt-intfnip deal with dhcpnnegotiation autonno cdp enablenno shutdownn!ninterface GigabitEthernet2ncdp enablen!ninterface GigabitEthernet3ncdp enablen!ninterface GigabitEthernet4ncdp enablen!nip http servernip http secure-servernip http max-connections 2n!nip ssh time-out 60nip ssh model 2nip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctrnip ssh consumer algorithm encryption aes128-ctr aes192-ctr aes256-ctrn!nline vty 0 4nexec-timeout 30 0nabsolute-timeout 60nsession-limit 16nlogin localntransport enter sshn!nend", 

        "cpus": 1, 

        "data_volume": null, 

        "image_definition": null, 

        "interfaces": [ 

            { 

                "ipv4_addresses": null, 

                "ipv6_addresses": null, 

                "mac_address": null, 

                "name": "Loopback0", 

                "state": "STARTED" 

            }, 

            { 

                "ipv4_addresses": [ 

                    "192.168.255.199" 

                ], 

                "ipv6_addresses": [], 

                "mac_address": "52:54:00:13:51:66", 

                "title": "GigabitEthernet1", 

                "state": "STARTED" 

            } 

        ], 

        "node_definition": "csr1000v", 

        "ram": 3072, 

        "state": "BOOTED" 

    } 

} 


The primary IPv4 deal with discovered (so as of the interfaces) is used as `ansible_host` to allow the playbook to connect with the gadget. We will use the cisco.cml.stock playbook included within the assortment to indicate the stock. On this case, we solely specify that we would like gadgets which can be within the “router” group created by the stock plugin as knowledgeable by the tags on the gadgets: 

mdd % ansible-playbook cisco.cml.stock --limit=router 

okay: [hq-rtr1] => { 

    "msg": "Node: hq-rtr1(csr1000v), State: BOOTED, Deal with: 192.168.255.199:22" 

} 

okay: [hq-rtr2] => { 

    "msg": "Node: hq-rtr2(csr1000v), State: BOOTED, Deal with: 192.168.255.53:22" 

} 

okay: [site1-rtr1] => { 

    "msg": "Node: site1-rtr1(csr1000v), State: BOOTED, Deal with: 192.168.255.63:22" 

} 

okay: [site2-rtr1] => { 

    "msg": "Node: site2-rtr1(csr1000v), State: BOOTED, Deal with: 192.168.255.7:22" 

} 


Along with group tags, the CML dynamic stock plugin can even parse tags to go info from PATty and to create generic stock information: 

 

If a CML tag is specified that matches `^pat:(?:tcp|udp)?:?(d+):(d+)`, the CML server deal with (versus the primary IPv4 deal with discovered) can be used for `ansible_host`. To alter `ansible_port` to level to the translated SSH port, the tag `ansible:ansible_port=2020` may be set. These two tags inform the Ansible playbook to connect with port 2020 of the CML server to automate the required host within the topology. The `ansible:` tag can be used to specify different host information. For instance, the tag `ansible:nso_api_port=2021` can be utilized to inform the playbook the port to make use of to achieve the Cisco NSO API. Any arbitrary reality may be set on this method. 

Getting began 

Attempting out the CML Ansible Assortment is straightforward. You should utilize the playbooks supplied within the assortment to load and begin a topology in your CML server. To begin, outline the atmosphere variable that tells the gathering methods to entry your CML server: 

% export CML_HOST=my-cml-server.my-domain.com 

% export CML_USERNAME=my-cml-username 

% export CML_PASSWORD=my-cml-password 

The subsequent step is to outline your topology file. That is a commonplace topology file you can export from CML. There are two methods to outline the topology file. First, you possibly can use  an atmosphere variable: 

% export CML_LAB=my-cml-labfile 

Alternatively, you possibly can specify the topology file once you run the playbook as an additionalvar.  For instance, to spin up a topology utilizing the in-built cisco.cml.construct playbook: 

% ansible-playbook cisco.cml.construct -e wait="sure" -e  

This command masses and begins the topology; then it waits till all nodes are working to finish.  If -e startup=’host’ is specified, the playbook will begin every host individually versus beginning them .  This enables for the config to be generated and fed into the host on startup.  When cml_config_file is outlined within the host’s stock, it’s parsed as a Jinja file and fed into that host as config at startup.  This enables for just-in-time configuration to happen. 

As soon as the playbook completes, you should utilize one other built-in playbook, cisco.cml.stock, to get the stock for the topology.  As a way to use it, first create a cml.yml within the stock listing as proven above, then run the playbook as follows: 

% ansible-playbook cisco.cml.stock 

PLAY [cml_hosts] ********************************************************************** 

TASK [debug] ********************************************************************** 

okay: [WAN-rtr1] => { 

    "msg": "Node: WAN-rtr1(csr1000v), State: BOOTED, Deal with: 192.168.255.53:22" 

} 

okay: [nso1] => { 

    "msg": "Node: nso1(ubuntu), State: BOOTED, Deal with: my-cml-server.my-domain.com:2010" 

} 

okay: [site1-host1] => { 

    "msg": "Node: site1-host1(ubuntu), State: BOOTED, Deal with: site1-host1:22" 

} 

On this truncated output, three completely different eventualities are proven.  First, WAN-rtr1 is assigned the DHCP deal with it obtained for its ansible_host worth, and ansible port is 22. If the host working the playbook has IP connectivity (both within the topology or a community linked to the topology with an exterior connector), will probably be in a position to attain that host. 

The second state of affairs reveals an instance of the PATty performance with the host nso1 through which the dynamic stock plugin reads these tags to find out that the host is on the market via the CML server’s interface (i.e. ansible_host is ready to my-cml-server.my-domain.com).  Additionally, it is aware of that ansible_port ought to be set to the port specified within the tags (i.e. 2010).  After these values are set, the ansible playbook can attain the host within the topology utilizing the PATty performance in CML. 

The final instance, site1-host1, reveals the state of affairs through which the CML dynamic stock script can both discover a DHCP allotted deal with or tags to specify to what ansible_host ought to be set, so it makes use of the node title.  For the playbook to achieve these hosts, it must have IP connectivity and be capable to resolve the node title to an IP deal with. 

These built-in playbooks present examples of methods to use the performance within the CML Ansible Assortment to construct your individual playbooks, however you can even use them instantly as a part of your pipeline.  The truth is, we frequently use them instantly within the pipelines we construct for purchasers. 

If you wish to study extra concerning the CML Ansible Assortment, you could find it in Ansible Galaxy in addition to on Github. 

You may also discover a full, IaC CI/CD pipeline utilizing these modules right here.

 

Be a part of the Cisco Studying Community right now free of charge.

Comply with Cisco Studying & Certifications

Twitter | Fb | LinkedIn | Instagram | YouTube

Use #CiscoCert to hitch the dialog.

Share:



Leave a Reply

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