[ English | русский | español | Indonesia | English (United Kingdom) | Deutsch ]
OpenStack-Ansible-Manifest¶
Bei diesem Projekt handelt es sich um ein Projekt Batterien eingeschlossen. Dies bedeutet, dass der Bereitsteller erwarten kann, dass die Bereitstellung aus einem der genannten Feature-Zweige oder -Tags eine OpenStack-Cloud bereitstellen sollte, die für die Produktion erstellt wurde und nach dem erfolgreichen Abschluss der Bereitstellung verfügbar ist.
Projektumfang¶
Bei diesem Projekt handelt es sich um ein Projekt Batterien eingeschlossen. Dies bedeutet, dass der Bereitsteller erwarten kann, dass die Bereitstellung aus einem der genannten Feature-Zweige oder -Tags eine OpenStack-Cloud bereitstellen sollte, die für die Produktion erstellt wurde und nach dem erfolgreichen Abschluss der Bereitstellung verfügbar ist.
Dieses Projekt konzentriert sich jedoch ausschließlich auf den Einsatz von OpenStack und seinen Anforderungen.
Dieses Projekt bootet Hosts nicht PXE. Host-Setup und Lifecycle-Management bleiben dem Deployer vorbehalten. Dieses Projekt erfordert außerdem, dass Bridges innerhalb der Hosts eingerichtet werden, damit die Container für den Netzwerkzugriff eine Verbindung zu einer lokalen Bridge herstellen können. Siehe auch Container networking.
Ansible Verwendung¶
Ansible bietet eine Automatisierungsplattform, um die Bereitstellung von Systemen und Anwendungen zu vereinfachen. Ansible verwaltet Systeme mithilfe von Secure Shell (SSH) anstelle von eindeutigen Protokollen, die Remote-Daemons oder -Agenten erfordern.
Ansible uses playbooks written in the YAML language for orchestration. For more information, see Ansible - Intro to Playbooks.
Ansible ist ein einfaches, aber leistungsstarkes Orchestrierungstool, das ideal für die Bereitstellung von OpenStack-basierten Clouds geeignet ist. Die deklarative Natur von Ansible ermöglicht es dem Deployer, eine gesamte Bereitstellung in eine ziemlich einfache Menge von Anweisungen umzuwandeln.
Rollen innerhalb des Openstack-Ansible-Bereichs werden mit den Best Practices von Ansible erstellt und enthalten Namespace-Variablen, die menschlich verständlich sind. Alle Rollen sind voneinander unabhängig und separat testbar.
Alle Rollen werden als mit Galaxy kompatible Rollen erstellt, auch wenn die angegebene Rolle nicht für die eigenständige Verwendung gedacht ist. Während das Projekt viele integrierte Rollen bietet, kann der Deployer Rollen mithilfe der integrierten Ansible-Funktionen mit externen Pull-down- oder Override-Funktionen versehen. Dies ermöglicht eine extreme Flexibilität für Bereitsteller.
Quellenbasierte Bereitstellungen¶
Wenn das OpenStack-Ansible-Projekt erstellt wurde, war es erforderlich, ein System bereitzustellen, das jeden OpenStack-Upstream-Quellcode überschreiben kann.
Dies bedeutet, dass OpenStack-Dienste und ihre Python-Abhängigkeiten standardmäßig aus Quellcode erstellt und installiert werden, wie er in den OpenStack Git-Repositorys gefunden wird. Erlaubt es den Deployern jedoch, auf ihre eigenen Repositories zu verweisen.
Auf diese Weise können Entwickler auch auf ihren eigenen Code für ihre Arbeit verweisen.
Eine quellbasierte Implementierung für von Python erstellte Teile von OpenStack ist sinnvoll, wenn es um Skalierung geht und Konsistenz über lange Zeiträume hinweg gewünscht wird. Ein Deployer sollte in der Lage sein, dieselbe OpenStack-Version auf jedem Knoten während des Lebenszyklus der Cloud bereitzustellen, selbst wenn einige Komponenten nicht mehr verwendet werden. Durch Bereitstellung eines Repositorys für die Quellen kann die Bereitstellung auch Jahre nach der ersten Bereitstellung wiederhergestellt werden, vorausgesetzt, die zugrunde liegenden Betriebssysteme und Pakete bleiben gleich.
Das bedeutet, dass es nie einen Zeitpunkt gibt, an dem OpenStack-spezifische Pakete, wie sie von den Distributionen bereitgestellt werden, für OpenStack-Dienste verwendet werden. Third-Party-Repositories wie CloudArchive und oder RDO können innerhalb einer gegebenen Bereitstellung zwar immer noch benötigt werden, aber nur um Anwendungsabhängigkeiten zu erfüllen.
Containerisierte Bereitstellungen¶
In diesem Projekt werden Container eingeführt, um Dienste voneinander zu abstrahieren.
Die Verwendung von Containern ermöglicht, dass zusätzliche Abstraktionen von ganzen Anwendungsstapeln alle innerhalb der gleichen physischen Host-Maschinen ausgeführt werden können.
Die containerisierten Anwendungen werden manchmal in einem einzelnen Container gruppiert, in dem sie sinnvoll sind, oder in mehreren Containern basierend auf Anwendungs- und Architekturanforderungen verteilt.
Die Standard-Containerarchitektur wurde so erstellt, dass Skalierbarkeit und hoch verfügbare Bereitstellungen möglich sind.
Die einfache Beschaffenheit von Maschinencontainern ermöglicht es dem Deployer, Container als physische Maschinen zu behandeln. Die gleichen Konzepte gelten für Maschinencontainer und physische Maschinen: Dies ermöglicht es den Bereitstellern, vorhandene operative Toolsets zu verwenden, um Probleme innerhalb einer Bereitstellung zu beheben und eine Anwendung oder einen Service innerhalb des Inventars in einen bekannten Arbeitsstatus zurückzusetzen, ohne einen neuen Kickdown durchführen zu müssen physischer Gastgeber.
Nicht alle Dienste sind containerisiert: Manche sind nicht sinnvoll, wenn sie innerhalb eines Containers ausgeführt werden. Logik muss in Bezug darauf verwendet werden, wie Dienste containerisiert werden. Wenn ihre Anforderungen aufgrund von Systemeinschränkungen (Kernel, Anwendungsreife usw.) nicht erfüllt werden können, wird der Dienst nicht in einem Container ausgeführt.
Beispiel für nicht containerisierte Dienste:
Nova compute (für den direkten Zugriff auf Virtualisierungsgeräte)
Swift-Speicher (für direkten Zugriff auf Laufwerk)
Die Container sind kein Mittel, um ein System zu sichern. Die Container wurden nicht für eventuelle Sicherheitsabsicherungen ausgewählt. Die Maschinencontainer wurden aufgrund ihrer praktischen Verwendbarkeit ausgewählt, um eine einheitlichere OpenStack-Bereitstellung bereitzustellen. Auch wenn die Abstraktionen, die die Container bieten, die allgemeine Einsatzsicherheit verbessern, sind diese potenziellen Vorteile nicht die Absicht der Containerisierung von Services.
