Application Hosting Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

PDF

Application Hosting Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

TP application bring-up methods

Want to summarize with AI?

Log in

Explore the general concepts and methodologies involved in TP application bring-up. This overview sets the foundation for specific deployment strategies and configurations.


A TP application bring-up is a deployment process that

  • allows TP container applications to be launched and initialized for operational readiness,

  • provides multiple configuration approaches to match different deployment needs, and

  • ensures flexibility in integration with system models and container management tools.

There are four main approaches for bringing up TP applications, each offering distinct deployment and management strategies.

The four recommended methods for TP application bring-up are:

  • App Config: Use the application configuration files to define startup parameters.

  • UM Model: Employ the Unified Management model for standardized operational controls.

  • Native Yang Model: Leverage native YANG data models for direct integration and configuration.

  • gNOI Containerz: Use gNOI Containerz for streamlined container orchestration and lifecycle management.


Configure a TPA using application configuration

Activate and configure a TPA by specifying docker runtime settings to control process resources and verify the configuration.
Configuring a TPA with application configuration allows you to manage its runtime options, such as limiting the number of process IDs, ensuring efficient operation and resource management.

Follow these steps to configure the docker run time options.

Procedure

1.

Configure the docker run time option.

Use --pids-limit to limit the number of process IDs using appmgr.

Example:

This example shows the configuration of the docker run time option --pids-limit to limit the number of process IDs using appmgr.

RP/0/RP0/CPU0:ios#appmgr application alpine_app activate type docker source alpine docker-run-opts "-it –pids-limit 90" docker-run-cmd "sh"

The number of process IDs is limited to 90.

2.

Verify the docker run time option configuration.

Use the show running-config appmgr command to verify the run time option.

Example:

This example shows how to verify the docker run time option configuration.

RP/0/RP0/CPU0:ios#show running-config appmgr
Thu Mar 23 08:22:47.014 UTC
appmgr
 application alpine_app
  activate type docker source alpine docker-run-opts "-it –pids-limit 90" docker-run-cmd "sh"
 !
!
The TPA is activated using the specified docker runtime options, and the configuration is verified to ensure resource limits are correctly applied.

Configure TPAs with the UM model

Limit the number of process IDs (PIDs) available to a TPA (Third Party Application) running in Docker using Netconf.
Use this task to apply resource limits to Docker-based TPAs managed through Cisco's Unified Model (UM). Limiting PIDs prevents runaway processes and supports system reliability.

Follow these steps to configure the docker run time options.

Procedure

Configure the docker run time option.

Use --pids-limit to limit the number of process IDs using Netconf.

Example:

This example shows the configuration of the docker run time option --pids-limit to limit the number of process IDs using Netconf.

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <config>
      <appmgr xmlns=http://cisco.com/ns/yang/Cisco-IOS-XR-um-appmgr-cfg>                     
        <applications>
          <application>
            <application-name>alpine_app</application-name>
            <activate>
              <type>docker</type>
                  <source-name>alpine</source-name>
                  <docker-run-cmd>/bin/sh</docker-run-cmd>
                  <docker-run-opts>-it --pids-limit=90</docker-run-opts>
            </activate>
          </application>
        </applications>
      </appmgr>
    </config>
  </edit-config>

The number of process IDs for the specified TPA is limited as configured. For example, with --pids-limit=90, the application will not spawn more than 90 processes.


Native model deployment for TPAs

The native deployment model for Third Party Applications (TPAs) offers direct integration and performance benefits for supported applications. This model enables users to configure advanced options, such as limiting process IDs for containerized applications using the Native YANG model.

This configuration uses the docker runtime option --pids-limit to restrict the number of process IDs for an application called alpine_app. This ensures resource control and operational stability in environments with multiple TPAs.

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <config>
      <appmgr xmlns=http://cisco.com/ns/yang/Cisco-IOS-XR-appmgr-cfg>
        <applications>
          <application>
            <application-name>alpine_app</application-name>
            <activate>
              <type>docker</type>
               <source-name>alpine</source-name>
               <docker-run-cmd>/bin/sh</docker-run-cmd>
               <docker-run-opts>-it --pids-limit=90</docker-run-opts>
            </activate>
          </application>
        </applications>
      </appmgr>
    </config>
  </edit-config>

Key benefits of using the native deployment model:

  • Enables direct integration for TPAs.
  • Provides better resource management through advanced container options.
  • Improves performance and operational reliability for supported applications.

gNOI Containerz for TPA onboarding and lifecycle management

The gNOI Containerz service on the router enables the onboarding and management of Third Party Applications (TPAs) using standardized gNOI remote procedure calls (RPCs). This approach offers:
  • A streamlined workflow for onboarding TPAs onto the router.

  • Standardized methods for managing the full lifecycle of containers, including deployment, start/stop, and removal.

  • Simplified and consistent administration of application containers on the device.

The Containerz - gNOI Container Service is a workflow to onboard and manage third-party applications using gNOI RPCs.