Red Hat SummitFuse 6 is no longer supported
As of February 2025, Red Hat Fuse 6 is no longer supported. If you are using Fuse 6, please upgrade to Red Hat build of Apache Camel.Kapitel 4. Erste Schritte bei der Bereitstellung
Zusammenfassung
Dieses Kapitel stellt die Fuse Fabric Technologieschicht vor und liefert ein ausführliches Beispiel für die Bereitstellung einer Application in einem Fabric, basierend auf der in Kapitel 3, Erste Schritte beim Entwickeln entwickelten Applikation.
4.1. Skalierbare Bereitstellung mit Fuse Fabric
4.1.1. Warum Fuse Fabric?
Ein einzelner Red Hat JBoss Fuse Container, der an einem Host bereitgestellt wird, liefert eine flexible und leistungsfähige Umgebung für die Bereitstellung Ihrer Applikationen mit Support für Versionierung, Bereitstellung verschiedener Pakettypen (OSGi-Bündel, FAB, WAR), Container-Diensten und so weiter. Wenn Sie jedoch eine auf JBoss Fuse basierende Bereitstellung in großem Rahmen eines Produktes durchführen, bei der mehrere Container auf mehreren Hostes über ein Netzwerk hinweg bereitgestellt werden, so stellen sich Ihnen neue Herausforderungen. Einige der Fähigkeiten, die bei einer Bereitstellung im großen Rahmen benötigt werden, sind:
- Überwachen des Status aller Container im Netzwerk
- Starten und Stoppen von entfernten Containern
- Provisionieren von entfernten Containern, damit diese bestimmte Applikationen ausführen
- Upgrade von Applikationen und Bereitstellen von Patches in einem Live System
- Schneller Start und Provisionierung neuer Container—um zum Beispiel einer höheren Systemauslastung gerecht zu werden
Die Fuse Fabric Technologie-Schicht handhabt diese Art von Herausforderungen in Produktionssystemen in großem Rahmen.
4.1.2. Ein Beispiel Fabric
Abbildung 4.1, »Containers in einem Fabric« zeigt ein Beispiel für eine distribuierte Collection von Containern, die zu einem einzelnen Fabric gehören.
Abbildung 4.1. Containers in einem Fabric
4.1.3. Fabric
Die Fuse Fabric Technologie-Schicht unterstützt die skalierbare Bereitstellung von JBoss Fuse Containern über ein Netzwerk hinweg. Sie ermöglicht eine Vielfalt fortgeschrittener Features, wie etwa entfernte Installation und Provisionierung von Containern, Einführung neuer Versionen von Bibliotheken und Applikationen in Phasen, Lastverteilung und Failover bereitgestellter Endpunkte.
Ein Fabric ist eine Collection von Containern, die sich eine Fabric Registryteilen, wo die Fabric Registry eine replizierte Datenbank ist, die alle mit der Provisionierung und Verwaltung von Containern zusammenhängenden Informationen verwahrt. Ein Fabric soll ein distribuiertes Netzwerk an Containern verwalten, wobei die Container über mehrere Hosts hinweg bereitgestellt werden.
4.1.4. Fabric Ensemble
Bei einem Fabric Ensemble handelt es sich um eine Collection von Fabric Servern, die kollektiv den Status einer Fabric Registry instand halten. Das Fabric Ensemble implementiert eine replizierte Datenbank und verwendet ein Quorum-basiertes Wahlsystem, um sicherzustellen, dass die Daten in der Fabric Registry über alle Container des Fabric hinweg konsistent bleiben. Um Netzwerkaufteilungen in einem Quorum-basierten System zu vermeiden, ist es eine Anforderung, dass die Anzahl der Fabric Server in einem Fabric Ensemble stets eine ungerade Zahl ist.
Die Anzahl von Fabric Servern in einem Fabric ist in der Regel 1, 3 oder 5. Ein Fabric mit nur einem Fabric Server eignet sich nur zum Experimentieren. Ein Live Produktionssystem sollte mindestens 3 oder 5 Fabric Server besitzen, die auf separaten Hosts installiert sind, um Fehlertoleranz zu gewährleisten.
4.1.5. Fabric Server
Ein Fabric Server hat einen Sonderstatus im Fabric, weil er verantwortlich für die Wartung einer Kopie der Fabric Registry ist. In jedem Fabric Server ist ein Registry-Dienst installiert (mit R gekennzeichnet in Abbildung 4.1, »Containers in einem Fabric«). Der Registry-Dienst (basierend auf Apache ZooKeeper) wartet eine Kopie der Registry-Datenbank und liefert einen ZooKeeper Server, mit dem sich reguläre Agents verbinden könne, um Registry-Daten abzurufen.
4.1.6. Fabric Container
Ein Fabric Container kennt alle Speicherorte sämtlicher Fabric Server und kann Registry Daten von jedem Fabric Server im Fabric Ensemble abrufen. Ein Fabric Agent (mit A gekennzeichnet in Abbildung 4.1, »Containers in einem Fabric«) ist in jedem Fabric Container installiert. Der Fabric Agent überwacht die Fabric Registry aktiv und wo eine relevante Änderung an der Registry erfolgt, aktualisiert er deren Container sofort, damit der Container konsistent mit den Registry-Einstellungen bleibt.
4.1.7. Profil
Ein Fabric Profile ist eine abstrakte Bereitstellungseinheit, die alle für die Bereitstellung einer Applikation in einem Fabric Container erforderlichen Daten enthält. Im Kontext von Fabrics werden ausschließlich Profile verwendet. Features oder Bündel, die direkt an Fabric Container bereitgestellt werden, sind kurzlebig.
Wichtig
Das Vorhandensein eines Fabric Agent in einem Container verändert das Entwicklungsmodell komplett und macht es erforderlich, dass Sie ausschließlich Profile als Bereitstellungseinheit verwenden . Obwohl das Bereitstellen eines einzelnen Bündels oder Features (mittels
osgi:install oder features:install) nach wie vor möglich ist, sind diese Änderungen nicht dauerhaft. Sobald Sie den Container neu starten oder dessen Inhalte neu laden, ersetzt der Fabric Agent die vorhandenen Inhalte des Containers durch die für die bereitgestellten Profile festgelegten Inhalte.
