Exemple 4 : Ajout du contrôle de flux

Important

Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur AWS Re:Post ou via le AWS Support Premium.

Certaines recettes sont une simple série de ressources Chef. Dans ce cas, lorsque vous exécutez la recette, elle exécute simplement chaque fournisseur de ressources dans l'ordre. Cependant, il est souvent utile d'avoir un chemin d'exécution plus sophistiqué. Voici deux scénarios courants :

• Vous voulez qu'une recette exécute la même ressource plusieurs fois avec des paramètres d'attribut différents.

• Vous souhaitez utiliser différents paramètres d'attribut sur différents systèmes d'exploitation.

Vous pouvez traiter ce type de scénario en intégrant les structures de contrôle Ruby à la recette. Cette section montre comment modifier la recette de Exemple 3 : Création de répertoires pour traiter les deux scénarios.

Itération

Exemple 3 : Création de répertoires a montré comment utiliser une ressource directory pour créer un répertoire ou une chaîne de répertoires. Toutefois, supposons que vous souhaitiez créer deux répertoires distincts, /srv/www/config et /srv/www/shared. Vous pouvez implémenter une ressource de répertoire distincte pour chaque répertoire, mais cette approche peut être fastidieuse si vous souhaitez créer un très grand nombre de répertoires. La recette suivante montre un moyen plus simple de gérer la tâche.

[ "/srv/www/config", "/srv/www/shared" ].each do |path|
  directory path do
    mode 0755
    owner 'root'
    group 'root'
    recursive true
    action :create
  end
end

Au lieu d'utiliser une ressource de répertoire distincte pour chaque sous-répertoire, la recette utilise un ensemble de chaînes qui contient les chemins de sous-répertoire. La méthode each de Ruby exécute la ressource une fois pour chaque élément de l'ensemble, en commençant par le premier. La valeur de l'élément est représentée dans la ressource par la variable path, qui représente dans ce cas le chemin d'accès au répertoire. Vous pouvez facilement adapter cet exemple afin de créer n'importe quel nombre de sous-répertoires.

Pour exécuter la recette

1. Restez dans le répertoire createdir. Vous allez utiliser ce livre de recettes pour les prochains exemples.

2. Si vous ne l'avez pas déjà fait, exécutez kitchen destroy afin de commencer avec une instance propre.

3. Remplacez le code de default.rb par l'exemple et exécutez kitchen converge.

4. Connectez-vous à l'instance. Vous verrez les répertoires nouvellement créés sous /srv.

Vous pouvez utiliser une table de hachage pour spécifier deux valeurs pour chaque itération. La recette suivante crée /srv/www/config et /srv/www/shared, chacun avec un mode différent.

{ "/srv/www/config" => 0644, "/srv/www/shared" => 0755 }.each do |path, mode_value|
  directory path do
    mode mode_value
    owner 'root'
    group 'root'
    recursive true
    action :create
  end
end

Pour exécuter la recette

1. Si vous ne l'avez pas déjà fait, exécutez kitchen destroy afin de commencer avec une instance propre.

2. Remplacez le code de default.rb par l'exemple et exécutez kitchen converge.

3. Connectez-vous à l'instance. Vous verrez les répertoires nouvellement créés sous /srv avec les modes spécifiés.

Note

AWS OpsWorks Les recettes Stacks utilisent généralement cette approche pour extraire des valeurs du JSON de configuration et de déploiement de la pile (qui est essentiellement une grande table de hachage) et les insérer dans une ressource. Pour obtenir un exemple, consultez Recettes Deploy.

Logique conditionnelle

Vous pouvez également utiliser la logique conditionnelle de Ruby pour créer plusieurs branches d'exécution. La recette suivante utilise la logique if-elsif-else afin d'étendre l'exemple précédent pour qu'il crée un sous-répertoire nommé /srv/www/shared, mais uniquement sur les systèmes Debian et Ubuntu. Pour tous les autres systèmes, il consigne un message d'erreur qui s'affiche dans la sortie de Test Kitchen.

if platform?("debian", "ubuntu")
  directory "/srv/www/shared" do
    mode 0755
    owner 'root'
    group 'root'
    recursive true
    action :create
  end
else
  log "Unsupported system"
end

Pour exécuter un exemple de recette

1. Si votre instance est toujours fonctionnelle, exécutez kitchen destroy pour la fermer.

2. Remplacez le code de default.rb par l'exemple de code.

