Openstack Deployment using Containers

I recently saw the Openstack self-healing demo from CoreOS team using Tectonic(Stackanetes project) and I kind of felt that the boundary between Containers and VMs are blurring. In this blog, I discuss the usecase of deploying Openstack using Containers.

We typically think of Openstack as a VM Orchestration tool. Openstack is composed of numerous services and deploying Openstack as one monolithic blob is pretty complex and difficult to maintain. The demo described showed how Containers simplify Openstack deployment. This is a great example of using Microservices architecture to simplify infrastructure deployment.

Following diagram shows the Openstack deployment model using Containers. The diagram below shows how Openstack service containers deploys user VM. The user VMs deployed using Openstack can run Containers as well..

Following are some notes on the architecture:

• Openstack services like Nova, Heat, Horizon are containerized using Openstack Kolla project as Docker Containers. Some Openstack services like Nova is composed of multiple Containers.
• Infrastructure components like Ceph, Openvswitch, Mongodb are also deployed as Containers.
• For Container deployment, Openstack natively uses Ansible. Kubernetes can also be used for Orchestration.
• Using Containers for Openstack service containers gives all the build, ship and deploy advantages of Containers.
• Using orchestration solution like Kubernetes gives all the resiliency and deployment advantages for Openstack services.

This work also shows how Containers and VMs can work closely with each other for lot of use-cases. There are other Openstack projects like Magnum and Kuryr where there is an intersection between Containers and VMs. Magnum project deals with Container orchestration using Openstack and Kuryr project deals with doing Container networking using Openstack Neutron.

References:

• Openstack Kolla presentation – 1, 2
• Stackanetes Github page

Microservices Infrastructure using Mantl

Mantl is an Open source project from Cisco and it provides an integrated solution to deploy distributed Microservices. Any company deploying Microservices has to integrate different components before the solution becomes production ready. Mantl makes it easier by integrating the different components and providing the glue software that integrates the components. In this blog, I will cover the following:

• Distributed Microservice infrastructure components and the need for Mantl.
• Mantl Architecture.
• Mantl installation using Vagrant
• Mantl installation using AWS public cloud

Microservices infrastructure

Following are typical components in Container based Microservices infrastructure:

Ansible book – Technical review

I recently did a technical review for “Mastering Ansible” book by Jesse Keating. This book covers usage of Ansible for automation with practical examples. If anyone is interested, please look at the book. Pre-requisite is to have basic Ansible knowledge.

Ansible is similar to configuration management tools like Chef, Puppet. Agent-less architecture and short learning curve has made Ansible very popular in recent years. I have covered Ansible in few of my previous blogs. Ansible documentation is also pretty good to understand the basics.

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.

Cisco NXAPI

Earlier, I had written about Cisco NXOS device configuration/monitoring using Python and OnePK. Recently, I came across NXAPI approach to configure and monitor NXOS  devices. NXAPI uses either http/https to connect to NXOS devices and talk using NXOS CLI. For configuration, CLI is encoded in XML/JSON. For monitoring, CLI is encoded in XML/JSON and the results are returned in similar format that makes it easy to parse. I also saw this blog and nxos-ansible project from Jason where he has created Ansible modules using NXAPI. In this blog, I will cover NXAPI basics and my experience in trying Pycsco library and nxos-ansible modules from Jason. Thanks to Jason, he has done a nice job abstracting the NXAPI into higher level functions and Ansible modules and this can help others to build up on top of it rather than working from scratch.

Enabling NXAPI:

NXAPI is available on Nexus 3k and 9k devices. I have access to N3K device and I tried this there. To enable NXAPI, we need to execute “feature nxapi” from config prompt. NXAPI also provides a sandbox environment which can be accessed using http from the management ip address. With the sandbox environment, we can execute NXOS CLI commands and get output in JSON or XML format. Following image is a snapshot of the sandbox.

Ansible for Network Automation – Part 2

This blog is part of my series on Devops for Networking. In the previous blog, I covered basics of Ansible and how to get started with it. In this blog, I will cover a sample application that I wrote with Ansible. This Ansible application builds on UCS sdk utility that I covered in a previous blog. The UCS python utility displays the inventory of UCS system. I have made that utility as an Ansible module and extended the application to display the inventory of a list of UCS systems that are defined in the host list. This project is more to illustrate the usecase for Ansible.

The source code for the project can be found here. There are 3 files listed here:

getucs.yml - YAML file that defines the playbook
getucsinfo - New module that is defined. This file needs to be in "usr/share/ansible"
getUcsProp.py - getucsinfo module uses functions in this library. This file needs to be in PYTHONPATH.The library provides utility functions to get UCS inventory.

Ansible for Network automation – Part 1

This blog is part of my series on Devops for Networking. Ansible is a very popular Devops tool and serves similar purposes as Puppet, Chef etc. Ansible has the unique feature that there is no need to install agent on the device side and this makes it very popular for Network device configuration since Network devices are still predominantly a closed system which does not allow agent installation in the device. In this blog, I will cover how to get started with Ansible and in the next blog, I will cover a sample application that I have written.

Ansible basics:

Ansible modules can be run locally or remotely. With the local approach, the module runs locally using apis to talk to remote devices. In remote scenario ,modules are pushed to remote devices, executed as python script and results are returned. Even though there is no need to install remote agent, remote device should allow execution of Python script. Ansible can either be run in command-line for simple tasks or can be executed using a playbook.

DevOps and Network Automation

Devops is now a widely used term. I recently read few articles on Devops in relation to Network Automation and that prompted me to do some research on this topic. In this blog, I will cover what I think comprises the Devops Networking domain and in the next series of blogs, I will try to explore individual areas in more detail. Devops allows infrastructure to be treated as a code and it makes the infrastructure programmable. The term Devops refers to a merger between Development and Operations role and it encourages Developer to look at Operations angle and Network operator to look from Developer angle. As everyone knows, automating infrastructure deployment improves efficiency, removes operator error and allows us to scale. Server automation has been present for quite some time and Network Automation is still very much in infancy stage at this point. Following article from Ivan describes Devops as a lifestyle or mindset on how infrastructure is treated rather than as tools associated with Devops.

How is Network Automation different from Server automation?