Software-Defined Networking and DevOps
The advent of software-defined networking (SDN) is changing network operations. Traditional methods are no longer enough as networks are provisioned through self-service applications and configuration management tools. The key aspects of this transition include:
- A shift from command-line to application programming interfaces
- Network devices treated as part of a cluster rather than individual networking elements
- Integration between network operations and development
DevOps enables continuous software delivery and infrastructure changes through automation. It spans the entire lifecycle, from business planning and creation, to delivery and feedback. DevOps can be described as collaborative practices among Software Development Engineering, Technology Operations, and Quality Assurance teams.
Transition in Networking
Scope of DevOps
A Sample DevOps Workflow for SDN
Code Management and Repository
The first component of a DevOps architecture is a code management repository. All software that will form part of the SDN infrastructure is placed in the code repository to enable continuous integration.
The code repository should support the following capabilities:
- Maintain code revisions
- Keep a history of commits
- Act as a code review system
- Allow API/web hooks integration
Build and Packaging Tools
Build tools convert the sources in the code repository to executables which can run on any infrastructure. Packaging tools allow the executables to be packaged along with rules and dependencies, easing the seamless delivery of executables on the infrastructure.
Build and packaging tools are completely dependent on the OS running on the infrastructure. For source codes in Python/Ruby/Perl which run via interpreter, no build is required, although they need to be packaged.
The package repository hosts the packages required for deployment. Most common OS package management tools, such as apt and yum, query the HTTP webserver which hosts the packages. In addition to storing packages, the repository also performs the following functions:
- Act as mirrors of other repositories
- Take snapshots of itself
Mirror and snapshot features ensure that any changes in the repository do not get deployed in the infrastructure, unless there are changes in the snapshot version. Examples of package repository management tools include aptly and Assemble.
Process and Deployment Orchestration
This refers to the core part of a DevOps architecture that automates and orchestrates the entire DevOps tool chain. This orchestration engine integrates the various DevOps tools and automates the process. An example of this is a workflow that automatically builds a package once a new source code commit is performed and detected. This tool also accesses the deployment environment, and automates or kick-starts the deployment on the infrastructure.
Jenkins is the most commonly used tool for this purpose. Jenkins is an open-source project which is commonly used in DevOps deployments. It can be set up locally inside an infrastructure and talk to most of the DevOps tools using a plethora of 100+ plugins which can be quickly utilized for Continuous Integration (CI) and Continuous Deployment (CD). Jenkins has an SSH plugin which can be utilized to automate remote deployments on servers.
Configuration Management (CM) is a critical component in any DevOps Architecture, as CM tools enable continuous delivery of changes to the infrastructure. CM tools manage files in a manner that allows multiple deployments of similar configurations. These tools also restart the services in case of configuration changes. If there are manual changes to a configuration, CM tools can detect and revert the changes. Commonly used CM tools include Puppet, Chef, and Ansible.
This is the final piece in a DevOps architecture. Its role is to monitor the infrastructure and provide feedback to the developers on how their services are functioning and performing. The framework should be flexible in such a way that any service running on the infrastructure can be monitored and its performance measured. In addition, it should scale easily based on infrastructure needs, store historical logs/data, and do correlation between various parameters. There should be a provision to set triggers to identify faults, and send notifications via email/SMS/chat or some other means when an alarm is triggered. Commonly used monitoring frameworks include Nagios, Check_MK, and Sensu.