Aruba JG632A Configuration Guide

Brand: Aruba

Model: JG632A

Type: Configuration Guide

HPE FlexFabric 12900E Switch Series

Application Hosting Configuration Guide

Software

version: Release 5210

Document version: 6W100-20230424

The information contained herein is subject to change without notice. The only warranties for Hewlett Packard

Enterprise products and services are set forth in the express warranty statements accompanying such

products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett

Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein.

Confidential computer software. Valid license from Hewlett Packard Enterprise required for possession, use, or

copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software

Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s

standard commercial license.

Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard

Enterprise has no control over and is not responsible for information outside the Hewlett Packard Enterprise

website.

Acknowledgments

Intel®, Itanium®, Pentium®, Intel Inside®, and the Intel Inside logo are trademarks of Intel Corporation in the

United States and other countries.

Microsoft® and Windows® are either registered trademarks or trademarks of Microsoft Corporation in the

United States and/or other countries.

Adobe® and Acrobat® are trademarks of Adobe Systems Incorporated.

Java and Oracle are registered trademarks of Oracle and/or its affiliates.

UNIX® is a registered trademark of The Open Group.

Contents

Hosting container applications ······································································· 1

About container applications ······························································································································ 1

Containerization and container ·················································································································· 1

Advantages of containers ··························································································································· 1

Container deployment and management ··································································································· 1

Container applications ································································································································ 2

Network communication of container applications ····················································································· 2

Restrictions and guidelines: Container application hosting ················································································ 4

Container application hosting tasks at a glance ································································································· 5

Enabling the container feature ··························································································································· 5

Deploying Docker containers ····························································································································· 5

About deploying Docker containers ··········································································································· 5

Restrictions and guidelines for Docker container deployment ··································································· 5

Reloading the Docker daemon configuration ····························································································· 6

Deploying a Docker container ···················································································································· 6

Configuring network parameters for containers ································································································· 7

Container network parameters configuration tasks at a glance ································································· 7

Configuring interface Loopback 0 ·············································································································· 7

Configuring interface Virtual-Eth-Group 0 ·································································································· 8

Enabling the kubelet service ······························································································································ 8

Container application hosting examples ············································································································ 9

Example: Deploying a container application that uses the same network namespace as Comware ········ 9

Example: Deploying a container application (separate network namespace)·········································· 12

Appendix Docker client command reference ··································································································· 14

Downloading and importing images ········································································································· 14

Pulling images ·········································································································································· 15

Running a container by using the docker run command ·········································································· 17

Allocating hardware resources to a container ·························································································· 17

Attaching to a running container ·············································································································· 18

Returning to the Comware CLI ················································································································· 18

Listing containers ····································································································································· 18

Saving containers ····································································································································· 19

Hosting RPM applications ············································································ 20

About RPM application hosting ························································································································ 20

Communication between RPM applications····································································································· 20

Restrictions and guidelines: RPM application hosting ····················································································· 21

Installing an RPM application ··························································································································· 21

Configuring network parameters for RPM applications ···················································································· 21

RPM application configuration examples ········································································································· 22

Example: Installing an RPM application ··································································································· 22

Appendix rpm command reference ·················································································································· 23

Downloading an RPM package without installing it·················································································· 23

Querying information about an RPM package ························································································· 24

Installing an RPM package ······················································································································ 24

Running an application that is installed through RPM·············································································· 24

Uninstalling an application that is installed through RPM ········································································ 24

Querying RPM package information (-qp)································································································ 25

Displaying rpm command help information ······························································································ 28

Configuring common container and open application parameters ················ 29

About configuring common container and open application parameters ························································· 29

Configuring common container parameters ····································································································· 29

Backing up container data························································································································ 29

Configuring common open application parameters ························································································· 29

Specifying a source IP address for open applications ············································································· 29

Preconditioning incoming IP packets ······································································································· 30

Document conventions and icons ································································ 33

Conventions ····················································································································································· 33

Network topology icons ···································································································································· 34

Support and other resources ······································································· 35

Accessing Hewlett Packard Enterprise Support······························································································· 35

Accessing updates ··········································································································································· 35

Websites ·················································································································································· 36

