BazelCon 2022 findet vom 16. bis 17. November in New York und online statt.
Jetzt anmelden

Bazel-Regeln für die Remote-Ausführung anpassen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Diese Seite richtet sich an Bazel-Nutzer, die benutzerdefinierte Build- und Testregeln schreiben, die die Anforderungen für Bazel-Regeln im Kontext der Remoteausführung verstehen möchten.

Remote-Ausführung ermöglicht es Bazel, Aktionen auf einer separaten Plattform auszuführen, z. B. in einem Rechenzentrum. Bazel verwendet ein gRPC-Protokoll für die Remote-Ausführung. Sie können die Remote-Ausführung mit bazel-buildfarm testen, einem Open-Source-Projekt, das eine verteilte Remote-Ausführungsplattform liefern soll.

Auf dieser Seite wird die folgende Terminologie verwendet, wenn es um verschiedene Umgebungstypen oder Plattformen geht:

  • Hostplattform, auf der Bazel ausgeführt wird
  • Ausführungsplattform: Hier werden die Bazel-Aktionen ausgeführt.
  • Zielplattform: Auf dieser Plattform werden die Build-Ausgaben (und einige Aktionen) ausgeführt.

Übersicht

Wenn Sie einen Build für die Remote-Ausführung konfigurieren, müssen Sie die auf dieser Seite beschriebenen Richtlinien einhalten, damit der Build fehlerfrei ausgeführt wird. Dies liegt an der Art der Remote-Ausführung, nämlich:

  • Isolierte Build-Aktionen. Build-Tools behalten den Zustand nicht bei und es können keine Abhängigkeiten zwischen ihnen auftreten.

  • Unterschiedliche Ausführungsumgebungen: Die lokale Build-Konfiguration ist nicht immer für Remote-Ausführungsumgebungen geeignet.

Auf dieser Seite werden die Probleme beschrieben, die beim Implementieren von benutzerdefinierten Bazel-Build- und Testregeln für die Remoteausführung auftreten können und wie sich diese vermeiden lassen. Folgende Themen werden behandelt:

Build-Tools über Toolchain-Regeln aufrufen

Eine Bazel-Toolchain-Regel ist ein Konfigurationsanbieter, der eine Build-Regel vorgibt, welche Build-Tools wie Compiler und Linker verwendet werden sollen und wie sie mit Parametern konfiguriert werden, die vom Ersteller der Regel definiert wurden. Eine Toolchain-Regel ermöglicht es, dass Build- und Testregeln Build-Tools auf vorhersehbare, vorkonfigurierte Weise aufrufen, die mit der Remote-Ausführung kompatibel sind. Verwenden Sie beispielsweise eine Toolchain-Regel, statt Build-Tools über PATH, JAVA_HOME oder andere lokale Variablen aufzurufen, für die in der Remote-Instanz möglicherweise keine entsprechenden Werte (oder überhaupt) festgelegt sind. Ausführungsumgebung

Toolchain-Regeln sind derzeit für Build- und Testregeln von Bazel für vorhanden.Scala ,Verrostete undGo und für andere Sprachen und Tools wieBash aus. Wenn für das Tool, das die Regel verwendet, keine Toolchain-Regel vorhanden ist, sollten Sie Toolchain-Regeln erstellen.

implizite Abhängigkeiten verwalten

Wenn ein Build-Tool auf Abhängigkeiten über Build-Aktionen zugreifen kann, schlagen diese Aktionen bei der Remote-Ausführung fehl, da jede Remote-Build-Aktion getrennt von anderen ausgeführt wird. Einige Build-Tools behalten den Status bei allen Build-Aktionen und Zugriffsabhängigkeiten bei, die nicht explizit im Toolaufruf enthalten sind, wodurch Remote-Ausführungs-Build-Aktionen fehlschlagen.

Wenn Bazel beispielsweise einen zustandsorientierten Compiler anweist, foo lokal zu erstellen, behält der Compiler Verweise auf die Build-Ausgaben von foo bei. Wenn Bazel dann den Compiler anweist, bar zu erstellen, was von foo abhängt, ohne explizit diese Abhängigkeit in der BUILD-Datei für die Aufnahme in {101 anzugeben }compiler-Aufrufs wird die Aktion erfolgreich ausgeführt, solange dieselbe kompilierte Instanz für beide Aktionen ausgeführt wird. Dies ist typisch für die lokale Ausführung. Da jedoch in einem Remote-Ausführungsszenario jede Build-Aktion eine separate Compiler-Instanz ausführt, gehen der Compiler-Zustand und die implizite Abhängigkeit von bar von foo verloren. und der Build schlägt fehl.

Um diese Abhängigkeitsprobleme zu erkennen und zu beheben, bietet Bazel 0.14.1 die lokale Docker-Sandbox, die für Einschränkungen die gleichen Einschränkungen wie die Remote-Ausführung hat. Verwenden Sie die Sandbox, um Ihren Build für die Remote-Ausführung vorzubereiten, indem Sie abhängigkeitsbezogene Build-Fehler identifizieren und beheben. Weitere Informationen finden Sie unter Fehlerbehebung bei der Bazel Remote-Ausführung mit Docker Sandbox.

Plattformabhängige Binärdateien verwalten

In der Regel kann eine auf der Hostplattform erstellte Binärdatei aufgrund von potenziell nicht übereinstimmenden Abhängigkeiten sicher auf einer beliebigen Remote-Ausführungsplattform ausgeführt werden. Beispielsweise verwendet die mit Bazel bereitgestellte SingleJar-Binärdatei die Hostplattform. Für die Remote-Ausführung muss SingleJar jedoch im Rahmen des Build-Codes für das Targeting auf die Remote-Ausführungsplattform kompiliert werden. Siehe Logik für die Zielauswahl.

