Projekte
Ein Projekt ist eine Sammlung von Ressourcen, die Knotenkonfigurationen definieren. Projekte enthalten Spezifikationen. Wenn ein Knoten gestartet wird, wird er durch Verarbeiten und Ausführen einer Sequenz von Spezifikationen konfiguriert.
Azure CycleCloud verwendet Projekte zum Verwalten von clusterierten Anwendungen, z. B. Batchplaner. Im CycleCloud HPCPack ist das Projekt eine hn Spezifikation und Spezifikation, die die Konfigurationen und cn Rezepte für HPCPack-Kopfnode und Computenode definiert.
Unten ist eine Teilknotendefinition. Der Docker-Registrierungsknoten führt drei Spezifikationen aus: Binden von Spezifikationen aus der Okta-Projektversion 1.3.0 sowie Kern- und Registrierungsspezifikationen aus der Docker-Projektversion 2.0.0:
[[node docker-registry]]
Locker = base-storage
[[[cluster-init okta:bind:1.3.0]]]
[[[cluster-init docker:core:2.0.0]]]
[[[cluster-init docker:registry:2.0.0]]]
Das nachgestellte Tag ist die Projektversionsnummer.
[[[cluster-init <project>:<spec>:<project version>]]]
Ein Schließfach ist ein Verweis auf einen Speicherkontocontainer und Anmeldeinformationen. Knoten verfügen über ein Standardfach, sodass dieses Attribut nicht streng erforderlich ist.
Azure CycleCloud verwendet eine Kurzhand für Speicherkonten, sodass sie https://mystorage.blob.core.windows.net/mycontainer als az://mystorage/mycontainer geschrieben werden können.
Der Knoten lädt jedes Projekt herunter, das über das Pogo-Tool auf das Schließfach verweist:
pogo get az://mystorage/mycontainer/projects/okta/1.3.0/bind
Wenn ein Projekt auf einem Knoten definiert ist, aber nicht an dem erwarteten Speicherort vorhanden ist, wird der Knoten an Software Installation Failure CycleCloud berichtet.
CycleCloud verfügt über interne Projekte, die standardmäßig auf allen Knoten ausgeführt werden, um spezielle Volumen- und Netzwerkbehandlungen und Einrichtungskommunikation an CycleCloud durchzuführen. Diese internen Projekte werden automatisch in das Schließfach gespiegelt.
Der Benutzer ist verantwortlich, alle zusätzlichen Projekte im Schließfach zu spiegeln. Die CycleCloud CLI verfügt über Methoden zum Verfassen von Projekten:
cyclecloud project init myproject
und Spiegelung:
cyclecloud project init mylocker
Projekte zum Schließfach.
Spezifikationen bestehen aus Python-, Shell- oder Powershell-Skripts.
Erstellen eines neues Projekts
Um ein neues Projekt zu erstellen, verwenden Sie den CLI-Befehl cyclecloud project init myproject, wo myproject der Name des Projekts ist, das Sie erstellen möchten. Dadurch wird ein Projekt namens "myproject" erstellt, mit einer einzigen Spezifikation namens "default", die Sie ändern können. Die Verzeichnisstruktur wird mit Skelettdateien erstellt, die Sie ändern, um ihre eigenen Informationen einzuschließen.
Verzeichnisstruktur
Die folgenden Verzeichnisse werden vom Projektbefehl erstellt:
\myproject
├── project.ini
├── blobs
├── templates
├── specs
│ ├── default
│ └── cluster-init
│ ├── scripts
│ ├── files
│ └── tests
│ └── chef
│ ├── site-cookbooks
│ ├── data_bag
│ └── roles
Das Vorlagenverzeichnis enthält Ihre Clustervorlagen, während Die Spezifikationen, die Ihr Projekt definieren, enthalten. spec verfügt über zwei Unterverzeichnisse: cluster-init und benutzerdefinierter Chef. cluster-init enthält Verzeichnisse, die besondere Bedeutung haben, z. B. das Skriptverzeichnis (enthält Skripts, die in lexikaler Reihenfolge auf dem Knoten ausgeführt werden), Dateien (Rohdatendateien, die auf dem Knoten platziert werden sollen), und Tests (enthält Tests , die ausgeführt werden sollen, wenn ein Cluster im Testmodus gestartet wird).
Das benutzerdefinierte Chef-Unterverzeichnis verfügt über drei Verzeichnisse: Website-Cookbooks (für Kochbuchdefinitionen), data_bags (Databag-Definitionen) und Rollen (Chef-Rollendefinitionsdateien).
project.ini
project.ini ist die Datei, die alle Metadaten für Ihr Projekt enthält. Es kann folgendes enthalten:
| Parameter | BESCHREIBUNG |
|---|---|
| name | Der Name des Projekts. Wörter müssen durch Striche getrennt werden, z. B. Order-66-2018 |
| label | Der Name des Projekts. Langer Name (mit Leerzeichen) des Clusters für Anzeigezwecke. |
| Typ | Drei Optionen: Zeitplaner, Anwendung, <leer>. Bestimmt den Projekttyp und generiert die entsprechende Vorlage. Standard: Anwendung |
| version | Format: x.x.x.x |
Schließfächer
Projektinhalte werden in einem Schließfach gespeichert. Sie können den Inhalt Ihres Projekts auf jedes in Ihrer CycleCloud-Installation definierte Schließfach hochladen, wobei (Schließfach) der Name eines Cloudspeichers in Ihrer CycleCloud-Installation cyclecloud project upload (locker)ist. Dieser Schließfach wird als Standardziel festgelegt. Alternativ können Sie sehen, welche Schließfächer für Sie mit dem Befehl cyclecloud locker listverfügbar sind. Details zu einem bestimmten Schließfach können mit cyclecloud locker show (locker)angezeigt werden.
Wenn Sie mehr als ein Schließfach hinzufügen, können Sie Ihren Standard mit cyclecloud project default_target (locker), und führen Sie dann einfach aus cyclecloud project upload. Sie können auch ein globales Standardfach festlegen, das von Projekten mit dem Befehl cyclecloud project default locker (locker) -globalfreigegeben werden kann.
Hinweis
Standardmäßige Schließfächer werden in der Cyclecloud-Config-Datei (normalerweise in ~/.cycle/config.ini) gespeichert, nicht im project.ini. Dies geschieht, damit project.ini version gesteuert werden können.
Das Hochladen Ihres Projektinhalts wird die Chefverzeichnisse zippen und sowohl Chef- als auch Cluster-Init mit Ihrem Zielfach synchronisieren. Dies wird unter:
- (locker)/projekte/(project)/(version)/(spec_name)/cluster-init
- (locker)/projekte/(project)/(version)/(spec_name)/chef
Blob-Download
Verwenden Sie project download zum Herunterladen aller Blobs, auf die im project.ini in Ihr lokales Blobs-Verzeichnis verwiesen wird. Der Befehl verwendet den Parameter und versucht, Blobs herunterzuladen, die [locker] in project.ini vom Schließfach in den lokalen Speicher aufgeführt sind. Ein Fehler wird zurückgegeben, wenn die Dateien nicht gefunden werden können.
Projekteinrichtung
Spezifikationen
Beim Erstellen eines neuen Projekts wird eine einzelne Standardspezifikation definiert. Sie können Ihrem Projekt zusätzliche Spezifikationen über den cyclecloud project add_spec Befehl hinzufügen.
Versionsverwaltung
Standardmäßig verfügen alle Projekte über eine Version von 1.0.0. Sie können eine benutzerdefinierte Version festlegen, während Sie Projekte entwickeln und bereitstellen, indem Sie sich in der project.ini-Datei festlegenversion=x.y.z.
Wenn beispielsweise "locker_url" "az://my-account/my-container/projects" war, wurde das Projekt "Order66" genannt, Version war "1.6.9", und die Spezifikation ist "standard", ihre URL wäre:
- az://my-account/my-container/projects/Order66/1.6.9/default/cluster-init
- az://my-account/my-container/projects/Order66/1.6.9/default/chef
BLOBs
Es gibt zwei Blobtypen: Projekt-Blobs und Benutzer-Blobs.
Project Blobs
Project Blobs sind binärdateien, die vom Autor des Projekts bereitgestellt werden, wobei davon ausgegangen wird, dass sie verteilt werden können (d. h. eine Binärdatei für ein Open-Source-Projekt, das Sie rechtlich verteilen dürfen). Project Blobs wechseln in das Verzeichnis "Blobs" eines Projekts, und wenn sie in ein Schließfach hochgeladen werden, befinden sie sich in /project/blobs.
Um Blobs zu Projekten hinzuzufügen, fügen Sie der project.inidie Datei(n) hinzu:
[[blobs optionalname]]
Files = projectblob1.tgz, projectblob2.tgz, projectblob3.tgz
Mehrere Blobs können durch ein Komma getrennt werden. Sie können auch den relativen Pfad zum Blobverzeichnis des Projekts angeben.
Benutzer-Blobs
Benutzer-Blobs sind binärdateien, die der Autor des Projekts nicht rechtsverteilt, z. B. UGE-Binärdateien. Diese Dateien werden nicht mit dem Projekt verpackt, sondern müssen manuell auf das Schließfach verwiesen werden. Die Dateien befinden sich unter /blobs/my-project/my-blob.tgz. Benutzer-Blobs müssen nicht im project.ini definiert werden.
Verwenden Sie zum Herunterladen eines Blobs den jetpack download Befehl aus der CLI oder der jetpack_download Chef-Ressource. CycleCloud sucht zuerst nach dem Benutzer-Blob. Wenn sich diese Datei nicht befindet, wird der Blob auf Projektebene verwendet.
Hinweis
Es ist möglich, einen Projekt-Blob mit einem Benutzer-Blob desselben Namens außer Kraft zu setzen.
Angeben von Project in einer Clustervorlage
Die Projektsyntax ermöglicht es Ihnen, mehrere Spezifikationen auf Ihren Knoten anzugeben. Um ein Projekt zu definieren, verwenden Sie folgendes:
[[[cluster-init myspec]]]
Project = myproject # inferred from name
Version = x.y.z
Spec = default # (alternatively, you can name your own spec to be used here)
Locker = default # (optional, will use default locker for node)
Hinweis
Der name, der nach "spec" angegeben wurde, kann alles sein, kann aber als Verknüpfung verwendet werden, um einige > allgemeine Eigenschaften zu definieren.
Sie können auch mehrere Spezifikationen auf einen bestimmten Knoten wie folgt anwenden:
[[node scheduler]]
[[[cluster-init myspec]]]
Project = myproject
Version = x.y.z
Spec = default # (alternatively, you can name your own spec to be used here)
Locker = default # (optional, will use default locker for node)
[[[cluster-init otherspec]]]
Project = otherproject
Version = a.b.c
Spec = otherspec # (optional)
Durch Trennen des Projektnamens, des Spezifikationsnamens und der Version mit Doppelpunkten kann CycleCloud diese Werte automatisch in die entsprechenden Project/Version/Spec Einstellungen analysieren:
[[node scheduler]]
AdditionalClusterInitSpecs = $ClusterInitSpecs
[[[cluster-init myproject:myspec:x.y.z]]]
[[[cluster-init otherproject:otherspec:a.b.c]]]
Spezifikationen können auch zwischen Knoten geerbt werden. Sie können beispielsweise eine gemeinsame Spezifikation zwischen allen Knoten freigeben und dann eine benutzerdefinierte Spezifikation auf dem Zeitplanknoten ausführen:
[[node defaults]]
[[[cluster-init my-project:common:1.0.0]]]
Order = 2 # optional
[[node scheduler]]
[[[cluster-init my-project:scheduler:1.0.0]]]
Order = 1 # optional
[[nodearray execute]]
[[[cluster-init my-project:execute:1.0.0]]]
Order = 1 # optional
Dies würde sowohl die commonscheduler Spezifikationen als auch die Spezifikationen auf den Zeitplanknoten anwenden, während nur die commonexecute und die Spezifikationen auf das Ausführen von Knotenarray angewendet werden.
Standardmäßig werden die Spezifikationen in der Reihenfolge ausgeführt, in der sie in der Vorlage angezeigt werden, wobei zuerst geerbte Spezifikationen ausgeführt werden. Order ist ein optionaler ganzzahliger Satz auf einen Standardwert von 1000 und kann verwendet werden, um die Reihenfolge der Spezifikationen zu definieren.
Wenn nur ein Name in der [[[cluster-init]]] Definition angegeben ist, wird davon ausgegangen, dass es sich um den Spezifikationsnamen handelt. Beispiel:
[[[cluster-init myspec]]]
Project = myproject
Version = 1.0.0
ist eine gültige Spezifikationseinrichtung, in Spec=myspec der der Name impliziert wird.
run_list
Sie können eine Runlist auf Projekt- oder Spezifikationsebene innerhalb Ihrer project.ini angeben:
[spec scheduler]
run_list = role[a], recipe[b]
Wenn ein Knoten den "Zeitplaner" enthält, wird die run_list definiert automatisch an jede zuvor definierte Runlist angefügt. Wenn z. B. meine run_list unter "definiert [configuration] " war run_list = recipe[test], würde die endgültige Runlist sein run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].
Sie können auch eine Runlist auf der Spezifikationsebene auf einem Knoten überschreiben. Dadurch werden alle run_list ersetzt, die im project.ini enthalten sind. Wenn wir beispielsweise die Knotendefinition in folgendes geändert haben:
[cluster-init test-project:scheduler:1.0.0]
run_list = recipe[different-test]
Die im Projekt definierte Runlist würde ignoriert und stattdessen verwendet. Die endgültige Runlist des Knotens wäre run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init]dann .
Hinweis
Runlists sind speziell für Chef und gelten andernfalls nicht.
Dateispeicherorte
Die komprimierten Chefdateien werden während der Startphase des Knotenstarts heruntergeladen. Sie werden in $JETPACK_HOME/system/chef/tarballs heruntergeladen und in $JETPACK_HOME/system/chef/chef-repo/entzippt und beim Verbinden des Knotens verwendet.
Hinweis
Um benutzerdefinierte Kochbücher auszuführen, MÜSSEN Sie sie im run_list für den Knoten angeben.
Die Cluster-Init-Dateien werden in /mnt/cluster-init/(project)/(spec)/heruntergeladen. Für "my-project" und "my-spec" werden Ihre Skripts, Dateien und Tests in /mnt/cluster-init/my-project/my-spec angezeigt.
Synchronisieren von Projekten
CycleCloud-Projekte können von Spiegelungen in den lokalen Cloudspeicher des Clusters synchronisiert werden. Legen Sie ein SourceLocker-Attribut in einem [cluster-init] Abschnitt in Ihrer Vorlage fest. Der Name des angegebenen Schließfachs wird als Quelle des Projekts verwendet, und Der Inhalt wird mit dem Schließfach am Clusterstart synchronisiert. Sie können auch den Namen des Schließfachs als ersten Teil des Cluster-Init-Namens verwenden. Wenn beispielsweise das Quellfach "cyclecloud" war, sind die folgenden beiden Definitionen identisch:
[cluster-init my-project:my-spect:1.2.3]
SourceLocker=cyclecloud
[cluster-init cyclecloud/my-proect:my-spec:1.2.3]
Große Dateispeicherung
Projekte unterstützen große Dateien. Auf oberster Ebene eines neu erstellten Projekts wird ein "Blobs"-Verzeichnis für ihre großen Dateien (Blobs) angezeigt. Bitte beachten Sie, dass blobs, die in diesem Verzeichnis platziert wurden, einen bestimmten Zweck haben und anders als die Elemente im Verzeichnis "Dateien" handeln.
Elemente im Verzeichnis "blobs" sind spezifikations- und versionsunabhängig: Alles in "Blobs" kann zwischen Spezifikationen oder Projektversionen freigegeben werden. Ein Installationsprogramm für ein Programm, das sich selten in "Blobs" ändert und in Ihrem project.iniverwiesen wird. Während Sie auf Versionen Ihres Projekts iterieren, bleibt diese einzelne Datei identisch und wird nur einmal in Ihren Cloudspeicher kopiert, der die Übertragung und Speicherkosten speichert.
Um ein Blob hinzuzufügen, platzieren Sie einfach eine Datei in das Verzeichnis "Blobs", und bearbeiten Sie Ihre project.ini , um auf diese Datei zu verweisen:
[blobs]
Files=big_file1.tgz
Wenn Sie den Befehl verwenden, werden alle Blobs, auf die project upload im project.ini verwiesen wird, in den Cloudspeicher übertragen.
Protokolldateien
Protokolldateien, die beim Ausführen von Cluster-Init generiert werden, befinden sich in $JETPACK_HOME/logs/cluster-init/(project)/(spec).
Ausführen von Dateien
Wenn ein Cluster-Init-Skript erfolgreich ausgeführt wird, wird eine Datei in /mnt/cluster-init/.run/(project)/(spec) platziert, um sicherzustellen, dass es nicht erneut auf einem nachfolgenden Konverg ausgeführt wird. Wenn Sie das Skript erneut ausführen möchten, löschen Sie die entsprechende Datei in diesem Verzeichnis.
Skriptverzeichnisse
Wenn CycleCloud Skripts im Skriptverzeichnis ausführt, fügen Sie umgebungsvariablen dem Pfad und dem Namen der Spezifikations- und Projektverzeichnisse hinzu:
CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH
Bei Linux hätte ein Projekt namens "test-project" mit einer Spezifikation von "default" Pfade wie folgt:
CYCLECLOUD_PROJECT_NAME = test-project
CYCLECLOUD_PROJECT_PATH = /mnt/cluster-init/test-project
CYCLECLOUD_SPEC_NAME = default
CYCLECLOUD_SPEC_PATH = /mnt/cluster-init/test-project/default
Nur Skripts ausführen
So führen Sie NUR die Cluster-Init-Skripts aus:
jetpack converge --cluster-init
Die Ausgabe des Befehls wird sowohl zu STDOUT als auch zu jetpack.log wechseln. Jedes Skript hat auch seine Ausgabe protokolliert:
$JETPACK_HOME/logs/cluster-init/(project)/(spec)/scripts/(script.sh).out
Benutzerdefinierte Chef- und Composable-Spezifikationen
Jede Spezifikation verfügt über ein Chefverzeichnis darin. Vor einer Konvergierung wird jede Spezifikation nichttarriert und in das lokale Chef-Repo extrahiert, indem alle vorhandenen Kochbücher, Rollen und Datentaschen durch denselben Namen ersetzt werden. Dies erfolgt in der Reihenfolge, in der die Spezifikationen definiert sind, daher wird die letzte definierte Spezifikation immer gewinnen.
Jetpack-Download
Um einen Blob in einem Cluster-Init-Skript herunterzuladen, verwenden Sie den Befehl jetpack download (filename) , um ihn aus dem Blobs-Verzeichnis abzurufen. Wenn Sie diesen Befehl aus einem Cluster-Init-Skript ausführen, wird die Projekt- und Basis-URL für Sie bestimmt. Um es in einem Nicht-Cluster-Init-Kontext zu verwenden, müssen Sie das Projekt angeben (siehe --hilfe für weitere Informationen).
Für Chefbenutzer wurde ein jetpack_download LWRP erstellt:
jetpack_download "big-file1.tgz" do
project "my-project"
end
In Chef ist #{node[:jetpack][:downloads]}der Standard-Downloadspeicherort . Um das Dateiziel zu ändern, verwenden Sie folgendes:
jetpack_download "foo.tgz" do
project "my-project"
dest "/tmp/download.tgz"
end
Wenn Sie innerhalb des Chefs verwendet werden, müssen Sie das Projekt angeben.