Progetti
Un progetto è una raccolta di risorse che definiscono le configurazioni dei nodi. I progetti contengono specifiche. Quando viene avviato un nodo, viene configurato elaborando ed eseguendo una sequenza di specifiche.
Azure CycleCloud usa progetti per gestire applicazioni cluster, ad esempio gli utilità di pianificazione batch. In CycleCloud HPCPack il progetto è una specifica e specifica hn che definiscono le configurazioni e cn le ricette per il nodo head HPCPack e il nodo di calcolo.
Di seguito è riportata una definizione di nodo parziale. Il nodo docker-registry eseguirà tre specifiche: associare le specifiche del progetto okta versione 1.3.0, nonché le specifiche di base e registro dal progetto docker versione 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]]]
Il tag finale è il numero di versione del progetto.
[[[cluster-init <project>:<spec>:<project version>]]]
Un archivio è un riferimento a un contenitore e credenziali dell'account di archiviazione. I nodi hanno un blocco predefinito, quindi questo attributo non è strettamente necessario.
Azure CycleCloud usa una breve mano per gli account di archiviazione, quindi https://mystorage.blob.core.windows.net/mycontainer può essere scritta come az://mystorage/mycontainer.
Il nodo scarica ogni progetto a cui fa riferimento dall'locker usando lo strumento pogo:
pogo get az://mystorage/mycontainer/projects/okta/1.3.0/bind
Se un progetto viene definito in un nodo ma non esiste nel percorso di archiviazione previsto, il nodo segnala un Software Installation Failure oggetto a CycleCloud.
CycleCloud include progetti interni eseguiti per impostazione predefinita in tutti i nodi per eseguire una gestione speciale del volume e della rete e la comunicazione con CycleCloud. Questi progetti interni vengono mirrorati automaticamente nell'archivio.
L'utente è responsabile del mirroring di eventuali progetti aggiuntivi nell'archivio. L'interfaccia della riga di comando CycleCloud include metodi per comporre progetti:
cyclecloud project init myproject
e mirror:
cyclecloud project init mylocker
progetti da bloccare.
Le specifiche sono costituite da script python, shell o powershell.
Creazione di un nuovo progetto
Per creare un nuovo progetto, usare il comando dell'interfaccia della riga di comando cyclecloud project init myproject, dove myproject è il nome del progetto che si desidera creare. Verrà creato un progetto denominato "myproject", con una singola specifica denominata "default" che è possibile modificare. L'albero della directory verrà creato con i file di scheletro che verranno modificare in modo da includere le proprie informazioni.
Struttura di directory
Le directory seguenti verranno create dal comando del progetto:
\myproject
├── project.ini
├── blobs
├── templates
├── specs
│ ├── default
│ └── cluster-init
│ ├── scripts
│ ├── files
│ └── tests
│ └── chef
│ ├── site-cookbooks
│ ├── data_bag
│ └── roles
La directory dei modelli conterrà i modelli di cluster, mentre le specifiche conterranno le specifiche che definiscono il progetto. spec include due sottodirectory: cluster-init e chef personalizzato. cluster-init contiene directory che hanno un significato speciale, ad esempio la directory degli script (contiene script eseguiti in ordine lexicografico nel nodo), file (file di dati non elaborati da inserire nel nodo) e test (contiene test da eseguire quando un cluster viene avviato in modalità di test).
La sottodirectory chef personalizzata include tre directory: site-cookbook (per le definizioni del libro di cucina), data_bags (definizioni di databag) e ruoli (file di definizione del ruolo chef).
project.ini
project.ini è il file contenente tutti i metadati per il progetto. Può contenere:
| Parametro | Descrizione |
|---|---|
| name | Nome del progetto. Le parole devono essere separate da trattini, ad esempio order-66-2018 |
| label | Nome del progetto. Nome lungo (con spazi) del cluster a scopo di visualizzazione. |
| tipo | Tre opzioni: utilità di pianificazione, applicazione, <vuota>. Determina il tipo di progetto e genera il modello appropriato. Impostazione predefinita: applicazione |
| version | Formato: x.x.x |
Armadietti
Il contenuto del progetto viene archiviato all'interno di un archivio. È possibile caricare il contenuto del progetto in qualsiasi archivio definito nell'installazione di CycleCloud tramite il comando cyclecloud project upload (locker), dove (locker) è il nome di un archivio cloud nell'installazione di CycleCloud. Questolocker verrà impostato come destinazione predefinita. In alternativa, è possibile visualizzare quali blocchi sono disponibili con il comando cyclecloud locker list. È possibile visualizzare i dettagli relativi a un determinato blocco con cyclecloud locker show (locker).
Se si aggiungono più di un blocco, è possibile impostare il valore predefinito con cyclecloud project default_target (locker), quindi semplicemente eseguire cyclecloud project upload. È anche possibile impostare un blocco predefinito globale che può essere condiviso dai progetti con il comando cyclecloud project default locker (locker) -global.
Nota
I blocchi predefiniti verranno archiviati nel file di configurazione cyclecloud (in genere situato in ~/.cycle/config.ini), non nella project.ini. Questa operazione consente di controllare la versione di project.ini.
Il caricamento del contenuto del progetto comprime le directory chef e sincronizza sia chef che cluster init nell'locker di destinazione. Queste verranno archiviate all'indirizzo:
- (locker)/projects/(project)/(version)/(spec_name)/cluster-init
- (locker)/projects/(project)/(version)/(spec_name)/chef
Blob Download
Usare project download per scaricare tutti i BLOB a cui si fa riferimento nella project.ini nella directory BLOB locali. Il comando usa il [locker] parametro e tenterà di scaricare i BLOB elencati in project.ini dall'archivio locale. Verrà restituito un errore se i file non possono trovarsi.
Configurazione del progetto
Specifiche
Quando si crea un nuovo progetto, viene definita una singola specifica predefinita. È possibile aggiungere altre specifiche al progetto tramite il cyclecloud project add_spec comando .
Controllo delle versioni
Per impostazione predefinita, tutti i progetti hanno una versione 1.0.0. È possibile impostare una versione personalizzata durante lo sviluppo e la distribuzione di progetti impostando version=x.y.z nel file project.ini .
Ad esempio, se "locker_url" era "az://my-account/my-container/projects", il progetto è stato denominato "Order66", versione "1.6.9" e la specifica è "predefinita", l'URL sarà:
- 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
BLOB
Esistono due tipi di BLOB: BLOB di progetto e BLOB utente.
BLOB di progetto
I BLOB di progetto sono file binari forniti dall'autore del progetto con il presupposto che possano essere distribuiti (ad esempio un file binario per un progetto open source consentito per la ridistribuzione). I BLOB di progetto passano alla directory "BLOB" di un progetto e, quando caricati in un archivio, si trovano in /project/BLOB.
Per aggiungere BLOB ai progetti, aggiungere i file al project.ini:
[[blobs optionalname]]
Files = projectblob1.tgz, projectblob2.tgz, projectblob3.tgz
È possibile separare più BLOB in base a una virgola. È anche possibile specificare il percorso relativo della directory BLOB del progetto.
BLOB utente
I BLOB utente sono file binari che l'autore del progetto non può ridistribuire legalmente, ad esempio file binari UGE. Questi file non vengono inseriti in pacchetto con il progetto, ma devono essere invece distribuiti manualmente nell'archivio. I file si trovano in /BLOBs/my-project/my-BLOB.tgz. I BLOB utente non devono essere definiti nella project.ini.
Per scaricare qualsiasi BLOB, usare il jetpack download comando dall'interfaccia della riga di comando o dalla jetpack_download risorsa Chef. CycleCloud cercherà prima il BLOB utente. Se tale file non si trova, verrà usato il BLOB a livello di progetto.
Nota
È possibile eseguire l'override di un BLOB di progetto con un BLOB utente dello stesso nome.
Specificare il progetto all'interno di un modello di cluster
La sintassi del progetto consente di specificare più specifiche nei nodi. Per definire un progetto, usare quanto segue:
[[[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)
Nota
Il nome specificato dopo 'spec' può essere qualsiasi elemento, ma può e deve essere usato come collegamento per definire alcune > proprietà comuni.
È anche possibile applicare più specifiche a un determinato nodo come indicato di seguito:
[[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)
Separando il nome del progetto, il nome della specifica e la versione con i due punti, CycleCloud può analizzare automaticamente tali valori nelle impostazioni appropriate Project/Version/Spec :
[[node scheduler]]
AdditionalClusterInitSpecs = $ClusterInitSpecs
[[[cluster-init myproject:myspec:x.y.z]]]
[[[cluster-init otherproject:otherspec:a.b.c]]]
Le specifiche possono anche essere ereditate tra i nodi. Ad esempio, è possibile condividere una specifica comune tra tutti i nodi, quindi eseguire una specifica personalizzata nel nodo dell'utilità di pianificazione:
[[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
In questo modo si applicano sia le common specifiche e scheduler al nodo dell'utilità di pianificazione, mentre si applicano solo le common specifiche e execute all'oggetto nodearray di esecuzione.
Per impostazione predefinita, le specifiche verranno eseguite nell'ordine in cui vengono visualizzate nel modello, eseguendo prima le specifiche ereditate. Order è un numero intero facoltativo impostato su un valore predefinito di 1000 e può essere usato per definire l'ordine delle specifiche.
Se nella definizione viene specificato [[[cluster-init]]] un solo nome, si presuppone che sia il nome della specifica. Ad esempio:
[[[cluster-init myspec]]]
Project = myproject
Version = 1.0.0
è una configurazione specifica valida in cui Spec=myspec è implicita dal nome.
run_list
È possibile specificare un elenco di runlist a livello di progetto o specifica all'interno del project.ini:
[spec scheduler]
run_list = role[a], recipe[b]
Quando un nodo include la specifica "utilità di pianificazione", il run_list definito verrà aggiunto automaticamente a qualsiasi runlist definito in precedenza. Ad esempio, se il run_list definito in [configuration] è run_list = recipe[test], l'elenco di runlist finale sarà run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].
È anche possibile sovrascrivere un elenco di runlist a livello di specifica in un nodo. Questo sostituirà qualsiasi run_list incluso nel project.ini. Ad esempio, se la definizione del nodo è stata modificata nel modo seguente:
[cluster-init test-project:scheduler:1.0.0]
run_list = recipe[different-test]
L'elenco di runlist definito nel progetto verrà ignorato e verrà usato il codice precedente. L'elenco di esecuzione finale nel nodo sarà run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init]quindi .
Nota
Runlist sono specifici di chef e non si applicano in caso contrario.
Percorsi dei file
I file chef compressi verranno scaricati durante la fase di bootstrap dell'avvio del nodo. Vengono scaricati in $JETPACK_HOME/system/chef/tarballs e decompressi in $JETPACK_HOME/system/chef/chef-repo/e usati durante la convergenza del nodo.
Nota
Per eseguire cookbook personalizzati, è NECESSARIO specificarli nel run_list per il nodo.
I file cluster-init verranno scaricati in /mnt/cluster-init/(project)/(spec)/. Per "my-project" e "my-spec", verranno visualizzati gli script, i file e i test che si trovano in /mnt/cluster-init/my-project/my-spec.
Sincronizzazione dei progetti
I progetti CycleCloud possono essere sincronizzati dai mirror nell'archiviazione cloud locale del cluster. Impostare un attributo SourceLocker in una [cluster-init] sezione all'interno del modello. Il nome della casella di sicurezza specificata verrà usato come origine del progetto e il contenuto verrà sincronizzato con l'locker all'avvio del cluster. È anche possibile usare il nome della casella di sicurezza come prima parte del nome cluster-init. Ad esempio, se l'locker di origine era "cyclecloud", le due definizioni seguenti sono le stesse:
[cluster-init my-project:my-spect:1.2.3]
SourceLocker=cyclecloud
[cluster-init cyclecloud/my-proect:my-spec:1.2.3]
Archiviazione file di grandi dimensioni
I progetti supportano file di grandi dimensioni. Al livello superiore di un progetto appena creato verrà visualizzata una directory "BLOB" per i file di grandi dimensioni (BLOB). Si noti che i BLOB inseriti in questa directory hanno uno scopo specifico e agiscono in modo diverso rispetto agli elementi all'interno della directory "file".
Gli elementi all'interno della directory "BLOB" sono indipendenti dalla specifica e dalla versione: qualsiasi elemento in "BLOB" può essere condiviso tra specifiche o versioni di progetto. Ad esempio, un programma di installazione per un programma che cambia raramente può essere archiviato all'interno di "BLOB" e a cui viene fatto riferimento all'interno del project.ini. Quando si esegue l'iterazione nelle versioni del progetto, il singolo file rimane invariato e viene copiato solo una volta nell'archiviazione cloud, che consente di risparmiare sui costi di trasferimento e archiviazione.
Per aggiungere un BLOB, inserire semplicemente un file nella directory "BLOB" e modificare il project.ini per fare riferimento a tale file:
[blobs]
Files=big_file1.tgz
Quando si usa il project upload comando , tutti i BLOB a cui viene fatto riferimento nel project.ini verranno trasferiti nell'archiviazione cloud.
File di log
I file di log generati durante l'esecuzione di cluster-init si trovano in $JETPACK_HOME/logs/cluster-init/(project)/(spec).
Esegui file
Quando viene eseguito correttamente uno script cluster-init, viene inserito un file in /mnt/cluster-init/.run/(project)/(spec) per assicurarsi che non venga eseguito di nuovo in una successiva convergenza. Se si vuole eseguire di nuovo lo script, eliminare il file appropriato in questa directory.
Directory script
Quando CycleCloud esegue script nella directory degli script, aggiungerà variabili di ambiente al percorso e al nome delle directory specifiche e del progetto:
CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH
In Linux, un progetto denominato "test-project" con una specifica "default" avrà percorsi come indicato di seguito:
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
Esegui solo script
Per eseguire SOLO gli script cluster-init:
jetpack converge --cluster-init
L'output del comando passerà sia a STDOUT che a jetpack.log. Ogni script avrà anche l'output registrato in:
$JETPACK_HOME/logs/cluster-init/(project)/(spec)/scripts/(script.sh).out
Specifiche chef e componibili personalizzate
Ogni specifica include una directory chef. Prima di una convergenza, ogni specifica verrà annullata ed estratta nel repository chef locale, sostituendo eventuali cookbook, ruoli e contenitori di dati esistenti con lo stesso nome. Questa operazione viene eseguita nell'ordine in cui vengono definite le specifiche, quindi in caso di collisione di denominazione, l'ultima specifica definita vincerà sempre.
download jetpack
Per scaricare un BLOB all'interno di uno script cluster-init, usare il comando jetpack download (filename) per eseguirne il pull dalla directory BLOBs. L'esecuzione di questo comando da uno script cluster-init determinerà automaticamente il progetto e l'URL di base. Per usarlo in un contesto non cluster-init, è necessario specificare il progetto (vedere --help per altre informazioni).
Per gli utenti chef è stato creato un jetpack_download LWRP:
jetpack_download "big-file1.tgz" do
project "my-project"
end
In chef il percorso di download predefinito è #{node[:jetpack][:downloads]}. Per modificare la destinazione del file, usare quanto segue:
jetpack_download "foo.tgz" do
project "my-project"
dest "/tmp/download.tgz"
end
Se usato all'interno di Chef, è necessario specificare il progetto.