Une courte digression : attributs des livres de cuisine, des recettes et des piles AWS OpsWorks

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.

Vous avez maintenant des serveurs d'applications et de bases de données, mais ils ne sont pas tout à fait prêts à être utilisés. Vous devez toujours configurer la base de données et les paramètres de connexion de l'application. AWS OpsWorks Stacks ne gère pas ces tâches automatiquement, mais prend en charge les livres de recettes, les recettes et les attributs dynamiques de Chef. Vous pouvez implémenter deux recettes, l'une pour configurer la base de données et l'autre pour configurer les paramètres de connexion de l'application, et demander à AWS OpsWorks Stacks de les exécuter pour vous.

Le livre de recettes phpapp, qui contient les recettes nécessaires, est déjà implémenté et prêt à être utilisé ; vous pouvez juste passer à Étape 3.3 : Ajoutez les livres de recettes personnalisés à MyStack si vous préférez. Si vous souhaitez en savoir plus, cette section fournit quelques informations sur les livres de recettes et sur les recettes, et décrit comment les recettes fonctionnent. Pour consulter le livre de recettes, accédez au livre de recettes phpapp.

Recettes et attributs

Une recette Chef est essentiellement une application Ruby spécialisée qui effectue des tâches sur une instance, telles que l'installation de packages, la création de fichiers de configuration, l'exécution de commandes shell, etc. Les groupes de recettes connexes sont organisés en livres de recettes, qui contiennent également les fichiers de prise en charge tels que les modèles pour la création des fichiers de configuration.

AWS OpsWorks Stacks propose un ensemble de livres de recettes qui prennent en charge les couches intégrées. Vous pouvez aussi créer des livres de cuisine personnalisés avec vos propres recettes pour effectuer des tâches personnalisées sur vos instances. Cette rubrique fournit une brève introduction aux recettes et montre comment les utiliser pour configurer la base de données et les paramètres de connexion de l'application. Pour plus d'informations sur les livres de recettes et les recettes, consultez Livres de recettes et recettes ou Personnalisation des piles AWS OpsWorks.

Les recettes dépendent généralement des attributs Chef pour les données en entrée :

• Certains attributs sont définis par Chef et fournissent des informations de base sur l'instance, telles que le système d'exploitation.

• AWS OpsWorks Stacks définit un ensemble d'attributs contenant des informations sur la pile, telles que les configurations des couches, et sur les applications déployées, telles que le référentiel d'applications.

  Vous pouvez ajouter des attributs personnalisés à cet ensemble en affectant le JSON personnalisé à la pile ou au déploiement.

• Vos livres de recettes peuvent aussi définir des attributs, qui sont spécifiques au livre de recettes.

  Les attributs du livre de recettes phpapp sont définis dans attributes/default.rb.

Pour une liste complète des attributs de AWS OpsWorks Stacks, reportez-vous aux sections Attributs de déploiement et de configuration de pile : Linux etAttributs des livres de recettes intégrés. Pour plus d’informations, consultez Remplacement des attributs.

Les attributs sont organisés selon une structure hiérarchique, laquelle peut être représentée sous forme d'un objet JSON.

Vous intégrez ces données dans votre application en utilisant la syntaxe nœud Chef, comme suit :

[:deploy][:simplephpapp][:database][:username]

Le nœud deploy possède un seul nœud d'application, simplephpapp, qui contient les informations sur la base de données de l'application, le référentiel Git, etc. L'exemple représente la valeur du nom d'utilisateur de la base de données, qui se résout en root.

Configurer la base de données

Les recettes de configuration intégrées à la couche MySQL créent automatiquement une base de données pour l'application nommée avec le nom abrégé de l'application. Dans cet exemple, vous avez déjà une base de données nommée simplephpapp. Cependant, vous devez terminer la configuration en créant une table pour que l'application stocke ses données. Vous pouvez créer le tableau manuellement, mais une meilleure approche consiste à implémenter une recette personnalisée pour gérer la tâche et à laisser AWS OpsWorks Stacks l'exécuter pour vous. Cette section décrit comment la recette, dbsetup.rb, est mise en œuvre. La procédure permettant à AWS OpsWorks Stacks d'exécuter la recette est décrite plus loin.