Customer self repair ································································································································· 36

Remote support ········································································································································ 36

Documentation feedback ························································································································· 36

Index ············································································································ 38

Hosting container applications

About container applications

Comware 9 supports open (also called third-party) container applications based on Docker. You can

quickly install, run, and manage such applications on physical HPE devices with ease to expand

device functionality. You can also use Kubernetes to automate deployment, scaling, and

management of the container applications for easy interoperability with SDN and cloud platforms.

Containerization and container

Containerization is a lightweight operating-system-level virtualization technology. A container

includes everything required for an application to run -- the code, a runtime, libraries, environment

variables, and configuration files. All containers share the operating system kernel of the host but are

isolated from each other.

Typical container management tools include Docker and LXC. Built on top of facilities such as

namespaces, cgroups, and UnionFS, Docker greatly simplifies container application and promotes

wide use of containers.

The Comware system integrates Docker and incorporates resource restriction features. It provides

robust support for you to run open container applications based on Docker.

Advantages of containers

Containers have the following advantages:

•

Lightweight—Containers leverage and share the host kernel. Compared with traditional virtual

machines, containers use fewer resources and are more lightweight and quicker to start,

allowing the host to support more applications.

•

Secure—Linux namespaces are used in combination with cgroups to isolate containers and

control resource allocation and usage.

•

Portable—Containers use RootFS and UnionFS technologies. You can run containers on

various mainstream Linux versions.

Container deployment and management

Comware 9 integrates Docker and kubelet. You can use Docker or Kubernetes to deploy container

applications on the device.

•

Comware supports native Docker client commands. When using the docker command to

create a container, you can assign the container namespaces and resources (cgroups) to

implement container isolation. You can also save containers to the flash memory on the device

so the device restores the containers after a reboot.

•

When kubelet is running on the device, the device is a Kubernetes node. You can use the

Kubernetes master to orchestrate and manage open applications on the device.

Figure 1 Comware cooperation with Kubernetes

Container applications

You can create and start containers on the device and run Docker container-based applications in

the containers to provide additional features, for example, information collection and monitoring.

Some containers are applications by themselves. For example, each device can run an agent

container to collect statistics on CPU usage, memory usage, and traffic and send the statistics to the

monitoring device.

Some containers provide a platform on which you can install open applications. You can use the

interfaces provided by the applications in the containers to start or stop the applications. The

containerization technology restricts the impact of open applications to the containers, isolating the

applications from Comware.

Network communication of container applications

Comware provides network communication services for open applications. Open applications

running on the device can communicate with both applications running on Comware and entities on

networks. In the latter case, the forwarding module of Comware uses the device's physical interfaces

to forward packets of open applications to entities on networks.

Docker uses namespaces to implement isolation between containers. The network namespaces are

used to isolate network resources, for example, IP addresses, IP routing tables, /proc/net directories,

and port numbers. When you create a container on the device, you can configure the container to

share or not to share the network namespace for Comware. The communication mode of the

container with entities on networks and the required networking configuration depend on the choice.

Comware

container

……

Device A

kubelet

dockerd

……

Device B

kubelet

dockerd

……

Kubernetes Master

IP network

Comware

container

Docker

container1 Docker

container2 Docker

container1 Docker

container2

Network communication of containers that share the network namespace of Comware

An open application in a container that shares the network namespace of Comware uses the

network parameters of Comware, including the interfaces, IP addresses, IP routing table, and port

numbers.

•

For the application to communicate with a host that resides on the same network as the device,

you do not need to configure additional network parameters. The application uses the IP

address of the device to communicate with the host.

•

For the application to communicate with a host that resides on a different network than the

device, you must configure a source IP address for the application. You must also make sure

that a connection is available between the source IP address and the remote host. The

application uses the source IP address to communicate with the remote host.

For example, if you configure the Docker container in Figure 2 to use the same network namespace

as Comware, the system kernel creates a default route and one direct route for each interface in up

state. Because Host A and Port A reside on the same subnet, Host A can use IP address 2.2.2.1 to

communicate with the open application. The similar is true for Host B. Because Host C resides on a

different subnet than the device, Host C must use the source IP address specified for the application

to communicate with the application.

