CISCO IOS XR Hosting Applications User Manual

Contents hide

CISCO IOS XR Hosting Applications

Hosting Applications on IOS XR
This section explains the different kinds of application hosting, and demonstrates how a simple application can be hosted natively or in a third-party container on IOS XR.

Application Hosting Using Docker Containers.
Docker-Based Container Application Hosting.

Application Hosting Using Docker Containers
Application hosting on IOS XR supports docker containers. You can create your own container on IOS XR using docker, and host applications within the container. The applications can be developed using any Linux distribution. This is well suited for applications that use system libraries that are different from that provided by the IOS XR root file system. Cisco NCS 540 supports only docker-based application hosting.

Docker-Based Container Application Hosting
This section introduces the concept of container application hosting and describes its workflow. Container application hosting makes it possible for applications to be hosted in their own environment and process space (namespace) within a Linux container on Cisco IOS XR. The application developer has complete control over the application development environment, and can use a Linux distribution of choice. The applications are isolated from the IOS XR control plane processes; yet, they can connect to networks outside XR through the XR GigE interfaces. The applications can also easily access local file systems on IOS XR.

Using Docker for Hosting Applications on Cisco IOS XR
Docker is a container used for hosting applications on Cisco IOS XR. Docker provides isolation for application processes from the underlying host processes on XR by using Linux network namespaces.

Need for Docker on Cisco IOS XR
Docker is becoming the industry-preferred packaging model for applications in the virtualization space. Docker provides the foundation for automating application life cycle management. Docker follows a layered approach that consists of a base image at the bottom that supports layers of applications on top. The base images are available publicly in a repository, depending on the type of application you want to install on top. You can manipulate docker images by using the docker index and registry. Docker provides a git-like workflow for developing container applications and supports the “thin update” mechanism, where only the difference in source code is updated, leading to faster upgrades. Docker also provides the “thin download” mechanism, where newer applications are downloaded faster because of the sharing of common base docker layers between multiple docker containers. The sharing of docker layers between multiple docker containers leads to lower footprint for docker containers on XR.

Docker Architecture on Cisco IOS XR
The following figure illustrates the docker architecture on IOS XR.

The application binaries for the applications to be hosted are installed inside the docker container.

Hosting Applications in Docker Containers
The following figure illustrates the workflow for hosting applications in Docker containers on IOS XR.

The docker file in the source repository is used to build the application binary file on your (docker engine build) host machine.

The application binary file is pushed into the docker image registry.
The application binary file is pulled from the docker image registry and copied to the docker container on XR (docker engine target host).

The application is built and hosted in the docker container on XR.

Updating Applications in Docker Containers
The following figure illustrates the workflow for updating applications hosted in docker containers.

The application update is generated as a base libs update file (delta update file) and pushed to the docker image registry.
The delta update file (containing only the difference in application code) is pulled from the docker image registry and copied to the docker containers on XR (docker engine target host).

The docker containers are restarted with the delta update file.

Hosting of TPA Using Application Manager

Table 1: Feature History Table

Feature Name

Release Information

Feature Description

On-Demand Docker Daemon Service

Release 7.5.1

From this release onwards, the

Docker daemon service starts on a router only if you configure a third-party hosting application using the appmgr command. Such an on-demand service optimizes operating system resources such as CPU, memory, and power.

In earlier releases, the Docker daemon service automatically started during the router boot up.

In previous releases, the applications were hosted and controlled by the Docker commands. These Docker commands were executed in the bash shell of the Kernel that also hosted the Cisco IOS XR software. With the introduction of Application Manager, it is now possible to manage third-party application hosting and their functioning through Cisco IOS XR CLIs. With this feature, all the activated third party applications can restart automatically after a router reload or an RP switchover. This automatic restart of the applications ensure seamless functioning of the hosted applications.

Supported Commands on Application Manager
For every application manager command or configuration executed, the Application Manager performs the requested action by interfacing with the Docker daemon through the Docker socket. The following table lists the Docker container functionalities, the generic Docker commands that were used in the previous releases, and its equivalent application manager commands that can now be used:

