Projecten

Een project is een verzameling resources die knooppuntconfiguraties definiëren. Projecten bevatten specificaties. Wanneer een knooppunt wordt gestart, wordt het geconfigureerd door een reeks specificaties te verwerken en uit te voeren.

Azure CycleCloud maakt gebruik van projecten voor het beheren van geclusterde toepassingen, zoals batchplanners. In de CycleCloud HPCPack is het project een hn specificatie en cn specificatie die de configuraties en recepten voor HPCPack headnode en computenode definieert.

Hieronder ziet u een gedeeltelijke knooppuntdefinitie. Het docker-registry-knooppunt voert drie specificaties uit: bindspecificatie van de okta-projectversie 1.3.0, evenals kern- en registerspecificaties van het Docker-project versie 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]]]

De volgtag is het versienummer van het project.

[[[cluster-init <project>:<spec>:<project version>]]]

Een locker is een verwijzing naar een opslagaccountcontainer en -referenties. Knooppunten hebben een standaardlocker, dus dit kenmerk is niet strikt nodig.

Azure CycleCloud maakt gebruik van een afkorting voor opslagaccounts, dus https://mystorage.blob.core.windows.net/mycontainer kan worden geschreven als az://mystorage/mycontainer.

Het knooppunt downloadt elk project dat het verwijst vanuit de locker met behulp van het pogo-hulpprogramma:

pogo get az://mystorage/mycontainer/projects/okta/1.3.0/bind

Als een project is gedefinieerd op een knooppunt, maar niet bestaat in de verwachte opslaglocatie, rapporteert het knooppunt een Software Installation Failure aan CycleCloud.

CycleCloud heeft interne projecten die standaard worden uitgevoerd op alle knooppunten om speciale volume- en netwerkafhandeling uit te voeren en communicatie met CycleCloud in te stellen. Deze interne projecten worden automatisch gespiegeld aan de locker.

De gebruiker is verantwoordelijk voor het spiegelen van eventuele aanvullende projecten aan de locker. De CycleCloud CLI heeft methoden voor het opstellen van projecten:

cyclecloud project init myproject

en spiegel:

cyclecloud project init mylocker

projecten voor kluisjes.

Specificaties bestaan uit python-, shell- of PowerShell-scripts.

Een nieuw project maken

Als u een nieuw project wilt maken, gebruikt u de CLI-opdracht cyclecloud project init myproject, waarbij myproject de naam is van het project dat u wilt maken. Hiermee maakt u een project met de naam 'myproject', met één specificatie met de naam 'standaard' die u kunt wijzigen. De mapstructuur wordt gemaakt met skeleton-bestanden die u wijzigt om uw eigen gegevens op te nemen.

Mapstructuur

De volgende mappen worden gemaakt met de projectopdracht:

      \myproject
          ├── project.ini
          ├── blobs
          ├── templates
          ├── specs
          │   ├── default
          │     └── cluster-init
          │        ├── scripts
          │        ├── files
          │        └── tests
          │     └── chef
          │         ├── site-cookbooks
          │         ├── data_bag
          │         └── roles

De map met sjablonen bevat uw clustersjablonen, terwijl specificaties de specificaties bevatten die uw project definiëren. spec heeft twee submappen: cluster-init en aangepaste chef. cluster-init bevat mappen die speciale betekenis hebben, zoals de map scripts (bevat scripts die worden uitgevoerd in lexicografische volgorde op het knooppunt), bestanden (onbewerkte gegevensbestanden die moeten worden geplaatst op het knooppunt) en tests (bevat tests die moeten worden uitgevoerd wanneer een cluster wordt gestart in de testmodus).

De aangepaste submap chef bevat drie mappen: site-cookbooks (voor kookboekdefinities), data_bags (databag-definities) en rollen (chef-roldefinitiebestanden).

project.ini

project.ini is het bestand met alle metagegevens voor uw project. Deze kan het volgende bevatten:

Parameter	Beschrijving
naam	Naam van het project. Woorden moeten worden gescheiden door streepjes, bijvoorbeeld order-66-2018
label	Naam van het project. Lange naam (met spaties) van het cluster voor weergavedoeleinden.
type	Drie opties: scheduler, toepassing, <leeg>. Bepaalt het type project en genereert de juiste sjabloon. Standaard: toepassing
versie	Indeling: x.x.x