Figure 2 Network diagram for containers that share the network namespace of Comware

Network communication of containers that do not share the network namespace of Comware

For open applications in containers that use a different network namespace than Comware to

communicate with hosts on indirectly connected networks, you must create interface

Virtual-Eth-Group 0. When creating interface Virtual-Eth-Group 0, Comware also creates an open

bridge. The open applications use the bridge to communicate with hosts on indirectly connected

networks.

As shown in Figure 3, after you create interface Virtual-Eth-Group 0 and assign it an IP address, an

open bridge is created. When you create a Docker container that uses a different network

namespace than Comware, Comware performs the following operations:

1. Creates virtual interface Eth 0 for the container.

2. Assigns the interface a free IP address that is on the subnet where Virtual-Eth-Group 0 resides,

for example, X.X.X.1/24, X.X.X.2/24, and X.X.X.3/24.

3. Set the default gateway IP address to the IP address of interface Virtual-Eth-Group 0.

Kernel space

User space

Comware system

Third-party app

Docker container

Routing table:

0.0.0.0/0 vrfif0 source X.X.X.X

2.2.2.0/24 PortA

3.3.3.0/16 PortB

Port A

2.2.2.1/24

Port B

3.3.3.1/24

Host A

2.2.2.2/24

Host C

4.4.4.2/24

Host B

3.3.3.2/24

Device

IP network

The open applications in the containers on the same device belong to the same subnet and can

communicate with each other directly.

When an open application in a container needs to communicate with a host on an indirectly

connected network, the application sends its packets to interface Virtual-Eth-Group 0. The host can

communicate with the open application as long as a network connection is available between the

host and interface Virtual-Eth-Group 0.

The applications in container 1, container 2, and container 3 uses X.X.X.1/24, X.X.X.2/24 and

X.X.X.3/24, respectively, to communicate with Host A, Host B, and Host C.

Figure 3 Network diagram for containers that do not share the network namespace of

Comware

Restrictions and guidelines: Container application

hosting

Comware is developed based on the Linux kernel and uses the x86 architecture. The system used to

compile containers and open applications must use the same CPU architecture as the device for

hosting the containers and open applications.

Run only secure and trustworthy open applications on the device and patch the applications in time.

You cannot reverse engineer open applications and Comware.

If an open application conflicts with a Comware application, the Comware application has higher

priority. For example, if the Comware native FTP server and an FTP server container are available at

the same IP address and port number, the device uses the native FTP server to respond to FTP

clients. The device uses the FTP server in the container only if the native FTP server is disabled.

As a best practice, do not configure open application containers to share the network namespace for

Comware containers. If an open application container shares the network space for Comware

containers, that open application container cannot persist through a Comware system reboot. When

the Comware system reboots, you must create that container again if you need to use it.

To prevent overuse of resources from degrading Comware performance, a system-defined limit is

set on the CPU and memory resources assignable to open application containers. If the CPU or

memory size specified for an open application container exceeds the system-defined limit when you

run it by using the docker run command with the --cpuset-cpus, --cpuset-shared, or

--memory option, the system-defined limit takes effect.

Comware system

Docker

container3

Port A

2.2.2.1/24

Port B

3.3.3.1/24

Host A

2.2.2.2/24

Host B

3.3.3.2/24

Device

Docker

container2

Docker

container1

Virtual-Eth-Group0

X.X.X.X/24

Eth0

X.X.X.1/24 Eth0

X.X.X.2/24 Eth0

X.X.X.3/24

TPA bridge

Host C

4.4.4.2/24

IP network

Container application hosting tasks at a glance

To host container applications, perform the following tasks:

1. Enabling the container feature

2. Deploying Docker containers

3. Configuring network parameters for containers

4. (Optional.) Enabling the kubelet service

5. (Optional.) Setting the virtual disk size

For more information, see "Configuring common container and open application parameters."

6. (Optional.) Backing up container data

For more information, see "Configuring common container and open application parameters."

Enabling the container feature

About this task

To install Docker containers on the device, you must enable the container feature.

Procedure

1. Enter system view.

system-view

2. Enable the container feature.

tpa container enable

By default, the container feature is enabled.

