Projets

Un projet est une collection de ressources qui définissent des configurations de nœud. Les projets contiennent des spécifications. Lorsqu’un nœud démarre, il traite et exécute une séquence de spécifications pour configurer le nœud.

Azure CycleCloud utilise des projets pour gérer des applications en cluster, telles que des planificateurs de lots. Dans le cluster HPCPack CycleCloud, le projet utilise les spécifications hn et cn pour définir les configurations et les recettes du nœud principal et du nœud de calcul HPCPack.

Dans la définition de nœud partielle suivante, le nœud docker-registry exécute trois spécifications : la bind spécification du projet Okta version 1.3.0 et les core spécifications registry 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 fait référence au conteneur et aux informations d’identification d’un compte de stockage . Les nœuds disposent d'un verrou par défaut, vous n’avez donc pas toujours besoin de spécifier cet attribut.

Azure CycleCloud utilise un raccourci pour les comptes de stockage. Par exemple, vous pouvez écrire https://mystorage.blob.core.windows.net/mycontainer en tant que az://mystorage/mycontainer.

Si vous définissez un projet 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. Le système met automatiquement en miroir ces projets internes dans le casier.

Vous êtes responsable de la mise en miroir des projets supplémentaires sur le casier. L’interface CLI CycleCloud offre des méthodes pour composer des projets :

cyclecloud project init myproject

Et de mettre en miroir des projets dans des casiers :

cyclecloud project init mylocker

Les spécifications se composent de scripts Python, shell ou PowerShell.

Créer un projet

Pour créer un projet, utilisez la commande cyclecloud project init myproject CLI où myproject se trouve le nom du projet que vous souhaitez créer. myproject a une default spécification que vous pouvez modifier. La commande crée l’arborescence de répertoires avec des fichiers squelettes que vous mettez à jour avec vos propres informations.

Structure de répertoires

La commande de projet crée les répertoires suivants :

      myproject
          ├── project.ini
          ├── blobs
          ├── templates
          ├── specs
          │   ├── default
          │     └── cluster-init
          │        ├── scripts
          │        ├── files
          │        └── tests

Le répertoire des modèles contient vos modèles de cluster, tandis que les spécifications contiennent les spécifications qui définissent votre projet. Le répertoire des spécifications possède un sous-répertoire nommé cluster-init (mais voir également Chef Orchestration). Le répertoire cluster-init contient des répertoires avec des significations spéciales, y compris le répertoire de scripts (qui contient des scripts qui s’exécutent dans l’ordre lexicographique sur le nœud), des fichiers (qui contiennent des fichiers de données brutes qui vont sur le nœud) et des tests (qui contiennent des tests qui s’exécutent lorsque vous démarrez un cluster en mode test).

project.ini

project.ini est le fichier qui contient toutes les métadonnées de votre projet. Il peut contenir les éléments suivants :

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 en exécutant la commande cyclecloud project upload (locker), où (locker) est le nom d’un casier de stockage cloud dans votre installation cycleCloud. Ce casier est la cible par défaut. Vous pouvez également exécuter la commande cyclecloud locker list pour voir les casiers disponibles. Vous pouvez afficher des détails sur un casier spécifique avec cyclecloud locker show (locker).

Si vous ajoutez plusieurs casiers, vous pouvez définir votre casier par défaut avec cyclecloud project default_target (locker), puis exécuter cyclecloud project upload. Vous pouvez également définir un casier global par défaut pour les projets à partager en exécutant la commande cyclecloud project default locker (locker) -global.

Lorsque vous chargez le contenu de votre projet, CycleCloud synchronise le contenu du cluster-init sur votre casier cible, à l’adresse projects/(project)/(version)/(spec_name)/cluster-init.

Blob Téléchargement

Permet project download de télécharger tous les objets blob référencés dans 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 au stockage local. Si la commande ne trouve pas les fichiers, elle retourne une erreur.

Configuration du projet

Spécifications

Lorsque vous créez un projet, vous définissez une default spécification. Utilisez la cyclecloud project add_spec commande pour ajouter d’autres spécifications à votre projet.

Gestion des versions

Par défaut, tous les projets utilisent la version 1.0.0. Définissez 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 l’locker_url est az://my-account/my-container/projects, le nom du projet est « Order66 », la version est 1.6.9 et la spécification est default, l’URL est :

az://my-account/my-container/projects/Order66/1.6.9/default

Objets blob

Il existe deux types d’objets blob : les objets blob de projet et les objets blob utilisateur.

Blocs de données de projet

