Orchestration Chef

Chef est un outil de gestion de la configuration qui automatise le déploiement et la gestion des applications et de l’infrastructure. Il utilise un langage spécifique au domaine (DSL) pour écrire des « recettes » de configuration système. Ces recettes sont stockées dans des « livres de recettes » qui peuvent être partagés et réutilisés sur différents systèmes.

Chaque spécification de cluster-init peut référencer un ou plusieurs rôles Chef et/ou recettes de livre de recettes qui doivent être exécutées sur la machine virtuelle de démarrage.

Structure du projet

Le répertoire des spécifications d’un projet peut également contenir un sous-répertoire chef . Ce répertoire comporte trois répertoires : site-cookbooks (pour les définitions de livres de recettes), data_bags (définitions de conteneur de données) et roles (fichiers de définition de rôle de Chef) :

      myproject
          ├── specs
          │   ├── default
          │     └── chef
          │         ├── site-cookbooks
          │         ├── data_bags
          │         └── roles

Chef listes de courses

Vous pouvez spécifier un run_list au niveau du projet ou des spécifications au sein de votre project.ini:

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

Lorsqu’un nœud inclut la scheduler spécification, la run_list que vous définissez s'ajoute automatiquement à un run_list défini précédemment. Par exemple, si le run_list sous [configuration] est run_list = recipe[test], le run_list final est run_list = recipe[cyclecloud], recipe[test], role[a], recipe[b], recipe[cluster_init].

Vous pouvez également remplacer run_list au niveau de la spécification sur un nœud. Ce remplacement run_list supprime tous les run_list éléments inclus dans project.ini. Par exemple, vous pouvez remplacer la définition de nœud par la définition suivante :

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

L'utilisation de cette `run_list` entraîne l'ignorance des `run_list` définies dans le projet. La run_list finale sur le nœud devient run_list = recipe[cyclecloud], recipe[test], recipe[different-test], recipe[cluster_init].

Chef personnalisé et spécifications composables

Chaque spécification peut contenir un répertoire chef . Avant de converger un nœud, le processus annule et extrait chaque spécification dans le référentiel chef local, en remplaçant tous les livres de cuisine, rôles et sacs de données existants par des noms correspondants. Le processus suit l’ordre dans lequel vous définissez les spécifications, de sorte que la dernière spécification définie gagne en cas de conflit d’affectation de noms.

Emplacements des fichiers

Lorsque vous chargez le contenu de votre projet, CycleCloud compresse les trois répertoires Chef personnalisés et les synchronise avec votre casier cible à l’adresse (locker)/projects/(project)/(version)/(spec_name)/chef.

Le nœud télécharge les fichiers Chef compressés pendant la phase de démarrage du nœud. Le nœud télécharge les fichiers sur $JETPACK_HOME/system/chef/tarballs*, les décompresse vers $JETPACK_HOME/system/chef/chef-repo/, et les utilise pour synchroniser le nœud.

Fournisseur de ressources de téléchargement Jetpack

L’exemple suivant montre comment créer un jetpack_download fournisseur de ressources léger pour les utilisateurs Chef :

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 le code suivant :

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

Lorsque vous utilisez la commande dans Chef, vous devez spécifier le projet.