A platform for developing cloud-native VNFs
Clone or download
ondrej-fabry Merge pull request #354 from VladoLavor/master
remove unnecessary lock on process Wait()
Latest commit 88f6c17 Nov 7, 2018
Failed to load latest commit information.
.github Add yamllint to our travis-ci runs Aug 22, 2018
agent Print stack trace on agent start/stop timeout Oct 18, 2018
config Satisfy linter Jul 31, 2018
datasync Cleanup code generation Oct 2, 2018
db Merge pull request #350 from VladoLavor/master Nov 7, 2018
docker/dev_cn_infra Rename etcdv3 to etcd Jun 4, 2018
docs removed/updated dead links Oct 2, 2018
examples Merge pull request #344 from VladoLavor/1.6-changelog Oct 2, 2018
health Cleanup code generation Oct 2, 2018
idxmap Use Plugin interface from infra package and remove all references to … Jul 18, 2018
infra Various changes to infra deps Jul 31, 2018
logging Merge pull request #344 from VladoLavor/1.6-changelog Oct 2, 2018
messaging dependency update Nov 2, 2018
processmanager remove unnecessary lock on process Wait() Nov 7, 2018
rpc removed go routine from authenticator Oct 1, 2018
scripts Update check_links.sh Sep 25, 2018
servicelabel Add option to set service label Jul 26, 2018
utils Introducing once.ReturnError Jun 13, 2018
vendor Merge pull request #350 from VladoLavor/master Nov 7, 2018
.gitignore Cleanup code generation Oct 2, 2018
.travis.yml Update .travis Oct 18, 2018
.yamllint.yml Add yamllint to our travis-ci runs Aug 22, 2018
CHANGELOG.md added default resync plugin dependency to etcd options Oct 4, 2018
CONTRIBUTING.md Update CODINGSTYLE and CONTRIBUTING and remove unused steps Jan 30, 2018
Gopkg.lock Merge pull request #350 from VladoLavor/master Nov 7, 2018
Gopkg.toml dependency update Nov 2, 2018
LICENSE.md Update LICENSE.md Jun 20, 2017
Makefile plugin finally renamed to fileDB Oct 16, 2018
README.md removed/updated dead links Oct 2, 2018
doc.go Minor editorial comments Sep 6, 2017



Build Status Coverage Status Go Report Card GoDoc GitHub license

CN-Infra (cloud-native infrastructure) is a Golang platform for building cloud-native microservices. Although it was originally intended for development/implementation of custom management/control plane agents for cloud-native Virtual Network Functions (VNFs), it can be used to develop any microservice.


Each management/control plane app built on top of the CN-Infra platform is basically a set of modules called "plugins" in CN-Infra lingo, where each plugin provides a very specific/focused functionality. Some plugins are provided by the CN-Infra platform itself, some are written by the app's implementors. In other words, the CN-Infra platform itself is implemented as a set of plugins that together provide the platform's functionality, such as logging, health checks, messaging (e.g. Kafka), a common front-end API and back-end connectivity to various KV data stores (Etcd, Cassandra, Redis, ...), and REST and gRPC APIs.

The architecture of the CN-Infra platform is shown in the following figure.


The CN-Infra platform consists of a Agent that provides plugin lifecycle management (initialization and graceful shutdown of plugins) and a set of platform plugins. Note that the figure shows not only CN-Infra plugins that are a part of the CN-Infra platform, but also app plugins that use the platform. CN-Infra platform plugins provide APIs that are consumed by app plugins. App plugins themselves may provide their own APIs consumed by external clients.

The platform is modular and extensible. Plugins supporting new functionality (e.g. another KV store or another message bus) can be easily added to the existing set of CN-Infra platform plugins. Moreover, CN-Infra based apps can be built in layers: a set of app plugins together with CN-Infra plugins can form a new platform providing APIs/services to higher layer apps. This approach was used in the VPP Agent - a management/control agent for VPP based software data planes.,

Extending the code base does not mean that all plugins end up in all apps - app writers can pick and choose only those platform plugins that are required by their app; for example, if an app does not need a KV store, the CN-Infra platform KV data store plugins would not be included in the app. All plugins used in an app are statically linked into the app.

CN-Infra Plugins

A CN-Infra plugin is typically implemented as a library providing the plugin's functionality/APIs wrapped in a plugin wrapper. A CN-Infra library can also be used standalone in 3rd party apps that do not use the CN-Infra platform. The plugin wrapper provides lifecycle management for the plugin component.

Platform plugins in the current CN-Infra release provide functionality in one of the following functional areas:

  • RPC - allows to expose application's API:

    • GRPC - handles GRPC requests and allows app plugins to define their own GRPC services
    • REST - handles HTTP requests and allows app plugins to define their own REST APIs
    • Prometheus - serves Prometheus metrics via HTTP and allows app plugins to register their own collectors
  • Data Stores - provides a common data store API for app plugins (the Data Broker) and back-end clients. The data store related plugins are:

    • Consul - implements key-value plugin providing access to Consul
    • Etcd - implements key-value plugin providing access to Etcd
    • Redis - implements key-value plugin providing access to Redis
    • Casssandra - implements sql plugin providing access to Cassandra
  • Messaging - provides a common API and connectivity to message buses:

    • Kafka - provides access to a Kafka broker (Sarama)
  • Logging:

    • Logrus wrapper - implements logging skeleton using the Logrus library. An app writer can create multiple loggers - for example, each app plugin can have its own logger. Log level for each logger can be controlled individually at run time through the Log Manager REST API.
    • Log Manager - allows the operator to set log level for each logger using a REST API.
  • Health - Self health check mechanism between plugins plus RPCs:

    • StatusCheck - allows to monitor the status of plugins and exposes it via HTTP
    • Probe - callable remotely from K8s
  • Miscellaneous - value-add plugins supporting the operation of a CN-Infra based application:

    • Config - helpers for loading plugin configuration.
    • Datasync - provides data resynchronization after HA events (restart or connectivity restoration after an outage) for data stores, gRPC and REST.
    • IDX Map - reusable thread-safe map with advanced features:
      • multiple subscribers for watching changes in the map
      • secondary indexes
    • ServiceLabel - provides setting and retrieval of a unique identifier for a CN-Infra based app. A cloud app typically needs a unique identifier so that it can differentiated from other instances of the same app or from other apps (e.g. to have its own space in a kv data store).


The following code shows the initialization/start of a simple agent application built on the CN-Infra platform. The code for this example can be found here.

func main() {
	flavor := &rpc.FlavorRPC{}
	agent := core.NewAgent(flavor)

	err := core.EventLoopWithInterrupt(agent, nil)
	if err != nil {

You can run this example code by using pre-build Docker images:

For quick start with the VPP Agent, you can use pre-build Docker images with the Agent and VPP on Dockerhub.

  1. Run ETCD and Kafka on your host (e.g. in Docker using this procedure).

  2. Run cn-infra example simple-agent.

docker pull ligato/dev-cn-infra
docker run -it --name dev-cn-infra --rm ligato/dev-cn-infra


GoDoc can be browsed online.


If you are interested in contributing, please see the contribution guidelines.