CISCO IOS XR Hosting Applications User Manual

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.

1. The docker file in the source repository is used to build the application binary file on your (docker engine build) host machine.
2. The application binary file is pushed into the docker image registry.
3. The application binary file is pulled from the docker image registry and copied to the docker container on XR (docker engine target host).
4. 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.

1. The application update is generated as a base libs update file (delta update file) and pushed to the docker image registry.
2. 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).
3. The docker containers are restarted with the delta update file.

Hosting of TPA Using Application Manager

Table 1: Feature History Table

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.x8664.rpm

Configure and activate the application| •  Load image – [xr- vm_node0_RP0_CPU0:~]$docker load -i /tmp/ _imagename.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 _imagename| Router#config

Router(config)#appmgr Router(config-appmgr)#application

_appname

Router(config-application)#activate type docker source _imagename docker- run-opts “–net=host” docker-run-cmd “iperf3 -s -d”

 | •  Start container – [xr-vm_node0_RP0_CPU0:~]$docker start _my_containerid| 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 _appname info summary

Router#show appmgr application name _appname info detail

Router#show appmgr application name _appname stats

 | •  Logs

-[xr-vm_node0_RP0_CPU0:~]$docker logs

| Router#show appmgr application-table

Router#show appmgr application name _appname logs

Functionality| Generic Docker Commands| Application Manager Commands
---|---|---
Run a new| •  Execute – [xr-vm_node0_RP0_CPU0:~]$docker exec -it _my_containerid| Router#appmgr application exec
command

inside a

| name _appname docker-exec-cmd
running|
container|
Stop the application container| •  Stop container – [xr- vm_node0_RP0_CPU0:~]$docker stop _my_containerid| Router#appmgr application stop name _appname
Kill the application container| •  Kill container – [xr- vm_node0_RP0_CPU0:~]$docker kill _my_containerid| Router#appmgr application kill name _appname
Start the application container| •  Start container – [xr- vm_node0_RP0_CPU0:~]$docker start _my_containerid| Router#appmgr application start name _appname
Deactivate the application| •  Stop container – [xr- vm_node0_RP0_CPU0:~]$docker stop _my_containerid| Router#configure

Router(config)#no appmgr application _appname

 | •  Remove container – [xr-vm_node0_RP0_CPU0:~]$docker rm _my_containerid| Router(config)#commit
 | •  Remove image – [xr-vm_node0_RP0_CPU0:~]$docker rmi _imagename|
Uninstall the application image/RPM| •  Uninstall image – [xr- vm_node0_RP0_CPU0:~]$docker app uninstall _imagename| Router#appmgr package uninstall package

_image_name-0.1.0-XR_7.3.1.x8664

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.

1. 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

2. Verify if the multi-VRF Docker has been successfully loaded.

3. 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.

4. Verify if the multiple VRFs are accessible from the Docker.
   

You have successfully launched a multi-VRF Docker on Cisco IOS XR.

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>