Deploying Docker containers

About deploying Docker containers

The Comware system is integrated with a modified version of the Docker daemon and can parse

standard Linux docker commands. At the Comware CLI, you can use standard Linux docker

commands to create, run, and monitor containers and construct and store images.

To create a Docker container that uses the same network namespace as Comware, use the

--network container:comware option. For example, the docker run --name tftpd

--network container:comware vimagick/tftpd command creates and runs a TFTP

server container that uses the same network namespace as Comware.

To create a Docker container that uses a different network namespace than Comware, use the

--network tpa option. For example, the docker run --name tftpd --network tpa

vimagick/tftpd command creates and runs a TFTP server container that uses a different

network namespace than Comware.

Restrictions and guidelines for Docker container deployment

CAUTION:

Before you execute the

docker load command, use the display memory

command to verify

that the free physical memory of the active MPU is greater th

an the size of the image file to be

loaded. The free physical memory is the value of the Free field in the command output. If the free

physical memory of the active MPU is not greater than the size of the image file to be loaded, the

device might automatically reboot due to insufficient memory during image loading.

The parameter requirements of the docker command are the same as those of the standard Linux

docker command. For more information, execute the docker –-help command. For

convenience, this configuration guide describes the most commonly used parameters in "Appendix

Docker client command reference."

If you modify the Docker daemon configuration file, verify that the modified configuration commands

do not have errors. If the Docker daemon configuration file has errors, the Docker process might not

be able to start up, causing the Comware system unable to start up correctly. If this symptom occurs,

perform the following tasks:

1. Reboot the device and enter the BootWare menu.

2. Delete the erroneous Docker daemon configuration file and reboot the device.

3. If the symptom persists, reboot the device and enter the BootWare menu again.

4. Delete the flash: /third-party directory and reboot the device again.

Reloading the Docker daemon configuration

About this task

When Docker reboots or you reload the Docker daemon configuration, the device automatically

loads the following files to the file system in memory:

•

Docker daemon configuration file flash:/third-party/autocopy/etc/docker/daemon.json.

This file was saved on the device before the device was shipped. To pull images from a private

registry, you must first create the daemon.json file and save it to the

flash:/third-party/autocopy/etc/docker directory.

•

Certificate for Docker registry access flash:/third-party/autocopy/etc/docker/certs.d. To use

HTTPS to access a registry, you must download and save the certificate as file certs.d in the

flash:/third-party/autocopy/etc/docker directory.

For the modified Docker daemon configuration file and the downloaded certificate to take effect, you

must reboot the device or reload the Docker daemon configuration.

Procedure

1. Enter system view.

system-view

2. Reload the Docker daemon configuration.

docker-config reload

Deploying a Docker container

1. Download and import images or pull images from a registry.

2. Enter system view.

system-view

3. Deploy a Docker container.

docker [ params ]

You can execute this command multiple times to deploy more containers.

Configuring network parameters for containers

Container network parameters configuration tasks at a

glance

Containers running in different environments require different network parameters.

•

To configure network parameters for open applications in containers that use the same network

namespace as Comware, perform the following tasks:

 Configuring interface Loopback 0

This task is required if you want to use Docker to pull images or use kubelet to communicate

with the Kubernetes master.

 Specifying a source IP address for open applications

This task is required for the open applications to communicate with indirectly connected

networks. For more information, see "Configuring common container and open application

parameters."

 (Optional.) Reserving port numbers for open client applications

For more information, see "Configuring common container and open application

parameters."

 (Optional.) Reserving port numbers for open server applications

For more information, see "Configuring common container and open application

parameters."

 (Optional.) Preconditioning incoming IP packets

For more information, see "Configuring common container and open application

parameters."

•

To configure network parameters for open applications in containers that use a different

network namespace than Comware, perform the following tasks:

 Configuring interface Loopback 0

This task is required if you want to use Docker to pull images or use kubelet to communicate

with the Kubernetes master.

 Configuring interface Virtual-Eth-Group 0

 (Optional.) Preconditioning incoming IP packets

For more information, see "Configuring common container and open application

parameters."

Configuring interface Loopback 0

About this task