Les auteurs de projets fournissent des objets blob de projet, qui sont des fichiers binaires qu’ils peuvent distribuer (par exemple, des fichiers binaires pour un projet open source que quelqu’un peut redistribuer légalement). Les objets blob de projet entrent dans le répertoire blobs d’un projet et se trouvent dans /project/blobs lorsque vous les chargez dans un casier.

Pour ajouter des blobs à des projets, ajoutez les fichiers à votre project.ini:

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

Séparez plusieurs blobs par une virgule. Vous pouvez également spécifier le chemin d’accès relatif au répertoire d’objets blob du projet.

Objets blob d’utilisateur

Les blobs utilisateur sont des fichiers binaires, tels que les binaires Univa Grid Engine, que l'auteur du projet ne peut pas redistribuer légalement. Ces fichiers ne sont pas empaquetés avec le projet. Les utilisateurs doivent les placer manuellement dans leur coffre. Les fichiers se trouvent dans /blobs/my-project/ dans le casier (par exemple, /blobs/my-project/my-blob.tgz). Vous n'avez pas besoin de définir des blobs utilisateur dans project.ini.

Pour télécharger n’importe quel objet blob, utilisez la jetpack download commande. CycleCloud recherche d'abord le blob utilisateur et utilise le blob au niveau du projet s'il ne peut pas localiser le fichier.

Spécifier des projets dans un modèle de cluster

Les spécifications sont définies dans votre modèle de cluster, à l’aide de la [[[cluster-init]]]section sur un nœud :

[[node defaults]]
[[[cluster-init my-project:common:1.0.0]]]

[[node scheduler]]
[[[cluster-init my-project:scheduler:1.0.0]]]

[[nodearray execute]]
[[[cluster-init my-project:execute:1.0.0]]]

Cet exemple tire parti de la defaults définition de nœud dont héritent tous les nœuds. Le nœud du planificateur obtient à la fois les spécifications common et scheduler, et les nœuds du tableau d’exécution obtiennent à la fois les spécifications common et execute.

Emplacements des fichiers

Le nœud télécharge les fichiers cluster-init vers /mnt/cluster-init/(project)/(spec)/. Pour my-project et my-spec, vos scripts, fichiers et tests se trouvent dans /mnt/cluster-init/my-project/my-spec.

Synchroniser des projets

Vous pouvez synchroniser des projets CycleCloud à partir de miroirs dans le stockage cloud local de cluster. Définissez un SourceLocker attribut sur une [cluster-init] section dans votre modèle. Le nom du casier que vous spécifiez est la source du projet et le contenu se synchronise avec votre casier lorsque le cluster démarre. Vous pouvez également utiliser le nom du casier comme première partie du nom de cluster-init. Par exemple, si le casier source est 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 voyez un blobs répertoire pour vos fichiers volumineux (objets blob). Les objets blob que vous placez dans ce répertoire servent un objectif spécifique et agissent différemment des éléments du files répertoire.

Les éléments du blobs répertoire agissent indépendamment des spécifications et des versions. Vous pouvez partager tout élément dans les BLOB entre les spécifications ou les versions de projet. Par exemple, vous pouvez stocker un programme d’installation qui change rarement dans des blobs et les référencer dans votre project.ini. Lorsque vous effectuez une itération sur les versions de votre projet, ce fichier unique reste le même et copie dans votre stockage cloud une seule fois, ce qui permet d’économiser sur les coûts de transfert et de stockage.

Pour ajouter un objet blob, placez un fichier dans le blobs répertoire et modifiez votre project.ini pour référencer ce fichier :

[blobs]
  Files=big_file1.tgz

Lorsque vous utilisez la project upload commande, elle transfère tous les objets blob référencés dans project.ini vers le stockage cloud.

Fichiers de logs

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 d’init de cluster s’exécute correctement, il place un fichier dans /mnt/cluster-init/.run/(project)/(spec) pour s’assurer que le script ne s’exécute pas à nouveau sur une convergence ultérieure. Pour 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 scripts répertoire, il ajoute des variables d’environnement au chemin d’accès et au nom des spec répertoires et project répertoires :

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 possède les chemins d’accès suivants :

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 des scripts cluster-init, utilisez la commande suivante :

jetpack converge --cluster-init

La commande envoie sa sortie à STDOUT et à jetpack.log. La sortie de chaque script est également enregistrée sur :

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

téléchargement jetpack

Pour télécharger un objet blob dans un script cluster-init, utilisez la commande jetpack download (filename) pour l’extraire du blobs répertoire. L’exécution de cette commande à partir d’un script cluster-init vous permet de déterminer le projet et l’URL de base pour vous. Pour l’utiliser dans un contexte non cluster-init, vous devez spécifier le projet. Pour plus d’informations, utilisez l’option --help .