Kluisjes

Projectinhoud wordt opgeslagen in een locker. U kunt de inhoud van uw project uploaden naar een locker die is gedefinieerd in uw CycleCloud-installatie via de opdracht cyclecloud project upload (locker), waarbij (locker) de naam is van een cloudopslagkluis in uw CycleCloud-installatie. Deze locker wordt ingesteld als het standaarddoel. U kunt ook zien welke kluisjes voor u beschikbaar zijn met de opdracht cyclecloud locker list. Details over een specifieke locker kunnen worden bekeken met cyclecloud locker show (locker).

Als u meer dan één locker toevoegt, kunt u uw standaardinstelling instellen met cyclecloud project default_target (locker)en gewoon uitvoeren cyclecloud project upload. U kunt ook een globale standaardlocker instellen die kan worden gedeeld door projecten met de opdracht cyclecloud project default locker (locker) -global.

Notitie

Standaardvergrendelingen worden opgeslagen in het configuratiebestand cyclecloud (meestal in ~/.cycle/config.ini), niet in de project.ini. Dit wordt gedaan om project.ini versiebeheer toe te staan.

Als u de inhoud van uw project uploadt, worden de chef-mappen gezipt en worden zowel chef- als cluster-init gesynchroniseerd met uw doelkluis. Deze worden opgeslagen op:

• (locker)/projects/(project)/(versie)/(spec_name)/cluster-init
• (locker)/projects/(project)/(versie)/(spec_name)/chef

Blob downloaden

Gebruik project download deze optie om alle blobs te downloaden waarnaar wordt verwezen in de project.ini naar uw lokale blobs-map. De opdracht maakt gebruik van de [locker] parameter en probeert blobs te downloaden die worden vermeld in project.ini van de locker naar lokale opslag. Er wordt een fout geretourneerd als de bestanden zich niet kunnen bevinden.

Projectinstallatie

Specificaties

Bij het maken van een nieuw project wordt één standaardspecificatie gedefinieerd. U kunt extra specificaties toevoegen aan uw project via de cyclecloud project add_spec opdracht.

Versiebeheer

Standaard hebben alle projecten een versie van 1.0.0. U kunt een aangepaste versie instellen tijdens het ontwikkelen en implementeren van projecten door het in te stellen version=x.y.z in het bestandproject.ini .

Als 'locker_url' bijvoorbeeld 'az://my-account/my-container/projects' was, het project de naam 'Order66', versie '1.6.9' was en de specificatie 'standaard' is, is uw URL:

• 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

Er zijn twee typen blob: project-blobs en gebruikers-blobs.

Project-blobs

Project Blobs zijn binaire bestanden die worden geleverd door de auteur van het project met de veronderstelling dat ze kunnen worden gedistribueerd (dat wil gezegd een binair bestand voor een open source project dat u wettelijk mag distribueren). Project-blobs gaan naar de map 'blobs' van een project en wanneer ze worden geüpload naar een locker, bevinden ze zich op /project/blobs.

Als u blobs aan projecten wilt toevoegen, voegt u de bestanden toe aan uw project.ini:

[[blobs optionalname]]
  Files = projectblob1.tgz, projectblob2.tgz, projectblob3.tgz

Meerdere blobs kunnen worden gescheiden door een komma. U kunt ook het relatieve pad opgeven naar de blobmap van het project.

Gebruikersblobs

Gebruikersblobs zijn binaire bestanden die de auteur van het project niet wettelijk kan herverdelen, zoals binaire UGE-bestanden. Deze bestanden worden niet verpakt met het project, maar moeten in plaats daarvan handmatig worden gefaseerd naar de locker. De bestanden bevinden zich op /blobs/my-project/my-blob.tgz. Gebruikersblobs hoeven niet te worden gedefinieerd in de project.ini.

Als u een blob wilt downloaden, gebruikt u de jetpack download opdracht van de CLI of de jetpack_download Chef-resource. CycleCloud zoekt eerst naar de gebruikersblob. Als dat bestand zich niet bevindt, wordt de blob op projectniveau gebruikt.

Notitie

Het is mogelijk om een project-blob te overschrijven met een gebruikersblob met dezelfde naam.