Docker and kubelet use Comware interface Loopback 0 for network access. If the applications to be

deployed need to access the network, you must configure interface Loopback 0.

Procedure

1. Enter system view.

system-view

2. Enter the view of interface Loopback 0.

interface loopback 0

3. Assign an IP address to the interface.

ip address ip-address { mask-length | mask } [ sub ]

By default, the interface does not have an IP address.

For more information about this command, see Layer 3—IP Services Command Reference.

Configuring interface Virtual-Eth-Group 0

About this task

Open applications in containers that do not share the network namespace of Comware uses

interface Virtual-Eth-Group 0 to communicate with indirectly connected networks.

Procedure

1. Enter system view.

system-view

2. Create interface Virtual-Eth-Group 0 and enter its view.

interface virtual-eth-group 0

3. Assign an IP address to the interface.

ip address ip-address { mask-length | mask } [ sub ]

By default, the interface does not have an IP address.

Enabling the kubelet service

About this task

After you enable the kubelet service on the device, the device becomes a Kubernetes node. You can

use the Kubernetes master to orchestrate and manage open applications on the device.

Restrictions and guidelines

The device is installed with kubelet when shipped. The Comware upgrade package contains the

upgrade image for kubelet. When you upgrade the Comware system on the device, kubelet is also

upgraded. You do not need to install or upgrade kubelet separately.

Prerequisites

When you enable the kubelet service, the system automatically synchronize the files listed in Table 1

to the file system in memory. To enable the kubelet service successfully, make sure the files exist in

the specified directory.

Table 1 Files required for enabling the kubelet service

File description Storage location File name

(extension not

allowed)

Kubernetes public

configuration file

flash:/third-party/autocopy/etc/kubernetes

kubeconfig

Kubelet configuration

file

kubeletconfig

Environment variable

file for Kubelet

command line

parameters

kubelet

The following are the sample content of the files. You can modify the files as required.

/* Kubernetes public configuration file flash:/third-party/autocopy/etc/kubernetes/kubeconfig */

apiVersion: v1

clusters:

- cluster:

insecure-skip-tls-verify: true

server: http://192.168.111.62:8080

name: TestCluster

contexts:

- context:

cluster: TestCluster

user: comwarev9

name: Comware

current-context: Comware

kind: Config

preferences: {}

users: []

/* Kubelet configuration file flash:/third-party/autocopy/etc/kubernetes/kubeletconfig */

kind: KubeletConfiguration

apiVersion: kubelet.config.k8s.io/v1beta1

failSwapOn: false

address: 0.0.0.0

port: 10250

/* Environment variable file for kubelet command line parameters:

flash:/third-party/autocopy/etc/kubernetes/kubelet */

KUBELET_ARGS=”--hostname-override 6890-A

--pod-infra-container-image=192.168.111.62:5000/pause:3.1“

Procedure

1. Enter system view.

system-view

2. Enable the kubelet service.

kubelet enable

By default, the kubelet service is disabled.

Container application hosting examples

Example: Deploying a container application that uses the

same network namespace as Comware

Network configuration

As shown in Figure 4, Device A is on the same subnet as Device B but is on a different subnet as

Device C.

Deploy a containerized TFTP server application on Device A. On Device B and Device C, use

192.168.1.64 as the IP address of the TFTP server to upload the configuration files to the TFTP

server.

Figure 4 Network diagram

Analysis

IP address 192.168.1.64 belongs to Device A. For the containerized TFTP server application to use

the same IP address as Device A, you must configure the container to use the same network

namespace as Comware.

Procedure

1. Configure Device A:

# Assign IP addresses to interfaces and configure routes. Make sure the network connections

are available. (Details not shown.)

# Download TFTP server image file tftpd.tar.gz from the host.

<DeviceA> tftp 192.168.1.22 get tftpd.tar.gz

Press CTRL+C to abort.

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

100 2135k 100 2135k 0 0 138k 0 0:00:15 0:00:15 --:--:-- 97686

100 2135k 100 2135k 0 0 137k 0 0:00:15 0:00:15 --:--:-- 137k

# Verify that the image file is downloaded successfully.

<DeviceA> dir *.gz

Directory of flash:

