Depending on your requirements, there may be different scenarios on how to use domains.
Both scenarios can be realized with a domain. Every node instance in both scenario contexts can be managed from an arbitrary Bridge installation, which is member of the domain.
As previously mentioned, a domain is an aggregation of several node instances.
You need a Bridge installation on each node instance that will be included in the domain. A Bridge can manage as many node instances of a domain as you want respectively what makes sense from an organizational point of view. There are no technical limitations on that.
User and group access rights are defined at domain level and are valid for each node instance that belongs to the same domain. Each modification is always distributed to all members of the domain.
The example below shows the administration view of the domain E2E_Education with the user admin logged in. This domain has three node instances called e2ebridge.e2e.ch, e2ebridge2.e2e.ch, and e2ebridge3.e2e.ch, which are technically independent from each other. This means they can run different deployed services. You can manage each service of each node instance in the domain from any Bridge installation (in this example, the administration console of the Bridge running on the node instance e2ebridge.e2e.ch is opened in the browser).
The advantages of domains are summarized as follows.
Keep the following in mind, if you are using Bridge domains:
For robust setups in productive environments that should have low dependencies between the systems, you should use server domains only with special care. We recommend to use it only for proxy requirements.
After installation, the Bridge is in an initial state called stand-alone, which also means that the node instance is not included in a domain, yet. You have two possibilities:
That way, you may setup your domain depending on your organizational requirements.
You can remove a node instance from a domain at any time by using the corresponding Remove function.
If there is only one node instance left in a domain, the Bridge installation can be converted back to a stand-alone installation. The domain and all users and groups of the domain will be removed.
For more details, refer to Managing a Bridge Domain.
Groups can be added or removed to/from a domain. User and group access rights are defined at domain level and are valid for each node instance that belongs to the same domain.
Groups are based on three roles:
Role | Description |
---|---|
ADMIN | Users belonging to a group with this role may invoke any function of the Bridge. |
MODELER | This role enables a user to perform the most important actions, but limits access to certain features. For instance, a user belonging to such a group may only start, stop, or replace a service, if it was deployed by a member of the same group. |
USER | Only read-only actions may be invoked when having this group role, except that the user may change his user name and password. |
For more details, refer to Managing Groups.
Users are defined at domain level and can be added or removed to/from a domain.
Installing the Bridge creates a predefined Bridge administration user with user id admin. You had to define a password for this user during the installation process. The admin user enables you to perform all necessary actions to maintain node instances, composite services, groups, users, and the Bridge itself.
To provide a higher granularity and address security issues for accessing features of the Bridge, you may add or remove users from/to groups of a domain.
Depending on the user's membership to a group, he is allowed to invoke functions like starting, stopping, replacing, or deleting services.
Users are defined at domain level. Mutations of users are replicated to each node instance that belongs to the same domain.
For more details, refer to Managing Users.