Container-Images in Amazon ECR für private Workflows

Bevor Sie einen privaten Workflow erstellen, erstellen Sie ein Container-Image für Ihren Workflow. Sie laden das Bild in ein privates Image-Repository in Amazon Elastic Container Registry (Amazon ECR) hoch. Wenn Sie den Workflow ausführen, greift der HealthOmics Service auf die Container zu, die Sie bereitstellen.

Das Amazon ECR-Repository für Container-Images muss sich in derselben AWS Region befinden wie das Konto, das den Service aufruft. Eine andere Person AWS-Konto kann Eigentümer des Container-Images sein, sofern das Quell-Image-Repository die entsprechenden Berechtigungen bietet. Weitere Informationen finden Sie unter Amazon Elastic Container Registry-Repository-Richtlinien für gemeinsam genutzte Workflows.

Wir empfehlen Ihnen, Ihr Amazon ECR-Container-Image URIs als Parameter in Ihrem Workflow zu definieren, damit der Zugriff verifiziert werden kann, bevor der Lauf beginnt. Es macht es auch einfacher, einen Workflow in einer neuen Region auszuführen, indem der Parameter Region geändert wird.

Anmerkung

HealthOmics unterstützt keine ARM-Container und unterstützt keinen Zugriff auf öffentliche Repositorys.

Informationen zur Konfiguration von IAM-Berechtigungen für den Zugriff HealthOmics auf Amazon ECR finden Sie unter. Ressourcenberechtigungen

Allgemeine Überlegungen zu Amazon ECR-Container-Images

• Architektur

  HealthOmics unterstützt x86_64-Container. Wenn Ihr lokaler Computer ARM-basiert ist (z. B. Apple Mac), verwenden Sie einen Befehl wie den folgenden, um ein x86_64-Container-Image zu erstellen:

  docker build --platform amd64 -t my_tool:latest .

• Entrypoint und Shell

  HealthOmics Workflow-Engines fügen Bash-Skripten als Befehlsüberschreibung in die Container-Images ein, die von Workflow-Aufgaben verwendet werden. Daher sollten Container-Images ohne einen angegebenen ENTRYPOINT erstellt werden, sodass eine Bash-Shell die Standardeinstellung ist.

• Bereitgestellte Pfade

  Ein gemeinsam genutztes Dateisystem wird in Container-Aufgaben unter /tmp eingehängt. Alle Daten oder Tools, die an diesem Ort in das Container-Image integriert sind, werden überschrieben.

  Die Workflow-Definition ist für Aufgaben über einen schreibgeschützten Mount unter /mnt/workflow verfügbar.

• Größe des Images

  Die maximalen Bildgrößen für Container finden Sie unterHealthOmics Workflow-Kontingente mit fester Größe.

Umgebungsvariablen für HealthOmics Workflows

HealthOmics stellt Umgebungsvariablen bereit, die Informationen über den im Container ausgeführten Workflow enthalten. Sie können die Werte dieser Variablen in der Logik Ihrer Workflow-Aufgaben verwenden.

Alle HealthOmics Workflow-Variablen beginnen mit dem AWS_WORKFLOW_ Präfix. Dieses Präfix ist ein geschütztes Umgebungsvariablenpräfix. Verwenden Sie dieses Präfix nicht für Ihre eigenen Variablen in Workflow-Containern.

HealthOmics stellt die folgenden Workflow-Umgebungsvariablen bereit:

AWS_REGION

Diese Variable ist die Region, in der der Container ausgeführt wird.

AWS_WORKFLOW_AUSFÜHREN

Diese Variable ist der Name des aktuellen Laufs.

AWS_WORKFLOW_RUN_ID

Diese Variable ist die Lauf-ID des aktuellen Laufs.

AWS_WORKFLOW_RUN_UUID

Diese Variable ist die Run-UUID des aktuellen Laufs.

AWS_WORKFLOW_AUFGABE

Diese Variable ist der Name der aktuellen Aufgabe.

AWS_WORKFLOW_TASK_ID

Diese Variable ist die Aufgaben-ID der aktuellen Aufgabe.

AWS_WORKFLOW_TASK_UUID

Diese Variable ist die Task-UUID der aktuellen Aufgabe.

Das folgende Beispiel zeigt typische Werte für jede Umgebungsvariable:

AWS Region: us-east-1
Workflow Run: arn:aws:omics:us-east-1:123456789012:run/6470304
Workflow Run ID: 6470304
Workflow Run UUID: f4d9ed47-192e-760e-f3a8-13afedbd4937
Workflow Task: arn:aws:omics:us-east-1:123456789012:task/4192063
Workflow Task ID: 4192063
Workflow Task UUID: f0c9ed49-652c-4a38-7646-60ad835e0a2e

Verwenden von Java in Amazon ECR-Container-Images

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

• Java-Anwendungen verwenden Stack-Speicher und Heap-Speicher. Standardmäßig ist der maximale Heap-Speicher ein Prozentsatz des gesamten verfügbaren Speichers im Container. Dieser Standard 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 maximale Heap-Speicherlimit explizit mithilfe von Java-Befehlszeilenoptionen (wie `-Xmx`) fest.

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

• Einige Java-Anwendungen, wie GATK, können native Methodenaufrufe oder andere Optimierungen wie Speicherzuordnungsdateien verwenden. Diese Techniken erfordern Speicherzuweisungen, die „außerhalb des Heaps“ erfolgen und nicht durch den JVM-Parameter „Maximum Heap“ gesteuert werden.

  Wenn Sie wissen (oder vermuten), dass Ihre Java-Anwendung Off-Heap-Speicher zuweist, stellen Sie sicher, dass Ihre Aufgabenspeicherzuweisung die Anforderungen an Off-Heap-Speicher berücksichtigt.

  Wenn diese Off-Heap-Zuweisungen dazu führen, dass dem Container nicht mehr genügend Speicher zur Verfügung steht, wird normalerweise kein OutOfMemory Java-Fehler angezeigt, da die JVM diesen Speicher nicht kontrolliert.

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

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

Es hat sich bewährt, die Verwendung von Skripten, Binärdateien und Bibliotheken zu vermeiden, die sich außerhalb eines Task-Container-Images befinden. Dies ist besonders wichtig, wenn nf-core Workflows verwendet werden, die ein bin Verzeichnis als Teil des Workflow-Pakets verwenden. Dieses Verzeichnis wird zwar für die Workflow-Aufgabe verfügbar sein, es ist jedoch als schreibgeschütztes Verzeichnis bereitgestellt. Erforderliche 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.

Die maximale Größe des HealthOmics unterstützten Container-Images finden HealthOmics Workflow-Kontingente mit fester Größe Sie unter.