0 -rw- 2186624 Jan 11 2019 16:04:16 tftpd.tar.gz

3710740 KB total (1893144 KB free)

# Load image file tftpd.tar.gz.

<DeviceA> system-view

[DeviceA] docker images

REPOSITORY TAG IMAGE ID CREATED SIZE

comware MPU 44921263afab 18 years ago 33B

[DeviceA] docker load -i tftpd.tar.gz

df64d3292fd6: Loading layer 4.672MB/4.672MB

ebf013859a34: Loading layer 99.84kB/99.84kB

Loaded image ID:

sha256:1ae5a7ba615b2fdbbba1819745f44d253ad6980ad4517d41755e9822e89561fb

[DeviceA] docker images

REPOSITORY TAG IMAGE ID CREATED SIZE

<none> <none> 1ae5a7ba615b 5 weeks ago 4.5MB

LAN

Device A

Device B

TFTP server

TFTP client

192.168.1.33/24

Device C

TFTP client

192.168.2.88/24

MGE0/0/0

192.168.1.64/24

192.168.1.22/24

Host

IP network

comware MPU 44921263afab 18 years ago 33B

# Configure a tag that is used to refer to the TFTP server image.

[DeviceA] docker tag 1ae tftpd:latest

[DeviceA] docker images

REPOSITORY TAG IMAGE ID CREATED SIZE

tftpd latest 1ae5a7ba615b 5 weeks ago 4.5MB

comware MPU 44921263afab 18 years ago 33B

# Create a container named tftpserver that uses the same network namespace as Comware in

the background, and run the TFTP server image in the container.

[DeviceA] docker run -d --name tftpserver --network container:comware tftpd

c773c637fd81d3dfb5453126b3b0bcaf20ab7a8b3e92875c4be69296b8b2928c

[DeviceA] docker ps

CONTAINER ID IMAGE COMMAND

CREATED STATUS

PORTS NAMES

c773c637fd81 tftpd "in.tftpd --verbose " 19 seconds ago Up

18 seconds tftpserver

bd84340b76a1 comware:MPU "/bin/v9.sh" 18 years ago Up

18 years comware

# Specify a source IPv4 address for the application.

[DeviceA] tpa ip source interface m-gigabitethernet 0/0/0

2. On Device B, save the running configuration and upload the configuration file to the TFTP

server on Device A.

<DeviceB> save DeviceB.cfg

The current configuration will be saved to flash:/DeviceB.cfg. Continue? [Y/N]:y

Now saving current configuration to the device.

Saving configuration flash:/DeviceB.cfg.Please wait...

Configuration is saved to device successfully.

<DeviceB> tftp 192.168.1.64 put DeviceB.cfg

Press CTRL+C to abort.

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

100 13137 0 0 100 13137 0 534k --:--:-- --:--:-- --:--:-- 583k

3. On Device C, save the running configuration and upload the configuration file to the TFTP

server on Device A.

<DeviceC> save DeviceC.cfg

The current configuration will be saved to flash:/DeviceC.cfg. Continue? [Y/N]:y

Now saving current configuration to the device.

Saving configuration flash:/DeviceC.cfg.Please wait...

Configuration is saved to device successfully.

<DeviceC> tftp 192.168.1.64 put DeviceC.cfg

Press CTRL+C to abort.

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

100 6120 0 0 100 6120 0 1103 0:00:05 0:00:05 --:--:-- 1111

Verifying the configuration

# Access the CLI of the containerized TFTP server application.

[DeviceA] docker exec -it tftpserver sh

/ #

# Display the routing table.

/ # ip route

default dev vrfif0 scope link src 192.168.1.64

127.0.0.0/8 dev InLoop0 scope link src 127.0.0.1

127.1.1.0/30 dev eth0 scope link src 127.1.1.2

192.168.1.0/24 dev MGE1_0_0_0 scope link src 192.168.1.64

// The command output shows that there is a default route and there are three direct routes. The

source IP address of the default route is 192.168.1.64.

# List files.

/ # ls

bin home mnt run sys usr

dev lib proc sbin tftpboot var

etc media root srv tmp

/ # ls tftpboot/

DeviceB.cfg DeviceC.cfg

