Mise en œuvre des recettes pour les piles Chef 11.10 - AWS OpsWorks

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Mise en œuvre des recettes pour les piles Chef 11.10

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.

Les piles Chef 11.10 offrent les avantages suivants sur les piles Chef 11.4 :

  • Comme les exécutions de Chef utilisent Ruby 2.0.0, vos recettes peuvent utiliser la nouvelle syntaxe Ruby.

  • Les recettes peuvent utiliser les conteneurs de données et la recherche Chef.

    Les piles Chef 11.10 peuvent utiliser plusieurs livres de recettes de la communauté sans modification.

  • Vous pouvez utiliser Berkshelf pour gérer les livres de recettes.

    Berkshelf fournit une manière beaucoup plus souple pour gérer vos livres de recettes personnalisés et utiliser les livres de recettes de la communauté dans une pile.

  • Les livres de recettes doivent déclarer les dépendances dans metadata.rb.

    Si votre livre de recettes dépend d'un autre livre, vous devez inclure cette dépendance dans le fichier metadata.rb de votre livre de recettes. Par exemple, si le livre inclut une recette avec une instruction telle que include_recipe anothercookbook::somerecipe, le fichier metadata.rb de votre livre de recettes doit comporter la ligne suivante : depends "anothercookbook".

  • AWS OpsWorks Stacks installe un client MySQL sur les instances d'une pile uniquement si celle-ci inclut une couche MySQL.

  • AWS OpsWorks Stacks installe un client Ganglia sur les instances d'une pile uniquement si celle-ci inclut une couche Ganglia.

  • Si un déploiement exécute bundle install et que l'installation échoue, le déploiement échoue aussi.

Important

Ne réutilisez pas les noms des livres de recettes intégrés comme livres personnalisés ou de la communauté. Les livres de recettes personnalisés ayant le même nom que les livres intégrés risquent d'échouer. Pour une liste complète des livres de recettes intégrés disponibles avec les piles Chef 11.10, 11.4 et 0.9, consultez le référentiel opsworks-cookbooks sur. GitHub

Les livres de recettes ayant des caractères non-ASCII et qui s'exécutent avec succès sur les piles Chef 0.9 et 11.4 peuvent échouer sur une pile Chef 11.10. La raison en est que les piles Chef 11.10 utilisent Ruby 2.0.0 pour les exécutions de Chef, qui est beaucoup plus strict sur l'encodage que Ruby 1.8.7. Pour garantir que ces livres s'exécutent correctement sur les piles Chef 11.10, chaque fichier utilisant des caractères non-ASCII doit comporter un commentaire fournissant une indication sur l'encodage. Par exemple, pour l'encodage UTF-8, le commentaire sera # encoding: UTF-8. Pour plus d'informations sur l'encodage Ruby 2.0.0, consultez Encodage.

Installation et priorité des livres de recettes

La procédure d'installation des livres de recettes AWS OpsWorks Stacks fonctionne quelque peu différemment pour les piles Chef 11.10 par rapport aux versions antérieures de Chef. Pour les piles Chef 11.10, une fois que AWS OpsWorks Stacks a installé les livres de recettes intégrés, personnalisés et Berkshelf, il les fusionne dans un répertoire commun dans l'ordre suivant :

  1. Livres de recettes intégrés.

  2. Livres de recettes Berkshelf, le cas échéant.

  3. Livres de recettes personnalisés, le cas échéant.

Lorsque AWS OpsWorks Stacks effectue cette fusion, il copie l'intégralité du contenu des répertoires, y compris les recettes. En cas de doublons, les règles suivantes s'appliquent :

  • Le contenu des livres de recettes Berkshelf a priorité sur les livres de recettes intégrés.

  • Le contenu des livres de recettes personnalisés a priorité sur les livres de recettes Berkshelf.

Pour illustrer le fonctionnement de ce processus, envisagez le scénario suivant, où les trois répertoires de livres de recettes incluent tous un livre de recettes nommé mycookbook :

  • Livres de recettes intégrés : mycookbook inclut un fichier d'attributs nommésomeattributes.rb, un fichier modèle nommé sometemplate.erb et une recette nomméesomerecipe.rb.

  • Livres de cuisine Berkshelf - mycookbook comprend et. sometemplate.erb somerecipe.rb

  • Livres de cuisine personnalisés — mycookbook inclussomerecipe.rb.