Pour consulter la recette dans le référentiel, accédez à dbsetup.rb. L'exemple suivant montre le code d'dbsetup.rb.

execute est une ressource Chef qui exécute une commande spécifiée. Dans ce cas, il s'agit d'une commande MySQL qui crée une table. La directive not_if garantit que la commande ne s'exécute pas si la table spécifiée existe déjà. Pour plus d'informations sur les ressources Chef, consultez À propos des ressources et des fournisseurs.

La recette insère les valeurs d'attribut dans la chaîne de commande, à l'aide de la syntaxe nœud discutée plus tôt. Par exemple, l'instruction suivante insère le nom d'utilisateur de la base de données.

#{deploy[:database][:username]}

Intéressons-nous de plus prés à ce code quelque peu énigmatique :

• Pour chaque itération, deploy est défini sur le nœud en cours de l'application et, par conséquent, se résout en [:deploy][:app_name]. Pour cet exemple, il est résolu en [:deploy][:simplephpapp].

• En utilisant les valeurs d'attribut de déploiement illustrées plus tôt, le nœud entier se résout en root.

• Vous enveloppez le nœud dans #{ } pour l'insérer en une chaîne.

La plupart des autres nœuds se résolvent d'une manière similaire. L'exception est #{node[:phpapp][:dbtable]}, qui est défini par le fichier d'attributs du livre de recettes personnalisé et se résout en nom de la table, urler. La commande réelle qui s'exécute sur l'instance MySQL est donc :

"/usr/bin/mysql 
    -uroot
    -pvjud1hw5v8
    simplephpapp
    -e'CREATE TABLE urler(
       id INT UNSIGNED NOT NULL AUTO_INCREMENT,
       author VARCHAR(63) NOT NULL,
       message TEXT,
       PRIMARY KEY (id))'
"

Cette commande crée une table nommée urler avec les champs id, author et message, à l'aide des informations d'identification et du nom de base de données des attributs de déploiement.

Connecter l'application à la base de données

La deuxième pièce du puzzle est l'application, qui a besoin des informations de connexion telles que le mot de passe de la base de données pour accéder à la table. SimplePHPApp n'a effectivement qu'un seul fichier de travail, app.php ; tout ce que fait index.php est de charger app.php.

app.php comprend db-connect.php, qui gère la connexion de la base de données, mais ce fichier n'est pas dans le référentiel. Vous ne pouvez pas créer db-connect.php à l'avance, car il définit la base de données en fonction de l'instance particulière. Au lieu de cela, la recette appsetup.rb génère db-connect.php à l'aide des données de connexion des attributs de déploiement.

Pour consulter la recette dans le référentiel, accédez à appsetup.rb. L'exemple suivant montre le code d'appsetup.rb.

Par exempledbsetup.rb, appsetup.rb itère sur les applications du nœud, encore une fois, une deploy simple application PHP. Il exécute un bloc de code avec une ressource script et une ressource template.

La script ressource installe Composer, un gestionnaire de dépendances pour les applications PHP. Il exécute ensuite la commande install de Composer pour installer les dépendances de l'exemple d'application sur le répertoire racine de l'application.

La ressource template génère db-connect.php et le met dans /srv/www/simplephpapp/current. Notez ce qui suit :

• La recette utilise une instruction conditionnelle pour spécifier le propriétaire du fichier, lequel dépend du système d'exploitation de l'instance.

• La directive only_if demande à Chef de ne générer le modèle que si le répertoire spécifié existe.

Une ressource template fonctionne sur un modèle qui a pour l'essentiel les mêmes contenu et structure que le fichier associé, mais qui inclut des espaces réservés pour les différentes valeurs de données. Le paramètre source spécifie le modèle, db-connect.php.erb, qui se trouve dans le répertoire phpapp templates/default du livre de recettes phpapp et contient les éléments suivants :

Lorsque le Chef traite le modèle, il remplace les espaces réservés <%= => par la valeur des variables correspondantes de la ressource modèle, qui proviennent à leur tour des attributs de déploiement. Le fichier généré se présente donc ainsi :