/ # exit

[DeviceA]

// Configuration files DeviceB.cfg and DeviceC.cfg are saved in the tftpboot directory.

Example: Deploying a container application (separate

network namespace)

Network configuration

As shown in Figure 5, the Google cAdvisor image file is saved in the registry.

Pull and deploy Google cAdvisor on the device to monitor resource usage on the device. Use Host to

view the resource usage information collected by cAdvisor.

Figure 5 Network diagram

Analysis

For cAdvisor to use a fixed IP address that is not the IP address of the device, you must configure the

container to use a different network namespace than Comware.

Prerequisites

Make sure that network connections are available between the following items:

•

Registry and IP address 1.1.1.1.

LAN

Device

Google cAdvisor

135.1.1.6/24

10.10.10.10/24 Host

3.3.3.3/24

Registry

Loop0

1.1.1.1/32

2.2.2.2/24

Internet

•

Host and IP address 10.10.10.10.

•

Host and IP address 135.1.1.6.

Procedure

# On Host, modify Docker daemon configuration file daemon.json. Set the registry IP address to

2.2.2.2.

{

"insecure-registries":["2.2.2.2"]

}

# On Device, create directory flash:/third-party/autocopy/docker and download file daemon.json

to the directory.

<Device> mkdir flash:/third-party/autocopy/docker/

<Device> tftp 3.3.3.3 get daemon.json flash:/third-party/autocopy/docker/daemon.json

# Reload daemon.json.

<Device> system-view

[Device] docker-config reload

Reloading docker configuration...

Done.

# Assign IP address 1.1.1.1/32 to interface Loopback 0. Device will use Loopback 0 to pull an image.

[Device] interface loopback 0

[Device-LoopBack0] ip address 1.1.1.1 32

[Device-LoopBack0] quit

# Pull image google/cadvisor from the registry.

[Device] docker pull google/cadvisor

# List images.

[Device] docker images

REPOSITORY TAG IMAGE ID CREATED SIZE

google/cadvisor latest 75f88e3ec333 10 months ago 62.2MB

comware MPU 9b5091ba7bd0 17 years ago 33B

# Create a container named cadvisor that uses a different network namespace than Comware in the

background, and run the cAdvisor image in the container.

[Device] docker run -v /:/rootfs:ro -v /var/run:/var/run:ro -v /sys:/sys:ro -v

/var/lib/docker:/var/lib/docker:ro -v /dev/disk:/dev/disk:ro --detach --name cadvisor

--ip 135.1.1.6 --network tpa google/cadvisor

4260ca77cec7b47649db94b9e63da7f57e06dcdb3d1c330707869f3818afcbbb

# List containers.

[Device] docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS

PORTS NAMES

4260ca77cec7 google/cadvisor "/usr/bin/cadvisor -…" 14 seconds ago Up

13 seconds 8080/tcp cadvisor

bd84340b76a1 comware:MPU "/bin/v9.sh" 18 years ago Up

18 years comware

# Create interface Virtual-Eth-Group 0 and assign IP address 135.1.1.1/24 to the interface. Google

cAdvisor will use this interface to communicate with indirectly connected networks.

[Device] interface virtual-eth-group 0

[Device-Virtual-Eth-Group0] ip address 135.1.1.1 24

[Device-Virtual-Eth-Group0] quit

Verifying the configuration

# On Host, launch a Web browser and enter http://135.1.1.6:8080 in the address bar to connect to

cAdvisor. Verify that the monitoring information on cAdvisor is displayed.

Appendix Docker client command reference

Downloading and importing images

CAUTION:

Before you execute the

docker load command, use the display memory

command to verify

that the free physical memory of the active MPU is greater than the size of the image file to be

loaded

. The free physical memory is the value of the Free field in the command output. If the free

physical memory of the active MPU is not

greater than the size of the image file to be loaded, the

device might automatically reboot due to insufficient memory during image loading.

Procedure

1. Export images as a tar archive. For more information, execute the docker save --help and

docker export --help commands.

2. Download the tar archive file to a file system on the device, for example, the flash file system.

3. If the tar archive file is generated by using the docker save command, use the docker

load command to load the images.

