This is a continuation of my previous 2 blogs on Docker machine, Swarm. In this blog, I will cover Docker Compose and how Docker Machine, Swarm and Compose can work with each other. The interworking part is actively being developed by Docker team and is still at the preliminary stages. Docker Compose: Docker Compose comes from Fig project. With Docker Compose, we can define a multi-container application in a YAML file along with the Container dependencies, affinities etc and Compose will take care of orchestrating the application. Following picture from Docker Compose presentation illustrates the point above. 
Following is a sample YAML file describing a small application with 2 containers, 1 for web and another for db. Continue reading Docker Compose and Interworking of Docker Machine, Swarm, Compose
Docker Swarm
This is a continuation of my previous blog on Docker machine. In this blog, I will cover Docker Swarm.
Swarm manages a set of Docker nodes as a single cluster. This has the following advantages:
- Rather than managing individual Docker nodes, the cluster can be managed as a single entity.
- Swarm has an in-built scheduler that will decide the placement of Containers in the cluster. There are different constraints and affinities that can be mentioned which Swarm uses to decide the Container placement. Constraints could be cpu, memory etc and Affinity could be for grouping related Containers together. Swarm also has the provision to take its scheduler out and work with other schedulers like Mesos and Kubernetes.
- Swarm will take care of node failures so that Container HA can be provided.
Swarm has the following software components:
- Swarm Manager that takes of scheduling and HA. HA piece is not yet available.
- Swarm agent that runs in each node and communicates to Swarm manager.
- Node discovery. There are different approaches available for Swarm worker nodes to discover Swarm master. Discovery is needed because Swarm master and agents run on different nodes and there is a need to find the discovery parameters dynamically. Available discovery mechanisms are docker hub, etcd, Consul etc.
Docker Machine
As part of Docker Orchestration, Docker has released 3 new tools Machine, Swarm, Compose. In the last few weeks, I was playing with these tools and I will share my experiences in this blog. I will start with Docker machine in this blog and I will cover Swarm, Compose in the next set of blogs. Only preliminary version of these tools are released and there is a plan to release more updated versions later this year. For basics and other details on Docker, you can refer to my Docker blog series.
Docker Machine:
Docker machine makes it easier to create Docker hosts using an uniform approach across bare metal, VM, Cloud provider, Private clouds etc. Before Docker machine was there, following were the approaches available to create Docker hosts:
- On Linux machines, Docker agent and client are installed natively.
- For Windows, boot2docker is used to create a Docker host on top of hypervisor like Virtualbox.
- For public clouds, we would create a Linux VM and install Docker on top of it.
Connecting VMs between Virtualbox and VMWare Player
I had written blogs earlier on using Virtualbox and VMWare Player. I recently had a need to connect VMs running on Virtualbox and VMWare player. This is for my Windows laptop. I found the procedure mentioned in this link to be very useful. There are 2 options.
- Use bridged mechanism. Create a networking interface with bridged adapter on Virtualbox and map it to 1 of the physical adapters. Create a networking interface with bridged adapter on VMWare player and map it to the same physical adapter as Virtualbox. In this option, the connection between the 2 hosts is established through external router. It is possible that the router blocks this external communication. Even after clearing the firewall rules on the router, I was not able to get Virtualbox VM talk to VMWare player VM with this approach. I was able to get Virtual box VMs using bridged adapters to talk to each other, same with VMWare player. I feel that there is some filtering enforced either by Virtualbox or VMWare and I am not able to find the reason…
- Use host-only adapter mechanism. Create a host-only adapter on Virtualbox and create a networking interface on the VM and map it to the host-only adapter created. The host-only adapter can be configured with/without dhcp. Open “vmnetcfg” to map 1 of the VMWare adapters to bridged host-only adapter that was created with Virtualbox. I have captured details of “vmnetcfg” in my VMWare player blog. On the VM with VMWare player, create a networking interface and map it to the custom VMNetx interface that was bridged to the Virtualbox adapter. After this, the 2 VMs will be able to talk to each other using the host-only network. This option does not have the disadvantage of dependency on external router and firewall.
References:
Netconf Python ncclient
In my earlier blogs, I had covered basics of Netconf and Yang and how to use Netconf to configure Cisco devices. Recently, I came across this Python ncclient library that simplifies the configuration/monitoring of Networking devices that supports Netconf. Using ncclient library, we can programmatically configure and monitor devices using Netconf. I also found out that Cisco Openstack Neutron plugin uses ncclient library to program the Nexus switches.
I have used Cisco Nexus 3k switch and Cisco VIRL NXOS switch for the examples in this blog.
In my earlier blog on configuring Cisco Nexus devices using Netconf, I covered the following netconf requests.
- “get” request using filter to display configuration.
- “edit-config” request to change configuration.
- “exec-command” to execute raw CLI requests.
In this blog, I will cover the above same tests using Python ncclient library. Even though the examples below are tried from Python interactive shell, the same can be executed as a Python program as well.
First step is to import the ncclient library and create a connection:
Connecting NXOS VIRL instance to Arista vEoS
In this blog, I will cover the steps that I did to connect Cisco NXOS VIRL switch instance to Arista vEoS switch instance. We can connect any Cisco switch simulated in VIRL, I just picked the NXOS switch type. CML/VIRL supports majority of Cisco switches as VM as well as few external switches from Juniper, Vyatta. External virtual or physical switches can be connected to Cisco switches running inside VIRL using VM Networking magic. I just think it is cool to connect Virtual devices, try out real-time network configurations and see how the device responds.
Prerequisites:
- Install CML/VIRL using the procedure here.
- Install vEoS using the procedure here.
- I used VMPlayer to run VIRL and vEoS. Connecting across Virtualbox and VMWare player is little painful.
Following is the network I created:
Continue reading Connecting NXOS VIRL instance to Arista vEoS
Cisco NXAPI with VIRL
In this blog, I will cover the steps to get NXAPI working with NXOS image in VIRL. For more details on CML/VIRL, please refer to my earlier blog series. Running NXAPI with VIRL image makes it easy to write automation scripts without needing a physical switch.
Earlier, I had installed VIRL February release(0.9.17) which included the VIRL STD 0.10.13.11. To run NXAPI which is supported in NXOS 7.2.0 version, it is needed to upgrade VIRL to the latest version. I tried running NXOS 7.2.0 in VIRL 0.10.13.11. Even though I was able to enable “feature nxapi”, I was not able to configure management IP and be able to connect from outside.
VIRL’s latest April release(0.9.242) has the following components:
- VM Maestro 1.2.2 Build Dev-211
- VIRL STD 0.10.14.20
There are 2 approaches to upgrade VIRL.
- Full upgrade which upgrades both VIRL and OS related stuff.
- Quick upgrade which upgrades only VIRL. Based on the VIRL 0.9.242 upgrade note here, it is fine to do quick upgrade for users running VIRL STD 0.10.13.11. For folks outside Cisco, I am not sure if VIRL 0.9.242 is released outside.
Ansible for Arista EoS
This is a continuation of my previous blog on Arista Eapi. Ansible provides a recipe driven approach to manage servers/switches, I have covered Ansible in some of my previous blogs. In this blog, I will cover the following:
- Ansible modules for Arista device
- Ansible galaxy eos role for Arista device
There are 2 approaches to use Ansible with Arista device. Following picture from Arista illustrates this point:
- The first approach is called remote approach from Ansible perspective. Here the ansible python script is transferred to Arista device using ssh and the python script is executed on the Arista device which connects locally to the device using Pyeapi which in turn talks through eapi.
- The second approach is called local approach from Ansible perspective. Here the Ansible python script is run locally in the client machine which in turn talks to Pyeapi library which in turn talks to the remote device using eapi.
- Typically, network devices dont allow running scripts directly on the device. In that case, only second option would be possible. In Arista’s case, there are no restrictions like this and both the approaches can be used for Ansible based automation.
Arista Eapi and pyeapi
I had covered basics of Arista EoS and vEoS in my previous blog. Arista’s Eapi gives programmatic approach to manage Arista devices. Arista’s Pyeapi Python library is built on top of Eapi. In this blog, I will cover the following:
- Eapi
- Pyeapi library
I have used Arista vEoS for trying out all examples below without needing a physical Arista device. That shows the power of virtual device.
There is lot of similarity between Arista’s Eapi and Cisco’s NXAPI. I covered NXAPI in 1 of my earlier blogs. Arista’s Eapi is equivalent to Cisco’s NXAPI, Arista’s Pyapi library is equivalent to Cisco’s Pycsco library. Arista’s Eapi provides http/https access to the Arista router/switch through which we can send standard CLI commands and the output is received in JSON/XML formatted output. There is no need to do screen scraping with this approach, this makes it devops friendly. Arista’ Pyeapi is available as a github project.
Eapi:
To enable Eapi in Arista device, do “management api http-commands” in config prompt. Following is the output in my Arista vEoS switch:
Arista EoS and vEoS
I had heard some good things about Arista EoS(Extensible Operating System). I have never used Arista switches before. I did some reading on Arista EoS and I also tried their VEoS which is their Virtual machine offering for running Arista switch as VM. In this blog, I will share some of my experiences.
EoS Overview:
I found this block diagram in Arista White paper:
Following are the things that I liked:
