IOx Core Services
IOx Core services make up the basic infrastructure for a microservices ecosystem on a Cisco IOx enabled device. These services are deployed on the device and facilitate a single point of entry and standardized interfaces for other microservices on the device. IOx Core services are packaged as bundle that can be installed and run in an isolated container environment.
IOx Core services are based on the following open source components:
Resgate is a smart API gateway, written in golang, that is a bridge between the App and the services. Functions include fetching resources, forwarding method calls, and passing on events. Resgate provides a North Bound Interface (NBI) gateway.
NATS is an open source, lightweight, high-performance cloud native infrastructure messaging system. It implements a highly scalable and elegant publish-subscribe (pub/sub) distribution model. NATS provides a Message Broker.
An IOx microservice has the following types of consumers:
- Other microservices deployed in the IOx enabled device. These services typically use the Mlib API to invoke other service's capabilities.
- IOx applications. These applications can run in the same fog node as the microservices and can be managed with the IOx application hosting framework (CAF).
Consumer applications use open interfaces, such as RESTful APIs and WebSocket APIs. However, open interface standards typically evolve as new best practices emerge and industries advance. The NBI gateway is intended to shield developers from these changes. The NBI gateway can expose multiple open interfaces northbound, and translate them into microservice interfaces.
The NBI acts as a secure conduit that allows applications and services to interact with each other. While applications use standard REST and WebSockets for consuming Message bus services, communication between applications and services can use the RPC or the PubSub protocol. All RPC and PubSub communication support JSON serialized data to provide language agnostic exchange of data types.
Application and Service Intercommunication Over RPC
NBI provides secure communication for applications and services interactions. Applications use REST and WebSocket while services use RPC and PubSub provided by NATS. NBI also acts as a single interface point for security enforcement. Applications are authenticated before invoking an service API over RPC. A service is authenticated before it becomes part of the microservice ecosystem.
Application and Service Inter Communication Over PubSub
An application is authenticated before it subscribes to a topic that is created by a service or application. A service is authenticated before it becomes part of the micro service ecosystem and starts PubSub.
Using the PubSub paradigm, a service can stream data to Iox applications. In the PubSub paradigm, a publisher does not need to be aware of the consumer of the data.
By default, the IR800 platform comes with “IOxCore” service package embedded as part of the image. Any service that needs to be installed will use this pre-installed platform service.
- IoxCore services (message broker + north bound gateway) are bundled as part of the IR8xx image.
- IOxCore is installed as a Docker service that brings in a set of pre-packaged IOx layers.
- IOxCore services will be not be available until an application or service depends on it. The service will not be shown under the app list API's when no service or App is using it.
- When any App or service depends on the IOxCore, it will be automatically deployed, activated, and sent to running state.
- When an App or service that depends on IOxCore is uninstalled, the IOxCore will be bought to deployed state automatically if no one is using it.
- Clients can optionally upgrade the IOxCore.
- If a persistent disk is formatted, and CAF reboots, the default version of IOxCore will be installed automatically.
- In case of a corruption, the default version of IOxCore will be recovered.
Dependency Management
Any IOx service will depend on the IOxCore platform service. The package.yaml of this service will be something similar to the following:
In general:
- Any service can depend on any other service.
- Any App can depend on any other service.
- Before activating/starting, ensure that the package that it depends on is already activated/started. If not, activation/start of the dependent App or service will fail.
- For example, while activating/starting the GPS app if IOxGPS service is not activated or started, it will fail.
- Dependency checks do not occur in install/deploy stage.
- IOx does not allow stopping or deactivating the container if there are some dependent apps/services in running/activated state.
- For example, you cannot stop/deactivate IOxGPS service when a GPS app that is dependent on IOxGPS is still running. You must stop the GPS app and then IOxGPS service.
Verifying IOxCore Is Up and Running
Services life cycle can be managed using many applications, for example, Fog Director, ioxclient, local manager, and so forth. For simplicity, this document will use ioxclient.
By default, IOxCore services are available on IR8xx platforms, so you do not need to install it seperately.
When a service that depends on IOxCore is installed, IOxCore will automatically activate and be kept in running state.
Check if IOxCore is provided as part of platform image:
After deploying any service that depends on IOxCore, you will see the following output:
Next steps