Senden Sie keine Binärdateien von Build-Tools, die für Ihren Build erforderlich sind, mit Ihrem Quellcode, es sei denn, Sie sind sicher, dass sie sicher auf Ihrer Ausführungsplattform ausgeführt werden. Führen Sie stattdessen einen der folgenden Schritte aus:

  • Senden Sie den Quellcode für das Tool oder verweisen Sie ihn extern, damit er für die Remote-Ausführungsplattform erstellt werden kann.

  • Installieren Sie das Tool vorab in der Remote-Ausführungsumgebung (z. B. einem Toolchain-Container), wenn es stabil genug ist, und verwenden Sie Toolchain-Regeln, um es in Ihrem Build auszuführen.

WORKSPACE-Regeln im Konfigurationsstil verwalten

Die WORKSPACE-Regeln von Bazel können zum Testen der Hostplattform auf Tools und Bibliotheken angewendet werden, die für den Build erforderlich sind. Für lokale Builds ist er auch die Ausführungsplattform von Bazel. Wenn der Build explizit von lokalen Build-Tools und Artefakten abhängt, schlägt er während der Remote-Ausführung fehl, wenn die Remote-Ausführungsplattform nicht mit der Host-Plattform identisch ist.

Die folgenden mit WORKSPACE-Regeln ausgeführten Aktionen sind nicht mit der Remote-Ausführung kompatibel:

  • Binärdateien erstellen: Die Ausführung von Kompilierungsaktionen in WORKSPACE-Regeln führt zu Binärdateien, die mit der Remote-Ausführungsplattform nicht kompatibel sind, sofern sie von der Hostplattform abweichen.

  • pip-Pakete installieren Die über WORKSPACE-Regeln installierten pip-Pakete erfordern, dass ihre Abhängigkeiten auf der Hostplattform vorinstalliert sind. Solche Pakete, die speziell für die Hostplattform erstellt wurden, sind nicht mit der Remote-Ausführungsplattform kompatibel, wenn sie sich von der Hostplattform unterscheidet.

  • Symlinking zu lokalen Tools oder Artefakten. Symlinks zu Tools oder Bibliotheken, die auf der Hostplattform installiert sind, die mit WORKSPACE-Regeln erstellt wurde, führen zu einem Fehler beim Build auf der Remote-Ausführungsplattform, da Bazel sie nicht finden kann. Erstellen Sie stattdessen Symlinks mit Standard-Build-Aktionen, damit die symlinken Tools und Bibliotheken über die runfiles-Struktur von Bazel zugänglich sind. Verwenden Sie repository_ctx.symlink nicht, um Zieldateien außerhalb des externen Repository-Verzeichnisses zu symlinken.

  • Hostplattform mutieren Erstellen Sie keine Dateien außerhalb des Bazel-Baums runfiles und erstellen Sie keine Umgebungsvariablen und ähnlichen Aktionen, da diese möglicherweise unerwartet auf der Remote-Ausführungsplattform funktionieren.

Mit dem Log für Arbeitsbereichsregeln können Sie potenzielle nicht hermetische Verhaltensweisen ermitteln.

Wenn eine externe Abhängigkeit bestimmte Vorgänge ausführt, die von der Hostplattform abhängig sind, sollten Sie diese Vorgänge so zwischen WORKSPACE und Build-Regeln aufteilen:

  • Aufzählung der Plattformen und Abhängigkeiten: Diese Vorgänge können lokal über Regeln vom Typ WORKSPACE ausgeführt werden, mit denen geprüft werden kann, welche Bibliotheken installiert sind, Pakete, die erstellt werden müssen, herunterladen und die erforderlichen Artefakte für die Kompilierung vorbereiten. Für die Remote-Ausführung müssen diese Regeln auch die Verwendung von vorab geprüften Artefakten unterstützen, um die Informationen bereitzustellen, die normalerweise bei der Prüfung der Host-Plattform abgerufen werden würden. Mit vorab geprüften Artefakten kann Bazel Abhängigkeiten beschreiben, als wären sie lokal. Verwenden Sie dazu bedingte Anweisungen oder das Flag --override_repository.

  • Zielspezifische Artefakte und Plattformmutation generieren oder kompilieren Diese Vorgänge müssen mit regulären Build-Regeln ausgeführt werden. Aktionen, die zielspezifische Artefakte für externe Abhängigkeiten erzeugen, müssen während des Builds ausgeführt werden.

Zur einfacheren Generierung vorab geprüfter Artefakte für die Remote-Ausführung können Sie WORKSPACE-Regeln verwenden, um generierte Dateien auszugeben. Sie können diese Regeln in jeder neuen Ausführungsumgebung ausführen, z. B. in jedem Toolchain-Container, und die Ausgaben Ihres Builds für die Remote-Ausführung in Ihr Quell-Repository prüfen.

Bei den TensorFlow-Regeln für cuda und python erzeugen die WORKSPACE-Regeln beispielsweise Folgendes: BUILD files Bei der lokalen Ausführung werden Dateien verwendet, die bei der Prüfung der Hostumgebung erzeugt wurden. Für die Remote-Ausführung ermöglicht eine bedingte Anweisung für eine Umgebungsvariable, dass die Regel Dateien verwendet, die im Repository eingecheckt sind.

Die BUILD-Dateien deklarieren genrules, die sowohl lokal als auch remote ausgeführt werden können und die zuvor mithilfe von repository_ctx.symlink durchgeführte Verarbeitung durchführen, wie hier.