chef-solo

chef-solo est une commande qui exécute Chef Infra Client d'une manière qui ne nécessite pas que le serveur Chef Infra fasse converger les cookbooks. chef-solo utilise le mode local Chef de Chef Infra Client et ne prend pas en charge les fonctionnalités suivantes présentes dans les configurations Chef Infra Client/serveur :

• Distribution centralisée de cookbooks
• Une API centralisée qui interagit avec et intègre les composants de l'infrastructure
• Authentification ou autorisation

L'exécutable chef-solo est exécuté comme un outil de ligne de commande.

chef-solo prend en charge deux emplacements à partir desquels les cookbooks peuvent être exécutés :

• Un répertoire local.
• Une URL à laquelle se trouve une archive tar.gz.

L'utilisation d'une archive tar.gz est l'approche la plus courante, mais nécessite que les cookbooks soient ajoutés à une archive. Par exemple:

tar zcvf chef-solo.tar.gz ./cookbooks

Si plusieurs répertoires de cookbooks sont utilisés, chef-solo s'attend à ce que l'archive tar.gz ait une structure de répertoires similaire à la suivante :

cookbooks/
  |---- cbname1/
    |--attributes/ ... etc
  ...
  |---- cbname2/
    |--attributes/

La variable cookbook_path dans le fichier solo.rb doit inclure les deux répertoires. Par exemple:

tar zcvf chef-solo.tar.gz ./cookbooks ./site-cookbooks

Lorsque l'archive tar.gz contient tous les cookbooks requis par chef-solo, il faut la télécharger sur le serveur Web à partir duquel chef-solo accédera à l'archive.

Contrairement à Chef Infra Client, où l'objet nœud est stocké sur le serveur Chef Infra, chef-solo stocke ses objets nœud sous forme de fichiers JSON sur le disque local. Par défaut, chef-solo stocke ces fichiers dans un dossier de nœuds dans le même répertoire que le répertoire de cookbooks. On peut contrôler l'emplacement de ce répertoire à l'aide de la valeur node_path dans le fichier de configuration.

chef-solo n'interagit pas avec le serveur Chef Infra. Par conséquent, les attributs spécifiques au nœud doivent se trouver dans un fichier JSON sur le système cible, un emplacement distant (comme Amazon Simple Storage Service (S3)) ou un serveur Web sur le réseau local.

Le fichier JSON doit également spécifier les recettes qui font partie de la liste d'exécution. Par exemple:

{
  "resolver": {
    "nameservers": [ "10.0.0.1" ],
    "search":"int.example.com"
  },
  "run_list": [ "recipe[resolver]" ]
}

Un sac de données est défini à l'aide de JSON. chef-solo recherchera les sacs de données dans /var/chef/data_bags, mais cet emplacement peut être modifié en modifiant le paramètre dans solo.rb. Par exemple, le paramètre suivant dans solo.rb :

data_bag_path '/var/chef-solo/data_bags'

Créer un sac de données en créant des dossiers. Par exemple:

mkdir /var/chef-solo/data_bags

et:

mkdir /var/chef-solo/data_bags/admins

puis créer un fichier JSON à cet emplacement :

{
   "id": "ITEM_NAME"
}

où le nom du fichier est ITEM_NAME, par exemple :

/var/chef-solo/data_bags/admins/ITEM_NAME.json

Un rôle est défini à l'aide de JSON ou de Ruby DSL. chef-solo recherchera les rôles dans /var/chef/roles, mais cet emplacement peut être modifié en modifiant le paramètre de role_path dans solo.rb. Par exemple, le paramètre suivant dans solo.rb:

role_path '/var/chef-solo/roles'

Les données de rôle ressemblent à ce qui suit en JSON:

{
  "name": "test",
  "default_attributes": { },
  "override_attributes": { },
  "json_class": "Chef::Role",
  "description": "This is just a test role, no big deal.",
  "chef_type": "role",
  "run_list": [ "recipe[test]" ]
}

et comme ce qui suit en Ruby DSL:

name 'test'
description 'This is just a test role, no big deal.'
run_list 'recipe[test]'

et enfin, les données JSON transmises à chef-solo:

{ 'run_list': 'role[test]' }

Un environnement est défini à l'aide de JSON ou de Ruby DSL. chef-solo recherchera les environnements dans /var/chef/environments, mais cet emplacement peut être modifié en modifiant le paramètre pour environment_path dans solo.rb. Par exemple, le paramètre suivant dans solo.rb:

environment_path '/var/chef-solo/environments'

Les données d'environnement ressemblent à ce qui suit dans JSON:

{
  "name": "dev",
  "default_attributes": {
    "apache2": {
      "listen_ports": [
        "80",
        "443"
      ]
    }
  },
  "json_class": "Chef::Environment",
    "description": "",
    "cookbook_versions": {
    "couchdb": "= 11.0.0"
  },
  "chef_type": "environment"
  }

et comme ce qui suit dans Ruby DSL:

name 'environment_name'
description 'environment_description'
cookbook OR cookbook_versions  'cookbook' OR 'cookbook' => 'cookbook_version'
default_attributes 'node' => { 'attribute' => %w(value value etc.) }
override_attributes 'node' => { 'attribute' => %w(value value etc.) }

Cette commande a la syntaxe suivante :

chef-solo VALEUR DE L'OPTION VALEUR DE L'OPTION ...

chef-solo peut être exécuté en tant qu'utilisateur non root. Par exemple, on peut mettre à jour le fichier sudoers :

# spécification du privilège chef-solo
chef ALL=(ALL) NOPASSWD: /usr/bin/chef-solo

où chef est le nom de l'utilisateur non root. Cela permettrait à chef-solo d'exécuter n'importe quelle commande sur le nœud sans nécessiter de mot de passe.

Exécuter chef-solo en utilisant les paramètres ~/chef/solo.rb

chef-solo -c ~/chef/solo.rb

Utiliser une URL

chef-solo -c ~/solo.rb -j ~/node.json -r http://www.example.com/chef-solo.tar.gz

Le fichier tar.gz est archivé dans file_cache_path, puis extrait dans cookbooks_path.

Utiliser un répertoire

chef-solo -c ~/solo.rb -j ~/node.json

chef-solo cherchera dans le fichier solo.rb pour déterminer le répertoire dans lequel se trouvent les cookbooks.

Utiliser une URL pour le cookbooks et les données JSON

chef-solo -c ~/solo.rb -j http://www.example.com/node.json --recipe-url http://www.example.com/chef-solo.tar.gz

où –recipe-url correspond à recette_url et -j correspond à json_attribs, qui sont tous deux des options de configuration dans solo.rb.