Bee provisioning
Installing and connecting bees to hives
Last updated
Installing and connecting bees to hives
Last updated
Bee provisioning refers to the process of installing and connecting bees to a hive server. It involves creating the topology of connections between bees and their respective hives. There are two types of bee provisioning available in BeeOS: Unmanaged and Managed.
Unmanaged bee provisioning can be done manually by registering each bee separately and then connecting them using authentication keys. This process involves the following steps:
Creating a bee template where data such as the bee's name, description, type, version, and connection roles are specified.
The next step is bee instantiation, where the bee is connected to the hive.
This process is suitable for simple scenarios:
There is a hive with very few bees
Bees must be manually installed without the involvement of containers, Kubernetes or snaps
No remote provisioning of bees is required
Installing a bee that connects remotely to a hive without any prior BeeOS infrastructure (hives or queen bees)
A hive with less functionality is required to adjust its resource consumption (a hive can be compiled so that it does not include various modules in its executable, such as the provisioning module)
However, for complex networks of hives and bees that need to be maintained remotely, managed bee provisioning is recommended.
To provision bees from the hive in a managed way, a configuration of hive and bee templates that reflects the desired deployment of agents must be created. Once the deployment is configured, the provisioning command must be executed, specifying the newly created configuration. The hive will start the provisioning mechanism to install all the bees specified in the template.
Once the deployment is completed, the bees will be connected to the hive and will be ready to receive configuration to start exchanging messages with other bees. The connection keys with the hive are automatically generated, so they do not need to be created manually or registered in the hive.
Provisioning engines refer to the different types of engines used for deploying bees, which can include containers, Kubernetes, or snaps.
When provisioning bees in a managed way, a deploy engine type must be used, which can be integrated into the hive or used by a queen bee with the corresponding engine. Currently, there are two types of engines available, with several other types in development:
Container deployment (currently using Docker, but other engines such as Podman can be added)
Linux snap package manager deployment (planned to be available soon)
Kubernetes deployment using an operator (planned to be available soon)
When provisioning bees in a managed way, there are two options available. Hive provisioning module or using an external bee to remotely provision other bees.
One way to provision bees in the Hive is to use its built-in provisioning module. As shown in the previous figure, this option allows you to integrate the provisioning engine directly into the hive server, which makes it possible to deploy bee agents using the beectl command line, API, or Beekeeper console. This eliminates the need to install an external bee to enable this functionality.
This option allows you to remotely deploy bees. To do so, a provisioning bee (queen bee) must be manually pre-installed on the remote server or device where the bees should be installed. This bee is connected to the Hive and is capable of receiving provisioning orders. By using this method, bees can be deployed and connected to the source Hive in a completely centralized manner.
The figure below shows this type of provisioning:
In fact, when provisioning using the module included in the Hive, an embedded bee within the Hive is used. The Hive has an internal host of bees that allows bees to be embedded in the executable during compilation and creation of the Hive.
The two provisioning modes are not mutually exclusive. They can work together to form a very wide range of options available for managing each type of deployment in the most appropriate way. The following diagram shows a hybrid deployment model that could be configured.
Bee provisioning should not be confused with container management by the Docker client bee. In the latter case, the bee is configured with a set of Docker images to start up and manage. However, in this case, neither bees are instantiated nor connected to the hive server. Instead, the deployed containers are applications whose lifecycle is controlled by the hive through the Docker client bee
The figure below shows the two ways of using container deployment (bees and apps)
