View a markdown version of this page

Bewährte Methoden für Container-Images - AWS HealthOmics

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bewährte Methoden für Container-Images

Folgen Sie diesen bewährten Methoden, wenn Sie Container-Images für erstellen HealthOmics Arbeitsabläufe.

Verwendung von Java in Amazon ECR-Container-Images

Wenn eine Workflow-Aufgabe eine Java-Anwendung wie GATK verwendet, berücksichtigen Sie die folgenden Speicheranforderungen für den Container:

  • Java-Anwendungen verwenden Stack-Speicher und Heap-Speicher. Standardmäßig ist der maximale Heap-Speicher ein Prozentsatz des gesamten verfügbaren Speichers im Container. Diese Standardeinstellung hängt von der jeweiligen JVM-Distribution und der JVM-Version ab. Konsultieren Sie daher die entsprechende Dokumentation für Ihre JVM oder legen Sie das Heap-Speichermaximum explizit mithilfe von Java-Befehlszeilenoptionen fest (wie -Xmx).

  • Stellen Sie den maximalen Heap-Speicher nicht auf 100% der Speicherzuweisung des Containers ein, da der JVM-Stack ebenfalls Speicher benötigt. Speicher wird auch für den JVM-Garbage Collector und alle anderen Betriebssystemprozesse benötigt, die im Container ausgeführt werden.

  • Einige Java-Anwendungen, wie GATK, können native Methodenaufrufen oder andere Optimierungen wie Speicherzuordnungsdateien verwenden. Diese Techniken erfordern Speicherzuweisungen, die „off-Heap“ ausgeführt werden, was durch den JVM-Parameter für den maximalen Heap nicht gesteuert wird.

    Wenn Sie wissen (oder vermuten), dass Ihre Java-Anwendung Off-Heap-Speicher zuweist, stellen Sie sicher, dass Ihre Aufgabenspeicherzuweisung den Off-Heap-Speicheranforderungen entspricht.

    Wenn diese Off-Heap-Zuweisungen dazu führen, dass dem Container der Arbeitsspeicher ausgeht, wird in der Regel kein Java-Code angezeigt OutOfMemory Fehler, weil die JVM diesen Speicher nicht kontrolliert.

Fügen Sie Aufgabeneingaben zu einem Amazon ECR-Container-Image hinzu

Fügen Sie alle ausführbaren Dateien, Bibliotheken und Skripts, die für die Ausführung einer Workflow-Aufgabe erforderlich sind, in das Amazon ECR-Image ein, das zur Ausführung der Aufgabe verwendet wird.

Es empfiehlt sich, die Verwendung von Skripten, Binärdateien und Bibliotheken zu vermeiden, die sich außerhalb des Container-Images einer Aufgabe befinden. Dies ist besonders wichtig bei der Verwendung nf-core Workflows, die eine verwenden bin Verzeichnis als Teil des Workflow-Pakets. Dieses Verzeichnis steht zwar für die Workflow-Aufgabe zur Verfügung, es ist jedoch als schreibgeschütztes Verzeichnis bereitgestellt. Die erforderlichen Ressourcen in diesem Verzeichnis sollten in das Task-Image kopiert und zur Laufzeit oder beim Erstellen des für die Aufgabe verwendeten Container-Images verfügbar gemacht werden.

Siehe HealthOmics feste Größenkontingente für Workflows für die maximale Größe des Container-Images HealthOmics unterstützt.

Verwenden Sie für Bilder, die nicht von PTC stammen, einen Digest oder eine Version anstelle eines Tags

Verweisen Sie bei Container-Images aus Registern, die keinen Pull-Through-Cache unterstützen, wie Seqera, NVIDIA NGC und Google Artifact Registry, auf einen Digest oder eine Version statt auf ein Tag wie latest. HealthOmics kopiert ein Bild, wenn eine Aufgabe es zum ersten Mal benötigt, und aktualisiert die Kopie nicht, sodass ein Tag, das sich im Upstream ändert, immer wieder in die frühere Kopie aufgelöst wird. Weitere Informationen finden Sie unter Verwendung von Drittanbieter-Registrierungen, die vom Pull-Through-Cache nicht unterstützt werden.

Das folgende Beispiel referenziert ein Seqera Container-Image nach Version und Digest:

community.wave.seqera.io/library/htslib_samtools:1.24--d697cfb9dce007cd@sha256:a55ddea590e567a91df592300a960aa534cfc1bd16e7623e3938ec21f4f3df15