Edge software management

IBM Edge Computing for Devices relies on geographically distributed autonomous processes to manage the software lifecycle of all edge nodes.

The autonomous processes that handle the edge node software management use the Horizon exchange and Horizon switchboard services to find each other on the internet, without revealing their addresses. After finding each other, the process use the Horizon exchange and Horizon switchboard to negotiate relationships, and then collaborate to manage the edge node software. For more information, see Discovery and Negotiation.

The Horizon software on any host can act as an edge node agent, or as an agbot, or both.

Agbot (agreement bot)

Agbot instances are created centrally for managing each software deployment pattern for IBM Edge Computing for Devices that is published to Horizon exchange. You, or one of your developers, can also run agbot processes on any machine that can access the Horizon exchange and Horizon switchboard.

When an agbot is started and configured to manage a specific software deployment pattern, the agbot registers with Horizon exchange and begins polling for edge nodes that are registered to run the same deployment pattern. When an edge node is discovered, the agbot sends a request to the local agent on that edge node to collaborate on managing the software.

When an agreement is negotiated, the agbot sends the following information to the agent:

• The policy details that are contained in the deployment pattern.
• The list of Horizon services and versions that are included in the deployment pattern.
• Any dependencies between those services.
• The shareability of the services. A service can be set as exclusive, singleton, or multiple.
• Details about each container for each service. These details include the following information:
  • The Docker registry where the container is registered, such as the public DockerHub registry, or a private registry.
  • The registry credentials for private registries.
  • The shell environment details for configuration and customization.
  • The cryptographically signed hashes of the container and its configuration.

The agbot continues to monitor the software deployment pattern in Horizon exchange for any changes, such as whether new versions of Horizon services are published for the pattern. If changes are detected, the agbot again sends requests to each edge node that is registered for the pattern to collaborate on managing the transition to the new software version.

The agbot also periodically checks each of the edge nodes that are registered for the deployment pattern to ensure that any policies for the pattern are enforced. If a policy is not being enforced, the agbot can stop the negotiated agreement. For instance, if the edge node stops sending data or providing heartbeats for an extended duration, the agbot can cancel the agreement.

Edge node agent

An edge node agent is created when the Horizon software package is installed on an edge machine. For more information about installing the software, see Installing Horizon software.

When you later register your edge node with the Horizon exchange, you must provide the following information:

• The Horizon exchange URL.
• The edge node name and the access token for the edge node.
• The software deployment pattern that is to run on the edge node. You need to provide both the organization and pattern name to identify the pattern.

For more information about registration, see Registering your edge machine.

After the edge node is registered, the local agent polls the Horizon switchboard for collaboration requests from remote agbot processes. When the agent is discovered by an agbot for its configured deployment pattern, the agbot sends a request to the edge node agent to negotiate collaboration on software lifecycle management for the edge node. When an agreement is reached, the agbot sends information to the edge node.

The agent pulls the specified Docker containers from the appropriate registries. Then, the agent verifies the container hashes and cryptographic signatures. The agent then starts the containers in reverse dependency order with the specified environment configurations. When the containers are running, the local agent monitors the containers. If any container unexpectedly stops running, the agent relaunches the container to attempt to keep the deployment pattern intact on the edge node.

Horizon service dependencies

Although the Horizon agent works to start and manage the containers in the assigned deployment pattern, dependencies between services must be managed in the service container code. Even though the containers are started in reverse dependency order, Horizon is unable to ensure that service providers are fully started and ready to provide service before the service consumers are started. Consumers must strategically handle the potential slow start of the services that they depend on. Since service providing containers can fail, and become disabled, service consumers must also handle the absence of the services they consume.

The local agent detects when a service crashes, and starts the service with the same network name, on the same Docker private network. A brief downtime occurs during the relaunch process. The consuming service must handle the brief downtime as well, or the consuming service can also fail.

The agent has a limited tolerance for failures. If a container is repeatedly and rapidly crashing, the agent can give up restarting the perpetually failing services, and can cancel the agreement.

Horizon Docker networking

Horizon uses Docker networking features to isolate Docker containers that provide services. This isolation ensures that only authorized consumers can access the containers. Each container is started in reverse dependency order, producers first, then consumers later, on a separate private Docker virtual network. Whenever a service-consuming container is started, the container is attached to the private network for its producer container. Producer containers are only reachable by the consumers whose dependencies on the producer are known to Horizon. Due to how Docker networks are implemented, all containers are reachable from host shells.

If you need to obtain the IP address for any container, you can use the docker inspect <containerID> command to get the assigned IPAddress. You can reach any container from your host shells.

Security and Privacy

Although the edge node agents and deployment pattern agbots can discover each other, the components maintain complete privacy until an agreement for collaboration is formally negotiated. The agent and agbot identities and all communication is encrypted. The software management collaborations are also encrypted. All software that is being managed is cryptographically signed. For more information about the privacy and security aspects of IBM Edge Computing for Devices, see Security and Privacy.