Institut für Architektur von Anwendungssystemen Universität Stuttgart Universitätsstraße 38 D–70569 Stuttgart Masterarbeit Entwicklung eines Multiagentensystems für das dezentrale Deployment von Softwarekomponenten Dominik Wagner Studiengang: Softwaretechnik Prüfer/in: Prof. Dr. Dr. h.c. Frank Leymann Betreuer/in: Dr. Uwe Breitenbücher Miles Stötzner, M.Sc. Beginn am: 8. März 2022 Beendet am: 30. September 2022 Kurzfassung Moderne Anwendungen bestehen häufig aus verschiedenen Komponenten, welche auf unterschiedli- chen Cloud Plattformen, Internet of Things oder Edge-Geräte und On-Premises Infrastrukturen ausgeführt werden. Weiterhin können Teile dieser Infrastruktur von verschiedenen Organisationen betrieben werden, die aufgrund von Compliance-Regeln und Sicherheitsbedenken oft keinen Zugriff auf Schnittstellen oder Anmeldedaten untereinander freigeben können. Weitere Einschränkungen entstehen durch Sicherheitsbeschränkungen von Private Clouds und der Netzwerkarchitektur, in der sich viele IoT-Geräte befinden, da diese oft keine eingehenden Verbindungen erlauben. Manuelle Softwaredeployments in diesen komplexen Umgebungen sind fehleranfällig, zeitaufwendig und erfordern viel Expertise. Aus diesem Grund wird in dieser Arbeit ein dezentralisiertes auf agentenba- siertes Konzept für automatisierte Deployments in verteilte und heterogene Umgebungen vorgestellt. In diesem Konzept wird die Anwendungstopologie mit TOSCA modelliert und anschließend aufgeteilt. Die einzelnen Teile werden jeweils einem Agenten zugeordnet, der das Deployment teilautonom ausführt. Es werden dabei mehrere Ansätze entwickelt und verglichen, um die Topologie so aufzuteilen, dass einzelne Agenten nur Zugriff auf den für sie relevanten Teil des Modells erhalten. Das beschriebene Konzept ermöglicht durch die Agenten ein organisationsübergreifendes Deployment ohne zentralen Zugang zu allen beteiligten Netzwerken und Infrastrukturen. Um die Koordination und den Informationsaustausch zwischen den Agenten zu ermöglichen, wird eine MQTT-basierte Kommunikationsarchitektur präsentiert, welche auch in Umgebungen mit Sicherheitsbeschränkungen, ohne eingehende Verbindungen funktioniert. Zusätzlich wurde in dieser Arbeit die Kommunikationsarchitektur um ein Sicherheitskonzept erweitert, welches den Schaden, durch eine Kompromittierung von einzelnen Agenten, einschränkt. Dabei lässt sich genau kontrollieren, welcher Agent auf welche Informationen eines anderen Agenten Zugriff hat. Der Lebenszyklus einer Anwendung umfasst nicht nur das Deployment, sondern auch die Entwicklung und Änderungen während der Lebenszeit der Anwendung. Deshalb wird in dieser Arbeit ein GitOps-basierten Workflow präsentiert, der die Zusammenarbeit von verschiedenen Organisationen an einer Anwendung erleichtert. Dieser Workflow erlaubt es, Änderungen einem Review zu unterziehen und diese automatisiert auf ein Deployment anzuwenden. Mit dieser Arbeit ermöglichen wir die Entwicklung und das Deployment von organisationsübergreifenden Multicloud- und IoT-Anwendungen in heterogenen Umgebungen mit verteilten Agenten. 3 Abstract Modern applications often consist of multiple components running on various cloud platforms, Internet of things or edge devices, and on-premises infrastructures. Furthermore, parts of this infrastructure may be operated by different organizations, which often cannot grant access to interfaces or credentials among themselves due to compliance rules and security concerns. Further constraints arise from security restrictions of private clouds and the architecture of the networks in which many IoT devices reside, as these often do not allow inbound connections. Manual software deployments in these complex environments are error-prone, time-consuming, and require a great deal of technical expertise. This thesis therefore presents a decentralized agent-based concept for automated software deployments to distributed and heterogeneous environments. In this concept, the application topology is modeled using TOSCA and subsequently partitioned into subgraphs. The individual parts are each assigned to an agent that performs the deployment semi-autonomously. Several approaches are presented and compared to split the topology in such a way that individual agents only have access to the part of the model that is relevant to them. The described concept enables a cross-organizational deployment based on agents without central access to all involved networks and systems. To enable coordination and information exchange between the agents, an MQTT-based communication architecture is presented. This architecture works in environments that do not allow inbound connections. In addition, a security extension to the communication architecture is presented that limits the damage caused by the compromise of individual agents. With this extension, the flow of information between the agents can be controlled via a rule set. The lifecycle of an application includes not only the deployment but also the development and changes during the lifetime of the application. Therefore, this work presents a GitOps-based workflow that facilitates collaboration between different organizations on an application. This workflow allows reviewing changes and applying them automatically to a deployment. With this thesis, we enable the development and deployment of multi-cloud and IoT applications across organizations in heterogeneous environments with distributed agents. 5 Inhaltsverzeichnis 1 Einleitung 15 1.1 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2 Grundlagen 19 2.1 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Topology and Orchestration Specification for Cloud Applications (TOSCA) . . 21 2.3 Message Queuing Telemetry Transport (MQTT) Protokoll . . . . . . . . . . . . 23 2.4 GitOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3 Konzept für die Entwicklung eines Multiagentensystems 37 3.1 Integration von Agenten in TOSCA Modelle . . . . . . . . . . . . . . . . . . . 38 3.2 Generierung von Modell-Subgraphen . . . . . . . . . . . . . . . . . . . . . . . 40 3.3 Kommunikationsarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.4 Agentenbasierte Skalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.5 GitOps mit TOSCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4 Implementierung des Prototyps 65 4.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2 Anwendungsszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5 Zusammenfassung und Ausblick 71 Literaturverzeichnis 73 7 Abbildungsverzeichnis 2.1 TOSCA Beispiel einer Webanwendung . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 GitOps Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1 Beispiel für die Repräsentation von Agenten in einem Service Template . . . . . 41 3.2 Beispiel für ein Proxy Replacement Subgraph . . . . . . . . . . . . . . . . . . . 44 3.3 Beispiel für ein Reduced Proxy Subgraph . . . . . . . . . . . . . . . . . . . . . 45 3.4 Beispiel für ein Total Separated Subgraph . . . . . . . . . . . . . . . . . . . . . 46 3.5 Beispiel für ein Total Separated Subgraph with Network . . . . . . . . . . . . . 47 3.6 Kommunikationsbeispiel für mehrere Agenten . . . . . . . . . . . . . . . . . . . 54 3.7 Beispiel für den netzwerkbasierten Zugriff auf ein Attribute . . . . . . . . . . . . 57 3.8 Beispiel für Skalierung von Replica Agenten . . . . . . . . . . . . . . . . . . . . 60 3.9 GitOps-basierter Workflow für TOSCA-basierte Deployments . . . . . . . . . . 63 4.1 Architekturübersicht des Prototyps . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2 Anwendungsszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 9 Tabellenverzeichnis 3.1 Auswertung der Modellierungsansätze . . . . . . . . . . . . . . . . . . . . . . . 52 11 Abkürzungsverzeichnis ACL Access Control List. 57 API Application Programming Interface. 66 CSAR Cloud Service Archive. 22 EDMM Essential Deployment Meta Model. 28 IoT Internet of Things. 15 MQTT Message Queuing Telemetry Transport. 19 NAT Network Address Translation. 16 PRS Proxy Replacement Subgraph. 43 RPS Reduced Proxy Subgraph. 44 SaaS Software-as-a-Service. 39 TOSCA Topology and Orchestration Specification for Cloud Applications. 15 TSS Total Separated Subgraph. 46 TSSN Total Separated Subgraph with Network. 47 VM Virtuelle Maschine. 21 13 1 Einleitung Konzepte wie Internet of Things (IoT), Edge oder Cloud Computing verändern nicht nur wie Software entwickelt, verteilt und betrieben wird, sondern auch das tägliche Leben der Nutzer [AIM10]. Diese Technologien finden sich in vielen Bereichen des Lebens wieder und umfassen unter anderem Smart-Home-Geräte, Connected Cars, intelligente Strom- und Verkehrsnetze oder industrielle Prozesskontrolle [Cis20; SY16]. Um die genannten Beispiele umzusetzen müssen Anwendungen entwickelt und provisioniert werden, welche die Vorteile von IoT, Edge Computing und Cloud Computing miteinander kombinieren. Deshalb bestehen viele Anwendungssysteme aus verschiedenen Komponenten, die auf unterschied- lichsten Geräten und Plattformen betrieben werden, diese reichen von kleinen IoT-Geräten bis zu großen Cloud-Rechenzentren. Dabei können verschiedene Teile dieser Infrastruktur zu unterschied- lichen Organisationen gehören. Diese Heterogenität in Kombination mit neuen Softwareentwicklungsparadigmen wie GitOps stellt große Herausforderungen an Softwaredeployment, Wartung und Betrieb. Erschwerend kommt hinzu, dass unterschiedliche Geräte und Plattformen diverse Protokolle, Schnittstellen und Standards zum Softwaredeployment und Management verwenden [MCRG15]. Die unterschiedlichen Komponenten des Anwendungssystems können weiterhin lokale und über Netzwerk erreichbare Abhängigkeiten aufweisen [BCS18]. Manche Softwarekomponenten benötigen zum Beispiel eine Ausführungsum- gebung wie Java oder eine Datenbank auf einem anderen Gerät. Manuelle Softwaredeployments erfordern daher viel Expertise, sind zeitaufwendig und fehleranfällig [BBK+13; OGP03]. Deshalb kann eine Orchestrierung und Automatisierung des Deployments helfen, Fehler zu vermeiden und Kosten zu sparen [KBL+19]. Eine Orchestrierung bedeutet in diesem Kontext, das Koordinieren und Automatisieren von allen Schritten und Prozessen, die für ein Deployment einer Anwendung bestehend aus mehreren Kom- ponenten in heterogene Umgebungen notwendig sind [OAS20a]. Um das zu ermöglichen, können solche komplexen Multicloud- und IoT-Anwendungen mithilfe der „Topology and Orchestration Specification for Cloud Applications“ (TOSCA) [OAS20b] in Form eines Graphen modelliert werden. Die Komponenten der Anwendung werden als Knoten und die Abhängigkeiten sowie die Verbindungen als Kanten modelliert. Der Graph wird dann einem deklarativen und portablen Modell gespeichert [BSW14; OAS20b]. Alle zum Deployment benötigten Skripte, Binärdateien und andere Ressourcen lassen sich zusammen mit dem deklarativen Modell in einem Archiv kombinieren. Ein Orchestrator kann anhand des Modells bestimmen, welche Aufgaben für ein erfolgreiches Deployment ausgeführt werden müssen [BBK+14]. Um dieses Deployment auszuführen, gibt es verschiedene Konzepte. Ein zentraler Orchestrator verbindet sich mit allen beteiligten Ressourcen wie IoT-Geräte, virtuelle Server oder Cloud Plattformen und führt die notwendigen Aufgaben für das Deployment aus [KBL+19]. Dazu werden zum Beispiel Skripte ausgeführt oder Schnittstellen zur Kontrolle von Cloud-Ressourcen genutzt [KBL+19; WBK+20]. In einem dezentralen Deployment werden auf allen beteiligten Ressourcen Agenten installiert [KBL+19]. Die Agenten holen sich die Aufgaben, die für das Deployment notwendig sind, von einem zentralen Manager und führen 15 1 Einleitung diese auf der Ressource aus, auf der sie installiert sind. Ein zentraler Orchestrator ist einfacher zu konfigurieren, weniger komplex und es müssen keine Agenten vorinstalliert werden. Eine Lösung basierend auf einem zentralen Orchestrator kann aber für ein heterogenes organisationsübergreifen- des Multicloud- und IoT-Deployment aus mehreren Gründen nicht eingesetzt werden [KBL+19; WBK+20]. Einerseits wird eine Verbindung von einem zentralen Orchestrator zu allen Geräten und Ressourcen benötigt, was aber oft nicht möglich ist [KBL+19]. Ressourcen, welche sich in Private Clouds oder IoT Netzwerken befinden, können häufig aufgrund von Sicherheitsmaßnahmen wie Firewalls oder der Netzwerkarchitektur nicht von außerhalb angesprochen werden [KBL+19; LS18]. Insbesondere Smart-Home-Anwendungen, die über Heimnetzwerke kommunizieren, sind durch die Network Address Translation (NAT) in Routern nicht direkt erreichbar [FSK05; HP11]. Auch außerhalb von Heimnetzwerken gibt es Einschränkungen in der Konnektivität von IoT-Geräten. Mobile Geräte haben zum Beispiel oft eine unzuverlässige Verbindung und eine begrenzte Stromversorgung [VPM+21]. Andererseits benötigt ein zentraler Orchestrator Zugang zu der internen Infrastruktur und zu Anmeldeinformationen von Cloud Plattformen aller beteiligter Organisationen. Aufgrund von Sicherheitsbedenken oder Compliance-Regeln kann dieser Zugang oft nicht gewährt werden. Um diese Problematiken zu lösen, wird in dieser Masterarbeit ein dezentralisiertes Deploymentkon- zept bestehend aus kooperierenden Agenten präsentiert, welche eigenständig Teile des Deployments ausführen können. In diesem dezentralen Ansatz wird eine Agentensoftware auf jeder teilnehmenden Ressource installiert. Die einzelnen Instanzen der Agentensoftware kommunizieren über eine Kom- munikationsarchitektur die auf einen eventbasierten Message Broker basiert. Ein Message Broker ist eine Komponente, die verteilten Anwendungen das Austauschen von Nachrichten ermöglicht [LPB+15]. Das hat den Vorteil, dass die lokal installierten Agenten nur eine Verbindung aus ihrem Netzwerk heraus zu dem Message Broker aufbauen müssen. Der Message Broker ermöglicht so Kommunikation zwischen den Agenten trotz Sicherheitsbeschränkungen, welche eingehende Verbindungen blockieren [KBL+19]. Auch erlaubt ein eventbasiertes asynchrones Kommunika- tionsmodell bei sporadisch vorhandener Internetverbindung zu kommunizieren, da Nachrichten während Unterbrechungen vom Broker gespeichert und später übertragen werden. Die in dieser Arbeit konzipierten Agenten erlauben es weiterhin teilautonome und asynchrone Deployments auszuführen. Ein Agent kann alle Komponenten einer Software, die lokal provisio- niert werden sollen, anhand des TOSCA Modells bestimmen und anschließend die notwendigen Operationen für das Deployment weitgehend autark ausführen. Kommunikation ist dabei nur für die Koordination der Agenten untereinander notwendig. Das reduziert die Netzwerknutzung im Vergleich mit dem zentralisierten Deploymentkonzept, da nicht jede einzelne Operation über das Netzwerk gesteuert werden muss. Durch das dezentrale Konzept können unabhängige Teile des TOSCA Modells lokal autonom provisioniert werden. Diese Autonomie erlaubt einen geringeren Stromverbrauch, da Datenübertragungen per Funk mehr Energie benötigen können als lokale autonome Datenverarbeitung [PK00]. Darüber hinaus ermöglicht das in dieser Arbeit beschriebene Konzept ein organisationsübergrei- fendes Deployment, ohne dass die beteiligten Organisationen Anmeldedaten offenlegen müssen. Es entfällt auch die Anforderung, einen externen Zugang zu internen Schnittstellen oder interner Infrastruktur für einen zentralen Orchestrator bereitzustellen. Geräte und Instanzen melden sich durch die Agenten nach dem Start bei dem Message Broker und werden nicht von einem zentralen Orchestrator instantiiert oder gestartet. Die beteiligten Organisationen behalten die Kontrolle über 16 ihre interne Infrastruktur und sind eigenständig für das Starten von Ressourcen wie virtuelle Maschinen oder das Bereitstellen von IoT-Geräten verantwortlich. Cloud Computing ermöglicht durch Skalierung dynamisch auf geänderte Workloads zu reagieren [MG11]. Deshalb bietet das in dieser Arbeit entwickelte Konzept die Möglichkeit, dass Organisatio- nen ein bestehendes Deployment um neue Instanzen erweitern oder nicht mehr benötigte stoppen können. Um die organisationsübergreifende Zusammenarbeit für das gemeinsame Erstellen, Verändern und Provisionieren eines Anwendungsmodells zu verbessern, wird in dieser Arbeit ein GitOps-basierter Workflow erarbeitet. Hierbei wird das Modell und alle Artefakte in einer Versionsverwaltung an einem zentralen Ort gespeichert. Das reduziert die Chancen für einen menschlichen Fehler, erlaubt durch die Versionsverwaltung das Zurückkehren in einen älteren Zustand und hinterlässt automatisch einen Audit Trail [Wea22]. Der Workflow sieht die Verwendung einer Plattform vor, welche für Veränderungen einen Review-Prozess bietet, das Erstellen von Issues ermöglicht und automatisiert bei Änderungen ein Deployment ausführen kann. Um das Deployment einer in TOSCA modellierten Anwendung über ein verteiltes dezentralisiertes Agentensystem zu ermöglichen, muss die TOSCA Spezifikation erweitert werden. Eine Instanz eines Agenten muss wissen, welcher Teil der Gesamtanwendung von dem Agenten lokal provisioniert werden soll. Deshalb wird im Verlauf dieser Arbeit ein Konzept entwickelt, um die Zuordnung eines Subgraph einer Anwendungstopologie zu einem Agenten in einem TOSCA Modell zu repräsentieren. Ein Subgraph ist ein Teil der Anwendungstopologie, die provisioniert werden soll. In dieser Arbeit werden weiterhin mehrere Ansätze entwickelt und verglichen, um ein TOSCA Modell in mehrere dieser Subgraphen aufzuteilen. Dadurch muss nicht das gesamte TOSCA Modell auf jeden Agenten übermittelt werden, sondern nur der Subgraph, welcher dem Agenten zugewiesen ist. Das reduziert die notwendige Bandbreite zur Übertragung. Weiterhin enthält ein TOSCA Modell sensible Informationen über die gesamte Infrastruktur einer Anwendung, daher sollte ein einzelner Agent nur Zugang zu den Teilen des Gesamtmodells erhalten, welche er für das lokale Deployment benötigt. So werden bei der Kompromittierung eines Agenten nicht alle im TOSCA Modell enthaltenen Informationen preisgegeben. Insbesondere IoT-Geräte sind hier besonders bedroht, da sie sich häufig an exponierten, öffentlich zugänglichen Standorten befinden. Kompromittierte Agenten könnten jedoch nicht nur auf den lokalen Subgraph des Agenten zugreifen, sondern auch die Kommunikationsarchitektur nutzen, um Informationen aus anderen Teilen der Topologie zu erhalten. Deshalb präsentiert diese Arbeit ein Sicherheitskonzept, das die Kommunikationsarchitektur erweitert. Das Sicherheitskonzept erlaubt eine genaue Kontrolle, welcher Agent Zugriff auf welche Informationen erhält. Es basiert dabei auf Regeln für den Nachrichtenaustausch in Verbindung mit einer TOSCA Erweiterung, welche die Sichtbarkeit von Informationen direkt im TOSCA Modell kontrolliert. Um die Machbarkeit der präsentierten Konzepte zu validieren wird ein Prototyp mit einem Anwendungsszenario konzipiert und entwickelt. Die Ziele dieser Arbeit werden in Abschnitt 1.1 nochmals zusammengefasst dargestellt. 17 1 Einleitung 1.1 Ziele Um die Herausforderungen des Deployments von Multicloud- und IoT-Anwendungen in heterogenen und organisationsübergreifenden Umgebungen zu erfüllen, hat diese Arbeit folgenden Ziele: 1. Entwicklung eines agentenbasierten Deploymentkonzepts, bei dem Organisationen ihre Infrastruktur selbst kontrollieren und nur wenige Informationen über diese offenlegen müssen. 2. Entwicklung eines Konzepts, um lokale Agenten in TOSCA Modelle zu integriert. 3. Entwicklung eines Konzepts um ein TOSCA Modell in Subgraphen für unterschiedliche Agenten aufzuteilen, sodass einzelne Agenten nur Zugriff auf den für sie relevanten Teil des Modells erhalten und die Subgraphen möglichst autonom provisioniert werden können. 4. Konzeption und Entwicklung einer Agentensoftware um verteilte TOSCA-basierte Software- deployments zu ermöglichen. 5. Entwicklung eines eventbasierten Kommunikationsmodells, um Softwaredeployments auf Agenten mit sporadischer Konnektivität und Beschränkungen durch Sicherheitsmaßnahmen zu ermöglichen. 6. Entwicklung eines GitOps-basierten Workflows, um die Zusammenarbeit an einem zentralen TOSCA Modell für alle Teilnehmer zu erleichtern. 1.2 Gliederung Kapitel 1 – Einleitung: Die Einleitung befasst sich mit der Motivation und den Zielen dieser Arbeit. Kapitel 2 – Grundlagen: In diesem Kapitel werden die Grundlagen zu den verwendeten Konzep- ten und Technologien erklärt. Es beinhaltet unter anderem eine Einführung in die TOSCA Spezifikation und Related Work. Kapitel 3 – Konzept für die Entwicklung eines Multiagentensystems: Dieses Kapitel um- fasst unterschiedliche Konzepte, um die in Abschnitt 1.1 formulierten Ziele zu erreichen. Hierfür wird ein Ansatz, um Agenten in TOSCA zu repräsentieren, vorgestellt. Weiterhin werden mehrere Konzepte für die Aufteilung eines TOSCA Modells in mehrere agentenspezi- fische Subgraphen erarbeitet und verglichen. Weiterhin enthält dieser Abschnitt ein Konzept für die Kommunikation der Agenten untereinander. Kapitel 4 – Implementierung des Prototyps: Dieser Teil der Arbeit setzt sich mit dem Konzept und der Implementierung des Prototyps auseinander. Er enthält eine Architekturbeschreibung des Prototyps und ein Anwendungsszenario, um die praktische Umsetzbarkeit der in Kapitel 3 erarbeiteten Konzepte zu validieren. Kapitel 5 – Zusammenfassung und Ausblick: Hier werden die Ergebnisse der Arbeit zusam- mengefasst und Anknüpfungspunkte für zukünftige Arbeiten vorgestellt. 18 2 Grundlagen In diesem Kapitel werden die Grundlagen dieser Arbeit und verwandte Arbeiten beschrieben. Abschnitt 2.1 beschreibt die Grundlagen von Cloud Computing und die unterschiedlichen Cloud Deploymentmodelle wie Private Cloud oder Public Cloud. In Abschnitt 2.2 wird TOSCA näher beschrieben und erklärt. Das zur Kommunikation der Agenten untereinander verwendete Kommuni- kationsprotokoll „Message Queuing Telemetry Transport“ (MQTT) wird in Abschnitt 2.3 näher beschreiben. Abschnitt 2.4 umfasst eine Beschreibung von GitOps. Am Ende dieses Kapitels in Abschnitt 2.5 werden verwandte Arbeiten vorgestellt. 2.1 Cloud Computing Cloud Computing bezeichnet laut dem National Institute of Standard and Technologies (NIST)1 ein Modell, um Kunden den Zugriff auf geteilte Computing-Ressourcen und Services On-Demand zu ermöglichen [AFG+10; MG11]. Die Ressourcen umfassen zum Beispiel Server, Speicherplatz, Netzwerke, Plattformen und Anwendungen, welche dem Kunden über ein Netzwerk zur Verfügung stehen [AFG+10; MG11]. Der Kunde kann die gewünschten Ressourcen schnell skalieren und an seine Anforderungen anpassen [HYA+15]. NIST hat hierbei die folgenden fünf essenziellen Eigenschaften von Cloud Computing identifiziert: „On-demand self-service“, „Broad network access“, „Resource pooling“, „Rapid elasticity“ und „Measured service“. „On-demand self-service“ beschreibt die Möglichkeit eines Kunden, die gewünschten Ressourcen zeitnah und ohne menschliche Interaktion anzupassen [MG11]. So kann ein Kunde Ressourcen kurzzeitig buchen und sie wieder freigeben, sobald diese nicht mehr benötigt werden [AFG+10]. Die freigegebenen Ressourcen gehen dabei in einen geteilten Ressourcenpool zurück, den sich viele Kunden durch „Resource pooling“ teilen [MG11]. Ein Cloud-Provider bietet seine Ressourcen in einem Pool an, aus dem viele Kunden Ressourcen buchen und wieder freigeben können [MG11]. Als Kunde ist dabei nicht ersichtlich an welchem Standort sich die Ressourcen befinden [MG11]. Manche Cloud-Provider bieten aber die Möglichkeit an Einschränkungen zum Beispiel auf eine geografische Region oder ein Rechenzentrum vorzunehmen [MG11]. Die Eigenschaft „Rapid elasticity“ beschreibt, dass Ressourcen schnell und dynamisch provisioniert und wieder freigegeben werden können [MG11]. In manchen Fällen werden die Ressourcen für Sekunden gebucht und anschließend wieder freigegeben. Diese Skalierung kann automatisch oder manuell erfolgen und ermöglicht es Kunden auf kurzzeitig auftretende Lastspitzen zu reagieren [AFG+10; MG11]. Kunden können zum Beispiel ihrem Webshop während einer erfolgreichen Werbeaktion dynamisch mehr Server, Bandbreite oder Speicherplatz aus einem endlos erscheinenden Ressourcenpool zur Verfügung stellen [MG11]. In einem eigenen Rechenzentrum müsste der Kunde für seinen Webshop die benötigten Ressourcen im Voraus kaufen, welche dann außerhalb der Werbeaktion ungenutzt bleiben. Die Eigenschaft 1https://www.nist.gov/ (zuletzt besucht 28.09.2022) 19 https://www.nist.gov/ 2 Grundlagen „Measured service“ bedeutet, dass die Ressourcennutzung innerhalb der Cloud genau überwacht wird und dem Kunden eine transparente Nutzungskontrolle erlaubt [MG11]. „Broad network access“ beschreibt, dass Kunden die Ressourcen und Dienste der Cloud über eine Netzwerkverbindung nutzen können [MG11]. Neben den Vorteilen und Chancen, die Cloud Computing bietet, gibt es für Kunden auch Nachteile. Beim Cloud Computing werden Daten, Anwendungen und möglicherweise sensiblen Informationen einem externen Anbieter anvertraut [AFG+10]. Das Bedrohungsmodell für in der Cloud umgesetzte Dienste umfasst auch anderen Kunden des Cloud-Providers, da beim Cloud Computing Ressourcen von verschiedenen Kunden mit unterschiedlichen Interessen geteilt werden. Dies bedeutet, dass Kunden auch vor andere Kunden geschützt werden müssen [AFG+10]. Neben Sicherheitsbedenken gibt es bei Cloud-Providern auch einen Vendor- oder Daten Lock-in [AFG+10]. Ein Vendor Lock-in bedeutet, dass ein Kunde von einem Anbieter abhängig ist und sich ein Wechsel zu einem anderen Anbieter wirtschaftlich nicht lohnt [OST16]. Ein Wechsel ist aufwendig, da unterschiedliche Cloud- Provider verschiedene Dienste und Ressourcen anbieten. Selbst Dienste mit ähnlicher Funktionalität haben unterschiedliche Schnittstellen zur Interaktion [AFG+10]. Deshalb kann es aufwendig sein, Daten und Anwendungen von einem Cloud-Provider zu einem anderen umzuziehen. Auch beim Softwaredeployment gibt es erhebliche Unterschiede zwischen den Anbietern [WBF+19]. TOSCA hat das Ziel den Vendor Lock-in zu reduzieren und ein Vendor neutrales Ökosystem zu erschaffen [OAS20b]. In Abschnitt 2.2 wird TOSCA näher beschrieben. 2.1.1 Cloud Deploymentmodelle Es gibt unterschiedliche Cloud Deploymentmodelle, die sich zum Beispiel in Kosten, Anzahl der Nutzer, Betreiber der Cloud und Sicherheit unterscheiden. Im Folgenden werden die von Mell und Grance [MG11] beschrieben Modelle näher betrachtet. „Public Clouds“ sind Clouds, die der Öffentlichkeit oder einer großen Gruppe zugänglich sind [MG11]. Im Gegensatz dazu beschreibt „Private Cloud“ Infrastruktur oder Dienste, die nur einer einzigen Organisation zur Verfügung stehen [AFG+10]. Diese können auf eigener Infrastruktur oder von einem Anbieter betrieben werden [MG11]. Diese Clouds profitieren nicht so stark durch Skaleneffekte wie „Public Clouds“, wenn diese nicht eine ähnliche Größe erreichen [AFG+10]. „Private Clouds“ eignen sich primär bei konsistenter Ressourcenauslastung oder wenn aufgrund von Datenschutz oder Sicherheitsaspekten „Public Clouds“ nicht genutzt werden können [AFG+10; Goy14]. Eine „Community Cloud“ steht einer bestimmten Gruppe von Kunden zur Verfügung, die gemeinsame Interessen hat [MG11]. Solche Gruppen können unter anderem Behörden einer Regierung oder Unternehmen im Gesundheitssektor sein, die gemeinsame Anforderungen an den Datenschutz und die Sicherheit haben. Bei „Hybrid Cloud“ handelt es sich um die Kombination aus mehreren Cloud-Infrastrukturen [MG11]. Die Clouds sind über eine Schnittstelle miteinander verbunden [MG11]. Ein Anwendungsfall ist datenschutzkritische Teile einer Anwendung in einer „Private Cloud“ zu betreiben, während nicht kritische Aufgaben in einer „Public Cloud“ erledigt werden [Goy14]. 20 2.2 Topology and Orchestration Specification for Cloud Applications (TOSCA) 2.2 Topology and Orchestration Specification for Cloud Applications (TOSCA) Die „Topology and Orchestration Specification for Cloud Applications“ (TOSCA) ist ein OASIS2 Standard, der erstmals 2013 in der Version 1.0 veröffentlicht wurde [PS13]. TOSCA hat das Ziel komplexe Multicloud-Anwendungen in einem portablen Format zu modellieren, ihr Deployment zu automatisieren und ihren Lebenszyklus zu verwalten [OAS20b]. Im Jahr 2020 wurde der Entwurf der Version 2.0 veröffentlicht [OAS20c]. Die Version ist YAML3-basiert und legt ihren Fokus nicht nur auf das Modellieren von Cloud-Anwendungen, sondern auch auf die Bereiche Function-as-a-Service, Virtualized Network Functions, IoT- und Edge-Computing [OAS20b]. Anwendungen werden in TOSCA als Service Templates modelliert. Ein Service Template enthält ein Topology Template, das die einzelnen Komponenten der zu modellierenden Anwendung in einem typisierten Graph abbildet. Ein Node Template ist ein Knoten in diesem Graph und repräsentiert jeweils eine Komponente der Anwendung. Die Beziehungen der Knoten werden über Relationship Templates repräsentiert. Node und Relationship Templates sind Instanzen von Node oder Relationship Types. Die Typen definieren die Semantik der Templates über zum Beispiel Properties, Attributes und Interfaces. Über Properties können die Templates konfiguriert werden. Sie repräsentieren den gewünschten Zustand eines Templates bei seiner Instantiierung. Attributes stellen den aktuellen Zustand einer Komponente dar und werden meist während des Deployments von Operationen gesetzt. Attributes und Properties können auch Funktionen enthalten, welche anderen Attributes und Properties von Node und Relationship Templates lesen können. Für Node Templates können Requirements und Capabilities definiert werden. Node Templates mit passenden Requirements und Capabilities können über Relationship Templates miteinander verbunden werden. Interfaces bestehen aus Operationen, welche von Implementation Artifacts implementiert werden. Implementation Artifacts sind zum Beispiel Skripte, Java Anwendungen oder Binärdateien. Jede Art von Implementierung kann verwendet werden, wenn diese vom eingesetzten Orchestrator unterstützt wird. [OAS20b] Die Abbildung 2.1 zeigt den Aufbau einer Webanwendung. Im Beispiel sind unter anderem „Frontend“, „Backend“ oder „WebServer“ Node Templates. Beim Deployment werden aus diesen Templates die Instanzen der Anwendungskomponenten erzeugt. Die Node Types der Node Templates sind in der jeweiligen zweiten Zeile erkennbar. So ist zum Beispiel der WebServer vom Node Type „ApacheServer“4. Die gerichteten Verbindungen sind Relationship Templates und zeigen die Abhängigkeiten der einzelnen Komponenten. So sind unter anderem das Frontend und der WebServer über ein Relationship Template vom Type „hostedOn“ miteinander verbunden. Das bedeutet, dass das Frontend auf dem WebServer gehostet wird. Des Weiteren repräsentiert das Relationship Template vom Type „connectsTo“ zwischen Frontend und Backend, dass eine Verbindung zwischen diesen zwei Node Templates aufgebaut wird. Alle hier dargestellten Komponenten laufen auf einer virtuellen Maschine (VM), die im unteren Teil der Abbildung dargestellt ist. Jedes Node Template kann Properties, Attributes und Operationen in Interfaces besitzen. Diese werden in Abbildung 2.1 aus Gründen der Übersichtlichkeit nicht dargestellt. So kann in diesem Beispiel ein Property namens „Port“ für die Datenbank definiert sein, welches festlegt auf welchem Port die Datenbank erreichbar 2https://www.oasis-open.org/ (zuletzt besucht 28.09.2022) 3https://yaml.org/ (zuletzt besucht 28.09.2022) 4https://httpd.apache.org/ (zuletzt besucht 28.09.2022) 21 https://www.oasis-open.org/ https://yaml.org/ https://httpd.apache.org/ 2 Grundlagen VM (Ubuntu18VM) Database (MySqlDatabase) WebServer (ApacheServer) ApplicationServer (Tomcat) Backend (JavaApplication) Frontend (PHP_Application) = (connectsTo) = (hostedOn) Abbildung 2.1: Vereinfachtes TOSCA Beispiel einer Webanwendung. [Notation basiert auf Vi- no4TOSCA BBK+12] sein soll. Properties und Attributes können in Operationen als Inputs verwendet werden. In dem Beispiel könnte das connectsTo Relationship Template welches Backend und Database verbindet eine Operation definieren, welche das Port Property liest, um die Verbindung aufzubauen. Das Service Template und alle weiteren Artefakte können zu einem Cloud Service Archive (CSAR) zusammengefasst werden. Dieses Archiv kann von einem Orchestrator interpretiert und provisioniert werden. [OAS20b] 2.2.1 TOSCA Orchestrator Ein TOSCA Orchestrator hat die Aufgabe ein CSAR zu interpretieren, die enthaltene Anwendung zu provisionieren und während ihres Lebenszyklus zu managen [OAS20b]. Der Orchestrator entpackt dafür das Archiv und interpretiert das enthaltene Service Template [OAS20b]. Um eine Anwendung zu provisionieren gibt es zwei unterschiedliche Vorgehensweisen [WBK+20]. Endres et al. [EBF+17] beschreiben den deklarativen und den imperativen Ansatz. Beim deklarativen Ansatz wird der gewünschte Zustand und die Struktur der Anwendung beschreiben. Der Orchestrator bestimmt dann die notwendigen Schritte, um diesen Zustand zu erreichen. Deklarative Modelle sind generell intuitiver zu erstellen und zu verstehen. Beim imperativen Ansatz werden alle Schritte und deren Reihenfolge, die während des Deployments ausgeführt werden müssen, zum Beispiel in einem Skript oder Workflow beschrieben. Imperative Modelle erlauben mehr Kontrolle über die Schritte, die ausgeführt werden und sind anpassbarer. Jedoch sind imperative Modelle typisch komplexer zu erstellen. Sie eignen sich zum Beispiel für komplexe Deployments oder wenn mehrere Deployment-Systeme kombiniert werden müssen. In TOSCA kann die Struktur der Anwendung deklarativ im Topology Template beschrieben werden. Der imperative Ansatz wird über Workflows realisiert. [EBF+17; WBK+20] Da deklarative Modelle intuitiver und einfacher zu verstehen sind, wird der in dieser Arbeit entwi- ckelte Orchestrator diesen Ansatz unterstützen [WBK+20]. Dabei werden die für das Deployment notwendigen Schritte anhand der beschriebenen Struktur der Anwendung bestimmt [OAS20b]. Weiterhin wird dieses Verfahren in der TOSCA Spezifikation als die häufiger verwendete Option 22 2.3 Message Queuing Telemetry Transport (MQTT) Protokoll beschrieben [OAS20b]. Um die notwendigen Schritte für das Gesamt-Deployment zu berechnen, muss bekannt sein welche Operationen für das Deployment jedes einzelnen Node oder Relationship Templates ausgeführt werden müssen. Der aktuelle Entwurf der TOSCA 2.0 Spezifikation enthält kein normativ definiertes Interface, um den Lebenszyklus eines Node oder Relationship Templates zu verwalten [OAS20b]. In einigen Beispielen aus dem Entwurf wird das in den vorherigen TOSCA Versionen definierte Lifecycle Interface verwendet [OAS20a; OAS20b]. Deshalb wird in dieser Arbeit das in der TOSCA 1.3 Spezifikation [OAS20a] definierte Lifecycle Interface genutzt, um Node und Relationship Templates zu provisionieren. Das Interface besteht aus den Operationen create, configure, start, stop und delete. Um ein Node oder Relationship Template zu provisionieren werden nacheinander die Operationen create, configure und start aufgerufen [OAS20a]. Node Tem- plates können aber nicht in beliebiger Reihenfolge provisioniert werden, da diese Abhängigkeiten untereinander haben können. In Abbildung 2.1 benötigt das Frontend den WebServer, um ausgeführt werden zu können. Hier gibt das hostedOn Relationship Template eine Deploymentreihenfolge vor [BBK+14]. Zunächst muss der Orchestrator den WebServer, dann das hostedOn Relationship Template und anschließend das Frontend provisionieren. Für die Verbindung zwischen Frontend und Backend funktioniert diese Reihenfolge nicht. Ein Relationship Template vom Type connectsTo repräsentiert zum Beispiel eine HTTP-Verbindung. Diese Verbindung kann nicht gestartet werden, bevor nicht Quelle und Ziel provisioniert wurden [BBK+14]. Breitenbücher et al. [BBK+14] beschreiben ein topologisches Sortierverfahren für Node und Relationship Templates, das die Beziehungen der Node Templates nutzt, um eine Deploymentreihenfolge anhand der Anwendungsto- pologie zu bestimmen. Ist die Deploymentreihenfolge bestimmt, führt der Orchestrator nacheinander für alle Node und Relationship Templates die Operationen des Lifecycle Interfaces aus. 2.3 Message Queuing Telemetry Transport (MQTT) Protokoll Das „Message Queuing Telemetry Transport“ (MQTT) Protokoll ist ein von OASIS2 entwickelter Standard zur Nachrichtenübermittlung [CBB+19]. Das Protokoll verwendet eine als Broker oder Server bezeichnete Komponente, zu der sich alle Clients verbinden. Der Broker empfängt alle gesen- deten Nachrichten und verteilt diese an die Empfänger. MQTT arbeitet nach dem „publish/subscribe“ Message Pattern mit einem hierarchisch gegliederten Topic-Baum [CBB+19]. Bei diesem Verfahren können Empfänger ihr Interesse an bestimmten Nachrichten beim Broker registrieren [EFGK03]. Wird eine passende Nachricht versendet, leitet der Broker die Nachricht an alle interessierten Empfänger weiter [EFGK03]. Um Nachrichten interessierten Empfängern zuordnen zu können, werden Topics verwendet. Ein Topic ist ein String, der von Empfängern beim Registrieren angeben wird. Wird eine Nachricht versendet, enthält diese Nachricht ebenfalls diesen String und der Broker kann die Nachricht den interessierten Empfängern zuordnen [CBB+19]. Topics können beim Registrieren mit einem Schrägstrich in unterschiedliche Level aufgeteilt werden [CBB+19]. Darüber hinaus können verschiedene Wildcardzeichen genutzt werden, um sich für ein oder mehrere Level zu registrieren [CBB+19]. Es gibt das Single-Level Wildcardzeichen „+“ und das Multi-Level Wildcardzeichen „#“ [CBB+19]. Registriert sich ein Empfänger zum Beispiel auf den Topic „zuhau- se/stockwerk2/+“, funktioniert das „+“ Zeichen wie ein Platzhalter für ein Level an dieser Stelle. Der Empfänger erhält zum Beispiel alle Nachrichten auf dem Topic „zuhause/stockwerk2/badezimmer“, aber keine von „zuhause/stockwerk2/badezimmer/temperaturSensor“. Das Rautezeichen erlaubt das Ersetzen von beliebig vielen Topic Levels [CBB+19]. Für die Nachrichtenübertragung werden drei unterschiedliche Quality of Service Levels angeboten 23 2 Grundlagen [CBB+19]. „At most once“ sorgt dafür, dass Nachrichten maximal einmal übertragen werden [CBB+19]. Dabei können Nachrichten verloren gehen. „At least once“ ermöglicht, dass keine Nachrichten verloren gehen, aber Duplikate auftreten können [CBB+19]. Das „Exactly once“ Level ermöglicht, dass keine Nachrichten verloren gehen und Duplikate verhindert werden [CBB+19]. Das Protokoll erlaubt neben dem Nachrichteninhalt auch benutzerdefinierte Schlüsselwertpaare, um Metadaten in einer Nachricht zu übertragen [CBB+19]. Durch die Verwendung dieses Protokolls entsteht eine Entkoppelung der Sender und Empfänger [CBB+19]. Sender und Empfänger müssen sich nicht kennen und benötigen auch keine direkte Verbindung zueinander [EFGK03]. Es genügt die Verwendung eines gemeinsamen Topics, um Nachrichten austauschen zu können. Weiterhin besteht eine zeitliche Entkoppelung, da Sender und Empfänger nicht gleichzeitig kommunizieren müssen [EFGK03]. So kann zum Beispiel ein Empfänger offline sein, während eine Nachricht für ihn gesendet wird. Der Broker stellt dem Empfänger die Nachricht zu, wenn er wieder online kommt [EFGK03]. 2.4 GitOps GitOps bezeichnet ein von Weaveworks5 beschriebenes Continuous-Deployment Modell, um mithilfe von Git6 Software auf Kubernetes7 Cluster zu betreiben [BH21; Ric17a; Wea22]. Der Name GitOps leitet sich von den Worten Git und Operations ab. Es hat das Ziel, Entwickler den Betrieb (Operations) und das Provisionieren von Software mit bekannten Werkzeugen zu ermöglichen [Ric17b]. Dabei wird Git als sogenannte einzige „Source of Truth“ [Ric17a] verwendet, um den gewünschten Zustand des Systems zu beschreiben [Wea18]. Durch Git erhält man Versionskontrolle, Versionshistorie und Code Review Möglichkeiten für ein Kubernetes Cluster [Ric17a]. Richardson [Ric17a] beschreibt, dass alle verwendeten Ressourcen deklarativ modelliert in einem einzigen Git-Repository gespeichert werden. Durch Infrastructure as Code (IaC) kann die gesamte Infrastruktur und Software in Git verwaltet werden. Dabei werden neben dem Quellcode auch zum Beispiel Kubernetes Manifeste in Git gespeichert. Wird eine Änderung über Pull Requests zu Git hinzugefügt, sorgt eine Softwarekomponente automatisch dafür, dass die Änderungen von Build und Release Pipelines gebaut und auf das Kubernetes Cluster angewendet werden [Ric17a]. Entstehen Probleme durch die Änderungen, sind Rollbacks zu älteren Versionen durch Git jederzeit möglich. Treten Abweichungen zwischen dem in Git beschriebenen Istzustand und dem im Cluster provisionierten Sollzustand auf, benachrichtigt das System die Nutzer beispielsweise über E-Mail- oder Slackbenachrichtigungen [Ric17a]. Um Abweichungen zu erkennen stellt Richardson [Ric17a] mehrere Werkzeuge vor. Abweichungen können zum Beispiel entstehen, wenn manuell Änderungen an der Konfiguration im Kubernetes Cluster vorgenommen werden [Ric17a]. Solche manuellen Änderungen sorgen dafür, dass nicht mehr nachvollzogen werden kann, wie der aktuelle Zustand im Cluster erreicht wurde. Abbildung 2.2 zeigt den Prozess anhand einer Codeänderung die provisioniert wird. Das Anwen- dungsrepository enthält den Quelltext der Anwendung und das Konfigurationsrepository enthält alle Konfiguration, die für das Deployment benötigt wird. Alle Anwendungen werden in GitOps als unveränderliche Container entwickelt [Ric17b; Wea]. Ein Container enthält eine Anwendung und 5https://www.weave.works/ (zuletzt besucht 28.09.2022) 6https://git-scm.com/ (zuletzt besucht 28.09.2022) 7https://kubernetes.io/ (zuletzt besucht 28.09.2022) 24 https://www.weave.works/ https://git-scm.com/ https://kubernetes.io/ 2.4 GitOps Anwendungs- repository Container Repository CI Pipeline Konfiguratios- repository DeploymentCluster Konfigurations- update Codeänderung Abbildung 2.2: Vereinfachtes Beispiel einer Codeänderung mit anschließendem Deployment im GitOps Prozess. [Basiert auf Wea] alle ihre Abhängigkeiten in einem ausführbaren Format [Mer14]. Das Konfigurationsrepository enthält zum Beispiel die Kubernetes Manifeste [Wea]. In der Konfiguration wird auf die Container in dem Container Repository verwiesen. Die Änderung an einer Anwendung wird von einem Entwickler über einen Pull Request vorgeschla- gen. Der Pull Request kann einem Review unterzogen oder direkt gemerged werden [Wea]. Sind die Änderungen in das Anwendungsrepository aufgenommen, baut eine Continuous Integration Pipeline die Anwendungen und checkt die neuen Container in das Container Repository ein [Wea]. Durch Bereitstellen einer neuen Version einer Anwendung im Container Repository wird automatisiert eine neue Konfiguration im Konfigurationsrepository erstellt [Wea]. Die neue Konfiguration beinhaltet eine Referenz auf die neue Version des aktualisierten Containers. Änderungen am Konfigurationsre- pository lösen automatisiert ein neues Deployment aus [Wea]. Dafür wird die neue Konfiguration über ein Synchronisationswerkzeug auf das Kubernetes Cluster angewendet [Wea]. Werden neue Komponenten hinzugefügt oder die Struktur der Anwendung verändert, muss ein Entwickler die Konfiguration manuell anpassen. Weaveworks [Wea] beschreibt vier Prinzipien, die für GitOps erforderlich sind. Diese Prinzipien werden zur Entwicklung des in Abschnitt 3.5 beschriebenen GitOps-basierten Workflows für TOSCA verwendet. Das erste Prinzip beschreibt, dass das komplette System deklarativ beschreiben sein muss [Wea]. Dazu zählt nicht nur die Kubernetes Konfiguration, sondern auch die verwendete virtuelle Infrastruktur [Ric17b]. Das zweite Prinzip nimmt die deklarative Systembeschreibung und speichert diese in einem Git-Repository [Ric17b]. Dadurch sind einfache Rollbacks zu älteren Zuständen möglich. Das dritte von Weaveworks [Wea] beschriebene Prinzip verlangt, dass Ände- rungen am Zustand in Git automatisiert angewendet werden. Direkt wenn eine neue Version einer Softwarekomponente entwickelt wurde, wird diese provisioniert. Das vierte Prinzip beschreibt, dass Agenten den provisionierten Systemzustand überprüfen und bei Abweichungen von der in Git gespeicherten Konfiguration automatisch den Benutzer benachrichtigen [Ric17b]. 25 2 Grundlagen 2.5 Related Work Die Abschnitte 2.5.1 bis 2.5.5 beschreiben mehrere verwandte Arbeiten genauer. Die erste Arbeit beschäftigt sich mit verteilten Deployments in heterogene Umgebungen und der Problematik von Sicherheitsbeschränkungen, welche eingehende Verbindungen verhindern. Wild et al. [WBK+20] legen den Fokus auf organisationsübergreifendes Deployment. Wurster et al. [WBB+21] nutzen einen zentralisierten Ansatz und entwickeln in Ihrer Arbeit ein Konzept, um TOSCA Modelle in technologiespezifische Subgraphen aufzuteilen, um diese mit unterschiedlichen Deployment- technologien zu provisionieren. Saatkamp et al. [SBKL20] formalisieren mehrere Algorithmen, die Topologie Modelle verarbeiten und aufteilen. Die letzte Arbeit von Panarello et al. [PBL+17] beschreibt eine Methode, um Anwendungen in zusammenarbeitende Clouds zu provisionieren. Abschnitt 2.5.6 gibt einen kurzen Überblick über eine Auswahl an weiteren Arbeiten, die entweder einen zentralisierten Orchestrator nutzen oder nicht TOSCA-basiert sind. In Abschnitt 2.5.7 werden weitere relevante TOSCA Orchestratoren vorgestellt. 2.5.1 Verteiltes Anwendungsdeployment in öffentliche und private Netzwerke Képes et al. [KBL+19] beschreiben in Ihrer Arbeit ein Konzept für automatisierte Softwaredeploy- ments in heterogenen Umgebungen bestehend aus öffentlichen und privaten Netzwerken. Diese Umgebungen bestehen aus Cloud-Instanzen, Edge- und IoT-Geräten, welche sich in unterschiedli- chen Netzwerken befinden können. Die Autoren argumentieren, dass bestehende Lösungen basierend auf zentralen Orchestratoren nicht eingesetzt werden können, da diese eine direkte Verbindung zu jedem Geräte benötigen, um Schnittstellen wie SSH zu nutzen. IoT-Geräte für zum Beispiel Smart-Homes sind oft durch Firewalls, welche eingehende Verbindungen blockieren, geschützt und können daher nicht von zentralen Orchestratoren erreicht werden. Aus diesem Grund wird in der Arbeit ein hybrider Ansatz zwischen einem zentralisierten Orchestra- tor und verteilten Agenten präsentiert. Dieser Ansatz bietet den Vorteil, Kommunikation trotz Firewalls zu ermöglichen und nicht auf jedem Gerät ein Agenten zu benötigen. In diesem hybriden Ansatz gibt es in jedem Netzwerk, in dem Ressourcen provisioniert werden, ein Deployment System das lokal Operationen ausführen kann. Die Deployment Systeme, in den einzelnen Netzwerken, können trotz Firewalls, Verbindungen von innerhalb der Netzwerke zu einem Message Broker aufbauen. Dieser Message Broker wird zur Kommunikation zwischen den Deployment Systemen eingesetzt. Im Ansatz von Képes et al. [KBL+19] werden Anwendungen deklarativ mit TOSCA modelliert und anhand dieses Modells werden die für das Deployment auszuführenden Operationen bestimmt. Die Arbeit erweitert das bestehenden Deploymentkonzept von einem zentralen Orchestrator um die Deployment Systeme, die sich in jedem Netzwerk befinden und einem Verfahren zur Bestimmung der korrekten Ausführungsumgebung für jede Operation des Deployments. Das Verfahren ermittelt dazu das Netzwerk der zu provisionierenden Ressource und führt dann die Operation auf dem Deployment System im Netzwerk der Ressource aus. Um dieses Konzept zu ermöglichen, müssen die verwendeten Geräte oder Instanzen in den einzelnen Netzwerken vor dem Deployment beim lokalen Deployment System mit Anmeldedaten und IP- oder MAC-Adresse registriert werden. Es können zum Beispiel Geräte oder virtuelle Maschinen registriert werden. Wird ein Deployment begonnen, übernimmt das startende Deployment System zeitweise die Rolle des koordinierenden Deployment Systems. Dieses bestimmt zuerst einen 26 2.5 Related Work Deploymentplan anhand des deklarativen Deploymentmodells und dem von Breitenbücher et al. [BBK+14] beschrieben Verfahrens. Dieser Plan enthält für jede Komponente alle Operationen, die für ein Deployment ausgeführt werden müssen. Um während des Deployments eine dieser Operationen ausführen zu können, muss die Ausführungsumgebung für die Operation bestimmt werden. Dazu wird für jede Komponente einer Anwendung die Infrastrukturkomponente identifiziert, auf der sie ausgeführt wird. Die Infrastrukturkomponente ist die unterste Komponente in jedem Anwendungsstack. Képes et al. [KBL+19] beschreiben in Ihrer Arbeit ein Verfahren, um diese Infrastrukturkomponente für jede Komponente anhand der hostedOn Verbindungen zu identifizieren. In Abbildung 2.1 ist die VM die Infrastrukturkomponente für die anderen Komponenten. Anschließend führt jedes Deployment System anhand der registrierten Daten über die verwendeten Geräte ein Matching-Verfahren aus. Das Matching-Verfahren überprüft, ob die Infrastrukturkomponente zu einem lokalen Gerät passt. Hat ein Deployment System ein Match, führt es die Operation lokal aus. Die Operationen nutzen dann zum Beispiel Netzwerkschnittstellen, um die Komponente auf dem Gerät oder der Instanz zu installieren. Durch dieses Verfahren ist es möglich für jede Komponente alle für das Deployment notwendigen Operationen im lokalen Netzwerk auszuführen. Dadurch behindert keine Firewall die Kommunikation zwischen Deployment System und Zielgerät oder Zielinstanz, da sich das jeweilige Deployment System im lokalen Netzwerk des Zielgeräts befindet. Zur Validierung der Machbarkeit Ihrer Arbeit haben Képes et al. [KBL+19] ihr Konzept in einem auf dem OpenTOSCA- Container8-basierten Prototypen implementiert. Dieser Prototyp wurde dann für das Deployment eines Smart-Home-Szenarios verwendet. Das in der Arbeit von Képes et al. [KBL+19] vorgestellte hybride Deploymentverfahren hat den Vorteil, Deployments zu ermöglichen, bei denen sich die Geräte und Instanzen in unterschiedlichen Netzwerken befinden. Durch die Deployment Systeme in jedem Netzwerk ist es möglich zu Geräten oder Instanzen eine Verbindung aufzubauen und Operationen auszuführen, obwohl jedes Netzwerk durch eine Firewall geschützt ist. Weiterhin können Geräte mit stark limitierten Hardwareressourcen eingesetzt werden, da nicht auf jedem Gerät, sondern nur auf einem Gerät im Netzwerk ein Deployment System benötigt wird. Jedoch kann jedes Deployment System nur einzelne Operationen ausführen und ist für die Gesamtkoordination von einem zentralen koordinierenden Deployment System abhängig. Dadurch ist keine Autonomie der einzelnen Deployment Systeme im Deploymentprozess möglich. Weiterhin haben einzelne Geräte keine Autonomie, da jede Operation von einem Deployment System über eine Netzwerkverbindung auf dem Gerät ausgeführt und koordiniert wird. Das benötigt mehr Netzwerkkommunikation als lokale teilautonome Deployments auf jedem Gerät. Auch müssen beim hybriden Ansatz Zugangsdaten zu Clouds oder interner Infrastruktur im Deploymentmodell hinterlegt und damit geteilt werden. Das ist aufgrund von Compliance-Richtlinien und Sicherheitsbedenken in einem organisationsübergreifenden Deployment problematisch [WBK+20]. Auch ist es bei mobilen Geräten möglich, dass diese während der Ausführung einer Operation das Netzwerk wechseln und somit nicht mehr für das lokale Deployment System erreichbar sind. 8https://opentosca.github.io/container/ (zuletzt besucht 28.09.2022) 27 https://opentosca.github.io/container/ 2 Grundlagen 2.5.2 Dezentralisiertes organisationsübergreifendes Anwendungsdeployment Wild et al. [WBK+20] präsentieren ein Konzept, um Anwendungen automatisiert über Organisati- onsgrenzen hinweg zu provisionieren, ohne dass die Teilnehmer Schnittstellen zu ihrer Infrastruktur von außerhalb zugänglich machen müssen. Sie argumentieren, dass die verbreiteten zentralen Orchestratoren nicht für organisationsübergreifende Deployments geeignet sind, da der zentrale Orchestrator Zugriff auf Zugangsdaten für Cloud-Provider und zu der internen Infrastruktur der beteiligten Organisationen benötigt. Das Teilen von Zugangsdaten oder ein Zugriff auf die interne Infrastruktur von außerhalb ist aufgrund von Sicherheitsbedenken und Compliance-Richtlinien oft nicht möglich. Der Ansatz von Wild et al. [WBK+20], um dieses Problem zu lösen, beginnt mit einem deklarativen Modell der Application-Specific Components. Diese werden mit dem deklarativen „Essential Deployment Meta Model“ (EDMM), das in einer vorausgegangenen Arbeit entwickelt wurde, modelliert [WBF+19]. Das EDMM nutzt ähnlich wie das in Abschnitt 2.2 beschriebene TOSCA eine graphbasierte Struktur aus Components und Relations [WBB+21; WBF+19]. Die Gesamtanwendung kann mit EDMM modelliert werden, indem logische, funktionale oder physikalische Komponenten der Anwendung als Components modelliert werden [WBB+21; WBF+19]. Die Abhängigkeiten und die Verbindungen zwischen den Components werden mit Relations modelliert. Über Operationen können Components und Relations installiert oder gestoppt werde [WBF+19]. Properties repräsentieren den gewünschten Zustand, den eine Component erreichen soll und ermöglichen, Inputs für den Deploymentprozess zu definieren [WBF+19]. Eine ausführliche Beschreibung von EDMM befindet sich in der Arbeit von Wurster et al. [WBF+19]. Der von Wild et al. [WBK+20] beschriebene Ansatz umfasst fünf Schritte für ein organisations- übergreifendes Deployment. Zuerst wird ein deklaratives Modell der Anwendung ohne konkrete Hosting-Umgebung modelliert. Das Modell enthält alle Application-Specific Components einer Anwendung, die für die Realisierung des Use Cases notwendig sind, wie zum Beispiel Business-, Speicher- oder Kommunikations-Components und alle Informationen, welche zur Zusammenarbeit dieser benötigt werden. In Schritt zwei wird jedem Teilnehmer ein Subgraph dieses Modells über Annotationen zugewiesen. Weiterhin werden in dem Anwendungsmodell Placeholder-Components für die Hosting-Umgebung eingefügt. Die Placeholder-Components enthalten nur minimalen In- formationen, die zwischen den Organisationen ausgetauscht werden müssen. Schritt drei umfasst die Verarbeitung des Gesamtmodells durch jeden Teilnehmer. Jeder Teilnehmer verarbeitet das Gesamtmodell und ersetzt in seinem individuellen Subgraph alle Placeholder-Components durch konkrete Middleware- und Infrastruktur-Components. Diese Ersetzung kann automatisiert über ein Requirement-Capability Matching-Verfahren ausgeführt werden. Das partiell ersetzte Modell bezeichnen Wild et al. [WBK+20] als local multi-participant deployment model (LDM). In Schritt vier berechnet jeder Teilnehmer basierend auf seinem individuellen LDM einen lokalen Workflow, der alle lokalen Components instantiiert. Der Workflow muss alle lokalen Komponenten in der richtigen Reihenfolge instanziieren und alle Input-Parameter jeder Operation bereitstellen. Die Input-Parameter können dabei aus nicht lokalen Teilen des Modells kommen und sind teilweise erst während des Deployments bekannt. Diese Parameter müssen daher während des Deployments von einem anderen Teilnehmer übertragen werden. Gleichzeitig müssen lokale Outputs von Operationen anderen Teilnehmern während des Deployments zur Verfügung gestellt werden. Weiterhin muss das Gesamt-Deployment implizit durch die einzelnen LDMs koordiniert werden. Wild et al. [WBK+20] beschreiben in Ihrer Arbeit ein Verfahren, um diese lokalen Workflows für jeden Teilnehmer zu generieren und notwendige Aktivitäten zur Kommunikation automatisch zu integrieren. Das Deployment kann in Schritt fünf von einem Teilnehmer initiiert werden und die lokalen Workflows 28 2.5 Related Work werden innerhalb jeder Organisation von einem Orchestrator ausgeführt. Zur Validierung wurde ein OpenTosca17-basierter Prototyp entwickelt. Da jeder Teilnehmer selbst die konkreten Informationen über seine Hosting-Umgebung in sein LDM integriert, bietet der Ansatz von Wild et al. [WBK+20] den Vorteil, dass nur wenig In- formationen geteilt werden müssen. Nur Informationen, die für Verbindungen, zwischen den Components benötigt werden, müssen ausgetauscht werden. Weiterhin kommt der Ansatz ohne einen zentralen Orchestrator für alle Organisationen aus. Die für jeden Teilnehmer generierten Workflows müssen trotzdem von einem organisationsinternen Orchestrator ausgeführt werden. Einzelne Geräte und Instanzen haben keine Autonomie von dem jeweiligen organisationsinternen Orchestrator. Dadurch ist mehr Kommunikation zwischen dem Orchestrator und jedem Gerät notwendig, was sich bei batteriebetriebenen und über Funk verbundenen Geräten negativ auf die Lebensdauer der Batterie auswirkt [PK00]. Auch muss der organisationsinterne Orchestrator eine direkte Verbindung zu jedem Gerät aufbauen können. Geräte können jedoch innerhalb einer Organisation durch eine Firewall, welche eingehende Verbindungen blockiert, geschützt sein. Auch können zum Beispiel Smart-Home-Anwendungen in Kundennetzwerken, welche durch NAT keine eingehende Verbindungen erlauben, nicht erreicht werden. Weiterhin muss jeder Teilnehmer im Vorfeld alle möglichen Placeholder-Ersetzungen für alle auftretenden Requirements definieren, um das Requirement-Capability Matching-Verfahren automatisiert ausführen zu können. 2.5.3 Deploymentautomatisierung von verteilten Anwendungen durch die Kombination von mehrere Deploymenttechnologien Wurster et al. [WBB+21] beschreiben in Ihrer Arbeit, dass oft mehrere Deploymenttechnolo- gien benötigt werden, um ein Deployment auszuführen. Unterschiedliche Technologien setzen unterschiedliche Schwerpunkte und haben jeweils Vor- und Nachteile. Für das Provisionieren von Amazon Web Services9 (AWS) Ressourcen eignet sich zum Beispiel CloudFormation10 [WBB+21]. Im Gegensatz dazu fokussiert sich Chef11 auf die Installation und Konfiguration von Anwendungen auf bereits provisionierter Infrastruktur. Komplexe Anwendungen bestehen oft aus mehreren Kom- ponenten, die auf unterschiedlichen Infrastrukturen betrieben werden. Ein Deployment benötigt daher oft verschiedene Deploymenttechnologien. Anwendungsteile in verschiedenen Deployment- technologien zu modellieren, ist aufwendig. Diese separat zu provisionieren, ist fehleranfällig und teuer. Weiterhin wird Expertise für jede Deploymenttechnologien benötigt. Um diese Probleme zu lösen, wird in der Arbeit die Forschungsfrage gestellt: „How to seamlessly model and automate the deployment of a complex application distributed across heterogeneous environments that requires different deployment technologies?“ [WBB+21, S. 2]. Das Konzept der Arbeit besteht aus sechs Schritten, um ein Deployment mit unterschiedlichen Deploymenttechnologien auszuführen. Als Erstes wird die Gesamtanwendung in dem technologie- neutralen von Wurster et al. [WBF+19] beschriebenen EDMM modelliert. Eine Kurzbeschreibung des EDMM befindet sich in Abschnitt 2.5.2 und eine ausführliche Beschreibung in der Arbeit von Wurster et al. [WBF+19]. Im zweiten Schritt wird jeder Teil des EDMM-Modells mit der gewünsch- ten Deploymenttechnologie annotiert. Dazu haben Wurster et al. [WBB+21] eine Erweiterung der EDMM-Syntax entwickelt, die es erlaubt jeder Component eine spezifische Deploymenttechnologien 9https://aws.amazon.com/de/ (zuletzt besucht 28.09.2022) 10https://aws.amazon.com/de/cloudformation/ (zuletzt besucht 28.09.2022) 11https://www.chef.io/ (zuletzt besucht 28.09.2022) 29 https://aws.amazon.com/de/ https://aws.amazon.com/de/cloudformation/ https://www.chef.io/ 2 Grundlagen zuzuweisen. Das EDMM-Modell besteht nach dem Annotieren aus mehreren Gruppen von Compon- ents, die jeweils mit einer Deploymenttechnologie provisioniert werden. So kann zum Beispiel ein Teil des Modells mit CloudFormation und ein anderer mit Chef annotiert sein. Um ein Deployment auszuführen, muss das Gesamtmodell der Anwendung in Schritt drei in mehrere technologiespezifi- sche Gruppen aufgeteilt werden. Da zwischen den verschiedenen technologiespezifischen Gruppen zyklische Abhängigkeiten bestehen können, ist es nicht immer möglich alle Components, die einer Deploymenttechnologie zugeordnet sind, auf einmal zu provisionieren. Daher haben Wurster et al. [WBF+19] einen auf der Arbeit von Saatkamp et al. [SBKL20] basierenden Algorithmus entwickelt, der die minimale Anzahl an Deploymentgruppen bestimmt, sodass keine zyklischen Abhängigkeiten entstehen. Eine Deploymentgruppe ist dabei eine Menge von Components, die von einer Ausführung der ihnen zugeordneten Deploymenttechnologie provisioniert werden kann. Diese Deploymentgruppen werden in Schritt vier von dem technologieneutralen EDMM-Modell in die spezifische Deploymenttechnologie transformiert. Dafür erweitert die Arbeit das von Wurster et al. [WBB+20] vorgestellte EDMM Transformation Framework. Die Erweiterung ermöglicht, dass Konfigurationsparameter anhand des EDMM-Modell aufgelöst und dynamisch zur Laufzeit als In- und Outputs abgebildet werden. Zum Beispiel können IP-Adressen dynamisch während des Deployments vergeben werden, deshalb müssen diese dann von einem technologiespezifischen Teil des Deployments in einen anderen übertragen werden, um eine Verbindung zu ermöglichen. In Schritt fünf wird die Deploymentreihenfolge der Deploymentgruppen bestimmt. Um das zu ermöglichen wird in der Arbeit ein Verfahren basierenden auf den Arbeiten von Breitenbücher et al. [BBK+14] und Saatkamp et al. [SBKL20] vorgestellt, um die Deploymentgruppen so zu sortieren, dass die Abhängigkeiten zwischen den Gruppen sowie ihre In- und Outputs berücksichtigt werden. Um das Deployment in Schritt sechs ausführen und koordinieren zu können, stellen Wurster et al. [WBB+21] eine Systemarchitektur vor. Der von Wurster et al. [WBB+21] beschriebene Ansatz hat den Vorteil, unterschiedliche Deploy- menttechnologien einsetzen zu können. Um organisationsübergreifende Deployments in heterogene Umgebungen umzusetzen, kann das vorteilhaft sein, da unterschiedliche Organisationen verschiede- ne Deploymenttechnologien benötigen könnten. Der vorgestellte Ansatz basiert auf einem zentralen Orchestrator, der das Deployment koordiniert. Daher kann keine Software auf Geräte provisio- niert werden, die sich hinter einer Firewall befinden. Auch müssen alle benötigten Zugangsdaten im EDMM-Modell enthalten sein und alle am Deployment beteiligten Organisationen müssen Schnittstellen für ihre interne Infrastruktur für den zentralen Orchestrator öffnen. 2.5.4 Formalisierungen und Algorithmen für Topologie Modelle von verteilten Cloud Deployments Saatkamp et al. [SBKL20] beschreiben in ihrer Arbeit mehrere Algorithmen, um topologische Deploymentmodelle wie TOSCA in verschiedene Teile aufzuteilen. Zentrale Orchestratoren oder Provisioning Engines benötigen Zugang zu Low-Level Schnittstellen von allen an einem Deployment beteiligen Cloud-Providern, um das Deployment auszuführen. Um das zu vermeiden, präsentieren Saatkamp et al. [SBKL20] in ihrer Arbeit eine Methode, um Deploymentmodelle in verschiedene Teile aufzuteilen. Cloud-Provider können die einzelnen Teile separat ausführen und müssen weniger oder keine Schnittstellen für eine Provisioning Engine nach außen öffnen. Um ein Deploymentmodelle zu erstellen, es in mehrere Teile aufzuteilen und in einem koordiniertem Deployment auszuführen, beschreiben Saatkamp et al. [SBKL20] ein Verfahren basierend auf acht Schritten. Die ersten fünf Schritte basieren auf der früheren Arbeit [SBKL17] und sind 30 2.5 Related Work ebenfalls in der Arbeit [SBKL20] beschrieben. In Schritt eins wird ein Topology Modell be- stehend aus den Components und Relations einer Anwendung erstellt. Ein solches Modell enthält zum Beispiel Application-Specific Components, Middleware Components wie Webserver oder Infrastructure Components wie zum Beispiel eine virtuelle Maschine. Schritt zwei umfasst das Hinzufügen von Labels zu mindestens allen Application-Specific Components. Jedes Label definiert die Zielumgebung, wie zum Beispiel ein Cloud-Provider, auf der die Component provisioniert wird. Schritt drei überprüft ob, eine über die Label definierte Aufteilung möglich ist. Zum Beispiel müssen alle Application-Specific Components mit einem Label versehen sein. Weiterhin kann keine Component auf einer Component, die einem anderen Provider zugeordnet ist, gehostet sein. In Schritt vier wird das Gesamtmodell basierend auf den Labels in mehrere Teile aufgeteilt. Sind zwei Application-Specific Components unterschiedlichen Providern zugeordnet, müssen zum Beispiel Middleware Components auf denen sie im Gesamtmodell gemeinsam gehostet werden, für beide Provider dupliziert werden. In Schritt fünf ersetzt ein Algorithmus in jedem Teil des Modells die Infrastructure oder Middleware Components durch Provider spezifische Components. So kann zum Beispiel ein Webserver im Modell durch AWS Elastic Beanstalk12 ersetzt werden. Die Schritte sechs bis acht sind neu und noch nicht von vorausgegangenen Arbeiten beschreiben. Schritt sechs berechnet die Reihenfolge in der die Provider ihre Teile des Modells provisionieren. Dafür werden Gruppen von Components erstellt, die jeweils einem Label zugeordnet sind und auf einmal provisioniert werden können. Die Reihenfolge, in der die Gruppen provisioniert werden, hängt von den Verbindungen zwischen Components die unterschiedlichen Providern zugeordnet sind ab. Wenn eine Verbindung aufgebaut werden soll, muss erst das Ziel der Verbindung und dann die Quelle provisioniert werden. Dadurch muss die Gruppe mit dem Ziel der Verbindung zuerst provisioniert werden. Eine Gruppe kann nicht immer alle Components von einem Provider umfassen, da unter anderem sonst zyklische Abhängigkeiten zwischen den Gruppen entstehen können. In Schritt sieben wird für jede Gruppe ein Deploymentmodell erstellt. Das Modell umfasst alle Components in der Gruppe, alle Ziele einer providerübergreifenden Verbindung und die der Ziel-Component zugeordneten Infrastructure oder Middleware Components. Im letzten Schritt werden die Deploymentmodelle der Gruppen zu den jeweiligen Providern übertragen und in der in Schritt sechs bestimmten Reihenfolge ausgeführt. Dabei müssen auch Inputs, die erst während des Deployments bestimmt werden können, wie IP-Adressen zwischen den Providern ausgetauscht werden. Saatkamp et al. [SBKL20] formalisieren diese Schritte anhand eines topologischen Meta-Modells und beschreiben für Schritt drei bis sieben jeweils einen Algorithmus in Pseudocode. Weiterhin implementieren die Autoren einen Prototyp, basierend auf dem grafischen Modellierungswerkzeug Winery13. Der vorgestellte Ansatz erlaubt ein verteiltes Deployment einer Anwendung mit mehreren Orchestra- toren in unterschiedlichen Organisationen. Weiterhin erlaubt dieser Ansatz, dass Organisationen gemeinsam ein Deployment ausführen können, ohne Schnittstellen nach außen zu öffnen. Jedoch enthält die Arbeit keinen Ansatz, um das Deployment automatisiert auszuführen. Zum Beispiel werden Inputs manuell zwischen den Organisationen ausgetauscht. Weiterhin gibt es einen zentralen Orchestrator pro Organisation, daher müssen alle Geräte und Instanzen innerhalb dieser Organisation 12https://aws.amazon.com/de/elasticbeanstalk/ (zuletzt besucht 28.09.2022) 13https://github.com/eclipse/winery/ (zuletzt besucht 28.09.2022) 31 https://aws.amazon.com/de/elasticbeanstalk/ https://github.com/eclipse/winery/ 2 Grundlagen für den zentralen Orchestrator erreichbar sein. Dazu kommt, dass einzelne Geräte keine Autonomie vom jeweils zentralen Orchestrator haben, dadurch muss jede Ausführung jeder Operation auf allen Geräte vom zentralen Orchestrator kontrolliert werden. 2.5.5 Deploymentautomatisierung von Multicloud-Anwendungen in föderierte Cloud Umgebungen Panarello et al. [PBL+17] beschreiben in Ihrer Arbeit ein Konzept, um das Deployment von Multicloud-Anwendungen in eine föderierte Cloud Umgebung zu ermöglichen. Cloud Föderation wird von den Autoren als ein Konzept beschreiben, bei dem Cloud-Provider dynamisch eigene und die Ressourcen von anderen Cloud-Providern kombinieren, um die Anforderungen von Kunden zu erfüllen. Die Cloud-Provider sind dabei separate Entitäten, die interagieren, um ihre jeweils ungenutzten Ressourcen zu teilen. Dadurch können Cloud-Provider die Auslastung ihrer Ressourcen verbessern und Lastspitzen mithilfe von Ressourcen anderer Cloud-Provider ausgleichen. In der Arbeit werden mehrere Probleme identifiziert, welche diese Zusammenarbeit behindern. So ist es problematisch, dass verschiedene Cloud-Provider unterschiedliche Management Systeme und Metamodelle, um Anwendungen zu beschreiben, einsetzen. Weiterhin gibt es keine Standards, um die verfügbaren Ressourcen der Cloud-Provider zu koordinieren und Anwendungen in die föderierte Umgebung zu provisionieren. Deshalb haben Panarello et al. [PBL+17] ein Konzept und eine Architektur für die Zusammen- arbeit zwischen den Cloud-Providern und das Deployment von Anwendungen entwickelt. Um das konzeptionell beschriebene System umzusetzen, kombinieren die Autoren mehrere Standards und existierende Technologien. Die Architektur beschreibt einen zentralen Messaging-Exchange- Server, über den alle Cloud-Provider miteinander kommunizieren können. Weiterhin betreibt jeder Cloud-Provider ein Application Deployment Toolkit. Das Toolkit empfängt Anwendungen zum Deployment von Endnutzern und entscheidet, welche Teile der Anwendung lokal vom jeweiligen Cloud-Provider selbst betrieben und welche Teile zu anderen Providern ausgelagert werden. Um diese Entscheidung zu treffen, sendet das Toolkit eine Anfrage über die Art, die Anzahl und den Preis der verfügbaren Ressourcen an die anderen Cloud-Provider. Für diese Kommunikation wählen die Autoren das XMPP14 Protokoll aus und beschreiben ein Nachrichtenformat für die Ressourcenanfragen und Antworten. Um die Ressourcenanfragen zu erhalten und Antworten zu senden, betreiben die Cloud-Provider Agenten, die in einem gemeinsamen XMPP Chatraum kommu- nizieren. Anhand der Antworten entscheidet das Toolkit, welche Cloud-Provider für die nicht lokalen Teile der Anwendung genutzt werden und provisioniert diese auf den verfügbaren Ressourcen der anderen Cloud-Provider. Die Arbeit von Panarello et al. [PBL+17] enthält kein Konzept, um zu entscheiden wo welche Anwendungsteile platziert werden, sondern verweist auf existierende Arbeiten. Da manche Cloud-Provider diese Interaktion nicht nativ unterstützen gibt es in dem Konzept Plugins und Message-Oriented Middlewares welche die Kommunikation und Interaktion er- möglichen. Die Autoren verwenden die CLoud-Enabled-Virtual-EnviRonment (CLEVER) [CFV13] Message-Oriented Middleware, welche sich durch Cloud-Provider spezifische Plugins erweitern lässt. Um ein Deployment durchzuführen, müssen die Anwendungsstacks einer Anwendung um Cloud-Provider spezifische Infrastrukturkomponenten erweitert werden. Ein Anwendungsstack ist dabei zum Beispiel ein auf einem virtuellen Server gehosteter Teil der Anwendungstopologie, 14https://xmpp.org/ und https://www.rfc-editor.org/rfc/rfc6120 (zuletzt besucht 28.09.2022) 32 https://xmpp.org/ https://www.rfc-editor.org/rfc/rfc6120 2.5 Related Work welcher einem Cloud-Provider zugeordnet ist. Die Autoren führen dazu ein Deployment Model Completion Manager ein, der vor dem Deployment jeden Stack um die Cloud-Provider spezifischen Infrastrukturkomponenten erweitert. Um die nötigen Infrastrukturkomponenten und ihre Properties zu bestimmen, gibt es eine Registry, die für jeden Cloud-Provider die benötigten Informationen über die Infrastruktur und Anmeldedaten enthält. Neue Cloud-Provider werden dabei manuell der Registry hinzugefügt. Anschließend wird das erweiterte Modell von einer Laufzeitumgebung ausgeführt. Die Laufzeitumgebung nutzt Schnittstellen, um die Komponenten bei den jeweiligen Cloud-Providern zu provisionieren. Anwendungen werden in TOSCA modelliert und nach den Ergänzungen des Deployment Model Completion Manager mit einer TOSCA Laufzeitumgebung provisioniert. Panarello et al. [PBL+17] nutzen für das Provisionieren OpenTOSCA. Das Konzept von der Arbeit ermöglicht die Zusammenarbeit von verschiedenen Cloud-Providern, um Ressourcen zu teilen und Anwendungen in föderierte Cloud Umgebung zu provisionieren. Da alle Cloud-Provider die Details ihrer Infrastruktur und die benötigten Anmeldedaten in einer Registry speichern müssen, eignet sich das Konzept nicht für ein organisationsübergreifendes Deployment, bei dem die Teilnehmer diese Informationen nicht teilen können. Weiterhin wird für den Informationsaustausch eine Messaging-basierte Lösung eingesetzt, welche trotz Firewalls oder NAT Kommunikation erlaubt. Jedoch wird für das Deployment aber ein zentraler Orchestrator eingesetzt, sodass Geräte oder Instanzen hinter Firewalls nicht erreicht werden können. 2.5.6 Weitere Arbeiten Neben den genauer betrachteten Arbeiten gibt es zum Beispiel [LVCD13], [FBH+17], [HBS+16] oder [SBK+16], welche sich mit Softwaredeployments auf IoT-Geräte mit TOSCA beschäftigen. Die Arbeiten [TPM+17], [TCDM21] oder [CCP15] nutzen TOSCA für Multicloud Deployments. Alle diese Arbeiten verwenden einen zentralisierten Orchestrator, der für organisationsübergreifende Deployments nicht geeignet ist [WBK+20]. Die Arbeit von Zimmermann et al. [ZBF+17] beschäftigt sich mit dem Deployment von Datenana- lysesoftware von einem externen Dienstleister zur lokalen Datenverarbeitung in einer Organisation. Der Dienstleister kennt dabei die lokale Infrastruktur und die zu verarbeiteten Daten nur teilweise. Die Arbeit bietet mehrere Ansätze, um ein TOSCA Modell ohne die genaue Kenntnis der lokalen Infrastruktur zu erstellen. Jedoch verwendet auch dieser Ansatz einen zentralen Orchestrator [ZBF+17]. Des Weiteren gibt es andere dezentrale Agentensysteme, um Deployments auszuführen. Zum Beispiel nutzen Herry et al. [HAR14] einen Planning-basierten Ansatz, um Workflows für Agenten aus einem Anwendungsmodell zu generieren. Diese Agenten arbeiten Push-based, daher können sie nicht hinter Sicherheitsbeschränkungen eingesetzt werden, welche eingehende Kommunikation verhindern. Die Arbeit von Hall et al. [HHW99] erarbeitet ein Schema, um eine Software mit ihren Abhän- gigkeiten in einem provisionierbaren Format zu definieren. Darüber hinaus gibt es in dem System von Hall et al. [HHW99] eine Komponente, welche die verfügbare Software zusammen mit den definierten Abhängigkeiten bereitstellt. Agenten, welche mit der Software mitgeliefert werden, interpretieren das Schema und führen das Deployment aus. Die Arbeit enthält aber kein Konzept, um das Deployment von mehrere Komponenten einer Software auf unterschiedlichen Geräten zu koordinieren. Weiterhin wird für jedes Deployment ein eigener Install-Agent übertragen. Das wirkt sich negativ auf die Lebensdauer eines batteriebetriebenen IoT Geräts aus. 33 2 Grundlagen Juve und Deelman [JD12] beschreiben ein agentenbasiertes Deployment System und eine Beschrei- bungssprache für Deployments. Es werden dabei gesamte virtuelle Maschinen als Nodes modelliert. Dieses System kann aber für organisationsübergreifende Deployments nicht eingesetzt werden, da ein zentraler Koordinator Zugriff auf alle beteiligten Cloud-Provider von allen Organisationen benötigt, um virtuelle Instanzen zu erstellen. Die Arbeit von Sampaio und Mendonça [SM11] erlaubt das Modellieren von Multicloud- Anwendungen basierend auf dem Open Virtualization Format15 und nutzt für das Deployment verschiedene Plugins für unterschiedliche Cloud-Provider. Auch in dieser Arbeit kommt eine zentrale Komponente zum Einsatz, die das Deployment ausführt. Terraform25 Cloud Agents ist eine cloudbasierte Lösung, um ein Terraform-Deployment in private Clouds oder interne Infrastruktur zu ermöglichen, ohne eingehende Verbindungen zu benötigen [WWG22]. Diese Lösung hat den Nachteil, dass alle Agenten einer Organisation global für alle Teilnehmer zugreifbar sind [WWG22]. Das betrifft auch Agenten, die aktuell nicht am Deployment teilnehmen [WWG22]. Das schränkt die organisationsübergreifende Nutzung ein [WWG22]. Die Arbeiten [MN10] und [FRL05] verwenden beide mobile Agenten, um Software auf Geräte zu installieren. Aber beide Arbeiten erlauben nicht das koordinierte Deployment von unterschiedlichen Komponenten einer Software. Ein Konzept, um imperative Deploymentmodelle aufzuteilen wurde von Kopp und Breitenbücher [KB17] präsentiert. Die Arbeit von Arcangeli et al. [ABL15] bietet einen Überblick zu automatisierten Deploymentlö- sungen in verteilten Umgebungen. Aber keine der vorgestellten Lösungen bietet TOSCA-basierte Agenten, die (teil)autonom ein Deployment bestehend aus mehrere Komponenten provisionieren und koordinieren können. Andere verbreitete Lösungen wie Ansible19 oder Terraform25 nutzen einen zentralen Manager, der Befehle auf Ressourcen pushed [KBL+19]. Diese Lösungen funktionieren nicht, wenn sich die Ressourcen hinter Sicherheitsbeschränkungen befinden. Puppet16 und Chef11 verwenden einen zentralen Manager und verteilte Agenten [KBL+19; Pup]. Beide Lösungen unterstützen aber kein TOSCA und verwenden HTTP zur Kommunikation zwischen dem Manager und den Agenten [MSDC22; Pup]. HTTP eignet sich jedoch schlechter für IoT-Geräte mit unzuverlässiger Verbindung als asynchrones Messaging. 2.5.7 Andere TOSCA Orchestratoren Neben dem in dieser Arbeit entwickelten Orchestrator, der im Agentenprototyp integriert ist, gibt es andere Implementierungen für TOSCA. Es werden im Folgenden mehrere ausgewählte Orchestratoren betrachtet. OpenTOSCA OpenTOSCA17 ist ein Ökosystem bestehend aus Eclipse Winery13 und dem TOSCA-1.0-basierten OpenTOSCA Container8 [BEK+16; II]. Eclipse Winery wird zum grafischen Modellieren von Anwendungen verwendet und der Container zum Provisionieren und Managen 15http://www.dmtf.org/standards/ovf und ISO Standart 17203 (zuletzt besucht 28.09.2022) 16https://puppet.com/ (zuletzt besucht 28.09.2022) 17https://www.opentosca.org/ (zuletzt besucht 28.09.2022) 34 http://www.dmtf.org/standards/ovf https://puppet.com/ https://www.opentosca.org/ 2.5 Related Work der in TOSCA modellierten Anwendungen. Ergänzend zu dem zentralen Orchestrator gibt es viele wissenschaftliche Arbeiten wie [KBL+19] oder [WBK+20], die Konzepte erforschen oder den Funktionsumfang erweitern. xOpera Bei xOpera18 handelt es sich um ein Open Source in Python entwickelten Orchestrator [LCM22]. Dieser verwendet TOSCA 1.3 und unterstützt Ansible19 Playbooks als Implementierungen für Operationen [LCM22]. Cloudify Cloudify20 ist eine Open Source Plattform mit TOSCA Orchestrator und einem Modellierungswerkzeug [LSC20]. Cloudify verwendet eine eigene auf TOSCA basierende Domain Specific Language (DSL) [EoB+20]. Neben der eigenen DSL hat Cloudify viele eingebaute abstrakte Node Types, die das Modellieren vereinfachen [NtM+22]. Cloudify bietet zum Beispiel Plugins für Skripte, Ansible Playbooks, AWS9 oder Kubernetes7. Manche dieser Plugins stellen vorgefertigte Node Types bereit, um Ressourcen zu modellieren [ENo+22]. Für das Deployment unterstützt Cloudify verteilte Agenten [NAoi22]. Die Agenten kommunizieren per AMQP21 Messaging und HTTPS mit einer zentralen Managerkomponente [NAoi22]. Dadurch ist Kommunikation trotz Sicherheitsbeschränkungen, welche eingehende Verbindungen blockieren, möglich. Jedoch können Cloudify-Agenten immer nur einzelne Operationen ausführen und nicht autonom ganze Subgraphen mit mehreren Node Templates provisionieren. Yorc Yorc22 ist ein Open Source Orchestrator für TOSCA 1.2 [AGB21]. Er unterstützt als Implementierungen für Operationen Bash und Python Skripte sowie Ansible Playbooks [AGB21]. Darüber hinaus hat der Orchestrator eine Plugin Schnittstelle, um weitere Implementierungsarten zu unterstützen [AGB21]. Außerdem verwendet das Alien4Cloud23 Projekt Yorc als einen TOSCA Orchestrator [fra21]. Unfurl Unfurl24 ist ein Open Source Orchestrator, der für ein Projekt das TOSCA 1.3 Modell, alle Implementierungen, Workflows und den Status der verwendeten Ressourcen und Services in einem Git-Repository speichert [Oneb]. Er unterstützt unter anderem Ansible Playbooks, verschiedene Skriptsprachen und Terraform25 in Operationen und zum Beispiel Kubernetes7 oder Docker26 über mitgelieferte Node Types. Unfurl verfolgt einen Ansatz, der keine Server oder Agenten verwendet [Sj22]. Der Orchestrator arbeitet mit Befehlen über eine Kommandozeilenschnittstelle und verwaltet Projekte in Ordnern [Sj22]. Unfurl ermöglicht einen GitOps-basierten Workflow, da Änderungen am Zustand oder der Konfiguration der verwalteten Ressourcen und Komponenten in ein Git-Repository synchronisiert werden [Onea]. 18https://github.com/xlab-si/xopera-opera/ (zuletzt besucht 28.09.2022) 19https://www.ansible.com/ (zuletzt besucht 28.09.2022) 20https://cloudify.co/ (zuletzt besucht 28.09.2022) 21https://www.amqp.org/ und ISO/IEC Standard 19464 (zuletzt besucht 28.09.2022) 22https://github.com/ystia/yorc/ (zuletzt besucht 28.09.2022) 23https://alien4cloud.github.io/ (zuletzt besucht 28.09.2022) 24https://unfurl.run/ (zuletzt besucht 28.09.2022) 25https://www.terraform.io/ (zuletzt besucht 28.09.2022) 26https://www.docker.com/ (zuletzt besucht 28.09.2022) 35 https://github.com/xlab-si/xopera-opera/ https://www.ansible.com/ https://cloudify.co/ https://www.amqp.org/ https://github.com/ystia/yorc/ https://alien4cloud.github.io/ https://unfurl.run/ https://www.terraform.io/ https://www.docker.com/ 3 Konzept für die Entwicklung eines Multiagentensystems Um die in Abschnitt 1.1 definierten Ziele für ein dezentralisiertes und TOSCA-basiertes Soft- waredeployment in eine heterogene organisationsübergreifende Multicloud- und IoT-Umgebung zu ermöglichen, werden in diesem Kapitel mehrere Konzepte erarbeitet. Das Deploymentkonzept setzt auf kooperierende Agenten, die jeweils möglichst autonom Teile des Deployments ausfüh- ren. Wooldridge [Woo02] beschreibt einen Agenten als ein System, das sich in einer Umgebung befindet und autonom Aktionen in dieser ausführen kann, um sein Ziel zu erreichen. Es gibt aber unterschiedliche Definitionen für einen Agenten in unterschiedlichen Fachbereichen [Woo02]. Um das verteilte Deployment über Agenten zu ermöglichen, muss ein Konzept erarbeitet werden, um Node Templates in einer mit TOSCA modellierten Anwendung, einem Agenten zuzuordnen. Die Zuordnung sollte dabei mit existierenden TOSCA Features umgesetzt werden und nicht durch die Einführung einer Erweiterung. Dadurch ist das resultierende Service Template kompatibel zu anderen Modellierungswerkzeugen. Das Konzept, um diese Zuordnung zu realisieren, ist in Abschnitt 3.1 näher beschrieben. Für modellierte Anwendungen werden außerdem keine Geräte oder Instanzen als Node Templates in das Service Template integriert. Im Service Template sind nur Anwendungskomponenten enthalten und diese werden direkt auf dem Gerät installiert, auf dem sich der Agent befindet. Dadurch müssen Organisationen keine Details über die verwendeten Geräte oder ihre Infrastruktur untereinander teilen. Die Agenten erlauben ein teilautonomes und asynchrones Deployment auszuführen. Dabei kann ein Agent alle Komponenten einer Software, die auf dem lokalen Gerät installiert werden sollen, anhand des TOSCA Modells bestimmen und die notwendigen Operationen weitgehend autark ausführen. Dabei ist es wichtig, dass nur die notwendigen Teile des Deploymentmodells auf jeden Agenten übertragen werden. Um das zu ermöglichen werden in, Abschnitt 3.2 mehrere Ansätze vorgestellt und miteinander verglichen, um ein TOSCA Modell in unterschiedliche Subgraphen aufzuteilen. Um ein dezentrales Deployment auszuführen, gibt es Anforderungen an die Kommunikation der Agenten untereinander. Diese wurden von Kopp und Breitenbücher [KB17] für die ver- teilte Ausführung von Workflows beschrieben. Basierend darauf werden in Abschnitt 3.3 die Kommunikationsanforderungen für ein deklaratives Modell erarbeitet und eine MQTT-basierte Kommunikationsarchitektur beschrieben. Um den gleichen CSAR mehrfach provisionieren zu können, wird in Abschnitt 3.3.1 ein Konzept präsentiert, um DeploymentIDs in die Kommunikati- onsarchitektur zu integrieren. Um zu verhindern, dass im Fall eines kompromittierten Agenten ein Angreifer Zugriff auf alle Properties und Attribute bekommt, wird die Kommunikationsarchitektur in Abschnitt 3.3.2 um ein Sicherheits- und Visibilitykonzept für Properties und Attribute erweitert. Das Sicherheitskonzept verhindert auch, dass ein Agent über MQTT Zugriff auf alle Subgraphen erhält. Viele Cloud-Provider bieten eine automatisierte Skalierung der verwendeten Ressourcen an. So können zum Beispiel neue virtuelle Maschinen gestartet werden, wenn mehr Leistung benötigt 37 3 Konzept für die Entwicklung eines Multiagentensystems wird. Um diesen Anwendungsfall abzubilden, ist in Abschnitt 3.4 ein Konzept beschrieben, um das dynamische Hinzufügen weiterer Agenten für einen bestimmten Subgraphen zu unterstützen. Der letzte Abschnitt dieses Kapitels beschreibt einen GitOps-basierten Workflow für TOSCA, um die Zusammenarbeit an einem zentralen Modell für alle Entwickler zu erleichtern. Auch organisationsübergreifende Zusammenarbeit wird erleichtert, da die Entwickler unterschiedlicher Organisationen in einem zentralen Repository zusammenarbeiten können. Der Workflow ermöglicht es Änderungen einem Review zu unterziehen und in einer Versionshistorie zu speichern. 3.1 Integration von Agenten in TOSCA Modelle Um das Deployment eines Service Templates über verteilte Agenten zu ermöglichen, muss jeder Agent wissen, welches Node Template ihm zugeordnet ist. Diese Zuordnung ist eine Liste von Node Templates für jeden Agenten. Diese Liste kann entweder separat vorliegen oder direkt in das Service Template integriert werden. Die Integration in ein Service Template bietet Vorteile gegenüber einer separaten Liste. Durch die Integration kann die Zuordnung mit den gleichen Werkzeugen modelliert werden, mit denen sonst auch das Service Template selbst bearbeitet und erstellt wird. Das reduziert die Wahrscheinlichkeit von Fehlern, wenn entweder das Service Template oder die Zuordnung bearbeitet wird. Weiterhin ist direkt anhand des Service Templates ersichtlich, welche Node Templates welchem Agenten zugeordnet sind. Es ist daher Ziel dieser Arbeit, die Zuordnung zwischen Node Templates und Agenten direkt in das Service Template zu integrieren. Weiterhin ist es vorteilhaft, wenn die Repräsentation der Zuordnung kompatibel mit der TOSCA Spezifikation ist. Spezielle Erweiterungen des Sprachumfangs wie zum Beispiel die Erweiterung für EDMM von Wurster et al. [WBB+21] hätten den Nachteil, dass diese nicht von anderen TOSCA-kompatiblen Werkzeugen unterstützt werden. Es ist daher das Ziel, die Zuordnung von Node Templates zu Agenten mit vorhanden TOSCA Features in Service Templates zu integrieren. Agenten sollten nicht als eigene Entitäten, wie zum Beispiel Node Templates modelliert werden, da sie mehrere Node Templates beinhalten können. Weiterhin sind die Agenten selbst keine Komponente der zu modellierenden Anwendung. Es gibt mehrere Möglichkeiten eine Zuordnung zwischen Node Template und Agenten vorzunehmen. Die folgenden Features wurden identifiziert, um eine solche Zuordnung zu repräsentieren: spezielle Properties, spezielle Metadaten, Directives, Policies und Groups. Die einzelnen Möglichkeiten werden im Folgenden erklärt. Spezielle Properties Properties sind Schlüsselwertpaare, die einem Node Template zugeordnet werden können. Um Properties für die Zuordnung von Node Templates zu Agenten zu benut- zen, wird ein Property mit einem speziellen Namen definiert. Das Property kann zum Beispiel „AGENT_NAME“ heißen. Diesem Property wird in der Definition des Node Templates der Namen des für ihn zuständigen Agenten als Wert zugewiesen. Während des Deployments werden alle Node Templates mit dem Property „AGENT_NAME“ identifiziert und anhand des gesetzten Namens einem Agenten zugeordnet. Die Verwendung von Properties hat den Nachteil, dass jedes Node Template um das neue Property erweitert werden muss. Auch muss das Property in jedem Node Template angepasst werden, wenn die Node Templates in einem anderem TOSCA Modell wiederverwendet werden. Weiterhin beschreibt die TOSCA Spezifikation Properties als Inputs für Node Templates [OAS20b]. Diese Inputs repräsentieren den gewünschten Zustand, in dem sich ein Node Template nach dem Deployment befinden soll [OAS20b]. Wird ein Property als Indikator für 38 3.1 Integration von Agenten in TOSCA Modelle die Zuordnung zu einem Agenten verwendet, ist das Property kein Input für das Node Template, sondern für den Orchestrator. Daher widerspricht diese Verwendung der von TOSCA vorgesehenen Semantik. Eine weitere Einschränkung dieser Lösung ist, dass sich die Zuordnung von Agenten auf Node Templates nicht weiter beschränken lässt. Es kann zum Beispiel nicht modelliert werden, dass Agenten nur spezielle Node Templates unterstützen. Spezielle Metadaten Die Verwendung von speziellen Metadaten funktioniert ähnlich wie die von Properties. Metadaten können in TOSCA für jedes Node Template definiert werden. Um ein Node Template einem Agenten zuzuordnen, wird in jedem Node Template ein spezielles Schlüsselwertpaar innerhalb der Metadaten definiert. Dieses Schlüsselwertpaar enthält den Namen des Agenten. Diese Lösung hat einerseits den Vorteil, dass sie anders als die spezielle Properties nicht gegen eine in der TOSCA Spezifikation definierte Semantik verstößt. Andererseits ist die Semantik der in den Metadaten enthaltenen Information, nicht genauer durch die TOSCA Spezifikation definiert. Dadurch können Modellierungswerkzeuge, welche für die TOSCA Spezifikation ohne diese Erweiterung entwickelt wurden, keine Unterstützung bei der Erstellung der Metadaten bieten. Directives Directives sind eine Liste von Strings, die jedem Node Template zugeordnet werden können, um einem Orchestrator weitere Instruktionen zur Verarbeitung mitzuteilen [OAS20b]. Die Spezifikation enthält eine Liste der möglichen Strings, welche für die Zuordnung von Node Templates zu einem Agenten erweitert wird. Jeder neue String enthält eine Zuordnung. Wird das Node Template „TemperaturSensor“ dem Agenten „TemperaturAgent“ zugeordnet, lautet der Directive String „AgentMapping:TemperaturAgent“. Dieser String wird dem „TemperaturSensor“ Node Template als Directive hinzugefügt. Nachteilig an dieser Lösung ist, dass die Spezifikation eine Liste aller definierten Directives enthält. Die Verwendung nicht definierter Directive Strings könnte zu Verarbeitungsproblemen in externen Modellierungs- und Validierungswerkzeugen führen. Policies und Groups Policies und Groups erlauben es, Node Templates in Gruppen zusam- menzufassen. Bei Policies wird der Keyname targets verwendet, um eine Liste an Node Templates zu definieren, auf welche die Policy angewendet wird [OAS20b]. Bei Groups wird dagegen der members Keyname verwendet, um Node Templates einer Gruppe zuzuweisen. Policies und Groups sind typisierte TOSCA Features [OAS20b]. Groups haben einen Group Type und Policies haben einen Policy Type. In den Typen ist es möglich, Einschränkungen der erlaubten Node Types zu definieren. Dadurch können nur Node Templates mit einem erlaubten Node Type der Group oder Policy hinzugefügt werden. So ist es unter anderem möglich sicherzustellen, dass modellierte externe Dienste wie zum Beispiel Software-as-a-Service (SaaS) Anwendungen nicht einem Agenten zum Provisionieren zugeordnet werden können. Modellierungswerkzeuge können diese Einschränkungen ohne Anpassungen unterstützen, da sie in der TOSCA Spezifikation enthaltene Features nutzen [OAS20b]. Weiterhin können Model- lierungswerkzeuge bei der Erstellung von Policies oder Groups unterstützen. Dafür müssen die Modellierungswerkzeuge keine Agenten unterstützen, sondern nur die TOSCA Spezifikation. Aus syntaktischer Sicht eignen sich beide Features, um die Zuordnung abzubilden. Die TOSCA Spezifikation definiert aber unterschiedliche Semantiken für beide Features. Policies sind laut der TOSCA Spezifikation nicht funktionale Anforderungen wie Quality-of-Service Ziele oder Zahlungsbedienungen, die auf eine Menge an Node Templates angewendet werden [OAS20b]. Groups sind als logische Gruppen, typischerweise für Managementziele, beschrieben [OAS20b]. 39 3 Konzept für die Entwicklung eines Multiagentensystems Die Semantik des Group Features passt besser, da es sich bei der Zuordnung zwischen Node Templates und Agenten um eine funktionale Anforderung handelt. Werden die Node Templates nicht korrekt verteilt, können manche Funktionalitäten nicht umgesetzt werden. Weiterhin lassen sich Policies auf Groups anwenden. Dadurch ist es möglich eine Policy zum Beispiel auf alle Node Templates eines Agenten anwenden, da alle Node Templates in einer Group enthalten sind. Alle gezeigten Möglichkeiten erlauben es, Node Templates den Agenten zuzuordnen. Am besten geeignet ist das Group Feature der TOSCA Spezifikation, da die Semantik des TOSCA Features am besten den Anforderungen entspricht und sich die kompatiblen Node Types einschränken lassen. Auch können Modellierungs- und Validierungswerkzeuge dieses Feature ohne spezielle Anpassungen für die Konzepte dieser Arbeit unterstützen. Deshalb wird in dieser Arbeit das Group Feature ausgewählt, um die Zuordnung von Node Templates zu Agenten umzusetzen. Dazu wird der Group Type „AgentGroupDefinition“ definiert. Jede Group von diesem Type repräsentieren jeweils einen Agenten. Einem Agenten können Node Templates zugeordnet werden, indem sie der members Liste hinzugefügt werden. Ein Service Template mit diesen Groups ist zu der TOSCA Spezifikation kompatibel. Orchestratoren, die keine Unterstützung für Agenten bieten, ignorieren diese Groups. Unterstützt ein Orchestrator das verteilte Deployment über Agenten, erkennt er den speziellen Group Type mit dem Namen „AgentGroupDefinition“. 3.2 Generierung von Modell-Subgraphen Dieser Abschnitt beschreibt, wie ein deklaratives TOSCA Modell einer Anwendung in mehrere Subgraphen aufgeteilt werden kann. Dazu werden im Folgenden mehrere Ansätze vorgestellt und miteinander verglichen. Es wird für jeden Agenten ein individueller Subgraph erstellt, der alle dem Agenten zugewiesenen Node und Relationship Templates umfasst. Aus den individuellen deklarativen Subgraphen kann jeder beteiligte Agent selbstständig lokal seinen eigenen Deployment- Workflow mit dem von Breitenbücher et al. [BBK+14] beschriebenen Verfahren ableiten. Der Workflow umfasst alle zur Provisionierung notwendigen Operationen für jedes Template des individuellen Subgraphs. Die im Folgenden präsentierten Ansätze, um Subgraphen aus der gesamten Anwendungstopologie zu generieren, haben unterschiedliche Vor- und Nachteile. Es kann zum Beispiel vorteilhaft sein, in den Subgraph jedes Agenten noch weitere Informationen aus anderen Teilen der Topologie einzubetten. Agenten können mit Zugriff auf mehr Informationen oft autonomer arbeiten. So kann eine Operation auf einem Agent Properties von Node Templates, die einem anderen Agenten zugeordnet sind, benötigen. Sind diese Properties direkt im Subgraph des ersten Agenten enthalten, müssen die Properties nicht während des Deployments von dem anderen Agenten abgerufen werden. Das spart den Overhead einer Nachrichtenübertragung und erhöht die Autonomie des Agenten. Jedoch hat es auch Nachteile, mehr Informationen in ein Subgraph einzubetten. Einerseits erhöhen nicht benötigte Informationen unnötig die Größe der Subgraphen, die auf die Agenten übertragen werden. Anderseits sind mehr Informationen bedroht, wenn ein Agent gestohlen oder kompromittiert wird. Die Ansätze unterscheiden sich nicht nur in der Menge der Informationen, die zusätzlich in die Subgraphen eingebettet werden, sondern auch in weiteren Punkten. Für manche Ansätze müssen zum 40 3.2 Generierung von Modell-Subgraphen JavaRuntime (Java_17_Runtime) DataProcessor (JavaApplication) Database (MySqlDatabase) ApplicationServer (Tomcat) TemperaturTopic (MQTT_Topic) Name: Temperatur MQTTBroker (Mosquitto) IP: ... TemperaturAgent DataProcessingAgent DatabaseAgent = (connectsTo) = (hostedOn) Username: user Password: pass TemperaturSensor (JavaApplication) Abbildung 3.1: Beispiel für die Repräsentation von Agenten in einem Service Template. Die Node Templates sind in drei Gruppen aufgeteilt, die jeweils einem Agenten zugeordnet sind. Attributes haben den Wert „...“, da diese erst während des Deployments bestimmt werden. [Notation basiert auf Vino4TOSCA BBK+12] Beispiel bei der Erstellung des Modells der Anwendung bestimmte Regeln oder Einschränkungen beachtet werden. Die einzelnen Ansätze werden in den Abschnitten 3.2.1 bis 3.2.5 näher beschrieben und in den Abschnitten 3.2.6 und 3.2.7 miteinander verglichen. In Abbildung 3.1 ist eine Anwendung abgebildet, die als Beispiel für die weiteren Abschnitte verwendet wird. Einige Properties und alle Operationen wurden zur Vereinfachung nicht abgebildet. Jedes Node und Relationship Template hat aber alle Operationen des in der TOSCA Spezifikation Version 1.3 [OAS20a] beschriebenen Lifecycle Interfaces, um den Lebenszyklus der Templates kontrollieren zu können. Die Anwendung besteht aus einer Java Anwendung, die Temperaturdaten über einen Sensor erfasst und auf der JavaRuntime läuft. Die Temperaturdaten werden über MQTT an einen Temperatur Topic weitergegeben. Der „DataProcessor“ ist auf diesen Topic subscribed und verarbeitet die Daten, bevor sie in einer Datenbank gespeichert werden. Der Topic ist auf einem MQTT Broker gehostet und der DataProcessor auf einem Tomcat1 Application Server. Die Node Templates sind auf Agenten verteilt, welche jeweils für das Deployment der ihnen zugeordneten Node Templates zuständig sind. Die Node Templates, die einem Agenten zugeteilt sind, werden im Folgenden als lokale Node Templates des Agenten bezeichnet. Relationship Templates, die zwei lokale Node Templates verbin- den, werden lokale Relationship Templates genannt. Node Templates von anderen Agenten, sind externe Node Templates. So ist der TemperaturSensor und die JavaRuntime dem TemperaturAgent zugeordnet. Für den TemperaturAgent sind beide Node Templates lokal, während sie für den DatabaseAgent extern sind. Dem DatabaseAgent ist das Node Template Database zugeordnet. Der Rest aller abgebildeten Node Templates wird vom DataProcessingAgent provisioniert. Nicht alle Node Templates müssen einem Agenten zugeordnet sein. Externe Dienste wie SaaS Angebote, die nicht während des Deployments gestartet werden müssen, können als Node Template modelliert werden, benötigen aber keinen Agenten. Jeder Agent muss über alle Informationen über die ihm zugeordneten Node und Relationship Templates verfügen, sonst kann er sie nicht provisionieren. Er muss alle lokalen Operationen kennen, um sie ausführen zu können. Weiterhin benötigt er zum Beispiel alle Node Types, Interfaces und 1https://tomcat.apache.org/ (zuletzt besucht 28.09.2022) 41 https://tomcat.apache.org/ 3 Konzept für die Entwicklung eines Multiagentensystems Artifacts welche von lokalen Node Templates verwendet werden. Deshalb werden bei jedem Ansatz die Subgraphen als Service Templates in einem CSAR übertragen. Die Service Templates enthalten alle in dem Subgraph verwendeten Types und Interfaces. Die für das Deployment notwendigen Implementation und Deployment Artifacts befinden sich zusammen mit dem Service Template im CSAR. Rela