Project opgeven binnen een clustersjabloon

Met projectsyntaxis kunt u meerdere specificaties op uw knooppunten opgeven. Gebruik het volgende om een project te definiëren:

[[[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)

Notitie

De naam die is opgegeven na 'specificatie' kan alles zijn, maar kan en moet worden gebruikt als een snelkoppeling om enkele > algemene eigenschappen te definiëren.

U kunt ook meerdere specificaties als volgt toepassen op een bepaald knooppunt:

[[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)

Door de projectnaam, specificatienaam en versie met dubbele punten te scheiden, kan CycleCloud deze waarden automatisch parseren in de juiste Project/Version/Spec instellingen:

[[node scheduler]]
  AdditionalClusterInitSpecs = $ClusterInitSpecs
  [[[cluster-init myproject:myspec:x.y.z]]]
  [[[cluster-init otherproject:otherspec:a.b.c]]]

Specificaties kunnen ook worden overgenomen tussen knooppunten. U kunt bijvoorbeeld een algemene specificatie delen tussen alle knooppunten en vervolgens een aangepaste specificatie uitvoeren op het scheduler-knooppunt:

[[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

Dit past zowel de common als scheduler de specificaties toe op het scheduler-knooppunt, terwijl alleen de common en execute specificaties worden toegepast op de execute nodearray.

De specificaties worden standaard uitgevoerd in de volgorde waarin ze worden weergegeven in de sjabloon, waarbij eerst overgenomen specificaties worden uitgevoerd. Order is een optioneel geheel getal ingesteld op een standaardwaarde van 1000 en kan worden gebruikt om de volgorde van de specificaties te definiëren.

Als er slechts één naam is opgegeven in de [[[cluster-init]]] definitie, wordt ervan uitgegaan dat deze de specificatienaam is. Bijvoorbeeld:

[[[cluster-init myspec]]]
Project = myproject
Version = 1.0.0

is een geldige specificatie-instelling waarin Spec=myspec de naam wordt geïmpliceerd.

run_list

U kunt een runlist opgeven op project- of specificatieniveau binnen uw project.ini:

[spec scheduler]
run_list = role[a], recipe[b]

Wanneer een knooppunt de specificatie scheduler bevat, wordt de gedefinieerde run_list automatisch toegevoegd aan een eerder gedefinieerde runlist. Als bijvoorbeeld mijn run_list gedefinieerd, [configuration] is run_list = recipe[test]de uiteindelijke runlist run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].

U kunt ook een runlist overschrijven op het specificatieniveau op een knooppunt. Hiermee worden alle run_list in de project.ini vervangen. Als we bijvoorbeeld de knooppuntdefinitie hebben gewijzigd in het volgende:

[cluster-init test-project:scheduler:1.0.0]
run_list = recipe[different-test]

De runlist die in het project is gedefinieerd, wordt genegeerd en in plaats daarvan wordt het bovenstaande gebruikt. De uiteindelijke runlist op het knooppunt zou dan zijn run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init].

Notitie

runlists zijn specifiek voor chef-koks en zijn anders niet van toepassing.

Bestandslocaties

De zip-chef-bestanden worden gedownload tijdens de opstartfase van het opstarten van het knooppunt. Ze worden gedownload naar $JETPACK_HOME/system/chef/tarballs en uitgepakt naar $JETPACK_HOME/system/chef/chef-repo/, en gebruikt bij het samenvoegen van het knooppunt.

Notitie

Als u aangepaste kookboeken wilt uitvoeren, moet u deze opgeven in de run_list voor het knooppunt.

De cluster-init-bestanden worden gedownload naar /mnt/cluster-init/(project)/(spec)/. Voor 'my-project' en 'my-spec' ziet u uw scripts, bestanden en tests in /mnt/cluster-init/my-project/my-spec.

Projecten synchroniseren

CycleCloud-projecten kunnen vanuit mirrors worden gesynchroniseerd naar lokale clusteropslag in de cloud. Stel een SourceLocker-kenmerk in voor een [cluster-init] sectie in uw sjabloon. De naam van de opgegeven locker wordt gebruikt als de bron van het project en de inhoud wordt gesynchroniseerd met de locker bij het begin van het cluster. U kunt ook de naam van de kluis gebruiken als het eerste deel van de cluster-init-naam. Als de bronkluis bijvoorbeeld 'cyclecloud' was, zijn de volgende twee definities hetzelfde:

[cluster-init my-project:my-spect:1.2.3]
  SourceLocker=cyclecloud

[cluster-init cyclecloud/my-proect:my-spec:1.2.3]

Grote bestandsopslag

Projecten ondersteunen grote bestanden. Op het hoogste niveau van een nieuw gemaakt project ziet u een map 'blobs' voor uw grote bestanden (blobs). Houd er rekening mee dat blobs die in deze map zijn geplaatst, een specifiek doel hebben en anders werken dan de items in de map 'bestanden'.

Items in de map 'blobs' zijn specificatie en versieonafhankelijk: alles in 'blobs' kan worden gedeeld tussen specificaties of projectversies. Als voorbeeld kan een installatieprogramma voor een programma dat onregelmatig wordt gewijzigd, worden opgeslagen in 'blobs' en waarnaar wordt verwezen in uw project.ini. Terwijl u versies van uw project doorgeeft, blijft dat ene bestand hetzelfde en wordt dit slechts één keer gekopieerd naar uw cloudopslag, wat bespaart op overdrachts- en opslagkosten.

Als u een blob wilt toevoegen, plaatst u gewoon een bestand in de map 'blobs' en bewerkt u uw project.ini om naar dat bestand te verwijzen:

[blobs]
  Files=big_file1.tgz

Wanneer u de project upload opdracht gebruikt, worden alle blobs waarnaar wordt verwezen in de project.ini overgebracht naar cloudopslag.

Logboekbestanden

Logboekbestanden die worden gegenereerd bij het uitvoeren van cluster-init bevinden zich in $JETPACK_HOME/logs/cluster-init/(project)/(spec).

Bestanden uitvoeren

Wanneer een cluster-init-script wordt uitgevoerd, wordt een bestand in /mnt/cluster-init/.run/(project)/(spec) geplaatst om ervoor te zorgen dat het niet opnieuw wordt uitgevoerd op een volgende converge. Als u het script opnieuw wilt uitvoeren, verwijdert u het juiste bestand in deze map.

Scriptmappen

Wanneer CycleCloud scripts uitvoert in de scriptsmap, worden omgevingsvariabelen toegevoegd aan het pad en de naam van de specificaties en projectmappen:

CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH

In Linux zou een project met de naam 'test-project' met een specificatie van 'default' als volgt paden hebben:

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

Alleen scripts uitvoeren

Alleen de cluster-init-scripts uitvoeren:

jetpack converge --cluster-init

Uitvoer van de opdracht gaat zowel naar STDOUT als jetpack.log. Elk script heeft ook de uitvoer geregistreerd bij:

      $JETPACK_HOME/logs/cluster-init/(project)/(spec)/scripts/(script.sh).out

Aangepaste chef-kok en composable specificaties

Elke specificatie heeft er een chef-directory in. Voordat een convergering wordt uitgevoerd, wordt elke specificatie niet-gerichte en geëxtraheerd in de lokale chef-opslagplaats, waarbij alle bestaande kookboeken, rollen en gegevenstassen worden vervangen door dezelfde naam(en). Dit gebeurt in de volgorde waarin de specificaties worden gedefinieerd, dus in het geval van een naamgevingsconflict zal de laatst gedefinieerde specificatie altijd winnen.

jetpack downloaden

Als u een blob in een cluster-init-script wilt downloaden, gebruikt u de opdracht jetpack download (filename) om deze op te halen uit de blobs-map. Als u deze opdracht uitvoert vanuit een cluster-init-script, wordt het project en de basis-URL voor u bepaald. Als u het wilt gebruiken in een niet-cluster-init-context, moet u het project opgeven (zie --help voor meer informatie).

Voor chef-gebruikers is een jetpack_download LWRP gemaakt:

jetpack_download "big-file1.tgz" do
  project "my-project"
  end

In chef is #{node[:jetpack][:downloads]}de standaard downloadlocatie. Als u het bestandsdoel wilt wijzigen, gebruikt u het volgende:

jetpack_download "foo.tgz" do
  project "my-project"
  dest "/tmp/download.tgz"
end

Wanneer u het project in chef-kok gebruikt, moet u het project opgeven.