此内容没有您所选择的语言版本。
Chapter 4. Getting Started with Deploying
Abstract
This chapter introduces the Fuse Fabric technology layer and provides a detailed example of how to deploy an application in a fabric, based on the application developed in Chapter 3, Getting Started with Developing.
4.1. Scalable Deployment with Fuse Fabric
Why Fuse Fabric?
A single Red Hat JBoss Fuse container deployed on one host provides a flexible and sophisticated environment for deploying your applications, with support for versioning, deployment of various package types (OSGi bundle, FAB, WAR), container services and so on. But when you start to roll out a large-scale deployment of a product based on JBoss Fuse, where multiple containers are deployed on multiple hosts across a network, you are faced with an entire new set of challenges. Some of the capabilities typically needed for managing a large-scale deployment are:
- Monitoring the state of all the containers in the network
- Starting and stopping remote containers
- Provisioning remote containers to run particular applications
- Upgrading applications and rolling out patches in a live system
- Starting up and provisioning new containers quickly—for example, to cope with an increased load on the system
The Fuse Fabric technology layer handles these kinds of challenges in a large-scale production system.
A sample fabric
Figure 4.1, “Containers in a Fabric” shows an example of a distributed collection of containers that belong to a single fabric.
Figure 4.1. Containers in a Fabric
Fabric
The Fuse Fabric technology layer supports the scalable deployment of JBoss Fuse containers across a network. It enables a variety of advanced features, such as remote installation and provisioning of containers; phased rollout of new versions of libraries and applications; load-balancing and failover of deployed endpoints.
A fabric is a collection of containers that share a fabric registry, where the fabric registry is a replicated database that stores all information related to provisioning and managing the containers. A fabric is intended to manage a distributed network of containers, where the containers are deployed across multiple hosts.
Fabric Ensemble
A Fabric Ensemble is a collection of Fabric Servers that collectively maintain the state of the fabric registry. The Fabric Ensemble implements a replicated database and uses a quorum-based voting system to ensure that data in the fabric registry remains consistent across all of the fabric's containers. To guard against network splits in a quorum-based system, it is a requirement that the number of Fabric Servers in a Fabric Ensemble is always an odd number.
The number of Fabric Servers in a fabric is typically 1, 3, or 5. A fabric with just one Fabric Server is suitable for experimentation only. A live production system should have at least 3 or 5 Fabric Servers, installed on separate hosts, to provide fault tolerance.
Fabric Server
A Fabric Server has a special status in the fabric, because it is responsible for maintaining a replica of the fabric registry. In each Fabric Server, a registry service is installed (labeled R in Figure 4.1, “Containers in a Fabric”). The registry service (based on Apache ZooKeeper) maintains a replica of the registry database and provides a ZooKeeper server, which ordinary agents can connect to in order to retrieve registry data.
Fabric Container
A Fabric Container is aware of the locations of all of the Fabric Servers, and it can retrieve registry data from any Fabric Server in the Fabric Ensemble. A Fabric Agent (labeled A in Figure 4.1, “Containers in a Fabric”) is installed in each Fabric Container. The Fabric Agent actively monitors the fabric registry, and whenever a relevant modification is made to the registry, it immediately updates its container to keep the container consistent with the registry settings.
Profile
A Fabric profile is an abstract unit of deployment, which is capable of holding all of the data required for deploying an application into a Fabric Container. Profiles are used exclusively in the context of fabrics. Features or bundles deployed directly to Fabric Containers are short lived.
Important
The presence of a Fabric Agent in a container completely changes the deployment model, requiring you to use profiles exclusively as the unit of deployment. Although it is still possible to deploy an individual bundle or feature (using
osgi:install or features:install, respectively), these modifications are impermanent. As soon as you restart the container or refresh its contents, the Fabric Agent replaces the container's existing contents with whatever is specified by the deployed profiles.
