Trying out the CML Ansible Collection is easy. You can use the playbooks provided in the collection to load and start a topology in your CML server. To start, define the environment variable that tells the collection how to access your CML server:\u00a0<\/p>\n

% export CML_HOST=my-cml-server.my-domain.com\u00a0
\n% export CML_USERNAME=my-cml-username\u00a0
\n% export CML_PASSWORD=my-cml-password\u00a0<\/p>\n

The next step is to define your topology file. This is a standard topology file you can export from CML. There are two ways to define the topology file. First, you can use\u00a0 an environment variable:\u00a0<\/p>\n

% export CML_LAB=my-cml-labfile\u00a0<\/p>\n

Alternatively, you can specify the topology file when you run the playbook as an extra\u2013var.\u00a0 For example, to spin up a topology using the built in cisco.cml.build<\/em> playbook:\u00a0<\/p>\n

% ansible-playbook cisco.cml.build -e wait=’yes’ -e cml_lab_file=topology.yaml <\/p>\n

This command loads and starts the topology; then it waits until all nodes are running to complete.\u00a0 If -e startup=\u2019host\u2019<\/em> is specified, the playbook will start each host individually as opposed to starting them all at once.\u00a0 This allows for the config to be generated and fed into the host on startup.\u00a0 When cml_config_file is defined in the host\u2019s inventory, it is parsed as a Jinja file and fed into that host as config at startup.\u00a0 This allows for just-in-time configuration to occur.\u00a0<\/p>\n

Once the playbook completes, you can use another built-in playbook, cisco.cml.inventory<\/em>, to get the inventory for the topology.\u00a0 In order to use it, first create a cml.yml<\/em> in the inventory directory as shown above, then run the playbook as follows:\u00a0<\/p>\n

% ansible-playbook cisco.cml.inventory\u00a0
\nPLAY [cml_hosts] **********************************************************************\u00a0
\nTASK [debug] **********************************************************************\u00a0
\nok: [WAN-rtr1] => {\u00a0
\n\u00a0\u00a0\u00a0 “msg”: “Node: WAN-rtr1(csr1000v), State: BOOTED, Address: 192.168.255.53:22”\u00a0
\n}\u00a0
\nok: [nso1] => {\u00a0
\n\u00a0\u00a0\u00a0 “msg”: “Node: nso1(ubuntu), State: BOOTED, Address: my-cml-server.my-domain.com:2010”\u00a0
\n}\u00a0
\nok: [site1-host1] => {\u00a0
\n\u00a0\u00a0\u00a0 “msg”: “Node: site1-host1(ubuntu), State: BOOTED, Address: site1-host1:22”\u00a0
\n}\u00a0<\/p>\n

In this truncated output, three different scenarios are shown.\u00a0 First, WAN-rtr1<\/em> is assigned the DHCP address it received for its ansible_host value, and ansible port <\/em>is 22<\/em>. If the host running the playbook has IP connectivity (either in the topology or a network connected to the topology with an external connector), it will be able to reach that host.\u00a0<\/p>\n

The second scenario shows an example of the PATty functionality with the host nso1<\/em> in which the dynamic inventory plugin reads those tags to determine that the host is available through the CML server\u2019s interface (i.e. ansible_host<\/em> is set to my-cml-server.my-domain.com<\/em>).\u00a0 Also, it knows that ansible_port should be set to the port specified in the tags (i.e. 2010).\u00a0 After these values are set, the ansible playbook can reach the host in the topology using the PATty functionality in CML.\u00a0<\/p>\n

The last example, site1-host1<\/em>, shows the scenario in which the CML dynamic inventory script can either find a DHCP allocated address or tags to specify to what ansible_host<\/em> should be set, so it uses the node name.\u00a0 For the playbook to reach those hosts, it would have to have IP connectivity and be able to resolve the node name to an IP address.\u00a0<\/p>\n

These built-in playbooks show examples of how to use the functionality in the CML Ansible Collection to build your own playbooks, but you can also use them directly as part of your pipeline.\u00a0 In fact, we often use them directly in the pipelines we build for customers.\u00a0<\/p>\n