Projekt
Ett projekt är en samling resurser som definierar nodkonfigurationer. Projekt innehåller specifikationer. När en nod startar konfigureras den genom bearbetning och körning av en sekvens med specifikationer.
Azure CycleCloud använder projekt för att hantera klustrade program, till exempel batchschemaläggare. I CycleCloud HPCPack är projektet en hn spec och cn spec som definierar konfigurationer och recept för HPCPack-huvudnod och beräkningsnod.
Nedan visas en partiell noddefinition. Noden docker-registry kör tre specifikationer: bindningsspecifikation från okta-projektversion 1.3.0, samt kärn- och registerspecifikationer från 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]]]
Den avslutande taggen är projektets versionsnummer.
[[[cluster-init <project>:<spec>:<project version>]]]
Ett skåp är en referens till en lagringskontocontainer och autentiseringsuppgifter. Noder har ett standardskåp, så det här attributet är inte absolut nödvändigt.
Azure CycleCloud använder en förkortning för lagringskonton, så https://mystorage.blob.core.windows.net/mycontainer kan skrivas som az://mystorage/mycontainer.
Noden laddar ned varje projekt som den refererar till från skåpet med hjälp av pogo-verktyget:
pogo get az://mystorage/mycontainer/projects/okta/1.3.0/bind
Om ett projekt definieras på en nod men inte finns på den förväntade lagringsplatsen rapporterar noden en Software Installation Failure till CycleCloud.
CycleCloud har interna projekt som körs som standard på alla noder för att utföra särskild volym- och nätverkshantering och konfigurera kommunikation till CycleCloud. Dessa interna projekt speglas automatiskt i skåpet.
Användaren ansvarar för att spegla eventuella ytterligare projekt i skåpet. CycleCloud CLI har metoder för att skapa projekt:
cyclecloud project init myproject
och spegling:
cyclecloud project init mylocker
projekt till skåp.
Specifikationer består av Python-, Shell- eller PowerShell-skript.
Skapa ett nytt projekt
Om du vill skapa ett nytt projekt använder du CLI-kommandot cyclecloud project init myproject, där myproject är namnet på det projekt som du vill skapa. Då skapas ett projekt med namnet "myproject", med en enda specifikation med namnet "default" som du kan ändra. Katalogträdet skapas med stommefiler som du ändrar för att inkludera din egen information.
Katalogstruktur
Följande kataloger skapas av projektkommandot:
\myproject
├── project.ini
├── blobs
├── templates
├── specs
│ ├── default
│ └── cluster-init
│ ├── scripts
│ ├── files
│ └── tests
│ └── chef
│ ├── site-cookbooks
│ ├── data_bag
│ └── roles
Mallkatalogen innehåller dina klustermallar, medan specifikationerna innehåller de specifikationer som definierar projektet. spec har två underkataloger: cluster-init och custom chef. cluster-init innehåller kataloger som har särskild betydelse, till exempel skriptkatalogen (innehåller skript som körs i lexikografisk ordning på noden), filer (rådatafiler som ska placeras på noden) och tester (innehåller tester som ska köras när ett kluster startas i testläge).
Den anpassade chef-underkatalogen har tre kataloger: site-cookbooks (för kokboksdefinitioner), data_bags (databagdefinitioner) och roller (chefsrolldefinitionsfiler).
project.ini
project.ini är filen som innehåller alla metadata för projektet. Den kan innehålla:
| Parameter | Beskrivning |
|---|---|
| name | Namnet på projektet. Ord måste avgränsas med bindestreck, t.ex. order-66-2018 |
| etikett | Namnet på projektet. Långt namn (med blanksteg) för klustret i visningssyfte. |
| typ | Tre alternativ: scheduler, application, <blank>. Avgör typen av projekt och genererar lämplig mall. Standard: program |
| version | Format: x.x.x |
Skåp
Projektinnehållet lagras i ett skåp. Du kan ladda upp innehållet i projektet till valfritt skåp som definierats i cyclecloud-installationen via kommandot cyclecloud project upload (locker), där (skåp) är namnet på ett molnlagringsskåp i cyclecloud-installationen. Det här skåpet anges som standardmål. Du kan också se vilka skåp som är tillgängliga för dig med kommandot cyclecloud locker list. Information om ett specifikt skåp kan visas med cyclecloud locker show (locker).
Om du lägger till fler än ett skåp kan du ange standardinställningen med cyclecloud project default_target (locker)och sedan bara köra cyclecloud project upload. Du kan också ange ett globalt standardskåp som kan delas av projekt med kommandot cyclecloud project default locker (locker) -global.
Anteckning
Standardskåp lagras i cyclecloud-konfigurationsfilen (vanligtvis i ~/.cycle/config.ini), inte i project.ini. Detta görs för att tillåta att project.ini versionskontrolleras.
När du laddar upp projektinnehållet zippar du chefkatalogerna och synkroniserar både chef- och kluster-init till målskåpet. Dessa lagras på:
- (skåp)/projekt/(projekt)/(version)/(spec_name)/cluster-init
- (skåp)/projekt/(projekt)/(version)/(spec_name)/chef
Nedladdning av blob
Använd project download för att ladda ned alla blobar som refereras i project.ini till din lokala blobkatalog. Kommandot använder parametern [locker] och försöker ladda ned blobar som anges i project.ini från skåpet till den lokala lagringen. Ett fel returneras om filerna inte kan hittas.
Projektkonfiguration
Specifikationer
När du skapar ett nytt projekt definieras en enda standardspecifikation. Du kan lägga till ytterligare specifikationer i projektet via cyclecloud project add_spec kommandot .
Versionshantering
Som standard har alla projekt en version av 1.0.0. Du kan ange en anpassad version när du utvecklar och distribuerar projekt genom att ange version=x.y.z i filenproject.ini .
Om till exempel "locker_url" var "az://my-account/my-container/projects" fick projektet namnet "Order66", versionen var "1.6.9" och specifikationen är "standard", så skulle url:en vara:
- 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
Blobar
Det finns två typer av blobar: projektblobar och användarblobar.
Projektblobar
Projektblobar är binära filer som tillhandahålls av projektförfattaren med antagandet att de kan distribueras (dvs. en binär fil för ett öppen källkod projekt som du har laglig behörighet att omdistribuera). Projektblobar går till katalogen "blobar" för ett projekt och när de laddas upp till ett skåp finns de på /project/blobar.
Om du vill lägga till blobar i projekt lägger du till filerna i project.ini:
[[blobs optionalname]]
Files = projectblob1.tgz, projectblob2.tgz, projectblob3.tgz
Flera blobar kan avgränsas med ett kommatecken. Du kan också ange den relativa sökvägen till projektets blobkatalog.
Användarblobar
Användarblobar är binära filer som projektets författare inte juridiskt kan omdistribuera, till exempel UGE-binärfiler. Dessa filer paketeras inte med projektet, utan måste i stället mellanlagras till skåpet manuellt. Filerna finns på /blobar/my-project/my-blob.tgz. Användarblobar behöver inte definieras i project.ini.
Om du vill ladda ned en blob använder du jetpack download kommandot från CLI eller Chef-resursen jetpack_download . CycleCloud letar först efter användarbloben. Om filen inte finns används bloben på projektnivå.
Anteckning
Det går att åsidosätta en projektblob med en användarblob med samma namn.
Ange projekt i en klustermall
Med projektsyntax kan du ange flera specifikationer på noderna. Om du vill definiera ett projekt använder du följande:
[[[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)
Anteckning
Namnet som anges efter "spec" kan vara vad som helst, men kan och bör användas som en genväg för att definiera några > vanliga egenskaper.
Du kan också tillämpa flera specifikationer på en viss nod på följande sätt:
[[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)
Genom att separera projektnamnet, specifikationsnamnet och versionen med kolon kan CycleCloud parsa dessa värden till lämpliga Project/Version/Spec inställningar automatiskt:
[[node scheduler]]
AdditionalClusterInitSpecs = $ClusterInitSpecs
[[[cluster-init myproject:myspec:x.y.z]]]
[[[cluster-init otherproject:otherspec:a.b.c]]]
Specifikationer kan också ärvas mellan noder. Du kan till exempel dela en gemensam specifikation mellan alla noder och sedan köra en anpassad specifikation på scheduler-noden:
[[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
Detta skulle tillämpa både specifikationerna common och scheduler på scheduler-noden, samtidigt som specifikationerna common och execute endast tillämpas på körningsnodmatrisen.
Som standard körs specifikationerna i den ordning de visas i mallen och kör ärvda specifikationer först. Order är ett valfritt heltal inställt på standardvärdet 1 000 och kan användas för att definiera ordningen på specifikationerna.
Om endast ett namn anges i [[[cluster-init]]] definitionen antas det vara specifikationens namn. Ett exempel:
[[[cluster-init myspec]]]
Project = myproject
Version = 1.0.0
är en giltig specifikationskonfiguration som Spec=myspec är underförstådd av namnet.
run_list
Du kan ange en runlist på projekt- eller specifikationsnivå inom project.ini:
[spec scheduler]
run_list = role[a], recipe[b]
När en nod innehåller specifikationen "scheduler" läggs run_list som definierats automatiskt till i alla tidigare definierade runlister. Om min run_list som definierades under [configuration] till exempel var run_list = recipe[test], skulle den sista runlisten vara run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].
Du kan också skriva över en runlist på specifikationsnivå på en nod. Detta ersätter alla run_list som ingår i project.ini. Om vi till exempel har ändrat noddefinitionen till följande:
[cluster-init test-project:scheduler:1.0.0]
run_list = recipe[different-test]
Den runlist som definierats i projektet ignoreras och ovanstående används i stället. Den sista runlisten på noden blir run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init]då .
Anteckning
runlists är specifika för chef och gäller inte på annat sätt.
Filplatser
De zippade chef-filerna laddas ned under startfasen av nodstarten. De laddas ned till $JETPACK_HOME/system/chef/tarballs och packas upp till $JETPACK_HOME/system/chef/chef-repo/, och används när noden konvergeras.
Anteckning
Om du vill köra anpassade kokböcker måste du ange dem i run_list för noden.
Cluster-init-filerna laddas ned till /mnt/cluster-init/(project)/(spec)/. För "my-project" och "my-spec" visas dina skript, filer och tester i /mnt/cluster-init/my-project/my-spec.
Synkronisera projekt
CycleCloud-projekt kan synkroniseras från speglingar till klusterlokal molnlagring. Ange ett SourceLocker-attribut för ett [cluster-init] avsnitt i mallen. Namnet på det angivna skåpet används som källa för projektet och innehållet synkroniseras till skåpet när klustret startar. Du kan också använda namnet på skåpet som den första delen av cluster-init-namnet. Om källskåpet till exempel var "cyclecloud" är följande två definitioner desamma:
[cluster-init my-project:my-spect:1.2.3]
SourceLocker=cyclecloud
[cluster-init cyclecloud/my-proect:my-spec:1.2.3]
Stor fillagring
Projekt stöder stora filer. På den översta nivån i ett nyligen skapat projekt visas en "blobar"-katalog för dina stora filer (blobar). Observera att blobar som placeras i den här katalogen har ett specifikt syfte och fungerar annorlunda än objekten i katalogen "files".
Objekt i katalogen "blobar" är specifikations- och versionsoberoende: allt i "blobar" kan delas mellan specifikationer eller projektversioner. Ett installationsprogram för ett program som ändras sällan kan till exempel lagras i "blobar" och refereras till i dinproject.ini. När du itererar i versioner av projektet förblir den enskilda filen densamma och kopieras bara till molnlagringen en gång, vilket sparar på överförings- och lagringskostnader.
Om du vill lägga till en blob placerar du bara en fil i katalogen "blobar" och redigerar dinproject.ini för att referera till filen:
[blobs]
Files=big_file1.tgz
När du använder project upload kommandot överförs alla blobar som refereras i project.ini till molnlagring.
Loggfiler
Loggfiler som genereras när du kör cluster-init finns i $JETPACK_HOME/logs/cluster-init/(project)/(spec).
Kör filer
När ett cluster-init-skript körs placeras en fil i /mnt/cluster-init/.run/(project)/(spec) för att säkerställa att den inte körs igen vid en efterföljande konvergering. Om du vill köra skriptet igen tar du bort lämplig fil i den här katalogen.
Skriptkataloger
När CycleCloud kör skript i skriptkatalogen läggs miljövariabler till i sökvägen och namnet på specifikationen och projektkatalogerna:
CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH
I Linux skulle ett projekt med namnet "test-project" med en "standardspecifikation" ha sökvägar på följande sätt:
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
Kör endast skript
Så här kör du ENDAST cluster-init-skripten:
jetpack converge --cluster-init
Utdata från kommandot går både till STDOUT och jetpack.log. Varje skript kommer också att ha sina utdata loggade till:
$JETPACK_HOME/logs/cluster-init/(project)/(spec)/scripts/(script.sh).out
Anpassade kock- och skrivbara specifikationer
Varje specifikation har en chef-katalog i sig. Före en konvergering tas varje specifikation bort från specifikationen och extraheras till den lokala lagringsplatsen, vilket ersätter befintliga kokböcker, roller och datapåsar med samma namn. Detta görs i den ordning som specifikationerna definieras, så vid en namngivningskollision kommer den senast definierade specifikationen alltid att vinna.
jetpack download
Om du vill ladda ned en blob i ett cluster-init-skript använder du kommandot jetpack download (filename) för att hämta den från blobkatalogen. Om du kör det här kommandot från ett cluster-init-skript avgör du projektet och bas-URL:en åt dig. Om du vill använda det i en icke-cluster-init-kontext måste du ange projektet (se --help för mer information).
För chef-användare har en jetpack_download LWRP skapats:
jetpack_download "big-file1.tgz" do
project "my-project"
end
I chef är #{node[:jetpack][:downloads]}standardplatsen för nedladdning . Om du vill ändra filmålet använder du följande:
jetpack_download "foo.tgz" do
project "my-project"
dest "/tmp/download.tgz"
end
När det används i chef måste du ange projektet.