3. Modifiez .kitchen.yml afin d'ajouter un système CentOS 6.4 à la liste de plateformes. La section platforms du fichier doit maintenant ressembler à ce qui suit.

   
   ...
   platforms:
     - name: ubuntu-12.04
     - name: centos-6.4
   ...

4. Exécutez kitchen converge, qui crée une instance et exécute les recettes pour chaque plateforme dans .kitchen.yml, dans l'ordre.

   Note

   Si vous souhaitez faire converger une seule instance, ajoutez le nom de l'instance comme paramètre. Par exemple, pour faire converger la recette uniquement sur la plateforme Ubuntu, exécutez kitchen converge default-ubuntu-1204. Si vous oubliez les noms de plateformes, il suffit d'exécuter kitchen list.

Vous devriez voir votre message de journal dans la partie CentOS de la sortie Test Kitchen, qui ressemblera à quelque chose de similaire à ce qui suit :

...
Converging 1 resources
Recipe: createdir::default
* log[Unsupported system] action write[2014-06-23T19:10:30+00:00] INFO: Processing log[Unsupported system] action write (createdir::default line 12)
[2014-06-23T19:10:30+00:00] INFO: Unsupported system
       
[2014-06-23T19:10:30+00:00] INFO: Chef Run complete in 0.004972162 seconds

Vous pouvez désormais vous connecter aux instances et vérifier que les répertoires ont été créés ou non. Toutefois, vous ne pouvez pas simplement exécuter kitchen login maintenant. Vous devez spécifier l'instance en ajoutant le nom de la plateforme, par exemple kitchen login default-ubuntu-1204.

Note

Si une commande de Test Kitchen prend un nom d'instance, vous n'avez pas besoin de taper le nom complet. Test Kitchen traite le nom d'instance comme une expression régulière Ruby, vous avez donc besoin de suffisamment de caractères pour fournir une correspondance unique et de rien de plus. Par exemple, vous pouvez converger uniquement l'instance Ubuntu en exécutant kitchen converge ub ou vous connecter à l'instance CentOS en exécutant kitchen login 64.

A ce stade, vous vous demandez probablement comment la recette sait sur quelle plateforme elle est exécutée. Chef exécute un outil appelé Ohai pour chaque exécution qui collecte les données du système, y compris la plateforme, et il la représente sous forme d'un ensemble d'attributs dans une structure nommé objet de nœud. La méthode platform? de Chef compare les systèmes entre parenthèses à la valeur de plateforme Ohai et retourne true en cas de correspondance.

Vous pouvez référencer la valeur d'un attribut de nœud directement dans votre code en utilisant node['attribute_name']. La valeur de la plateforme, par exemple, est représentée par node['platform']. Vous pouvez, par exemple, avoir écrit l'exemple précédent comme suit.

if node[:platform] == 'debian' or node[:platform] == 'ubuntu'
  directory "/srv/www/shared" do
    mode 0755
    owner 'root'
    group 'root'
    recursive true
    action :create
  end
else
  log "Unsupported system"
end

Les utilisateurs incluent souvent une logique conditionnelle dans une recette pour tenir compte du fait que les différentes familles Linux utilisent parfois des noms différents pour les packages, les répertoires, etc. Par exemple, le nom du package Apache est httpd sur les systèmes CentOS et apache2 sur les systèmes Ubuntu.

Si vous avez juste besoin d'une chaîne différente pour différents systèmes, la méthode value_for_platform de Chef est une solution plus simple que if-elsif-else. La recette suivante crée un répertoire /srv/www/shared sur les systèmes CentOS, un répertoire /srv/www/data sur les systèmes Ubuntu et /srv/www/config sur tous les autres.

data_dir = value_for_platform(
  "centos" => { "default" => "/srv/www/shared" },
  "ubuntu" => { "default" => "/srv/www/data" },
  "default" => "/srv/www/config"
)
directory data_dir do
  mode 0755
  owner 'root'
  group 'root'
  recursive true
  action :create
end

value_for_platform attribue le chemin d'accès approprié pour data_dir et la ressource directory utilise cette valeur pour créer le répertoire.

Pour exécuter un exemple de recette

1. Si votre instance est toujours fonctionnelle, exécutez kitchen destroy pour la fermer.

2. Remplacez le code de default.rb par l'exemple de code.

3. Exécutez kitchen converge, puis connectez-vous à chaque instance pour vérifier que les répertoires appropriés sont présents.