Erste Schritte mit der direkten Codebereitstellung von Amazon Bedrock AgentCore Runtime
Die direkte Codebereitstellung ermöglicht es Ihnen, Ihren Agenten zu Amazon Bedrock AgentCore Runtime zu bringen, indem Sie den Agentencode und seine Abhängigkeiten einfach in einem ZIP-Dateiarchiv verpacken. Ihr Agent muss weiterhin die AgentCore Runtime-Anforderungen erfüllen.
Um Ihr Bereitstellungspaket als ZIP-Dateiarchiv zu erstellen, können Sie AgentCore CLIzip-Befehlszeilen-Tool in einer Linux- oder MacOS-Umgebung verwenden. Um dieselben Befehle in Windows zu verwenden, können Sie das Windows-Subsystem für Linux installieren, um eine Windows-integrated Version von Ubuntu und Bash
Beachten Sie, dass AgentCore Runtime POSIX-Dateiberechtigungen verwendet. Daher müssen Sie möglicherweise die Berechtigungen für den Bereitstellungspaketordner festlegen
Themen
Konzepte der direkten Codebereitstellung
Erfahren Sie mehr über die wichtigsten Konzepte bei der direkten Codebereitstellung mit Amazon Bedrock AgentCore Runtime.
Themen
Amazon Bedrock AgentCore Runtime mit direkter Codebereitstellung verwendet ein Modell der gemeinsamen Verantwortung, das AWS Lambda ähnelt. AgentCore Runtime verwaltet die Laufzeitumgebung der Sprache und wendet Sicherheitspatches automatisch an, während Sie sich auf Ihren Agentencode und Ihre Abhängigkeiten konzentrieren können.
Wenn Sie Container-Images für die Bereitstellung Ihrer Agenten verwenden, ist AgentCore Runtime dafür verantwortlich, nur den Compute-Kernel zu patchen. In diesem Fall sind Sie dafür verantwortlich, das Container-Image Ihres Agenten aus dem neuesten sicheren Image neu zu erstellen und das Container-Image erneut bereitzustellen.
Dies ist in der folgenden Tabelle zusammengefasst:
| Bereitstellungsmodus | AgentCore Die Verantwortung von Runtime | Deine Verantwortung |
|---|---|---|
|
Direkter Bereitstellungsmodus |
Veröffentlichen Sie eine neue Language Runtime-Version, die die neuesten Patches für Language Runtime enthält. Wenden Sie Language Runtime-Patches auf bestehende AgentCore Runtime Direct Deploy an. |
Aktualisieren Sie Ihren Agentencode, einschließlich der Abhängigkeiten, um etwaige Sicherheitslücken zu schließen. |
|
Container-Image |
Patchen Sie den zugrunde liegenden Compute-OS-Kernel automatisch mit der neuesten Version. |
Aktualisieren Sie Ihren Agentencode, einschließlich der Abhängigkeiten, um etwaige Sicherheitslücken zu schließen. Erstellen Sie Ihr Container-Image regelmäßig neu und stellen Sie es erneut bereit, indem Sie das neueste Basis-Image verwenden. |
Weitere Informationen zur geteilten Verantwortung mit finden Sie AWS unter Modell der geteilten Verantwortung
AgentCore Runtime hält jede Runtime zur direkten Codebereitstellung mit Sicherheitsupdates, Bugfixes, neuen Funktionen, Leistungsverbesserungen und Unterstützung für kleinere Versionen auf dem neuesten Stand. Diese Runtime-Updates werden als Runtime-Versionen veröffentlicht. AgentCore Runtime wendet Runtime-Updates zur direkten Codebereitstellung auf Agenten an, indem die Agenten von einer früheren Runtime-Version zu einer neuen Runtime-Version migriert werden.
Bei Runtimes zur direkten Bereitstellung wendet AgentCore Runtime Updates automatisch an. Bei automatischen Runtime-Updates übernimmt AgentCore Runtime den operativen Aufwand für das Patchen der Runtime-Versionen. Für die meisten Kunden sollte dies eine sichere Wahl sein, da nur Language Runtime-Patches automatisch angewendet werden und die Kunden selbst dafür verantwortlich sind, ihre Codeabhängigkeiten mitzubringen und zu verwalten. Derzeit unterstützt AgentCore Runtime keine Änderung dieses automatisierten Patch-Verhaltens.
AgentCore Runtime ist bestrebt, Runtime-Updates bereitzustellen, die mit bestehenden Funktionen abwärtskompatibel sind. Wie beim Software-Patching gibt es jedoch seltene Fälle, in denen sich eine Laufzeitaktualisierung negativ auf eine vorhandene Funktion auswirken kann. Beispielsweise können Sicherheits-Patches ein zugrunde liegendes Problem mit einer vorhandenen Funktion aufdecken, das vom vorherigen, unsicheren Verhalten abhängt. Wenn dieses Risiko in extrem seltenen Fällen nicht akzeptabel ist, verwenden Sie bitte Container-Images, um Ihren Agenten bereitzustellen.
Einige der Dimensionen des Vergleichs, um zu sehen, wie sich eine Option von der anderen unterscheidet, sodass es hilfreich ist, die richtige Option auszuwählen
-
Bereitstellungsprozess: Bei der direkten Codebereitstellung werden Agenten mithilfe von ZIP-Dateien anstelle von Containern bereitgestellt, was sich für schnellere Entwicklungsiterationen eignet.
-
Bereitstellungszeit: Obwohl es bei der ersten Bereitstellung eines Agenten keinen großen Unterschied gibt, sind nachfolgende Updates für den Agenten bei der direkten Codebereitstellung erheblich schneller.
-
Anpassung: Direkter Code unterstützt benutzerdefinierte Abhängigkeiten durch ZIP-based Paketierung bei gleichzeitiger Beibehaltung der Einfachheit der Bereitstellung, während der containerbasierte Code von einer Docker-Datei abhängt.
-
Paketgröße: Die direkte Codebereitstellung begrenzt die Paketgröße auf 250 MB, wohingegen containerbasierte Pakete eine Größe von bis zu 2 GB haben können.
-
Rate der Sitzungserstellung: Die direkte Codebereitstellung ermöglicht eine höhere Anzahl von 25 neuen Sitzungen sessions/second im Vergleich zu 1,6 neuen Sitzungen sessions/second bei containerbasierten Bereitstellungen.
Unsere allgemeine Anleitung lautet
-
Wenn die Größe des Bereitstellungspakets 250 MB überschreitet und Sie bereits über CI/CD Container-Pipelines verfügen und hochspezialisierte Abhängigkeiten und Paketierungen benötigen, sind containerbasierte Bereitstellungen eine gute Option.
-
Wenn die Größe des Bereitstellungspakets klein ist, der Code und das Paket nicht komplex zu erstellen sind und gemeinsame Frameworks und Sprachen verwendet werden und Sie schnelle Prototypenerstellung und Iteration benötigen, dann wäre die direkte Codebereitstellung die Option.
Es kann auch eine Hybridoption geben, bei der Entwickler die direkte Codebereitstellung verwenden, um schnell mit Agenten zu experimentieren und Prototypen zu erstellen, und dann (aus den oben genannten Gründen) zu containerbasierten Bereitstellungen wechseln, um sie zu entwickeln, zu testen und in der Produktion bereitzustellen.
