Projets
Un projet est une collection de ressources qui définissent des configurations de nœud. Les projets contiennent des spécifications. Quand un nœud démarre, il est configuré en traitant et en exécutant une séquence de spécifications.
Azure CycleCloud utilise des projets pour gérer des applications en cluster, telles que des planificateurs de lots. Dans CycleCloud HPCPack, le projet est une spécification et cn une hn spécification qui définissent les configurations et les recettes pour le nœud principal et le nœud de calcul HPCPack.
Vous trouverez ci-dessous une définition de nœud partielle. Le nœud docker-registry exécute trois spécifications : lier les spécifications du projet okta version 1.3.0, ainsi que les spécifications de base et de registre du projet Docker version 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]]]
La balise de fin est le numéro de version du projet.
[[[cluster-init <project>:<spec>:<project version>]]]
Un casier est une référence à un conteneur de compte de stockage et aux informations d’identification. Les nœuds ont unlocker par défaut. Cet attribut n’est donc pas strictement nécessaire.
Azure CycleCloud utilise un raccourci pour les comptes de stockage. Il peut donc https://mystorage.blob.core.windows.net/mycontainer être écrit en tant que az://mystorage/mycontainer.
Le nœud télécharge chaque projet qu’il référence à partir du casier à l’aide de l’outil pogo :
pogo get az://mystorage/mycontainer/projects/okta/1.3.0/bind
Si un projet est défini sur un nœud, mais qu’il n’existe pas dans l’emplacement de stockage attendu, le nœud signale un Software Installation Failure à CycleCloud.
CycleCloud a des projets internes qui s’exécutent par défaut sur tous les nœuds pour effectuer une gestion spéciale des volumes et des réseaux et configurer la communication avec CycleCloud. Ces projets internes sont mis en miroir automatiquement dans le casier.
L’utilisateur est responsable de la mise en miroir de tous les projets supplémentaires dans le casier. L’interface CLI CycleCloud a des méthodes pour composer des projets :
cyclecloud project init myproject
et miroir :
cyclecloud project init mylocker
projets dans des casiers.
Les spécifications sont constituées de scripts python, shell ou powershell.
Création d'un projet
Pour créer un projet, utilisez la commande cyclecloud project init myprojectCLI, où myproject est le nom du projet que vous souhaitez créer. Cela crée un projet appelé « myproject », avec une seule spécification nommée « default » que vous pouvez modifier. L’arborescence de répertoires sera créée avec des fichiers squelettes que vous modifierez pour inclure vos propres informations.
Structure de répertoires
Les répertoires suivants seront créés par la commande projet :
\myproject
├── project.ini
├── blobs
├── templates
├── specs
│ ├── default
│ └── cluster-init
│ ├── scripts
│ ├── files
│ └── tests
│ └── chef
│ ├── site-cookbooks
│ ├── data_bag
│ └── roles
Le répertoire des modèles contient vos modèles de cluster, tandis que les spécifications contiennent les spécifications définissant votre projet. spec a deux sous-répertoires : cluster-init et chef personnalisé. cluster-init contient des répertoires qui ont une signification particulière, comme le répertoire de scripts (contient des scripts exécutés dans l’ordre lexicographique sur le nœud), des fichiers (fichiers de données brutes à placer sur le nœud) et des tests (contient des tests à exécuter lors du démarrage d’un cluster en mode test).
Le sous-répertoire chef personnalisé comporte trois répertoires : des livres de cuisine de site (pour les définitions de livres de cuisine), des data_bags (définitions de sacs de données) et des rôles (fichiers de définition de rôle chef).
project.ini
project.ini est le fichier contenant toutes les métadonnées de votre projet. Il peut contenir les éléments suivants :
| Paramètre | Description |
|---|---|
| name | Nom du projet. Les mots doivent être séparés par des tirets, par exemple, order-66-2018 |
| label | Nom du projet. Nom long (avec espaces) du cluster à des fins d’affichage. |
| type | Trois options : planificateur, application, <vide>. Détermine le type de projet et génère le modèle approprié. Valeur par défaut : application |
| version | Format : x.x.x.x |
Casiers
Le contenu du projet est stocké dans un casier. Vous pouvez charger le contenu de votre projet dans n’importe quel casier défini dans votre installation CycleCloud via la commande cyclecloud project upload (locker), où (locker) est le nom d’un coffre de stockage cloud dans votre installation CycleCloud. Celocker est défini comme cible par défaut. Vous pouvez également voir ce que les casiers sont disponibles avec la commande cyclecloud locker list. Des détails sur un casier spécifique peuvent être consultés avec cyclecloud locker show (locker).
Si vous ajoutez plusieurs casiers, vous pouvez définir votre valeur par défaut avec cyclecloud project default_target (locker), puis simplement exécuter cyclecloud project upload. Vous pouvez également définir un coffre par défaut global qui peut être partagé par des projets avec la commande cyclecloud project default locker (locker) -global.
Notes
Les casiers par défaut sont stockés dans le fichier de configuration cyclecloud (généralement situé dans ~/.cycle/config.ini), et non dans le project.ini. Pour permettre à project.ini d’être contrôlée par la version.
Le chargement du contenu de votre projet zipera les répertoires des chefs et synchronise à la fois chef et cluster init sur votre casier cible. Celles-ci seront stockées à l’adresse suivante :
- (locker)/projects/(project)/(version)/(spec_name)/cluster-init
- (locker)/projects/(project)/(version)/(spec_name)/chef
Téléchargement d’objets blob
Permet project download de télécharger tous les objets blob référencés dans le project.ini dans votre répertoire d’objets blob locaux. La commande utilise le [locker] paramètre et tente de télécharger des objets blob répertoriés dans project.ini du casier vers le stockage local. Une erreur est retournée si les fichiers ne peuvent pas se trouver.
Configuration du projet
Spécifications
Lors de la création d’un projet, une seule spécification par défaut est définie. Vous pouvez ajouter des spécifications supplémentaires à votre projet via la cyclecloud project add_spec commande.
Contrôle de version
Par défaut, tous les projets ont une version de 1.0.0. Vous pouvez définir une version personnalisée lorsque vous développez et déployez des projets en définissant version=x.y.z dans le fichier project.ini .
Par exemple, si « locker_url » était « az://my-account/my-container/projects », le projet a été nommé « Order66 », la version était « 1.6.9 », et la spécification est « par défaut », votre URL serait :
- 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
Objets blob
Il existe deux types d’objets blob : objets blob de projet et objets blob utilisateur.
Objets blob de projet
Les objets blob de projet sont des fichiers binaires fournis par l’auteur du projet avec l’hypothèse qu’ils peuvent être distribués (c’est-à-dire un fichier binaire pour un projet open source que vous êtes autorisé à redistribuer). Les objets blob de projet se trouvent dans le répertoire « blobs » d’un projet, et quand ils sont chargés dans un casier, ils se trouvent sur /project/blobs.
Pour ajouter des objets blob à des projets, ajoutez le ou les fichiers à votre project.ini:
[[blobs optionalname]]
Files = projectblob1.tgz, projectblob2.tgz, projectblob3.tgz
Plusieurs objets blob peuvent être séparés par une virgule. Vous pouvez également spécifier le chemin relatif du répertoire d’objets blob du projet.
Objets blob utilisateur
Les objets blob utilisateur sont des fichiers binaires que l’auteur du projet ne peut pas redistribuer légalement, comme les fichiers binaires UGE. Ces fichiers ne sont pas empaquetés avec le projet, mais doivent plutôt être intermédiaires vers le casier manuellement. Les fichiers se trouvent sur /blobs/my-project/my-blob.tgz. Les objets blob utilisateur n’ont pas besoin d’être définis dans le project.ini.
Pour télécharger n’importe quel objet blob, utilisez la jetpack download commande à partir de l’interface CLI ou de la jetpack_download ressource Chef. CycleCloud recherche d’abord l’objet blob utilisateur. Si ce fichier n’est pas situé, l’objet blob au niveau du projet est utilisé.
Notes
Il est possible de remplacer un objet blob de projet par un objet blob utilisateur du même nom.
Spécifier un projet dans un modèle de cluster
La syntaxe du projet vous permet de spécifier plusieurs spécifications sur vos nœuds. Pour définir un projet, utilisez les éléments suivants :
[[[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)
Notes
Le nom spécifié après « spec » peut être tout, mais peut et doit être utilisé comme raccourci pour définir certaines > propriétés communes.
Vous pouvez également appliquer plusieurs spécifications à un nœud donné comme suit :
[[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)
En séparant automatiquement le nom du projet, le nom de spécification et la version par deux-points, CycleCloud peut analyser ces valeurs dans les paramètres appropriés Project/Version/Spec :
[[node scheduler]]
AdditionalClusterInitSpecs = $ClusterInitSpecs
[[[cluster-init myproject:myspec:x.y.z]]]
[[[cluster-init otherproject:otherspec:a.b.c]]]
Les spécifications peuvent également être héritées entre les nœuds. Par exemple, vous pouvez partager une spécification commune entre tous les nœuds, puis exécuter une spécification personnalisée sur le nœud du planificateur :
[[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
Cela appliquerait à la fois les spécifications et scheduler les common spécifications au nœud du planificateur, tout en appliquant uniquement les spécifications et execute les common spécifications au nœud d’exécution.
Par défaut, les spécifications sont exécutées dans l’ordre dans lequel elles sont affichées dans le modèle, en exécutant d’abord les spécifications héritées. Order est un entier facultatif défini sur une valeur par défaut de 1 000 et peut être utilisé pour définir l’ordre des spécifications.
Si un seul nom est spécifié dans la [[[cluster-init]]] définition, il est supposé être le nom de spécification. Par exemple :
[[[cluster-init myspec]]]
Project = myproject
Version = 1.0.0
est une configuration de spécification valide dans laquelle Spec=myspec est implicite le nom.
run_list
Vous pouvez spécifier une liste d’exécution au niveau du projet ou de la spécification au sein de votre project.ini :
[spec scheduler]
run_list = role[a], recipe[b]
Lorsqu’un nœud inclut la spécification « scheduler », la run_list définie est automatiquement ajoutée à n’importe quelle liste d’exécution précédemment définie. Par exemple, si mon run_list défini sous [configuration] était run_list = recipe[test], la liste finale de runlist serait run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].
Vous pouvez également remplacer une runlist au niveau des spécifications sur un nœud. Cela remplacera toutes les run_list incluses dans le project.ini. Par exemple, si nous avons modifié la définition de nœud en procédant comme suit :
[cluster-init test-project:scheduler:1.0.0]
run_list = recipe[different-test]
La liste d’exécution définie dans le projet est ignorée et les éléments ci-dessus sont utilisés à la place. La dernière liste d’exécution sur le nœud serait run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init]alors .
Notes
Les runlists sont spécifiques au chef et ne s’appliquent pas autrement.
Emplacements des fichiers
Les fichiers chef compressés sont téléchargés pendant la phase de démarrage du démarrage du nœud. Ils sont téléchargés sur $JETPACK_HOME/system/chef/tarballs et décompressés sur $JETPACK_HOME/system/chef/chef/chef-repo/, et utilisés lors de la convergence du nœud.
Notes
Pour exécuter des livres de recettes personnalisés, vous DEVEZ les spécifier dans le run_list du nœud.
Les fichiers cluster-init sont téléchargés sur /mnt/cluster-init/(project)/(spec)/. Pour « my-project » et « my-spec », vous verrez vos scripts, fichiers et tests situés dans /mnt/cluster-init/my-project/my-spec.
Synchronisation de projets
Les projets CycleCloud peuvent être synchronisés à partir de miroirs dans un stockage cloud local de cluster. Définissez un attribut SourceLocker sur une [cluster-init] section dans votre modèle. Le nom du casier spécifié sera utilisé comme source du projet, et le contenu sera synchronisé avec votre casier au début du cluster. Vous pouvez également utiliser le nom du casier comme première partie du nom de cluster-init. Par exemple, si le casier source était « cyclecloud », les deux définitions suivantes sont les mêmes :
[cluster-init my-project:my-spect:1.2.3]
SourceLocker=cyclecloud
[cluster-init cyclecloud/my-proect:my-spec:1.2.3]
Stockage de fichiers volumineux
Les projets prennent en charge les fichiers volumineux. Au niveau supérieur d’un projet nouvellement créé, vous verrez un répertoire « blobs » pour vos fichiers volumineux (objets blob). Notez que les objets blob placés dans ce répertoire ont un objectif spécifique et agissent différemment des éléments du répertoire « fichiers ».
Les éléments du répertoire « blobs » sont des spécifications et des versions indépendantes : tout ce qui se trouve dans « blobs » peut être partagé entre des spécifications ou des versions de projet. Par exemple, un programme d’installation qui change peu souvent peut être stocké dans des « objets blob » et référencés dans votre project.ini. Lorsque vous effectuez une itération sur les versions de votre projet, ce fichier unique reste le même et n’est copié qu’une seule fois dans votre stockage cloud, ce qui permet d’économiser sur le coût de transfert et de stockage.
Pour ajouter un objet blob, placez simplement un fichier dans le répertoire « blobs » et modifiez votreproject.ini pour référencer ce fichier :
[blobs]
Files=big_file1.tgz
Lorsque vous utilisez la project upload commande, tous les objets blob référencés dans le project.ini sont transférés dans le stockage cloud.
Fichiers journaux
Les fichiers journaux générés lors de l’exécution de cluster-init se trouvent dans $JETPACK_HOME/logs/cluster-init/(project)/(spec)).
Exécuter des fichiers
Lorsqu’un script cluster-init est exécuté avec succès, un fichier est placé dans /mnt/cluster-init/.run/(project)/(spec) pour s’assurer qu’il n’est pas réexécuter sur une convergence ultérieure. Si vous souhaitez réexécuter le script, supprimez le fichier approprié dans ce répertoire.
Répertoires de script
Lorsque CycleCloud exécute des scripts dans le répertoire des scripts, il ajoute des variables d’environnement au chemin d’accès et au nom des répertoires de spécifications et de projets :
CYCLECLOUD_PROJECT_NAME
CYCLECLOUD_PROJECT_PATH
CYCLECLOUD_SPEC_NAME
CYCLECLOUD_SPEC_PATH
Sur Linux, un projet nommé « test-project » avec une spécification de « default » aurait des chemins d’accès comme suit :
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
Exécuter des scripts uniquement
Pour exécuter uniquement les scripts cluster-init :
jetpack converge --cluster-init
La sortie de la commande passe à STDOUT ainsi qu’à jetpack.log. Chaque script aura également sa sortie enregistrée dans :
$JETPACK_HOME/logs/cluster-init/(project)/(spec)/scripts/(script.sh).out
Specs personnalisés et composables
Chaque spécification a un répertoire chef dans celui-ci. Avant une convergence, chaque spécification n’est pas mise en place et extraite dans le dépôt chef local, en remplaçant tous les livres de cuisine, rôles et sacs de données existants portant le même nom. Cette opération est effectuée dans l’ordre dans lequel les spécifications sont définies. Par conséquent, dans le cas d’une collision de nommage, la dernière spécification définie gagnera toujours.
jetpack download
Pour télécharger un objet blob dans un script cluster-init, utilisez la commande jetpack download (filename) pour l’extraire du répertoire des objets blob. L’exécution de cette commande à partir d’un script cluster-init détermine le projet et l’URL de base pour vous. Pour l’utiliser dans un contexte non cluster-init, vous devez spécifier le projet (voir --help pour plus d’informations).
Pour les utilisateurs chef, un jetpack_download LWRP a été créé :
jetpack_download "big-file1.tgz" do
project "my-project"
end
Dans chef, l’emplacement de téléchargement par défaut est #{node[:jetpack][:downloads]}. Pour modifier la destination du fichier, utilisez les éléments suivants :
jetpack_download "foo.tgz" do
project "my-project"
dest "/tmp/download.tgz"
end
Lorsqu’il est utilisé dans chef, vous devez spécifier le projet.