This project was created to house edge micro-services that can be easily built, tested, and published to any open horizon management hub.
Open Horizon documentation repository coming soon! For the time being, you can learn more about Open Horizon here.
Before you can publish and use any of the services in this repository, you must first deploy your own Horizon Management Hub. This can be done with one simple command using the deploy-mgmt-hub.sh script located in the devops repository. This will give you with a Management Hub with several services, policies and patterns published in the exchange.
Edge nodes must first be registered with a Management Hub before services can be deployed to them. The agent-install.sh script is a fast and easy way to register an edge node with a Management Hub, more information can be found in the open-horizon/anax repository. Edge nodes can be either a device or a cluster. Open Horizon edge cluster capability helps you manage and deploy workloads from a management hub cluster to remote instances of OpenShift® Container Platform or other Kubernetes-based clusters.
Typically, edge devices have a prescriptive purpose, provide (often limited) compute capabilities, and are located near or at the data source. Currently supported edge device OS and architectures:
- x86_64
- Linux x86_64 devices or virtual machines that run Ubuntu 20.x (focal), Ubuntu 18.x (bionic), Debian 10 (buster), Debian 9 (stretch)
- Red Hat Enterprise Linux® 8.2
- Fedora Workstation 32
- CentOS 8.2
- SuSE 15 SP2
- ppc64le (Horizon Agent version >=2.28)
- Red Hat Enterprise Linux® 7.9
- ARM (32-bit)
- Linux on ARM (32-bit), for example Raspberry Pi, running Raspberry Pi OS buster or stretch
- ARM (64-bit)
- Linux on ARM (64-bit), for example NVIDIA Jetson Nano, TX1, or TX2, running Ubuntu 18.x (bionic)
- Mac
- macOS
If you have a service you would like to contribute to the open-horizon-services project, please create a post on the Matrix chat server open-horizon-examples channel and tag it with #new-edge-service. In your post, please provide a brief description of the service you want to add, the desired name, and a list of the github usernames of each maintainer/contributor you would like added to your new repo(s). Please note, we do have a naming convention where microservices designed to be a building-block and incorporated into a variety of edge solutions, like service-mqtt, are prepended with "service-".
Each service in the open-horizon-services project has a similar structure, and set of files, in an attempt to make each service as easy as possible to build, test, publish, and deploy. See the web-helloworld-python service for an example of the minimum set of files a service should have.
init- mostly used for operator services to create the scaffolding of a new operator, or any form of code generation required to buildbuild- build the containerdev- open a shell in the container for development, with source dir mounted. See web-helloworld-python for an example of how this is donerun- run container locallystop- stop and remove the containeragent-run- deploy the container to your edge node using the agentagent-stop- stop the container running fromagent-runtest- assumes container is running. See web-helloworld-python for one example of how this can be donepush- to docker compliant registrypublish- verify and publish the serviceclean- calls stop and also removes the container imagedistclean- clean as much as possible, e.g., remove all container and all images, and docker network prune, etc.
Each service should at least have a service definition json file that can be used to publish the service to a management hub. See the service.json file of the web-helloworld-python service for an example.
Similar to the instructions above for contributing a microservice, if you want to add a top-level service that is designed to be used as a deployment pattern or policy, we ask you still create a post on the Matrix chat server open-horizon-examples channel and tag it with #new-edge-service, provide a brief description of the service, and include a list of the github usernames of each maintainer/contributor you would like added to your new repository. However, the name of your edge solution should be capitalized, similar to the Achatina (add link when we have it merged) service.
init- mostly used for operator services to create the scaffolding of a new operator, or any form of code generation required to buildbuild- build the containerdev- open a shell in the container for development, with source dir mounted. See web-helloworld-python for an example of how this is donerun- run container locallystop- stop and remove the containeragent-run- deploy the container to your edge node using the agentagent-stop- stop the container running fromagent-runtest- assumes container is running. See web-helloworld-python for one example of how this can be donepush- to docker compliant registrypublish-service- verify and publish the servicepublish-pattern- publish the pattern using the properties defined in thepattern.jsonfileregister-pattern- register an edge node with the published patternclean- calls stop and also removes the container imagedistclean- clean as much as possible, e.g., remove all container and all images, and docker network prune, etc.
Each service designed to be composed as a deployment pattern should have a service definition json file and a deployment pattern json that can be used to publish the service to a management hub. See the service.json and pattern.json file of the Achatina (add link when we have it merged) service for an example.