Le livre de recettes fusionné contient les éléments suivants :

  • someattributes.rb du livre de recettes intégré.

  • sometemplate.erb du livre de recettes Berkshelf.

  • somerecipe.rb du livre de recettes personnalisé.

Important

Vous ne devez pas personnaliser votre pile Chef 11.10 en copiant la totalité d'un livre de recettes intégré sur votre espace de stockage, puis en modifiant des parties du livre. Une telle action remplace la totalité du livre de recettes intégré, recettes incluses. Si AWS OpsWorks Stacks met à jour ce livre de recettes, votre pile ne bénéficiera de ces mises à jour que si vous mettez à jour manuellement votre copie privée. Pour plus d'informations sur la personnalisation des piles, consultez Personnalisation des piles AWS OpsWorks.

Vous pouvez utiliser la méthode search de Chef dans vos recettes pour interroger les données de la pile. Vous utilisez la même syntaxe que pour le serveur Chef, mais AWS OpsWorks Stacks obtient les données à partir de l'objet du nœud local au lieu d'interroger un serveur Chef. Ces données comprennent :

Les attributs de configuration et de déploiement de la pile contiennent la plupart des informations que les recettes obtiennent généralement par le biais de la recherche, notamment des données telles que les noms d'hôtes et les adresses IP pour chaque instance en ligne de la pile. AWS OpsWorks Stacks met à jour ces attributs pour chaque événement du cycle de vie, ce qui garantit qu'ils reflètent précisément l'état actuel de la pile. Cela signifie que vous pouvez souvent utiliser dans votre pile des recettes de la communauté dépendant de la recherche sans modification. La méthode de recherche retourne toujours les données appropriées ; elles proviennent simplement des attributs de configuration et de déploiement de pile, et non d'un serveur.

La principale limite de AWS OpsWorks Stacks search est qu'elle ne gère que les données de l'objet du nœud local, en particulier la configuration de la pile et les attributs de déploiement. Pour cette raison, les types de données suivants ne peuvent pas être disponibles par le biais de la recherche :

  • Attributs définis localement sur d'autres instances.

    Si une recette définit un attribut localement, ces informations ne sont pas renvoyées au service AWS OpsWorks Stacks. Vous ne pouvez donc pas accéder à ces données depuis d'autres instances à l'aide de la recherche.

  • Attributs deploy personnalisés.

    Vous pouvez spécifier le JSON personnalisé lorsque vous déployez une application et que les attributs correspondants sont installés sur les instances de la pile de ce déploiement. Cependant, si vous ne déployez que sur des instances sélectionnées, les attributs ne sont installés que sur ces instances. Les requêtes de ces attributs JSON personnalisés échouent sur toutes les autres instances. En outre, les attributs personnalisés ne sont inclus dans le JSON de configuration et de déploiement de la pile que pour ce déploiement. Ils ne sont accessibles que jusqu'à ce que le prochain événement du cycle de vie installe un nouvel ensemble d'attributs de déploiement et de configuration de la pile. Notez que si vous spécifiez un JSON personnalisé pour la pile, les attributs sont installés sur chaque instance pour tous les événements du cycle de vie et sont toujours accessibles par le biais de la recherche.

  • Données Ohai des autres instances.

    L'outil Ohai de Chef obtient une grande variété de données système sur une instance et les ajoute à l'objet nœud. Comme ces données sont stockées localement et ne sont pas rapportées au service AWS OpsWorks Stacks, la recherche ne peut pas accéder aux données Ohai à partir d'autres instances. Cependant, certaines de ces données peuvent être incluses dans les attributs de déploiement et de configuration de la pile.

  • Instances hors connexion.

    Les attributs de configuration et de déploiement de la pile contiennent les données uniquement pour les instances en ligne.

L'extrait de recette suivant montre comment obtenir l'adresse IP privée de l'instance d'une couche PHP à l'aide de la recherche.

appserver = search(:node, "role:php-app").first Chef::Log.info("The private IP is '#{appserver[:private_ip]}'")
Note

Lorsque AWS OpsWorks Stacks ajoute la configuration de la pile et les attributs de déploiement à l'objet du nœud, il crée en fait deux ensembles d'attributs de couche, chacun contenant les mêmes données. Un ensemble se trouve dans l'espace de layers noms, qui permet à AWS OpsWorks Stacks de stocker les données. L'autre ensemble se trouve dans l'espace de noms role, qui concerne la façon dont le serveur Chef stocke les données équivalentes. Le but de l'espace de role noms est de permettre au code de recherche implémenté pour le serveur Chef de s'exécuter sur une instance AWS OpsWorks Stacks. Si vous écrivez du code spécifiquement pour AWS OpsWorks Stacks, vous pouvez utiliser l'un layers:php-app ou role:php-app l'autre des exemples précédents et vous search obtiendrez le même résultat.

