OpenRadiant is a modular platform for enterprise container-native devops. OpenRadiant supports kubernetes and docker APIs on the same infrastructure in a multi-tenant setting. It provides the ability to customize your deployment options in order to select the components to deploy from among Kubernetes, Mesos, and Swarm. Currently it supports Flannel for networking. Soon other networking options will be available to select from.
Features of the OpenRadiant platform include:
- Kubernetes
- Swarm (original, not "swarm mode" introduced in Docker 1.12)
- Mesos
- Multi-tenancy - with or without Bring-Your-Own-IPv4
- Multi-sharding
- HA control plane in each shard
- Ansible-based create/update/destroy tooling
- Support for a variety of sources of authentication
- Control plane secured by TLS
- Support for a variety of Software-Defined-Network technologies
- Live container crawling
OpenRadiant is a work in progress. The above features are not yet available in all combinations.
- Architecture Overview
- Tiny Example
- Ansible Principles
- The container images
- The installer machine
- Installing OpenRadiant
- Code of Conduct
- Contributing to the project
- Maintainers
- Communication
- Proxy documentation
- Mesos clues
- Live Container crawling
- Learn concepts and commands
- License
- Issues
OpenRadiant is software that you can subset and/or extend to produce software that you use to operate an enterprise container-native devops service.
One operating instantiation of the full platform is called an environment, and it contains one or more shards that operate independently of each other. Each shard provides Kubernetes, Swarm, and/or Mesos service --- you can pick the subset you want, subject to reasonableness constraints. There is an outer control plane with a proxy API server that implements the Kubernetes and Swarm APIs --- with appropriate restrictions and extensions --- by appropriately transforming each RPC and dispatching it to the appropriate shard.
You can subset OpenRadiant so that it creates just one shard. You can subset OpenRadiant to omit API proxy if you are not interested in multi-sharding nor the conveniences it supplies for multi-tenancy.
In a shard there are worker nodes and control plane nodes. The Kubernetes and Swarm workload is dispatched to the worker nodes. The control plane nodes run the Kubernetes, Swarm, and/or Mesos control planes in an HA configuration. We use Mesos to coordinate resource allocation decisions between Kubernetes and Swarm.
OpenRadiant includes Ansible-based installation technology to instantiate an OpenRadiant environment. An installer machine acts as Ansible controller to install OpenRadiant in a target environment. The installation is parameterized by some Ansible variables files that describe the desired target environment.
OpenRadiant deploys Kubernetes, Swarm, and Mesos in containers. You can choose whatever version of each that you want. Your configure your choice of images and tags. See the doc about the relevant configuration variables and where to put your settings for those variables.
The Ansible playbooks strive to meet the Ansible ideal of achieving a prescribed desired state, and can thus be used to update as well as install. However, there are limits to the space of initial states with which these playbooks can cope.
See the architecture doc for more details.
The structure of the Ansible playbooks and roles, and the related conventions for how environments and shards are organized and how they are described by files, are important parts of OpenRadiant's modularity. This includes the inventory contracts that establish the orthogonality between (a) how machines are provisioned and (b) how software is installed on them. This also includes the concept of networking plugins, the convention for where temporary and not-temporary files are kept on the installer machine(s), and the considerations for deploying in a context where external repositories can not be reached. See the Ansible doc for details.
Following are instructions on how to create a usable installer machine. In the near future we hope to also provide a Docker image of a usable installer machine.
All the controller machine really needs is to have a copy of OpenRadiant and be able to run Ansible commands using that. The following shows ways to accomplish these using Linux shell commands. For other operating systems you could do something analogous.
The controller machine must have git installed.
Checkout this project along with all its submodules:
git clone --recursive https://github.com/containercafe/containercafe.git
cd openradiantThe controller machine must have Ansible installed, including its
netaddr module. See
our Ansible doc
for details on Ansible versions. One way to get these two installed
is to use our requirements.txt file, as follows.
pip install -r requirements.txtIn order to use that method, the controller machine must have Python's
pip installed. One way to accomplish that is to install the
python-pip package using your operating system's package manager.
Another way is to use Python's easy_install to install pip.
Another way to get the netaddr module is to install python-netaddr
using the operating system's package manager.
If the installer machine is running MacOS 10 then it needs to have
done brew install gnu-tar, for mysterious reasons.
To create/update an OpenRadiant environment, invoke the
ansible/env-basics.yml playbook. This will create the certificates
and keys that are common throughout the environment, and deploy the
API proxy. Following is an example invocation.
cd ansible
ansible-playbook -v env-basics.yml -e env_name==${env_kind}-${env_loc} -e envs=${envs}To create/update an OpenRadiant shard, invoke the ansible/shard.yml
playbook. Following is an example invocation.
cd ansible
ansible-playbook -v shard.yml -e cluster_name=${shard_name} -e envs=${envs} -e network_kind=flannelThe shard name, AKA cluster name, is explained in
the inventory contract doc
and this variable must be defined in the Ansible invocation. Two
other variables must also be defined, as mentioned in that document:
envs and network_kind.
See also the deployment doc.
It is essentially an agentless system crawler that offers a native and seamless framework for operational visibility and analytics. It makes use of virtualization and containerization abstractions together with introspection techniques to provide complete visibility into running entities like containers without modifying, instrumenting, or accessing the end user context.
This is an opensource technology. For details visit agentless-system-crawler. For how to use crawler in OpenRadiant environment, see link
Participation in the OpenRadiant community is governed by the OpenRadiant Code of Conduct
We welcome contributions to the OpenRadiant Project in many forms. There's always plenty to do! Full details of how to contribute to this project are documented in the CONTRIBUTING.md file.
The project's maintainers: are responsible for reviewing and merging all pull requests and they guide the over-all technical direction of the project.
We use [TODO] OpenRadiant Slack for communication between developers.
Browse TBD to learn more. Here are some topics you may be interested in:
TBD
Copyright 2015-2016 IBM Corporation
Licensed under the Apache License, Version 2.0 (the "License").
Unless required by applicable law or agreed to in writing, software distributed under the license is distributed on an "as is" basis, without warranties or conditions of any kind, either express or implied. See the license for the specific language governing permissions and limitations under the license.
Report bugs, ask questions and request features here on GitHub.