Docker and Containers

Docker is an open platform application that runs as a program within the host server's operating system. It allows applications to be separated from the infrastructure so that software can be developed quickly and reliably.

Containers are applications that are run within Docker and are loosely isolated giving extra security. Many containers can run simultaneously on a host as they are lightweight and contain all the code and dependencies needed to run the application, thereby removing any potential library dependency issues.

For Infinity VIP, the individual components that comprise system functions operate as containers. For example, VIP server and each of the VIP panels operate as individual containers.

Images are containers that contain all the required code but have yet to be run. It is possible to hold an image in storage without running it.

Software functions that make up an application are referred to as "Services" and are a subset of the container.

Portainer

Portainer is an open-source web application that allows easy management of local Docker containers running on the host server. It operates as a web server application accessed from a web browser, providing a convenient user interface.

It is possible to maintain containers using the command-line interface, but this is often a difficult and complicated task. Portainer abstracts away this complexity to provide an easy-to-use management tool allowing individual control for containers such as start, stop, pause, enable, disable, and delete.

Containers are the fundamental software component of Infinity VIP and provide the feature licensing, matrix-free audio routing functionality, virtual panels, interfaces to third-party systems, and other Telos Alliance products.

Portainer is loaded and executed as part of the Infinity VIP boot sequence and sets up a TCP/IP socket listening to port 9000 on both NET-1 (AoIP) and NET-2 (WAN). This allows local browser access from the Infinity VIP or externally on either the AoIP or the WAN networks.

Portainer is set to automatically start at the end of boot-up as this reduces the possibility of any IP address conflicts until the configuration is complete. When the system has been configured for the first time, each container application can be set to automatically run so that Infinity VIP can start without further configuration.

Setting a Password for Portainer

Before Portainer can be used, the admin password must be set. On first login you will be prompted to create your own password as shown below.

Figure 1 - Setting the admin password for Portainer

Included in the front panel menu is the Telos VIP Setup tool - “Set Portainer Password”. It is used to reset a forgotten Portainer's password.

Figure 2 - Telos VIP portainer password setup

From the Portainer password screen, select "Yes".

Figure 3- Setting the Portainer password

A new, randomly generated password will be created. Be sure to record the password as it will be needed later to log in to Portainer.

Figure 4- Portainer password generator

Accessing Portainer

To access the Portainer from anywhere on the AoIP or WAN networks, open a web browser and enter the Infinity VIP IP address followed by 9000. For example, if the IP address of the Infinity VIP is “10.216.40.2”, enter “10.216.40.2:9000” in the address bar.

After entering the IP address in the browser, log in to Portainer with the user name "admin" and the random eight-character password referenced above.

On the first login of a new installation, select "Get Started" to continue.

Figure 5 - Portainer log in

Once logged in, select the local group.

Figure 6 - Portainer local group

The local group contains all the containers needed to run Infinity VIP. The images and containers can be found by clicking on the “local” keyword highlighted above.

To access updated images, access to the Quay repository is required. Information on Quay can be found here.

Container IP Address

Each container requires a unique IP address so that it can communicate with devices within the host server as well as other devices on the network such as panels, other Telos products, and other AoIP products and services.

From the Portainer home window, click on “local”, then click on “container” to open the Infinity Dashboard application.

Figure 7 - Container IP address

Note that the Infinity Dashboard application in this example is not running. Click on the “Dashboard” name, then click on "Duplicate/Edit".

Figure 8 - Container details

Enter the following information into the Name, Registry, and Image fields:

Figure 9 - Portainer name and registry fields

The advanced container settings will appear. Click on the “Network” tab to change IP addresses, network, and domain names.

Figure 10 - Advanced container settings

Use the "Deploy the container" button when finished. Connect to the Dashboard container using <DashboardContainerIP>:5000.

Creating VIP Containers Manually

Adding a Container

To add a container manually, navigate to the Containers tab and click on the "+Add container" button.

Figure 11 - Adding a container

Enter a name for the container, typically in the format of "vipNN" where "NN" is the container number.

Important! It is possible to enter a container name that is already in use which results in the original container being destroyed and overwritten by the new container. Be sure to choose a unique name for each new container.