4. If the tar archive file is generated by using the docker export command, use the docker

import command to import the images.

For more information about the docker commands, execute the docker load –help and docker

import --help commands.

Examples

# Import the cAdvisor image from file cadvisor.img.tar.gz.

<Sysname> dir *.tar.gz

Directory of flash:

0 -rw- 694482 Jan 03 2019 18:55:02 busybox.tar.gz

1 -rw- 24297962 Jan 13 2019 02:35:51 cadvisor.img.tar.gz

3710740 KB total (1158972 KB free)

<Sysname> system-view

[Sysname] docker load -i cadvisor.img.tar.gz

52a5560f4ca0: Loading layer 5.06MB/5.06MB

f04a25da66bf: Loading layer 31.51MB/31.51MB

f60e27acaccf: Loading layer 26.49MB/26.49MB

Loaded image: google/cadvisor:latest

# List images.

<Sysname> system-view

[Sysname] docker images

REPOSITORY TAG IMAGE ID CREATED SIZE

registry latest d1fd7d86a825 Less than a second

ago 33.3MB

google/cadvisor latest 75f88e3ec333 Less than a second

ago 62.2MB

busybox latest 54511612f1c4 Less than a second

ago 1.13MB

bd84340b76a1 comware:MPU "/bin/v9.sh" 18 years ago Up

18 years comware

Pulling images

Prerequisites

The Docker daemon uses Comware interface Loopback 0 for network access. Make sure that

network connections are available between interface Loopback 0 and the public registry and private

registry.

Pulling images from Docker's public registry

You can use the docker pull command to pull images from Docker's public registry after you

Pulling images from private registries (HTTP)

An HTTP-type private registry is an insecure registry. To pull images from HTTP-type private

registries, you must use the insecure-registries option to specify the insecure registries.

1. Modify file flash:/third-party/autocopy/etc/docker/daemon.json as follows:

<Sysname> more flash:/third-party/autocopy/etc/docker/daemon.json

{

"live-restore": true,

"insecure-registries":["192.168.111.62","test.io:5000"]

}

This example supposes that the IP address of the private registry is 192.168.111.62 and the

default port number is used. test.io:5000 is the domain name and port number of another

image registry.

2. Reboot the device or execute the docker-config reload command to make the

modifications take effect.

Pulling images from private registries (HTTPS)

An HTTPS-type private registry is a secure registry. When you pull images form a secure registry, the

server might use one of the following client authentication modes:

•

No authentication.

You can use the docker pull or docker push command to pull or push images directly.

•

Simple authentication.

You must log in to a registry before you can use the docker pull or docker push

command to pull images from or push images to the registry.

To log in to a registry, execute the docker login command and provide the correct

authentication data.

•

Certificate-based authentication.

To access a private registry that requires certificate-based authentication, you cannot use the

IP address of the server. You must use the server's domain name.

Follow these steps:

a. Contact the service provider or administrator to obtain the server's certificate.

b. Download the server's certificate to the device.

The certificate must be saved in file

flash:/third-party/autocopy/etc/docker/certs.d/server-domain-name:port-number/ca.crt, for

example, flash:/third-party/autocopy/etc/docker/certs.d/img.hpe.com:5000/ca.crt. Because

the flash file system does not support colons (:), the colon must be replaced with an at sign

(@). The actual path is

flash:/third-party/autocopy/etc/docker/certs.d/img.hpe.com@5000/ca.crt.

c. Reboot the device or execute the docker-config reload command to make the

modifications take effect.

d. Execute the docker login command and provide the correct authentication data.

e. Execute the docker pull or docker push command to pull or push images.

Examples

# Pull image busybox from server 192.168.111.62:5000.

<Sysname> system-view

[Sysname] docker pull 192.168.111.62:5000/busybox

Using default tag: latest

latest: Pulling from busybox

Digest: sha256:545e6a6310a27636260920bc07b994a299b6708a1b26910cfefd335fdfb60d2b

Status: Image is up to date for 192.168.111.62:5000/busybox:latest

Page is loading ...

Aruba JG632A Configuration Guide

Aruba JG632A Configuration Guide

Aruba JG632A Configuration Guide

Related papers

Other documents