Functionality	Generic Docker Commands	Application Manager Commands
Install the application RPM	NA	Router#appmgr package install rpm image_name-0.1.0-XR_7.3.1.x86_64.rpm
Configure and activate the application	• Load image – [xr-vm_node0_RP0_CPU0:~]$docker load -i /tmp/image_name.tar • Verify the image on the router – xr-vm_node0_RP0_CPU0:~]$docker images ls • Create container over the image – [xr-vm_node0_RP0_CPU0:~]$docker create image_name	Router#config Router(config)#appmgr Router(config-appmgr)#application app_name Router(config-application)#activate type docker source image_name docker-run-opts “–net=host” docker-run-cmd “iperf3 -s -d”
	• Start container – [xr-vm_node0_RP0_CPU0:~]$docker start my_container_id	Router(config-application)#commit
View the list, statistics, logs, and details of the application container	• List images -[xr-vm_node0_RP0_CPU0:~]$docker images ls • List containers – [xr-vm_node0_RP0_CPU0:~]$docker ps • Statistics -[xr-vm_node0_RP0_CPU0:~]$docker stats	Router#show appmgr source-table Router#show appmgr application name app_name info summary Router#show appmgr application name app_name info detail Router#show appmgr application name app_name stats
	• Logs -[xr-vm_node0_RP0_CPU0:~]$docker logs	Router#show appmgr application-table Router#show appmgr application name app_name logs

Functionality	Generic Docker Commands	Application Manager Commands
Run a new	• Execute – [xr-vm_node0_RP0_CPU0:~]$docker exec -it my_container_id	Router#appmgr application exec
command inside a		name app_name docker-exec-cmd
running
container
Stop the application container	• Stop container – [xr-vm_node0_RP0_CPU0:~]$docker stop my_container_id	Router#appmgr application stop name app_name
Kill the application container	• Kill container – [xr-vm_node0_RP0_CPU0:~]$docker kill my_container_id	Router#appmgr application kill name app_name
Start the application container	• Start container – [xr-vm_node0_RP0_CPU0:~]$docker start my_container_id	Router#appmgr application start name app_name
Deactivate the application	• Stop container – [xr-vm_node0_RP0_CPU0:~]$docker stop my_container_id	Router#configure Router(config)#no appmgr application app_name
	• Remove container – [xr-vm_node0_RP0_CPU0:~]$docker rm my_container_id	Router(config)#commit
	• Remove image – [xr-vm_node0_RP0_CPU0:~]$docker rmi image_name
Uninstall the application image/RPM	• Uninstall image – [xr-vm_node0_RP0_CPU0:~]$docker app uninstall image_name	Router#appmgr package uninstall package image_name-0.1.0-XR_7.3.1.x86_64

Note: The usage of the application manager commands are explained in the “Hosting iPerf in Docker Containers to Monitor Network Performance using Application Manager” section.

Configuring a Docker with Multiple VRFs

This section describes how you can configure a Docker with multiple VRFs on Cisco IOS XR. For information on configuring multiple VRFs, see Configuring Multiple VRFs for Application Hosting topic.

Configuration
Use the following steps to create and deploy a multi-VRF Docker on XR.

Create a multi-VRF Docker with NET_ADMIN and SYS_ADMIN privileges.
In the following example, a Docker container containing three VRFs (yellow, blue, and green) is launched. The example assumes that a previous “multivrfimage” docker image was installed using the appmgr package install command.
Note:
- Mounting the entire content of /var/run/netns from host to Docker is not recommended, because it mounts the content of netns corresponding to XR and the system admin plane into the Docker.
- You should not delete a VRF from Cisco IOS XR when it is used in a Docker. If one or more VRFs are deleted from XR, the multi-VRF Docker cannot be launched
Verify if the multi-VRF Docker has been successfully loaded.
Connect to the multi-VRF Docker container by executing the following command.
Router# appmgr application exec name multivrfcontainer1 docker-exec-cmd /bin/bash/
By default, the Docker is loaded in global-vrf namespace on Cisco IOS XR.