Next, change the Registry from "Dockerhub" to "Quay" and select the image.

• intercom:latest = The image used for all VIP panels

• intercom-dashboard:latest = The image used for Dashboard

Figure 12 - Creating the registry and selecting an image

Adding a Volume

Add a volume mount for storing container configurations by navigating to the Volumes tab.

Figure 13 - Adding a volume

Important! The mount for /opt/telos/vipNN must be unique and not used by another container. Otherwise, both containers will try to use the same (and sometimes wrong) configuration stored therein. This location normally uses the Name that was previously entered, for example:

Name: vip23 host: /opt/telos/vip23

Network

Select "telosmacvlan" as the Network, then enter a Hostname for the container (usually the container name to keep things simple).

Figure 14 - Network setup

Environmental Variables

In Advanced Container Settings, click on "Env" then click "Add an environment variable".

Figure 15 - Environmental variables

Fill in the variables as follows:

name	BASEURL	value	.
name	DEVTYPE	value	(see options below)

Possible DEVTYPES for containers using image:quay.io/telosalliance/intercom include:

Devtype Value	Description
vip4	4 Key Virtual Intercom Panel
vip8	8 Key Virtual Intercom Panel
vip16	16 Key Virtual Intercom Panel
vip36	36 Key Virtual Intercom Panel
link8	8 Coded Virtual Infinity Link Gateway
vipserver	Platform Server; handles sending and receiving invites to VIP panels

Capabilities

Navigate to the Capabilities tab, then enable SYS_NICE so that containers can change their process nice values and set real-time scheduling and CPU affinity.

When finished, click on "Deploy the container".

Figure 16 - Capabilities

Starting, Stopping, and Naming Containers

Upon starting for the first time, the management container tool Portainer is the only application that is set to autorun. The applications listed below must be set to run once their network settings have been configured:

• Dashboard: Used to manage both VIP and hardware panels. This container must be running to configure Groups, Partylines, etc.

• Vipserver: Sends invitations to connect to VIP. It also handles authentication from users and must be running for remote users to connect.

• Vipx: Invitations to users are sent to match individual intercom panels. The number of panels shown here may differ from available licenses shown at /license as licenses are only consumed by running panels. It is possible to operate Infinity VIP with just one of these applications or a combination of multiple applications. For example, if an Infinity IP intercom already exists with multiple hardware panels, then Dashboard may be running on another server and will not be required within Infinity VIP. Or, if VIP-server is not required, it may be necessary only to operate Dashboard and Vipx.

Although this flexibility may be useful in some applications, a standard configuration requires all three containers to be set to running. The diagram below shows how Dashboard is changed from “stopped” by selecting it, clicking on “start”.

Figure 17 - Starting and stopping containers

Adding the Beacon Container Manually

The Beacon container is used extensively to send email invitations and during the connection process. This section will only cover setting up the Beacon container. For more information on how to configure the internals of the Beacon server. see the "VIP Beacon and Invitation Server" section.

Figure 18 - Adding the Beacon container

Next, add two volumes - one writeable and one read-only - as shown below in Figure 19:

Figure 19 - Adding volumes

Set the hostname and IP address of the Beacon container as shown below in Figure 20:

Figure 20 - Beacon hostname and IP address

Click the "Deploy the container" button when finished. Connect to the Beacon container using <BeaconContainerIP>.

Container Startup Policy

To adjust whether a container such as Dashboard or ViPX automatically runs, the restart policy must be configured for each container.

Select the relevant container, then click on “duplicate/edit”.

Figure 21 - Editing container details

The "Restart policy" is located at the bottom of the page and offers the following options:

• Never: The container does not automatically restart and must be manually started after the VM has booted. This is the default behavior.

• Always: The container always restarts if it stops. If it is manually stopped, it restarts only when the Docker daemon restarts or when it is manually restarted.

• On failure: The container restarts if it closes due to an error that manifests as a non-zero exit code.

• Unless stopped: Similar to “Always” except that when the container is stopped (manually or otherwise), it is not re-started even after the Docker daemon restarts.

Figure 22 - Container restart policy