Utilisation des conteneurs de données

Vous pouvez utiliser la méthode data_bag_item de Chef dans vos recettes pour exécuter une requête sur un conteneur de données. Vous utilisez la même syntaxe comme vous le feriez pour un serveur Chef, mais AWS OpsWorks Stacks obtient les données des attributs de déploiement et de configuration de la pile de l'instance. Cependant, AWS OpsWorks Stacks ne prend pas actuellement en charge les environnements Chef et revient _default donc node.chef_environment toujours.

Vous créez un conteneur de données en utilisant un JSON personnalisé pour ajouter un ou plusieurs attributs à l'attribut [:opsworks][:data_bags]. L'exemple suivant illustre le format général de la création d'un conteneur de données dans un JSON personnalisé.

Note

Vous ne pouvez pas créer un conteneur de données en l'ajoutant à votre référentiel de livres de recettes. Vous devez utiliser un JSON personnalisé.

{ "opsworks": { "data_bags": { "bag_name1": { "item_name1: { "key1" : “value1”, "key2" : “value2”, ... } }, "bag_name2": { "item_name1": { "key1" : “value1”, "key2" : “value2”, ... } }, ... } } }

Généralement, vous spécifiez un JSON personnalisé pour la pile, lequel installe les attributs personnalisés sur chaque instance pour chaque événement ultérieur du cycle de vie. Vous pouvez aussi spécifier un JSON personnalisé lorsque vous déployez une application, mais ces attributs ne sont installés que pour ce déploiement et ne peuvent être installés que sur un ensemble sélectionné d'instances. Pour plus d’informations, consultez Déploiement d'applications.

L'exemple de JSON personnalisé suivant crée un conteneur de données nommé myapp. Il possède un seul élément, mysql, avec deux paires clé-valeur.

{ "opsworks": { "data_bags": { "myapp": { "mysql": { "username": "default-user", "password": "default-pass" } } } } }

Pour utiliser les données dans votre recette, vous pouvez appeler data_bag_item et lui transmettre les noms du conteneur de données et des valeurs, comme illustré dans l'extrait suivant.

mything = data_bag_item("myapp", "mysql") Chef::Log.info("The username is '#{mything['username']}' ")

Pour modifier les données du conteneur de données, il suffit de modifier le JSON personnalisé et il sera installé sur les instances de la pile lors du prochain événement du cycle de vie.

Utilisation de Berkshelf

Avec les piles Chef 0.9 et Chef 11.4, vous ne pouvez installer qu'un seul référentiel de livres de recettes personnalisés. Avec les piles Chef 11.10, vous pouvez utiliser Berkshelf pour gérer vos livres de recettes et leurs dépendances, ce qui vous permet d'installer des livres de recettes à partir de plusieurs référentiels. (Pour plus d’informations, consultez Empaquetage local des dépendances des livres de recettes.) Avec Berkshelf, vous pouvez notamment installer des livres de cuisine communautaires AWS OpsWorks compatibles avec Stacks directement à partir de leurs référentiels au lieu de devoir les copier dans votre référentiel de livres de recettes personnalisé. Les versions Berkshelf prises en charge dépendent du système d'exploitation. Pour plus d’informations, consultez AWS OpsWorks Systèmes d'exploitation Stacks.

Pour utiliser Berkshelf, vous devez l'activer explicitement, comme décrit dans Installation de livres de recettes personnalisés. Ensuite, incluez un fichier Berksfile dans le répertoire racine de votre référentiel de livres de recettes qui spécifie les livres à installer.

Pour spécifier une source de livres de recettes externe dans un fichier Berksfile, incluez un attribut source en haut du fichier qui spécifie l'URL du référentiel par défaut. Berkshelf recherchera les livres dans l'URL de la source, sauf si vous spécifiez explicitement un référentiel. Ensuite, incluez une ligne pour chaque livre de recettes que vous voulez installer dans le format suivant :

cookbook 'cookbook_name', ['>= cookbook_version'], [cookbook_options]

Les champs après cookbook spécifient le livre de recettes.

  • cookbook_name — (Obligatoire) Spécifie le nom du livre de recettes.

    Si vous n'incluez aucun autre champ, Berkshelf installe le livre de recettes à partir des URL source spécifiées.

  • cookbook_version — (Facultatif) Spécifie la ou les versions du livre de recettes.

    Vous pouvez utiliser un préfixe comme = ou >= pour spécifier une version ou une plage particulière de versions acceptables. Si vous ne spécifiez pas de version, Berkshelf installe la plus récente.

  • cookbook_options — (Facultatif) Le dernier champ est un hachage contenant une ou plusieurs paires clé-valeur qui spécifient des options telles que l'emplacement du référentiel.

    Par exemple, vous pouvez inclure une clé git pour définir un référentiel Git particulier et une clé tag pour définir une branche de référentiel particulière. La spécification de la branche du référentiel est généralement le meilleur moyen de s'assurer que vous installez votre livre de recettes préféré.

Important

Ne déclarez pas de livres de recettes en incluant une ligne metadata dans votre fichier Berksfile et en déclarant les dépendances des livres de recettes dans metadata.rb. Pour un bon fonctionnement, les deux fichiers doivent se trouver dans le même répertoire. Avec AWS OpsWorks Stacks, le Berksfile doit se trouver dans le répertoire racine du dépôt, mais les metadata.rb fichiers doivent se trouver dans leurs répertoires de livres de recettes respectifs. Vous devez à la place déclarer explicitement les livres de recettes externes dans le fichier Berksfile.

Voici un exemple de fichier Berksfile qui indique les différentes façons de spécifier les livres de recettes. Pour plus d'informations sur la façon de créer un fichier Berksfile, consultez Berkshelf.

source "https://supermarket.chef.io" cookbook 'apt' cookbook 'bluepill', '>= 2.3.1' cookbook 'ark', git: 'git://github.com/opscode-cookbooks/ark.git' cookbook 'build-essential', '>= 1.4.2', git: 'git://github.com/opscode-cookbooks/build-essential.git', tag: 'v1.4.2'

Le fichier installe les livres de recettes suivants :

  • La version apt la plus récente à partir du référentiel des livres de recettes de la communauté.

  • La version bluepill la plus récente à partir des livres de recettes de la communauté, aussi longtemps qu'il s'agit de la version 2.3.1 ou ultérieure.

  • La version ark la plus récente à partir d'un référentiel spécifié.

    L'URL de cet exemple est celle d'un dépôt de livres de recettes communautaire public sur GitHub, mais vous pouvez installer des livres de recettes provenant d'autres référentiels, y compris des référentiels privés. Pour plus d'informations, consultez Berkshelf.

  • Le livre de recettes build-essential à partir de la branche v1.4.2 du référentiel spécifié.

Un référentiel de livres de recettes personnalisés peut contenir des livres de recettes personnalisés en plus d'un fichier Berksfile. Dans ce cas, AWS OpsWorks Stacks installe les deux ensembles de livres de recettes, ce qui signifie qu'une instance peut avoir jusqu'à trois référentiels de livres de recettes.

  • Les livres de recettes intégrés sont installés dans /opt/aws/opsworks/current/cookbooks.

  • Si votre référentiel de livres de recettes personnalisés contient des livres de recettes, ils sont installés dans /opt/aws/opsworks/current/site-cookbooks.

  • Si vous avez activé Berkshelf et que votre référentiel de livres de recettes personnalisés contient un fichier Berksfile, les livres de recettes spécifiés sont installés dans /opt/aws/opsworks/current/berkshelf-cookbooks.

Les livres de recettes intégrés et vos livres de recettes personnalisés sont installés sur chaque instance lors de l'installation et ne sont pas mis à jour ultérieurement, sauf si vous exécutez manuellement la commande Update Custom Cookbooks stack. AWS OpsWorks Stacks fonctionne berks install pour chaque course de Chef. Vos livres de recettes Berkshelf sont donc mis à jour pour chaque événement du cycle de vie, conformément aux règles suivantes :

  • Si vous avez une nouvelle version du livre de recettes dans le référentiel, cette opération met à jour le livre à partir du référentiel.

  • Sinon, cette opération met à jour les livres de recettes Berkshelf à partir d'un cache local.

Note

Comme l'opération remplace les livres de recettes Berkshelf, si vous avez modifié les copies locales de livres de recettes, les modifications sont écrasées. Pour plus d'informations, consultez Berkshelf.

Vous pouvez aussi mettre à jour vos livres de recettes Berkshelf en exécutant la commande de pile Update Custom Cookbooks, qui met à jour aussi bien les livres Berkshelf que vos livres de recettes personnalisés.