cook_rsh – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

Cook – Lastausgleich rsh

ZUSAMMENFASSUNG

Koch [ zu erhalten... ] Architektur Befehl [ Argument... ]
Koch -Hilfe

BESCHREIBUNG

Das Koch Das Programm ist ein Wrapper rsh(1), das einen einfachen Lastausgleich durchführt. Es gilt
seine Ladeinformationen durch Ausführen von rup(1) Befehl und wählt den am besten geeigneten Host aus
basierend auf der von Ihnen angegebenen Architektur und der geringsten Auslastung aller Hosts davon
die Architektur.

Das erste Befehlszeilenargument ist der Architekturname, der zum Abrufen der Liste verwendet wird
mögliche Gastgeber. Aus dieser Liste die rup(1) Der Befehl wird ausgeführt, um den Host mit dem zu ermitteln
niedrigste Last, die wiederum als erstes Argument des Eventuals verwendet wird rsh(1) Befehl.

KOCHBÜCHER

Um dieses Programm nutzen zu können, müssen Sie irgendwo in Ihrem Kochbuch eine Zeile hinzufügen
was liest
parallel_rsh = "cook";
Wenn der ausgewählte Host derselbe ist wie der Aufrufer (Build-Host), führt dieses Programm einfach den aus
Befehl überspringt den RSH. Es kostet also nichts, dies in einem Ein-Maschinen-Netzwerk zu verwenden!

Für jedes Rezept, das Sie an einen Remote-Host verteilen möchten, müssen Sie eine Host-Bindung hinzufügen
zuschreiben. Typische Verwendung ist ein Build mit mehreren Architekturen.
%1/%0%.o: %0%.c
Hostbindung %1 {
cc -o [Ziel] -c [%0%.c auflösen]; }
In dem hier angegebenen Rezept werden die Objektdateien jeder Architektur separat abgelegt
architekturspezifischer Verzeichnisbaum. Der Architekturname (%1) wird im Host verwendet.
Bindung, sodass die Kompilierungen auf alle Maschinen dieser Architektur verteilt werden können.

Wenn Sie einen Befehl zur Ausführung auf einem bestimmten Host benötigen (z. B. weil sich dort ein bestimmter Host befindet).
Wenn sich die Anwendungslizenz befindet), verwenden Sie einfach den Hostnamen in der Hostbindung
Attribut anstelle eines Architekturnamens.

DEFINIEREN KLASSEN

Das /host_lists.pl Es wird erwartet, dass die Datei vorhanden ist und die gewohnten Variablendefinitionen enthält
Bestimmen Sie, ob Hosts Mitglieder bestimmter Architekturen sind.

Das /host_lists.pl Datei definiert einen Perl-HOL-"Hash von Listen". Der Hash ist %ArchNames und it
Ordnet Namen von Architekturen so zu, wie der Benutzer sie sehen möchte, um Referenzen als tatsächlich aufzulisten
Listen werden gespeichert.

Die Namen der einzelnen Architekturen können jede gewünschte Form haben, es gilt jedoch die Konvention
die GNU-Namen wie „sparc-sun-solaris2.8“.

Definieren Sie für jede Architektur eine oder mehrere Maschinenlisten je nach Funktion
Jeder Maschinensatz kann dies tun. Dies kann je nach Bedarf so einfach oder so aufwändig sein. Die Form von
Der Name der Listenvariablen kann ein beliebiger gültiger Perl-Bezeichner sein, kann aber auch so lauten
Architekturname mit Bindestrich in Unterstrich geändert, Punkt entfernt und Typ hinzugefügt. Für
Beispielsweise könnte man Solaris-Hosts wie folgt definieren:
@sparc_sun_solaris28_hosts = (
„Mickey“, „Minny“, „Scrooge“);
Und Linux-Hosts wie:
@i386_linux22_hosts = (
„doof“, „scrooge“);

Wenn es notwendig ist, unterschiedliche Maschinensätze für unterschiedliche Arten von Aufgaben zu definieren, dann
Fügen Sie den Namen in der ein Suffix hinzu Wirtsbindung Richtlinie zu jedem der Rezepte und
Listen hier mit dem gleichen Suffix.

Der Hash zum Zuordnen von Argumentnamen zu Listen ist wie folgt definiert:
%ArchNames = (
"sparc-solaris2.8", => @sparc_solaris28_hosts,
"i586-unknown-linux22", => @i386_linux22_hosts, );

Natürlich, wenn Benutzer unterschiedliche Meinungen darüber haben, wie die Architekturnamen aussehen sollten
Sie können beispielsweise auch „Alias“-Zuordnungen definieren.
"sun4-SunOS-5.8", => @sparc_solaris28_hosts,
Oder vielleicht ist das Niveau nicht wichtig, dann definieren Sie es
„sparc-solaris“, => @sparc_solaris28_hosts,
"sparc-solaris2.7", => @sparc_solaris28_hosts,
Außerdem darf diese Liste nicht leer sein.

Und schließlich muss dank Perl die letzte Zeile der Datei lauten
1; aus obskuren und magischen Gründen.

SYSLOG LOGGING

Typische Befehle, die während eines Builds angezeigt werden, sehen folgendermaßen aus:
sh -c 'cd /aegis/dd/gumby2.2.C079 && \ sh -ce /aegis/dd/gumby2.2.C079/.6.1; \
Echo $? > /aegis/dd/gumby2.2.C079/.6.2'
So können wir das Projekt/die Änderung ganz einfach aus dem Befehl extrahieren und über protokollieren
Syslog wäre eine triviale Ergänzung.

OPTIONAL

Für diesen Befehl werden normalerweise keine Optionen angegeben.

-h Hilfe – Nutzungsinformationen anzeigen

-vP Ausführlich – Berichtsauswahl

-Tn Trace-Wert zum Testen

Verwenden Sie Cook_rsh online über die Dienste von onworks.net