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.

# Personnalisation des piles OpsWorks
<a name="customizing"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

OpsWorks Les couches intégrées de Stacks fournissent des fonctionnalités standard suffisantes à de nombreuses fins. Cependant, vous pouvez rencontrer un ou plusieurs des problèmes suivants :
+ La configuration standard d'une couche intégrée est adéquate, mais pas idéale ; vous souhaitez l'optimiser pour vos besoins.

  Par exemple, vous souhaiterez peut-être ajuster la configuration du serveur Nginx d'une couche de serveur Web statique en spécifiant vos propres valeurs pour des paramètres tels que le nombre maximum de processus de travail ou la `keepalivetimeout` valeur.
+ Il est bien d'avoir une fonctionnalité de couche intégrée, mais il est important de l'étendre en installant des packages supplémentaires ou en exécutant des scripts d'installation personnalisés.

  Par exemple, vous souhaiterez peut-être étendre une couche PHP App Server en installant également un serveur Redis.
+ Vous avez des exigences qui ne sont pas gérées par les couches intégrées.

  Par exemple, OpsWorks Stacks n'inclut pas de couches intégrées pour certains serveurs de base de données populaires. Vous pouvez créer une couche personnalisée qui installe ces serveurs sur les instances de la couche.
+ Vous exécutez une pile Windows qui prend en charge uniquement les couches personnalisées.

OpsWorks Stacks propose différentes méthodes pour personnaliser les couches afin de répondre à vos besoins spécifiques. Les exemples suivants sont listés afin d'accroître la complexité et la puissance :

**Note**  
Certaines de ces approches fonctionnent uniquement pour les piles Linux. Consultez les rubriques suivantes pour plus de détails.
+ Utilisez le JSON personnalisé pour remplacer les paramètres par défaut de OpsWorks Stacks.
+ Implémentez un livre de recettes Chef personnalisé avec un fichier d'attributs qui remplace les paramètres par défaut de OpsWorks Stacks.
+ Implémentez un livre de recettes Chef personnalisé avec un modèle qui remplace ou étend un modèle OpsWorks Stacks par défaut.
+ Implémentez un livre de recettes Chef personnalisé avec une recette simple qui exécute un script shell.
+ Implémentez un livre de recettes Chef personnalisé avec des recettes qui effectuent des tâches telles que la création et la configuration des répertoires, l'installation de packages, la création de fichiers de configuration, le déploiement d'applications, etc. 

Vous pouvez également remplacer les recettes, en fonction de la version de Chef de la pile et du système d'exploitation.
+ Avec les piles Chef 0.9 et 11.4, vous ne pouvez pas remplacer une recette intégrée en implémentant une recette personnalisée avec les mêmes noms de livre de recettes et de recette.

  Pour chaque événement du cycle de vie, OpsWorks Stacks exécute toujours les recettes intégrées en premier, suivies de toutes les recettes personnalisées. Etant donné que ces versions de Chef n'exécutent pas deux fois une recette avec les mêmes noms de livre de recettes et de recette, la recette intégrée est prioritaire et la recette personnalisée ne sera pas exécutée.
+ Vous pouvez remplacer les recettes intégrées sur les piles de Chef 11.10.

  Pour de plus amples informations, veuillez consulter [Installation et priorité des livres de recettes](workingcookbook-chef11-10.md#workingcookbook-chef11-10-override).
+ Vous ne pouvez pas remplacer les recettes intégrées sur les piles Windows.

  La façon dont OpsWorks Stacks gère les exécutions de Chef pour Windows Stacks ne permet pas de remplacer les recettes intégrées.

**Note**  
Étant donné que de nombreuses techniques utilisent des livres de recettes personnalisés, vous devez d'abord les lire [Livres de recettes et recettes](workingcookbook.md) si vous n'êtes pas déjà familiarisé avec l'implémentation des livres de recettes. [Principes de base des livre de recettes](cookbooks-101-basics.md)fournit une introduction détaillée à la mise en œuvre de livres de recettes personnalisés et [Implémentation de Cookbooks for Stacks OpsWorks](cookbooks-101-opsworks.md) explique en détail comment implémenter des livres de recettes pour les instances OpsWorks Stacks.

**Topics**
+ [Personnalisation de la configuration OpsWorks des piles en remplaçant les attributs](workingcookbook-attributes.md)
+ [Extension des fichiers de configuration de OpsWorks Stacks à l'aide de modèles personnalisés](workingcookbook-template-override.md)
+ [Extension d'une couche](workingcookbook-extend.md)
+ [Création d'une couche serveur Tomcat personnalisée](create-custom.md)
+ [Attributs de déploiement et de configuration de pile](workingcookbook-json.md)

# Personnalisation de la configuration OpsWorks des piles en remplaçant les attributs
<a name="workingcookbook-attributes"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

**Note**  
Pour les stacks Windows et les stacks Chef 12 Linux, OpsWorks Stacks utilise des exécutions Chef distinctes pour les recettes intégrées et les recettes personnalisées. Cela signifie que vous ne pouvez pas utiliser les techniques décrites dans cette section pour remplacer les attributs intégrés des piles Windows et Chef 12 Linux.

Les recettes et les modèles dépendent de divers attributs de Chef pour les informations propres à l'instance ou à la pile, par exemple les paramètres de configuration de couche ou de serveur d'applications. Ces attributs ont plusieurs sources :
+ **JSON personnalisé** : vous pouvez éventuellement spécifier des attributs JSON personnalisés lorsque vous créez, mettez à jour ou clonez une pile, ou lorsque vous déployez une application.
+ **Attributs de configuration de pile** —OpsWorks Stacks définit ces attributs pour contenir les informations de configuration de la pile, y compris les informations que vous spécifiez dans les paramètres de la console. 
+ **Attributs de déploiement** : AWS OpsWorks définit les attributs liés au déploiement pour les événements de déploiement.
+ **Attributs du livre de recettes** — Les livres de recettes intégrés et personnalisés incluent généralement un ou plusieurs [fichiers d'attributs](workingcookbook-installingcustom-components-attributes.md), qui contiennent des attributs représentant des valeurs spécifiques au livre de recettes, telles que les paramètres de configuration du serveur d'applications. 
+ **Chef** [—L'outil Ohai](http://docs.chef.io/resource_ohai.html) de Chef définit les attributs qui représentent une grande variété de paramètres de configuration du système, tels que le type de processeur et la mémoire installée.

Pour une liste complète des attributs de configuration et de déploiement de la pile, ainsi que des attributs intégrés des livres de recettes, consultez [Attributs de déploiement et de configuration de pile : Linux](attributes-json-linux.md) et [Attributs des livres de recettes intégrés](attributes-recipes.md). Pour plus d'informations sur les attributs Ohai, consultez [Ohai](https://docs.chef.io/ohai.html).

Lorsqu'un [événement du cycle de vie](workingcookbook-events.md) tel que Deploy ou Configure se produit, ou si vous exécutez une [commande de pile](workingstacks-commands.md) comme `execute_recipes` ou `update_packages`, OpsWorks Stacks effectue les opérations suivantes :
+ Envoie une commande correspondante à l'agent sur chaque instance concernée.

  L'agent exécute les recettes appropriées. Par exemple, pour un événement Deploy, l'agent exécute les recettes Deploy intégrées, suivies des recettes Deploy personnalisées.
+ Fusionne les attributs personnalisés JSON et de déploiement avec les attributs de configuration de la pile et les installe sur les instances.

Les attributs du JSON personnalisé, les attributs de configuration et de déploiement de la pile, les attributs des livres de recettes et les attributs Ohai sont fusionnés dans un *objet de nœud*, qui donne les valeurs d'attributs aux recettes. En règle générale, une instance n'a pas d'état en ce qui concerne les attributs de configuration de la pile, y compris n'importe quel JSON personnalisé. Lorsque vous exécutez une commande de déploiement ou de pile, les recettes associées utilisent les attributs de configuration de la pile qui ont été téléchargés avec la commande.

**Topics**
+ [Priorité des attributs](workingcookbook-attributes-precedence.md)
+ [Remplacement des attributs par un JSON personnalisé](workingcookbook-json-override.md)
+ [Remplacer les attributs des OpsWorks piles à l'aide d'attributs de livre de recettes personnalisés](workingcookbook-cookbook-attributes.md)

# Priorité des attributs
<a name="workingcookbook-attributes-precedence"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Si un attribut est défini de façon unique, Chef l'intègre simplement dans l'objet de nœud. Toutefois, n'importe quelle source d'attribut peut définir un attribut, il est donc possible pour le même attribut d'avoir plusieurs définitions avec des valeurs différentes. Par exemple, le livre de recettes intégré `apache2` définit `node[:apache][:keepalive]`, mais vous pouvez également définir cet attribut dans le JSON personnalisé ou dans un livre de recettes personnalisé. Si un attribut possède plusieurs définitions, elles sont évaluées dans un ordre qui est décrit plus loin et l'objet de nœud reçoit la définition avec la priorité la plus élevée.

Un attribut est défini comme suit :

```
node.type[:attribute][:sub_attribute][:...]=value
```

Si un attribut possède plusieurs définitions, le type détermine quelle définition est prioritaire, et cette définition est incorporée dans l'objet du nœud. OpsWorks Stacks utilise les types d'attributs suivants :
+ **default** —Il s'agit du type le plus courant, et cela signifie essentiellement « utiliser cette valeur si l'attribut n'a pas déjà été défini ». Si toutes les définitions d'un attribut sont de type `default`, la première définition dans l'ordre d'évaluation a priorité et les valeurs suivantes sont ignorées. Notez que OpsWorks Stacks définit toutes les définitions d'attributs de configuration et de déploiement de la pile sur le `default` type.
+ **normal** —Les attributs de ce type remplacent tous `default` `normal` les attributs définis précédemment dans l'ordre d'évaluation. Par exemple, si le premier attribut provient d'un livre de recettes intégré et possède un type `default` et si un deuxième attribut a été défini par l'utilisateur avec un type `normal`, la deuxième définition sera prioritaire.
+ **set** —Il s'agit d'un type obsolète que vous pourriez voir dans les anciens livres de cuisine. Il a été remplacé par `normal`, qui a la même priorité. 

Chef prend en charge plusieurs types d'attribut supplémentaires, dont un type `automatic` qui est prioritaire sur toutes les autres définitions d'attributs. Les définitions d'attributs générées par l'outil Ohai de Chef ont toutes le type `automatic` et sont donc en lecture seule. Ce n'est généralement pas un problème, car il n'y a aucune raison de les remplacer et ils sont distincts des attributs de OpsWorks Stacks. Toutefois, veillez à nommer vos attributs personnalisés des livres de recettes différemment des attributs Ohai. Pour plus d'informations, consultez [À propos des attributs](http://docs.chef.io/attributes.html).

**Note**  
L'outil Ohai est un exécutable que vous pouvez exécuter à partir de la ligne de commande. Pour lister les attributs Ohai d'une instance, connectez-vous à l'instance et exécutez `ohai` dans une fenêtre de terminal. Sachez qu'elle produit une très longue sortie.

Voici les étapes qui intègrent les différentes définitions d'attributs à l'objet de nœud :

1. Fusionnez les attributs personnalisés de configuration avec les attributs de configuration et de déploiement de la pile. 

   Les attributs JSON personnalisés peuvent être définis pour la pile ou pour un déploiement particulier. Ils sont les premiers dans l'ordre d'évaluation et ont le type `normal`. Si un ou plusieurs attributs de configuration de la pile sont aussi définis dans le JSON personnalisé, les valeurs du JSON personnalisé ont priorité. Sinon, OpsWorks Stacks intègre simplement les attributs personnalisés de JSON dans la configuration de la pile. 

1. Fusionnez les attributs de déploiement personnalisés JSON avec les attributs de déploiement et de configuration de la pile.

   Les attributs de déploiement personnalisés JSON ont le type `normal`, ce qui signifie qu'ils ont la priorité sur le JSON de configuration de pile intégré et personnalisé et sur le JSON de déploiement intégré.

1. Fusionnez les attributs de configuration et de déploiement de pile dans l'objet de nœud de l'instance.

1. Fusionnez les attributs des livres de recettes intégrés de l'instance dans l'objet de nœud.

   Les attributs intégrés des livres de recettes ont tous le type `default`. Si le ou les attributs intégrés du livre de recettes sont également définis dans les attributs de configuration et de déploiement de la pile, généralement parce que vous les avez définis avec du code JSON personnalisé, les définitions de configuration de la pile ont priorité sur les définitions du livre de recettes intégrées. Tous les autres attributs intégrés des livres de recettes sont simplement intégrés dans l'objet de nœud.

1. Fusionnez les attributs des livres de recettes personnalisés de l'instance dans l'objet de nœud.

   Les attributs personnalisés des livres de recettes ont généralement le type `normal` ou `default`. Des attributs uniques sont intégrés dans l'objet de nœud. Si des attributs de livre de recettes personnalisés sont également définis aux étapes 1 à 3 (généralement parce que vous les avez définis avec du JSON personnalisé), la priorité dépend du type de l'attribut de livre de recettes personnalisé :
   + Les attributs définis aux étapes 1 à 3 ont priorité sur les attributs personnalisés du livre de recettes`default`.
   + Les `normal` attributs personnalisés du livre de cuisine ont priorité sur les définitions des étapes 1 à 3. 

**Important**  
N'utilisez pas les attributs personnalisés `default` des livres de recettes pour remplacer les attributs intégrés des livres de recettes ou les attributs de configuration de la pile. Dans la mesure où les attributs personnalisés des livres de recettes sont évalués en dernier, les attributs `default` ont la priorité la plus basse et ne peuvent rien remplacer.

# Remplacement des attributs par un JSON personnalisé
<a name="workingcookbook-json-override"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

**Note**  
Comme OpsWorks Stacks gère les exécutions de Chef différemment pour les piles Windows et pour les piles Linux, vous ne pouvez pas utiliser les techniques décrites dans cette section pour les piles Windows.

Le moyen le plus simple de remplacer un attribut OpsWorks Stacks consiste à le définir dans du JSON personnalisé, qui a priorité sur les attributs de configuration et de déploiement de la pile, ainsi que sur les attributs de livre de recettes intégrés et personnalisés. `default` Pour de plus amples informations, veuillez consulter [Priorité des attributs](workingcookbook-attributes-precedence.md).

**Important**  
Vous devez remplacer les attributs de configuration et de déploiement de la pile avec soin. Par exemple, le remplacement des attributs dans l'espace de noms `opsworks` peut interférer avec les recettes intégrées. Pour de plus amples informations, veuillez consulter [Attributs de déploiement et de configuration de pile](workingcookbook-json.md).

Vous pouvez également utiliser le JSON personnalisé pour définir les attributs uniques, généralement pour transmettre des données à vos recettes personnalisées. Les attributs sont simplement intégrés à l'objet de nœud et les recettes peuvent les référence à l'aide de la syntaxe de nœud standard de Chef.

## Procédure pour spécifier le JSON personnalisé
<a name="workingcookbook-json-override-specify"></a>

Pour utiliser le JSON personnalisé afin de remplacer une valeur d'attribut, vous devez tout d'abord déterminer le nom qualifié de l'attribut. Vous créez ensuite un objet JSON qui contient les attributs que vous voulez remplacer, défini sur vos valeurs préférées. Pour plus de commodité, les documents [Attributs de déploiement et de configuration de pile : Linux](attributes-json-linux.md) et [Attributs des livres de recettes intégrés](attributes-recipes.md) utilisent généralement les attributs de configuration de la pile, de déploiement et de livres de recettes intégrés, avec leurs noms pleinement qualifiés.

Les relations parent-enfant de l'objet doivent correspondre aux nœuds pleinement qualifiés appropriés de Chef. Par exemple, supposons que vous souhaitiez modifier les attributs suivants d'Apache : 
+ L'attribut [`keepalivetimeout`](attributes-recipes-apache.md#attributes-recipes-apache-keep-timeout), dont le nœud est `node[:apache][:keepalivetimeout]` et a une valeur par défaut de `3`.
+ L'attribut `logrotate` [`schedule`](attributes-recipes-apache.md#attributes-recipes-apache-log-schedule), dont le nœud est `node[:apache][:logrotate][:schedule]` et a une valeur par défaut de `"daily"`.

Pour remplacer les attributs et définir les valeurs sur `5` et `"weekly"`, respectivement, vous devez utiliser le JSON personnalisé suivant :

```
{
  "apache" : {
    "keepalivetimeout" : 5,
    "logrotate" : {
       "schedule" : "weekly"
    }
  }
}
```

## Quand spécifier le JSON personnalisé
<a name="workingcookbook-json-override-when"></a>

Vous pouvez spécifier une structure de JSON personnalisé pour les tâches suivantes :
+ [Créer une pile](workingstacks-creating.md)
+ [Mettre à jour une pile](workingstacks-edit.md)
+ [Exécuter une commande de pile](workingstacks-edit.md)
+ [Cloner une pile](workingstacks-cloning.md)
+ [Déployer une application](workingapps-deploying.md)

Pour chaque tâche, OpsWorks Stacks fusionne les attributs JSON personnalisés avec les attributs de configuration et de déploiement de la pile et les envoie aux instances pour qu'elles soient fusionnées dans l'objet du nœud. Toutefois, notez les points suivants :
+ Si vous spécifiez le JSON personnalisé lorsque vous créez, clonez ou mettez à jour une pile, les attributs sont fusionnés avec les attributs de configuration et de déploiement de la pile pour tous les événements du cycle de vie et les commandes de pile qui suivront.
+ Si vous spécifiez un JSON personnalisé pour un déploiement, les attributs sont fusionnés dans les attributs de configuration et de déploiement de la pile uniquement pour l'événement correspondant.

  Si vous souhaitez utiliser ces attributs personnalisés pour les déploiements suivants, vous devez spécifier explicitement le JSON personnalisé à nouveau.

Il est important de se souvenir que les attributs affectent uniquement l'instance lorsqu'ils sont utilisés par des recettes. Si vous remplacez une valeur d'attribut, mais qu'aucune recette ultérieure ne fait référence à l'attribut, la modification n'a aucun effet. Vous devez soit vous assurer que le JSON personnalisé est envoyé avant l'exécution des recettes associées, soit veiller à ce que les recettes appropriées soient exécutées à nouveau. 

## Bonnes pratiques pour le JSON personnalisé
<a name="workingcookbook-json-override-best"></a>

Vous pouvez utiliser du JSON personnalisé pour remplacer n'importe quel attribut OpsWorks Stacks, mais la saisie manuelle des informations est quelque peu fastidieuse et ne fait l'objet d'aucun contrôle de source. Le JSON personnalisé est plus adapté pour les raisons suivantes :
+ Lorsque vous voulez remplacer uniquement un petit nombre d'attributs et vous n'avez pas besoin d'utiliser les livres personnalisés dans d'autres buts.

  Avec le JSON personnalisé, vous pouvez éviter la complexité de la configuration et de la gestion d'un référentiel de livres de recettes uniquement pour remplacer deux attributs.
+ Valeurs sensibles, telles que les mots de passe ou les clés d'authentification.

  Les attributs des livres de recettes sont stockés dans un référentiel, c'est pourquoi les informations sensibles risquent d'être compromises. C'est pourquoi il est préférable de définir les attributs avec des valeurs fictives et d'utiliser le JSON personnalisé pour définir les valeurs réelles.
+ Valeurs qui sont censées varier.

  Par exemple, une pratique recommandée consiste à avoir votre pile de production prise en charge par des piles de développement et intermédiaires distinctes. Supposons que ces piles prennent en charge une application qui accepte les paiements. Si vous utilisez le JSON personnalisé pour spécifier le point de terminaison du paiement, vous pouvez spécifier une URL de test pour votre pile intermédiaire. Lorsque vous êtes prêt à migrer une pile mise à jour vers votre pile de production, vous pouvez utiliser les mêmes livres de recettes et le JSON personnalisé pour définir le point de terminaison de paiement sur l'URL de production.
+ Les valeurs qui sont propres à une commande spécifique de pile ou de déploiement.

# Remplacer les attributs des OpsWorks piles à l'aide d'attributs de livre de recettes personnalisés
<a name="workingcookbook-cookbook-attributes"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

**Note**  
Pour les piles Windows, OpsWorks Stacks utilise des exécutions Chef distinctes pour les recettes intégrées et les recettes personnalisées. Cela signifie que vous ne pouvez pas utiliser les techniques décrites dans cette section pour remplacer les attributs intégrés pour les piles Windows.

Le JSON personnalisé est un moyen pratique de remplacer la configuration de la pile OpsWorks Stacks et les attributs intégrés du livre de recettes, mais il présente certaines limites. Vous devez plus particulièrement entrer le JSON personnalisé manuellement chaque utilisation, ce qui signifie que vous n'avez aucun moyen solide pour gérer les définitions. Une meilleure approche consiste souvent à utiliser des fichiers d'attributs de livres de recettes personnalisés pour remplacer les attributs intégrés. Cela vous permet de placer les définitions sous le contrôle de code source.

La procédure d'utilisation de fichiers d'attributs personnalisés pour remplacer les définitions de OpsWorks Stacks est simple.

**Pour remplacer les définitions d' OpsWorks attributs Stacks**

1. Définissez un référentiel de livres de recettes, comme décrit dans [Livres de recettes et recettes](workingcookbook.md).

1. Créez un livre de recettes avec le même nom que le livre de recettes intégré qui contient les attributs que vous voulez remplacer. Par exemple, pour remplacer les attributs Apache, le livre de recettes doit être nommé apache2. 

1. Ajoutez un dossier `attributes` au livre de recettes et ajoutez un fichier dans ce dossier nommé `customize.rb`. 

1. Ajoutez une définition d'attribut dans le fichier pour chacun des attributs du livre de recettes intégré que vous voulez remplacer, avec votre valeur préférée. L'attribut doit être de `normal` type ou supérieur et porter exactement le même nom de nœud que l'attribut OpsWorks Stacks correspondant. Pour une liste détaillée des attributs de OpsWorks Stacks, y compris les noms des nœuds, reportez-vous aux sections [Attributs de déploiement et de configuration de pile : Linux](attributes-json-linux.md) et[Attributs des livres de recettes intégrés](attributes-recipes.md). Pour plus d'informations sur les attributs et les fichiers d'attributs, consultez [À propos des fichiers d'attributs](http://docs.chef.io/attributes.html).
**Important**  
Vos attributs doivent être `normal` de type pour remplacer les attributs de OpsWorks Stacks ; les `default` types n'ont pas de priorité. Par exemple, si votre fichier `customize.rb` contient une définition d'attribut `default[:apache][:keepalivetimeout] = 5`, l'attribut correspondant du fichier d'attributs intégré `apache.rb` est évalué en premier et il est prioritaire. Pour de plus amples informations, veuillez consulter [Remplacement des attributs](workingcookbook-attributes.md).

1. Répétez les étapes 2 à 4 pour chaque livre de recettes intégré dont les attributs doivent être remplacés.

1. Activez des livres de recettes personnalisés pour votre pile et fournissez les informations requises pour que OpsWorks Stacks télécharge vos livres de recettes sur les instances de la pile. Pour de plus amples informations, veuillez consulter [Installation de livres de recettes personnalisés](workingcookbook-installingcustom-enable.md).

**Note**  
Pour une présentation complète de cette procédure, consultez [Remplacement des attributs intégrés](cookbooks-101-opsworks-attributes.md).

L'objet de nœud utilisé par les événements du cycle de vie, les commandes de déploiement et les commandes de pile ultérieurs contiendra désormais vos définitions d'attributs au lieu des valeurs OpsWorks Stacks. 

Par exemple, pour remplacer les paramètres intégrés `keepalivetimeout` et `logrotate schedule` dans [Procédure pour spécifier le JSON personnalisé](workingcookbook-json-override.md#workingcookbook-json-override-specify), ajoutez un livre de recettes `apache2`apache à votre référentiel et ajoutez un fichier `customize.rb` au dossier `attributes` du livre de recettes avec le contenu suivant.

```
normal[:apache][:keepalivetimeout] = 5
normal[:apache][:logrotate][:schedule] = 'weekly'
```

**Important**  
Vous ne devez pas remplacer les attributs OpsWorks Stacks en modifiant une copie du fichier d'attributs intégré associé. Si, par exemple, vous copiez `apache.rb` dans votre dossier `apache2/attributes` et que vous modifiez certains de ses paramètres, vous remplacez essentiellement tous les attributs du fichier intégré. Les recettes utiliseront les définitions d'attribut de votre copie et ignoreront le fichier intégré. Si OpsWorks Stacks modifie ultérieurement le fichier d'attributs intégré, les recettes n'auront pas accès aux changements, sauf si vous mettez à jour manuellement votre copie.   
Pour éviter cette situation, tous les livres de recettes intégrés comportent un fichier d'attributs `customize.rb` vide, qui est nécessaire dans tous les modules via une directive `include_attribute`. En remplaçant les attributs de votre copie du fichier `customize.rb`, vous affectez uniquement ces attributs. Les recettes obtiendront toutes les autres valeurs d'attribut des fichiers d'attributs intégrés et obtiendront automatiquement les valeurs actuelles de tous les attributs que vous n'aurez pas remplacés.  
Cette approche vous permet de limiter le nombre d'attributs dans votre référentiel de livres de recettes, ce qui réduit votre charge de maintenance et rend les mises à niveau futures plus faciles à gérer.

# Extension des fichiers de configuration de OpsWorks Stacks à l'aide de modèles personnalisés
<a name="workingcookbook-template-override"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

**Note**  
Comme OpsWorks Stacks gère les exécutions de Chef différemment pour les piles Windows et pour les piles Linux, vous ne pouvez pas utiliser les techniques décrites dans cette section pour les piles Windows.

OpsWorks Stacks utilise des modèles pour créer des fichiers tels que des fichiers de configuration, qui dépendent généralement des attributs de nombreux paramètres. Si vous utilisez du JSON personnalisé ou des attributs de livre de recettes personnalisés pour remplacer les définitions de OpsWorks Stacks, vos paramètres préférés sont incorporés dans les fichiers de configuration à la place des paramètres Stacks. OpsWorks Cependant, OpsWorks Stacks ne spécifie pas nécessairement un attribut pour chaque paramètre de configuration possible ; il accepte les valeurs par défaut de certains paramètres et en code dur d'autres directement dans le modèle. Vous ne pouvez pas utiliser du JSON personnalisé ou des attributs de livre de recettes personnalisés pour spécifier les paramètres préférés s'il n'existe aucun attribut OpsWorks Stacks correspondant.

Vous pouvez étendre le fichier de configuration de façon à inclure des paramètres de configuration supplémentaires en créant un modèle personnalisé. Vous pouvez ensuite ajouter des paramètres de configuration ou tout autre contenu dont vous avez besoin au fichier et remplacer les paramètres codés en dur. Pour plus d'informations sur les modèles, consultez [Modèles](workingcookbook-installingcustom-components-templates.md).

**Note**  
Vous pouvez remplacer n'importe quel modèle intégré, *sauf* opsworks-agent.monitrc.erb.

**Pour créer un modèle personnalisé**

1. Créez un livre de recettes avec les mêmes noms de structure et de répertoire que le livre de recettes intégré. Ensuite, créez un modèle de fichier dans le répertoire approprié avec le même nom que celui du modèle intégré que vous souhaitez personnaliser. Par exemple, pour utiliser un modèle personnalisé afin d'étendre le fichier de configuration `httpd.conf` Apache, vous devez implémenter un livre de recettes `apache2` dans votre référentiel et votre modèle de fichier doit être `apache2/templates/default/apache.conf.erb`. L'utilisation des mêmes noms permet à OpsWorks Stacks de reconnaître le modèle personnalisé et de l'utiliser à la place du modèle intégré.

   L'approche la plus simple consiste à simplement copier le fichier modèle intégré du [ GitHubréférentiel du livre de recettes intégré dans votre livre de](https://github.com/aws/opsworks-cookbooks) recettes et à le modifier selon vos besoins. 
**Important**  
Ne copiez aucun fichier du livre de recettes intégré à l'exception des fichiers de modèles que vous souhaitez personnaliser. Des copies d'autres types de fichiers de livres de recettes, par exemple des recettes, créent des ressources de Chef en double et peuvent entraîner des erreurs.

   Le livre de recettes peut également inclure des attributs personnalisés, des recettes et des fichiers associés, mais leurs noms de fichiers ne doivent pas dupliquer les noms de fichiers intégrés.

1. Personnalisez le modèle de fichier pour générer un fichier de configuration correspondant à vos besoins. Vous pouvez ajouter des paramètres, supprimer des paramètres existants, remplacer des attributs codés en dur, etc. 

1. Si vous ne l'avez pas déjà fait, modifiez les paramètres de la pile afin d'activer les livres de recettes personnalisés et de spécifier votre référentiel de livres de recettes. Pour de plus amples informations, veuillez consulter [Installation de livres de recettes personnalisés](workingcookbook-installingcustom-enable.md).

**Note**  
Pour une présentation complète de cette procédure, consultez [Remplacement des modèles intégrés](cookbooks-101-opsworks-templates.md).

Il n'est pas nécessaire d'implémenter des recettes ou d'[ajouter des recettes à la configuration des couches](workingcookbook-assigningcustom.md) pour remplacer un modèle. OpsWorks Stacks exécute toujours les recettes intégrées. Lorsqu'il exécute la recette qui crée le fichier de configuration, il utilise automatiquement votre modèle personnalisé au lieu du modèle intégré.

**Note**  
Si OpsWorks Stacks apporte des modifications au modèle intégré, votre modèle personnalisé risque de se désynchroniser et de ne plus fonctionner correctement. Supposons, par exemple, que votre modèle fasse référence à un fichier dépendant et que le nom du fichier change. OpsWorks Stacks n'apporte pas souvent de telles modifications, et lorsqu'un modèle change, il répertorie les modifications et vous donne la possibilité de passer à une nouvelle version. Vous devez surveiller les modifications apportées au référentiel OpsWorks Stacks et mettre à jour manuellement votre modèle si nécessaire.

# Extension d'une couche
<a name="workingcookbook-extend"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Parfois, vous avez besoin de personnaliser une couche intégrée au-delà de ce qui peut être géré en modifiant les attributs OpsWorks Stacks ou en personnalisant les modèles. Par exemple, supposons que vous ayez besoin de créer des liens symboliques, de définir des modes de fichier ou de dossier, d'installer des packages supplémentaires, etc. Vous devez étendre les couches personnalisées pour offrir plus que les fonctionnalités minimales. Dans ce cas, vous devrez mettre en place un ou plusieurs livres de recettes personnalisés, avec des recettes pour gérer les tâches de personnalisation. Cette rubrique fournit quelques exemples de la façon d'utiliser les recettes pour étendre une couche.

Si vous utilisez Chef pour la première fois, lisez [Les bases des livres de recettes](cookbooks-101.md) ; ce didacticiel présente les notions de base qui expliquent comment implémenter les livres de recettes et exécuter une grande variété de tâches courantes. Pour obtenir un exemple détaillé de la façon d'implémenter une couche personnalisée, consultez [Création d'une couche serveur Tomcat personnalisée](create-custom.md). 

**Topics**
+ [Utilisation de recettes pour exécuter des scripts](workingcookbook-extend-scripts.md)
+ [Utilisation des raccordements de déploiement Chef](workingcookbook-extend-hooks.md)
+ [Exécution de tâches cron sur les instances Linux](workingcookbook-extend-cron.md)
+ [Installation et configuration des packages sur les instances Linux](workingcookbook-extend-package.md)

# Utilisation de recettes pour exécuter des scripts
<a name="workingcookbook-extend-scripts"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Si vous avez déjà un script qui exécute les tâches de personnalisation nécessaires, l'approche la plus simple pour l'extension d'une couche consiste souvent à implémenter une recette simple pour exécuter le script. Vous pouvez ensuite assigner la recette à des événements de cycle de vie appropriés, généralement Setup ou Deploy, ou utiliser la commande de pile `execute_recipes` pour exécuter la recette manuellement.

L'exemple suivant exécute un script shell sur des instances Linux, mais vous pouvez utiliser la même approche pour d'autres types de scripts, y compris les PowerShell scripts Windows.

```
cookbook_file "/tmp/lib-installer.sh" do
  source "lib-installer.sh"
  mode 0755
end

execute "install my lib" do
  command "sh /tmp/lib-installer.sh"
end
```

La ressource `cookbook_file` représente un fichier qui est stocké dans un sous-répertoire du répertoire `files` d'un livre de recettes et transfère le fichier vers un emplacement spécifié sur l'instance. Cet exemple transfère un script shell, `lib-installer.sh`, vers le répertoire `/tmp` de l'instance et définit le mode du fichier sur `0755`. Pour plus d'informations, consultez [cookbook\$1file](https://docs.chef.io/chef/resources.html#cookbook-file).

La ressource `execute` représente une commande, telle qu'une commande shell. Cet exemple exécute `lib-installer.sh`. Pour plus d'informations, consultez [execute](https://docs.chef.io/chef/resources.html#execute).

Vous pouvez également exécuter un script en l'intégrant à une recette. L'exemple suivant exécute un script bash, mais Chef prend également en charge Csh, Perl, Python et Ruby.

```
script "install_something" do
  interpreter "bash"
  user "root"
  cwd "/tmp"
  code <<-EOH
    #insert bash script
  EOH
end
```

La ressource `script` représente un script. L'exemple spécifie un interpréteur bash, définit l'utilisateur sur `"root"`et le répertoire de travail sur `/tmp`. Ensuite, il exécute le script bash du bloc `code`, lequel peut inclure autant de lignes que requis. Pour plus d'informations, consultez [script](https://docs.chef.io/chef/resources.html#script).

Pour plus d'informations sur l'utilisation de recettes pour exécuter des scripts, consultez [Exemple 7 : Exécution des commandes et des scripts](cookbooks-101-basics-commands.md). Pour un exemple d'exécution d'un PowerShell script sur une instance Windows, consultez[Exécution d'un PowerShell script Windows](cookbooks-101-opsworks-opsworks-powershell.md).

# Utilisation des raccordements de déploiement Chef
<a name="workingcookbook-extend-hooks"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Vous pouvez personnaliser le déploiement en implémentant une recette personnalisée pour exécuter les tâches requises et en l'affectant à l'événement Deploy de la couche appropriée. Une approche alternative et parfois plus simple, en particulier si vous n'avez pas besoin d'implémenter un livre de recettes à d'autres fins, consiste à utiliser les hooks de déploiement Chef pour exécuter votre code de personnalisation. En outre, les recettes Deploy personnalisées s'exécutent une fois que le déploiement a déjà été réalisé par les recettes intégrées. Les raccordements de déploiement vous permettent d'interagir lors d'un déploiement : par exemple, une fois que le code de l'application a été extrait du référentiel, mais avant qu'Apache n'ait redémarré.

Chef déploie les applications en quatre étapes :
+ **Checkout** —Télécharge les fichiers depuis le référentiel
+ **Migrer** —Exécute une migration, selon les besoins
+ **Symlink —Crée des liens symboliques**
+ **Redémarrer** : redémarre l'application

Les raccordements de déploiement Chef offrent un moyen simple de personnaliser un déploiement en exécutant le cas échéant une application Ruby fournie par l'utilisateur, une fois chaque étape terminée. Pour utiliser les raccordements de déploiement, implémentez une ou plusieurs applications Ruby et placez-les dans le répertoire `/deploy`. (Si votre application n'a pas de répertoire `/deploy`, créez-en un au niveau `APP_ROOT`.) L'application doit avoir l'un des noms suivants, qui détermine quand elle s'exécute.
+ `before_migrate.rb` s'exécute une fois l'étape d'extraction terminée, mais avant la migration.
+ `before_symlink.rb` s'exécute une fois l'étape d'extraction terminée, mais avant les liens symboliques.
+ `before_restart.rb` s'exécute une fois l'étape des liens symboliques terminée, mais avant le redémarrage.
+ `after_restart.rb` s'exécute une fois le redémarrage terminé.

Les raccordements de déploiement Chef peuvent accéder à l'objet nœud en utilisant la syntaxe nœud standard, tout comme les recettes. Les raccordements de déploiement peuvent également accéder aux valeurs des [variables d'environnement d'application](workingapps-creating.md#workingapps-creating-environment) que vous avez spécifiées. Cependant, vous devez utiliser `new_resource.environment["VARIABLE_NAME"] ` pour accéder à valeur de la variable au lieu de `ENV["VARIABLE_NAME"]`.

# Exécution de tâches cron sur les instances Linux
<a name="workingcookbook-extend-cron"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Une tâche cron Linux demande au processus cron d'exécuter une ou plusieurs commandes selon un calendrier spécifié. Par exemple, supposons que votre pile prenne en charge une application de commerce en ligne PHP. Vous pouvez configurer une tâche cron pour que le serveur vous envoie un rapport des ventes à une heure définie chaque semaine. Pour plus d'informations sur cron, consultez [cron](http://en.wikipedia.org/wiki/Cron) sur Wikipedia. Pour plus d'informations sur la façon d'exécuter directement une tâche cron sur une instance ou un ordinateur Linux, consultez [Présentation et utilisation de cron et crontab](https://kb.iu.edu/d/afiz) sur le site de la base de connaissances de l'université d'Indiana.

Même si vous pouvez configurer manuellement des tâches `cron` sur les instances Linux en vous connectant à elles avec SSH et en modifiant leurs entrées `crontab`, un avantage essentiel d' OpsWorks Stacks est que vous pouvez lui ordonner d'exécuter la tâche sur une couche complète d'instances. La procédure suivante décrit comment configurer une `cron` tâche sur les instances d'une couche PHP App Server, mais vous pouvez utiliser la même approche avec n'importe quelle couche.

**Pour configurer une tâche `cron` sur les instances d'une couche**

1. Implémentez un livre de recettes avec une recette ayant une ressource `cron` qui configure la tâche. L'exemple suppose que la recette se nomme `cronjob.rb` ; les détails de l'implémentation sont décrits ultérieurement. Pour plus d'informations sur les livres de recettes et les recettes, consultez [Livres de recettes et recettes](workingcookbook.md).

1. Installez le livre de recettes sur votre pile. Pour de plus amples informations, veuillez consulter [Installation de livres de recettes personnalisés](workingcookbook-installingcustom-enable.md).

1. Demandez à OpsWorks Stacks d'exécuter automatiquement la recette sur les instances de la couche en l'affectant aux événements du cycle de vie suivants. Pour de plus amples informations, veuillez consulter [Exécution automatique des recettes](workingcookbook-assigningcustom.md).
   + **Configuration** : l'attribution `cronjob.rb` à cet événement indique à OpsWorks Stacks d'exécuter la recette sur toutes les nouvelles instances.
   + **Déployer** : l'attribution `cronjob.rb` à cet événement indique à OpsWorks Stacks d'exécuter la recette sur toutes les instances en ligne lorsque vous déployez ou redéployez une application sur la couche.

   Vous pouvez aussi exécuter manuellement la recette sur les instances en ligne en utilisant la commande de pile `Execute Recipes`. Pour de plus amples informations, veuillez consulter [Exécution des commandes de pile](workingstacks-commands.md).

L'exemple `cronjob.rb` suivant configure une tâche cron pour exécuter une fois par semaine une application PHP implémentée par l'utilisateur et qui collecte les données des ventes à partir du serveur et envoie un rapport. Pour plus d'exemples d'utilisation d'une ressource cron, consultez [cron](https://docs.chef.io/chef/resources.html#cron). 

```
cron "job_name" do
  hour "1"
  minute "10"
  weekday "6"
  command "cd /srv/www/myapp/current && php .lib/mailing.php"
end
```

`cron` est une ressource Chef qui représente une tâche `cron`. Lorsque OpsWorks Stacks exécute la recette sur une instance, le fournisseur associé gère les détails de configuration de la tâche.
+ `job_name` est un nom défini par l'utilisateur pour la tâche `cron`, tel que `weekly report`.
+ `hour`/`minute`/`weekday` spécifie à quel moment les commandes doivent être exécutées. Cet exemple exécute les commandes chaque samedi à 1 h 10.
+ `command` spécifie les commandes à exécuter.

  Cet exemple exécute deux commandes. La première accède au répertoire `/srv/www/myapp/current`. La seconde exécute l'application `mailing.php` implémentée par l'utilisateur et qui collecte les données des ventes et envoie le rapport.

**Note**  
La commande `bundle` ne fonctionne pas avec les tâches `cron` par défaut. La raison en est que OpsWorks Stacks installe le bundler dans le répertoire. `/usr/local/bin` Pour utiliser `bundle` avec une tâche `cron`, vous devez ajouter explicitement le chemin d'accès `/usr/local/bin` à la tâche cron. En outre, comme la variable d'environnement \$1PATH peut ne pas se développer dans la tâche `cron`, une bonne pratique consiste à ajouter explicitement à la tâche les informations de chemin d'accès nécessaires sans s'appuyer sur l'expansion de la variable \$1PATH. Les exemples suivants illustrent deux façons d'utiliser `bundle` dans une tâche `cron`.  

```
cron "my first task" do
  path "/usr/local/bin"
  minute "*/10"
  command "cd /srv/www/myapp/current && bundle exec my_command"
end
```

```
cron_env = {"PATH" => "/usr/local/bin"}
cron "my second task" do
  environment cron_env
  minute "*/10"
  command "cd /srv/www/myapp/current && /usr/local/bin/bundle exec my_command"
end
```

Si votre stack comporte plusieurs serveurs d'applications, l'attribution des `cronjob.rb` événements du cycle de vie de la couche PHP App Server n'est peut-être pas une approche idéale. Par exemple, comme la recette s'exécute sur toutes les instances de la couche, vous recevrez plusieurs rapports. Une meilleure approche consiste à utiliser une couche personnalisée pour s'assurer qu'un seul serveur envoie un rapport.

**Pour exécuter une recette sur une seule des instances d'une couche**

1. Créez une couche personnalisée appelée, par exemple, PHPAdmin et attribuez-la `cronjob.rb` à ses événements de configuration et de déploiement. Les couches personnalisées n'ont pas nécessairement à en faire beaucoup. Dans ce cas, PHPAdmin il suffit d'exécuter une recette personnalisée sur ses instances.

1. Attribuez l'une des instances de PHP App Server à AdminLayer. Si une instance appartient à plusieurs couches, OpsWorks Stacks exécute les recettes intégrées et personnalisées de chaque couche.

Comme une seule instance appartient au serveur d'applications PHP et aux PHPAdmin couches, elle ne `cronjob.rb` s'exécute que sur cette instance et vous ne recevez qu'un seul rapport.

# Installation et configuration des packages sur les instances Linux
<a name="workingcookbook-extend-package"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Les couches intégrées ne prennent en charge que certains packages. Pour de plus amples informations, veuillez consulter [Layers](workinglayers.md). Vous pouvez installer d'autres packages, tels qu'un serveur Redis, en implémentant des recettes personnalisées pour gérer les tâches d'installation, de configuration de déploiement associées. Dans certains cas, la meilleure approche consiste à étendre une couche intégrée afin que le package soit installé sur ses instances en même temps que les packages standard de la couche. Par exemple, si vous avez une pile qui prend en charge une application PHP et que vous souhaitez inclure un serveur Redis, vous pouvez étendre la couche PHP App Server pour installer et configurer un serveur Redis sur les instances de la couche en plus d'un serveur d'applications PHP.

Une recette d'installation de package doit généralement exécuter des tâches telles que celles-ci :
+ Créer un ou plusieurs répertoires et définir leurs modes.
+ Créer un fichier de configuration à partir d'un modèle.
+ Exécuter le programme d'installation pour installer le package sur l'instance.
+ Démarrer un ou plusieurs services.

Pour obtenir un exemple d'installation du serveur Tomcat, consultez [Création d'une couche serveur Tomcat personnalisée](create-custom.md). La rubrique explique comment configurer une couche Redis personnalisée, mais vous pouvez utiliser pratiquement le même code pour installer et configurer Redis sur une couche intégrée. Pour des exemples d'installation d'autres packages, consultez les livres de recettes intégrés, sur [https://github.com/aws/opsworks-cookbooks](https://github.com/aws/opsworks-cookbooks).

# Création d'une couche serveur Tomcat personnalisée
<a name="create-custom"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

**Note**  
Cette rubrique explique comment implémenter une couche personnalisée pour une pile Linux. Cependant, les principes de base et une partie du code peuvent aussi être adaptés afin d'implémenter des couches personnalisées pour les piles Windows, notamment dans la section relative au déploiement d'applications.

Le moyen le plus simple d'utiliser des packages non standard sur des instances OpsWorks Stacks consiste à [étendre une couche existante](workingcookbook-extend-package.md). Cependant, cette approche installe et exécute aussi bien les packages standard que les packages non standard sur les instances de la couche, ce qui n'est pas toujours souhaitable. Une approche plus exigeante, mais plus efficace, consiste à implémenter une couche personnalisée, laquelle vous offre un contrôle presque complet sur les instances de la couche, éléments suivants inclus : 
+ Packages installés
+ Configuration de chaque package
+ Déploiement des applications d'un référentiel sur l'instance

Que ce soit à l'aide de la console ou de l'API, vous créez et gérez une couche personnalisée tout comme une autre couche, comme décrit dans [Couches personnalisées](workinglayers-custom.md). Cependant, les recettes intégrées d'une couche personnalisée n'effectuent que quelques tâches très élémentaires, telles que l'installation d'un client Ganglia pour rapporter les métriques à un serveur maître Ganglia. Afin que les instances d'une couche personnalisée soient plus que fonctionnelles a minima, vous devez implémenter un ou plusieurs livres de recettes personnalisés avec les recettes Chef et les fichiers associés pour pouvoir gérer, entre autres, les tâches d'installation et de configuration de packages, ou de déploiement d'applications. Néanmoins, vous n'avez pas nécessairement à tout implémenter de A à Z. Par exemple, si vous stockez les applications dans l'un des référentiels standard, vous pouvez utiliser les recettes de déploiement intégrées pour gérer la plus grande partie du travail d'installation des applications sur les instances de la couche.

**Note**  
Si vous utilisez Chef pour la première fois, lisez [Les bases des livres de recettes](cookbooks-101.md) ; ce didacticiel présente les notions de base qui expliquent comment implémenter les livres de recettes et exécuter une grande variété de tâches courantes. 

La procédure suivante décrit comment mettre en œuvre une couche personnalisée qui prend en charge un serveur d'applications Tomcat. La couche s'appuie sur un livre personnalisé nommé Tomcat, qui contient les recettes permettant, entre autres, de gérer l'installation et le déploiement de packages. La procédure pas à pas inclut des extraits du livre de recettes Tomcat. Vous pouvez télécharger le livre de recettes complet depuis son [GitHub référentiel](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat). Si vous ne maîtrisez pas [Opscode Chef](http://www.opscode.com/chef/), lisez d'abord [Livres de recettes et recettes](workingcookbook.md).

**Note**  
OpsWorks Stacks inclut une [couche Java App Server complète pour une utilisation](layers-java.md) en production. Comme le livre de recettes Tomcat a pour objectif d'expliquer l'implémentation des couches personnalisées, il ne prend en charge qu'une version limitée de Tomcat, d'où sont absentes certaines fonctionnalités telles que SSL. Pour obtenir un exemple d'implémentation complète, consultez le livre de recettes [opsworks\$1java](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/opsworks_java).

Le livre de recettes Tomcat prend en charge une couche personnalisée dont les instances possèdent les caractéristiques suivantes :
+ Elles prennent en charge un serveur d'applications Java Tomcat avec un serveur frontal Apache.
+ Tomcat est configuré pour permettre aux applications d'utiliser un `DataSource` objet JDBC pour se connecter à une instance MySQL distincte, qui sert de magasin de données principal.

Le livre de recettes du projet comporte plusieurs composants clés :
+ Le [fichier d'attributs](create-custom-attributes.md) contient les paramètres de configuration utilisés par les différentes recettes.
+ Les [recettes Setup](create-custom-setup.md) sont affectées à l'[événement de cycle de vie](workingcookbook-events.md) Setup de la couche. Elles s'exécutent après le démarrage d'une instance et accomplissent différentes tâches telles que l'installation de packages et la création de fichiers de configuration.
+ Les [recettes Configure](create-custom-configure.md) sont affectées à l'événement de cycle de vie Configure de la couche. Ils s'exécutent après les modifications de configuration de la pile, principalement lorsque les instances sont mises en ligne ou hors ligne, et gèrent les modifications de configuration requises.
+ Les [recettes Deploy](create-custom-deploy.md) sont attribuées à l'événement de cycle de vie Deploy de la couche. Elles s'exécutent après les recettes Setup et lorsque vous déployez manuellement une application pour installer le code et les fichiers associés sur les instances de la couche et gérer les tâches connexes, telles que le redémarrage des services.

La dernière section décrit comment créer une pile qui inclut une couche personnalisée basée sur le livre de recettes Tomcat et comment déployer et exécuter une application JSP simple qui affiche les données d'une base de données MySQL exécutée sur une instance appartenant à une couche MySQL distincte. [Créer une pile et exécuter une application](create-custom-stack.md)

**Note**  
Les recettes du livre de recettes Tomcat dépendent de certaines recettes intégrées à OpsWorks Stacks. Pour que l'origine de chaque recette apparaisse clairement, la présente rubrique identifie les recettes selon la convention Chef *nom\$1du\$1livre\$1de\$1recettes*::*nom\$1de\$1recette*.

**Topics**
+ [Fichiers d'attributs](create-custom-attributes.md)
+ [Recettes Setup](create-custom-setup.md)
+ [Recettes Configure](create-custom-configure.md)
+ [Recettes Deploy](create-custom-deploy.md)
+ [Créer une pile et exécuter une application](create-custom-stack.md)

# Fichiers d'attributs
<a name="create-custom-attributes"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Avant de regarder les recettes, il est utile d'examiner le fichier d'attributs du livre de recettes Tomcat. Ce fichier contient différents paramètres de configuration utilisés par les recettes. Les attributs ne sont pas obligatoires ; vous pouvez simplement coder ces valeurs en dur dans vos recettes ou modèles. Toutefois, si vous définissez les paramètres de configuration à l'aide d'attributs, vous pouvez utiliser la console ou l'API OpsWorks Stacks pour modifier les valeurs en définissant des attributs JSON personnalisés, ce qui est plus simple et plus flexible que de réécrire le code de la recette ou du modèle chaque fois que vous souhaitez modifier un paramètre. Cette approche permet, par exemple, d'utiliser le même livre de recettes pour plusieurs piles, mais de configurer le serveur Tomcat différemment selon chaque pile. Pour de plus amples informations sur les attributs et leur remplacement, consultez [Remplacement des attributs](workingcookbook-attributes.md).

L'exemple suivant montre le fichier d'attributs complet, `default.rb`, qui se trouve dans le répertoire `attributes` du livre de recettes Tomcat.

```
default['tomcat']['base_version'] = 6
default['tomcat']['port'] = 8080
default['tomcat']['secure_port'] = 8443
default['tomcat']['ajp_port'] = 8009
default['tomcat']['shutdown_port'] = 8005
default['tomcat']['uri_encoding'] = 'UTF-8'
default['tomcat']['unpack_wars'] = true
default['tomcat']['auto_deploy'] = true
case node[:platform]
when 'centos', 'redhat', 'fedora', 'amazon'
  default['tomcat']['java_opts'] = ''
when 'debian', 'ubuntu'
  default['tomcat']['java_opts'] = '-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC'
end
default['tomcat']['catalina_base_dir'] = "/etc/tomcat#{node['tomcat']['base_version']}"
default['tomcat']['webapps_base_dir'] = "/var/lib/tomcat#{node['tomcat']['base_version']}/webapps"
default['tomcat']['lib_dir'] = "/usr/share/tomcat#{node['tomcat']['base_version']}/lib"
default['tomcat']['java_dir'] = '/usr/share/java'
default['tomcat']['mysql_connector_jar'] = 'mysql-connector-java.jar'
default['tomcat']['apache_tomcat_bind_mod'] = 'proxy_http' # or: 'proxy_ajp'
default['tomcat']['apache_tomcat_bind_config'] = 'tomcat_bind.conf'
default['tomcat']['apache_tomcat_bind_path'] = '/tc/'
default['tomcat']['webapps_dir_entries_to_delete'] = %w(config log public tmp)
case node[:platform]
when 'centos', 'redhat', 'fedora', 'amazon'
  default['tomcat']['user'] = 'tomcat'
  default['tomcat']['group'] = 'tomcat'
  default['tomcat']['system_env_dir'] = '/etc/sysconfig'
when 'debian', 'ubuntu'
  default['tomcat']['user'] = "tomcat#{node['tomcat']['base_version']}"
  default['tomcat']['group'] = "tomcat#{node['tomcat']['base_version']}"
  default['tomcat']['system_env_dir'] = '/etc/default'
end
```

Les paramètres eux-mêmes sont présentés ultérieurement dans la section associée. En règle générale, les remarques suivantes s'appliquent :
+ Comme toutes les définitions de nœud sont de type `default`, vous pouvez les remplacer par des [attributs JSON personnalisés](workingcookbook-json-override.md).
+ Le fichier utilise une instruction `case` pour définir de manière conditionnelle certaines valeurs d'attribut en fonction du système d'exploitation de l'instance.

  Le nœud `platform` est généré par Ohai, outil de Chef, et représente le système d'exploitation de l'instance. 

# Recettes Setup
<a name="create-custom-setup"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Les recettes Setup sont affectées à l'[événement de cycle de vie](workingcookbook-events.md) Setup de la couche et s'exécutent une fois qu'une instance a démarré. Elles exécutent des tâches telles que l'installation de packages, la création de fichiers de configuration et le démarrage de services. Une fois l'exécution des recettes d'installation terminée, OpsWorks Stacks exécute les [recettes de déploiement](create-custom-deploy.md) pour déployer toutes les applications sur la nouvelle instance.

**Topics**
+ [tomcat::setup](#create-custom-setup-setup)
+ [tomcat::install](#create-custom-setup-install)
+ [tomcat::service](#create-custom-setup-service)
+ [tomcat::container\$1config](#create-custom-setup-config)
+ [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind)

## tomcat::setup
<a name="create-custom-setup-setup"></a>

La recette `tomcat::setup` est destinée à être affectée à un événement du cycle de vie Setup de la couche.

```
include_recipe 'tomcat::install'
include_recipe 'tomcat::service'

service 'tomcat' do
  action :enable
end

# for EBS-backed instances we rely on autofs
bash '(re-)start autofs earlier' do
  user 'root'
  code <<-EOC
    service autofs restart
  EOC
  notifies :restart, resources(:service => 'tomcat')
end

include_recipe 'tomcat::container_config'
include_recipe 'apache2'
include_recipe 'tomcat::apache_tomcat_bind'
```

La recette `tomcat::setup` est en grande partie une méta-recette. Elle contient un ensemble de recettes dépendantes qui gèrent la plupart des détails de l'installation et de la configuration de Tomcat et des packages associés. La première partie de `tomcat::setup` exécute les recettes suivantes, présentées en détail ultérieurement : 
+ La recette [tomcat::install](#create-custom-setup-install) installe le package du serveur Tomcat.
+ La recette [tomcat::service](#create-custom-setup-service) configure le service Tomcat.

La partie centrale de `tomcat::setup` active et démarre le service Tomcat :
+ La [ressource service](https://docs.chef.io/chef/resources.html#service) de Chef active le service Tomcat au démarrage.
+ La [ressource Chef bash](https://docs.chef.io/chef/resources.html#bash) exécute un script Bash pour démarrer le démon autofs, qui est nécessaire pour les instances soutenues par Amazon EBS. La ressource demande ensuite à la ressource `service` de redémarrer le service Tomcat.

  Pour plus d'informations, consultez [autofs](https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-config-autofs.html) (pour Amazon Linux) ou [Autofs](https://help.ubuntu.com/community/Autofs) (pour Ubuntu).

La partie finale de `tomcat::setup` crée les fichiers de configuration, puis installe et configure le serveur frontal Apache :
+ La recette [tomcat::container\$1config](#create-custom-setup-config) crée les fichiers de configuration.
+ La `apache2` recette (qui est un raccourci pour`apache2::default`) est une recette intégrée à OpsWorks Stacks qui installe et configure un serveur Apache.
+ La recette [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind) configure le serveur Apache pour qu'il fonctionne comme serveur frontal pour le serveur Tomcat.

**Note**  
Vous pouvez souvent économiser du temps et des efforts en utilisant les recettes intégrées pour exécuter certaines tâches requises. Cette recette utilise la recette intégrée `apache2::default` pour installer Apache plutôt que de l'implémenter à partir de rien. Pour obtenir un autre exemple de l'utilisation des recettes intégrées, consultez [Recettes Deploy](create-custom-deploy.md).

Les sections suivantes décrivent plus en détail les recettes Setup du livre de recettes Tomcat. Pour plus d'informations sur les recettes `apache2`, consultez [opsworks-cookbooks/apache2](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/apache2).

## tomcat::install
<a name="create-custom-setup-install"></a>

La recette `tomcat::install ` installe le serveur Tomcat, OpenJDK et une bibliothèque de connecteurs Java qui gère la connexion au serveur MySQL.

```
tomcat_pkgs = value_for_platform(
  ['debian', 'ubuntu'] => {
    'default' => ["tomcat#{node['tomcat']['base_version']}", 'libtcnative-1', 'libmysql-java']
  },
  ['centos', 'redhat', 'fedora', 'amazon'] => {
    'default' => ["tomcat#{node['tomcat']['base_version']}", 'tomcat-native', 'mysql-connector-java']
  },
  'default' => ["tomcat#{node['tomcat']['base_version']}"]
)

tomcat_pkgs.each do |pkg|
  package pkg do
    action :install
  end
end

link ::File.join(node['tomcat']['lib_dir'], node['tomcat']['mysql_connector_jar']) do
  to ::File.join(node['tomcat']['java_dir'], node['tomcat']['mysql_connector_jar'])
  action :create
end

# remove the ROOT webapp, if it got installed by default
include_recipe 'tomcat::remove_root_webapp'
```

La recette exécute les tâches suivantes :

1. Crée une liste de packages à installer, en fonction du système d'exploitation de l'instance.

1. Installe chaque package de la liste.

   La [ressource du package](https://docs.chef.io/chef/resources.html#id146) Chef utilise le fournisseur approprié (`yum`pour Amazon Linux et `apt-get` pour Ubuntu) pour gérer l'installation. Les fournisseurs de package installent OpenJDK comme dépendance Tomcat, mais la bibliothèque de connecteurs MySQL doit être installée explicitement.

1. Utilise une [ressource link](https://docs.chef.io/chef/resources.html#link) de Chef pour créer un lien symbolique entre le répertoire lib du serveur Tomcat et la bibliothèque de connecteurs MySQL du JDK.

   Selon les valeurs d'attribut par défaut, le répertoire lib Tomcat est `/usr/share/tomcat6/lib` et la bibliothèque de connecteurs MySQL (`mysql-connector-java.jar`) se trouve dans `/usr/share/java/`.

La recette `tomcat::remove_root_webapp` supprime l'application web racine (`/var/lib/tomcat6/webapps/ROOT` par défaut) pour éviter certains problèmes de sécurité.

```
ruby_block 'remove the ROOT webapp' do
  block do
    ::FileUtils.rm_rf(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT'), :secure => true)
  end
  only_if { ::File.exists?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) && !::File.symlink?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) }
end
```

L'instruction `only_if` garantit que la recette ne supprime le fichier que s'il existe.

**Note**  
La version Tomcat est spécifiée par l'attribut `['tomcat']['base_version']`, défini sur 6 dans le fichier d'attributs. Pour installer Tomcat 7, vous pouvez utiliser des attributs JSON personnalisés pour remplacer l'attribut. [Modifiez simplement vos paramètres de pile](workingstacks-edit.md) et entrez le code JSON suivant dans la zone **Custom Chef JSON (JSON Chef personnalisé)**, ou ajoutez-le à un JSON personnalisé existant :  

```
{
  'tomcat' : {
    'base_version' : 7
  }
}
```
L'attribut JSON personnalisé remplace l'attribut par défaut et définit la version Tomcat sur 7. Pour plus d'informations sur le remplacement des attributs, consultez [Remplacement des attributs](workingcookbook-attributes.md).

## tomcat::service
<a name="create-custom-setup-service"></a>

La recette `tomcat::service` crée la définition du service Tomcat.

```
service 'tomcat' do
  service_name "tomcat#{node['tomcat']['base_version']}"

  case node[:platform]
  when 'centos', 'redhat', 'fedora', 'amazon'
    supports :restart => true, :reload => true, :status => true
  when 'debian', 'ubuntu'
    supports :restart => true, :reload => false, :status => true
  end

  action :nothing
end
```

La recette utilise la [ressource service](https://docs.chef.io/chef/resources.html#service) de Chef pour spécifier le nom de service Tomcat (tomcat6, par défaut) et définit l'attribut `supports` pour définir la façon dont Chef gère le redémarrage du service, le rechargement et les commandes d'état sur les différents systèmes d'exploitation.
+ `true` indique que Chef peut utiliser le script init ou un autre fournisseur de services pour exécuter la commande.
+ `false` indique que le Chef doit tenter d'exécuter la commande par d'autres moyens.

Notez que l'élément `action` est défini sur `:nothing`. Pour chaque événement du cycle de vie, OpsWorks Stacks lance une exécution [Chef pour exécuter](https://docs.chef.io/chef_client_overview.html#the-chef-client-run) l'ensemble de recettes approprié. Le livre de recettes Tomcat suit un modèle commun, selon lequel une recette crée la définition de service, mais ne redémarre pas le service. D'autres recettes de l'exécution Chef gèrent le redémarrage, généralement en incluant une commande `notifies` dans les ressources `template` utilisées pour créer les fichiers de configuration. Les notifications sont un moyen pratique de redémarrer un service, car elle ne le font que si la configuration a changé. En outre, si une exécution Chef comporte plusieurs notifications de redémarrage pour un service, Chef redémarre le service au plus une fois. Cette pratique évite les problèmes susceptibles de se produire lorsque vous tentez de redémarrer un service qui n'est pas pleinement opérationnel, ce qui est une source commune d'erreurs Tomcat.

 Le service Tomcat doit être défini pour toute exécution Chef qui utilise les notifications de redémarrage. `tomcat::service` est par conséquent inclus dans plusieurs recettes afin de garantir que le service soit défini pour chaque exécution Chef. Aucune pénalité ne s'applique si une exécution Chef inclut plusieurs instances de `tomcat::service`, car Chef garantit qu'une recette ne s'exécute qu'une seule fois par exécution Chef, quel que soit le nombre de fois où elle est incluse.

## tomcat::container\$1config
<a name="create-custom-setup-config"></a>

La recette `tomcat::container_config` crée les fichiers de configuration à partir des fichiers modèles du livre de recettes.

```
include_recipe 'tomcat::service'

template 'tomcat environment configuration' do
  path ::File.join(node['tomcat']['system_env_dir'], "tomcat#{node['tomcat']['base_version']}")
  source 'tomcat_env_config.erb'
  owner 'root'
  group 'root'
  mode 0644
  backup false
  notifies :restart, resources(:service => 'tomcat')
end

template 'tomcat server configuration' do
  path ::File.join(node['tomcat']['catalina_base_dir'], 'server.xml')
  source 'server.xml.erb'
  owner 'root'
  group 'root'
  mode 0644
  backup false
  notifies :restart, resources(:service => 'tomcat')
end
```

La première recette appelle `tomcat::service`, qui définit le service si nécessaire. Le bloc principal de la recette se compose de deux [ressources template](https://docs.chef.io/chef/resources.html#template), chacune d'elles créant un fichier de configuration à partir de l'un des fichiers modèles du livre de recettes, définissant les propriétés du fichier et informant Chef de redémarrer le service.

### Fichier de configuration de l'environnement Tomcat
<a name="create-custom-setup-config-env"></a>

La première ressource `template` utilise le fichier modèle `tomcat_env_config.erb` pour créer un fichier de configuration de l'environnement Tomcat, qui permet de définir les variables d'environnement telles que `JAVA_HOME`. Le nom de fichier par défaut est l'argument de la ressource `template`. `tomcat::container_config` utilise un attribut `path` pour remplacer la valeur par défaut et nommer le fichier de configuration `/etc/sysconfig/tomcat6` (Amazon Linux) ou `/etc/default/tomcat6` (Ubuntu). La ressource `template` spécifie également le propriétaire du fichier, le groupe et le mode, et demande à Chef de ne pas créer de fichiers de sauvegarde.

Si vous regardez le code source, il existe de fait trois versions de `tomcat_env_config.erb`, chacune dans un sous-répertoire différent du répertoire `templates`. Les répertoires `ubuntu` et `amazon` contiennent les modèles de leurs systèmes d'exploitation respectifs. Le dossier `default` contient un modèle vide avec une seule ligne de commentaire, qui n'est utilisée que si vous tentez d'exécuter cette recette sur une instance dont le système d'exploitation n'est pas pris en charge. La recette `tomcat::container_config` n'a pas besoin de spécifier le modèle `tomcat_env_config.erb` à utiliser. Chef sélectionne automatiquement le répertoire approprié pour le système d'exploitation de l'instance en fonction des règles décrites dans [File Specificity](http://docs.chef.io/templates.html#file-specificity).

Les fichiers `tomcat_env_config.erb` de cet exemple se composent essentiellement de commentaires. Pour définir des variables d'environnement supplémentaires, supprimez les marques de commentaire des lignes appropriées et fournissez vos valeurs préférées.

**Note**  
Tout paramètre de configuration susceptible de changer doit être défini comme attribut plutôt que codé en dur dans le modèle. De cette façon, vous n'avez pas à réécrire le modèle pour modifier un paramètre et il vous suffit de remplacer l'attribut.

Le modèle Amazon Linux définit une seule variable d'environnement, comme illustré dans l'extrait suivant.

```
...
# Use JAVA_OPTS to set java.library.path for libtcnative.so
#JAVA_OPTS="-Djava.library.path=/usr/lib"

JAVA_OPTS="${JAVA_OPTS} <%= node['tomcat']['java_opts'] %>"

# What user should run tomcat
#TOMCAT_USER="tomcat"
...
```

JAVA\$1OPTS permet de spécifier des options Java telles que le chemin d'accès de la bibliothèque. A l'aide des valeurs d'attribut par défaut, le modèle ne définit aucune option Java pour Amazon Linux. Vous pouvez définir vos propres options Java en remplaçant l'attribut `['tomcat']['java_opts']`, à l'aide, par exemple, des attributs JSON personnalisés. Pour obtenir un exemple, consultez [Créez une pile](create-custom-stack.md#create-custom-stack-stack).

Le modèle Ubuntu définit plusieurs variables d'environnement, comme illustré dans l'extrait de modèle suivant.

```
# Run Tomcat as this user ID. Not setting this or leaving it blank will use the
# default of tomcat<%= node['tomcat']['base_version'] %>.
TOMCAT<%= node['tomcat']['base_version'] %>_USER=tomcat<%= node['tomcat']['base_version'] %>
...
# Run Tomcat as this group ID. Not setting this or leaving it blank will use
# the default of tomcat<%= node['tomcat']['base_version'] %>.
TOMCAT<%= node['tomcat']['base_version'] %>_GROUP=tomcat<%= node['tomcat']['base_version'] %>
...
JAVA_OPTS="<%= node['tomcat']['java_opts'] %>"

<% if node['tomcat']['base_version'].to_i < 7 -%>
# Unset LC_ALL to prevent user environment executing the init script from
# influencing servlet behavior.  See Debian bug #645221
unset LC_ALL
<% end -%>
```

A l'aide des valeurs d'attribut par défaut, le modèle définit les variables d'environnement Ubuntu comme suit :
+ `TOMCAT6_USER` et `TOMCAT6_GROUP`, qui représentent le groupe et l'utilisateur Tomcat, sont tous deux définis sur `tomcat6`.

  Si vous définissez ['tomcat']['base\$1version'] sur `tomcat7`, les noms des variables sont résolus en `TOMCAT7_USER` et `TOMCAT7_GROUP`, et les deux sont définis sur `tomcat7`.
+ `JAVA_OPTS` a la valeur `-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC` :
  + L'attribution à `-Djava.awt.headless` de la valeur `true` informe le moteur graphique que l'instance est sans périphérique de contrôle et sans console, ce qui prend en compte le comportement défaillant de certaines applications graphiques.
  + `-Xmx128m` garantit que la machine virtuelle Java dispose des ressources mémoire adéquates (128 Mo, dans cet exemple).
  + `-XX:+UseConcMarkSweepGC` spécifie le nettoyage de la mémoire « mark and sweep » simultané, ce qui aide à limiter les interruptions induites par le nettoyage de la mémoire.

    Pour plus d'informations, consultez : [Concurrent Mark Sweep Collector Enhancements](http://docs.oracle.com/javase/6/docs/technotes/guides/vm/cms-6.html).
+ Si la version Tomcat est inférieure à la version 7, le modèle annule la définition de `LC_ALL`, ce qui résout un bogue Ubuntu.

**Note**  
Avec les attributs par défaut, certaines variables d'environnement sont simplement définies sur leurs valeurs par défaut. Cependant, la définition explicite des variables d'environnement avec les attributs signifie que vous pouvez définir des attributs JSON personnalisés pour remplacer les attributs par défaut et fournir des valeurs personnalisées. Pour plus d'informations sur le remplacement des attributs, consultez [Remplacement des attributs](workingcookbook-attributes.md).

Pour les fichiers modèles complets, consultez le [code source](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat).

### Fichier de configuration Server.xml
<a name="create-custom-setup-config-server"></a>

La deuxième `template` ressource est utilisée `server.xml.erb` pour créer le [fichier `system.xml` de configuration](http://tomcat.apache.org/tomcat-7.0-doc/config/), qui configure le servlet/JSP conteneur. `server.xml.erb`ne contient aucun paramètre spécifique au système d'exploitation, il se trouve donc dans le `template` sous-répertoire du `default` répertoire.

Le modèle utilise les paramètres standard, mais peut créer un fichier `system.xml` pour Tomcat 6 ou Tomcat 7. Par exemple, le code suivant de la section serveur du modèle configure les écouteurs de façon appropriée pour la version spécifiée.

```
<% if node['tomcat']['base_version'].to_i > 6 -%>
  <!-- Security listener. Documentation at /docs/config/listeners.html
  <Listener className="org.apache.catalina.security.SecurityListener" />
  -->
<% end -%>
  <!--APR library loader. Documentation at /docs/apr.html -->
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
  <Listener className="org.apache.catalina.core.JasperListener" />
  <!-- Prevent memory leaks due to use of particular java/javax APIs-->
  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<% if node['tomcat']['base_version'].to_i < 7 -%>
  <!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html -->
  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
<% end -%>
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<% if node['tomcat']['base_version'].to_i > 6 -%>
  <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<% end -%>
```

Comme le modèle utilise des attributs à la place de paramètres codés en dur, vous pouvez facilement modifier les paramètres en définissant des attributs JSON personnalisés. Par exemple :

```
<Connector port="<%= node['tomcat']['port'] %>" protocol="HTTP/1.1"
           connectionTimeout="20000"
           URIEncoding="<%= node['tomcat']['uri_encoding'] %>"
           redirectPort="<%= node['tomcat']['secure_port'] %>" />
```

Pour plus d'informations, consultez le [code source](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat).

## tomcat::apache\$1tomcat\$1bind
<a name="create-custom-setup-bind"></a>

La recette `tomcat::apache_tomcat_bind` permet au serveur Apache de faire office de serveur frontal de Tomcat : il reçoit les demandes entrantes, les transmet à Tomcat et retourne les réponses au client. Cet exemple utilise [mod\$1proxy](https://httpd.apache.org/docs/2.2/mod/mod_proxy.html) comme proxy/passerelle Apache.

```
execute 'enable mod_proxy for apache-tomcat binding' do
  command '/usr/sbin/a2enmod proxy'
  not_if do
    ::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', 'proxy.load')) || node['tomcat']['apache_tomcat_bind_mod'] !~ /\Aproxy/
  end
end

execute 'enable module for apache-tomcat binding' do
  command "/usr/sbin/a2enmod #{node['tomcat']['apache_tomcat_bind_mod']}"
  not_if {::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', "#{node['tomcat']['apache_tomcat_bind_mod']}.load"))}
end

include_recipe 'apache2::service'

template 'tomcat thru apache binding' do
  path ::File.join(node['apache']['dir'], 'conf.d', node['tomcat']['apache_tomcat_bind_config'])
  source 'apache_tomcat_bind.conf.erb'
  owner 'root'
  group 'root'
  mode 0644
  backup false
  notifies :restart, resources(:service => 'apache2')
end
```

Pour activer `mod_proxy`, vous devez activer le module `proxy` et un module basé sur le protocole. Vous avez deux options pour le module de protocole : 
+ HTTP: `proxy_http`
+ [ JServ Protocole Apache](http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html) (AJP) : `proxy_ajp`

  AJP est un protocole Tomcat interne.

Les deux [ressources execute](https://docs.chef.io/chef/resources.html#execute) de la recette exécutent la commande `a2enmod`, qui active le module spécifié en créant les liens symboliques requis :
+ La première ressource `execute` exécute le module `proxy`.
+ La seconde ressource `execute` active le module de protocole, défini sur `proxy_http` par défaut.

  Si vous préférez utiliser AJP, vous pouvez définir un JSON personnalisé pour remplacer l'attribut `apache_tomcat_bind_mod` et le définir sur `proxy_ajp`. 

La `apache2::service` recette est une recette intégrée à OpsWorks Stacks qui définit le service Apache. Pour plus d'informations, consultez la [recette](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/apache2/recipes/service.rb) dans le GitHub référentiel OpsWorks Stacks. 

La ressource `template` utilise `apache_tomcat_bind.conf.erb` pour créer un fichier de configuration, nommé `tomcat_bind.conf` par défaut. Elle place le fichier dans le répertoire `['apache']['dir']/.conf.d`. L'attribut `['apache']['dir']` est défini dans le fichier d'attributs `apache2` intégré et est défini par défaut sur `/etc/httpd` (Amazon Linux) ou `/etc/apache2` (Ubuntu). Si la ressource `template` crée ou modifie le fichier de configuration, la commande `notifies` planifie un redémarrage du service Apache.

```
<% if node['tomcat']['apache_tomcat_bind_mod'] == 'proxy_ajp' -%>
ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/
ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/
<% else %>
ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/
ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/
<% end -%>
```

Le modèle utilise les [ProxyPassReverse](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypassreverse)directives [ProxyPass](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypass)et pour configurer le port utilisé pour transmettre le trafic entre Apache et Tomcat. Comme les deux serveurs sont sur la même instance, ils peuvent utiliser une URL localhost et sont tous deux définis par défaut sur `http://localhost:8080`.

# Recettes Configure
<a name="create-custom-configure"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Les recettes Configure sont affectées à l'[événement de cycle de vie](workingcookbook-events.md) Configure de la recette, qui se produit sur toutes les instances de la pile chaque fois qu'une instance entre ou quitte l'état « en ligne » (online). Vous utilisez les recettes Configure pour ajuster la configuration d'une instance afin de répondre à la modification, le cas échéant. Lorsque vous implémentez une recette Configure, gardez à l'esprit qu'une modification de configuration de la pile peut impliquer des instances qui n'ont rien à voir avec la couche. La recette doit être capable de répondre de manière appropriée, ce qui peut signifier de ne rien faire dans certains cas.

## tomcat::configure
<a name="create-custom-configure-configure"></a>

La recette `tomcat::configure` est destinée à l'événement de cycle de vie Configure d'une couche.

```
include_recipe 'tomcat::context'
# Optional: Trigger a Tomcat restart in case of a configure event, if relevant
# settings in custom JSON have changed (e.g. java_opts/JAVA_OPTS):
#include_recipe 'tomcat::container_config'
```

La recette `tomcat::configure` est en gros une méta-recette qui exécute deux recettes dépendantes.

1. La recette `tomcat::context` crée un fichier de configuration du contexte de l'application web.

   Ce fichier configure les ressources JDBC que les applications utilisent pour communiquer avec l'instance MySQL, comme indiqué dans la section suivante. L'exécution de cette recette en réponse à un événement Configure permet à la couche de mettre à jour le fichier de configuration du contexte de l'application web si la couche base de données a été modifiée.

1. La recette Setup `tomcat::container_config` est exécutée à nouveau pour capturer les modifications de la configuration du conteneur.

Le code `include` pour `tomcat::container_config` est mis en commentaire dans cet exemple. Si vous souhaitez utiliser un JSON personnalisé pour modifier les paramètres Tomcat, vous pouvez supprimer le commentaire. Un événement du cycle de vie Configure exécute alors `tomcat::container_config`, qui met à jour les fichiers de configuration Tomcat associés, comme décrit dans [tomcat::container\$1config](create-custom-setup.md#create-custom-setup-config) et redémarre le service Tomcat.

## tomcat::context
<a name="create-custom-configure-context"></a>

Le livre de recettes Tomcat permet aux applications d'accéder à un serveur de base de données MySQL, qui peut être exécuté sur une instance distincte, à l'aide d'un objet [ DataSourceJ2EE](http://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html). Avec Tomcat, vous pouvez activer la connexion en créant et en installant un fichier de configuration du contexte de l'application web pour chaque application. Ce fichier définit la relation entre l'application et la ressource JDBC que l'application utilise pour communiquer avec la base de données. Pour plus d'informations, consultez [The Context Container](http://tomcat.apache.org/tomcat-7.0-doc/config/context.html).

La recette `tomcat::context` a pour objectif principal de créer ce fichier de configuration.

```
include_recipe 'tomcat::service'

node[:deploy].each do |application, deploy|
  context_name = deploy[:document_root].blank? ? application : deploy[:document_root]

  template "context file for #{application} (context name: #{context_name})" do
    path ::File.join(node['tomcat']['catalina_base_dir'], 'Catalina', 'localhost', "#{context_name}.xml")
    source 'webapp_context.xml.erb'
    owner node['tomcat']['user']
    group node['tomcat']['group']
    mode 0640
    backup false
    only_if { node['datasources'][context_name] }
    variables(:resource_name => node['datasources'][context_name], :webapp_name => application)
    notifies :restart, resources(:service => 'tomcat')
  end
end
```

Outre les attributs du livre de recettes Tomcat, cette recette utilise les attributs de [configuration et de déploiement de la pile](workingcookbook-json.md) installés par OpsWorks Stacks avec l'événement Configure. Le service OpsWorks Stacks ajoute des attributs à l'objet nœud de chaque instance qui contiennent les informations que les recettes obtiendraient généralement en utilisant des sacs de données ou en effectuant une recherche, et installe les attributs sur chaque instance. Les attributs contiennent des informations détaillées sur la configuration de la pile, les applications déployées et les données personnalisées qu'un utilisateur souhaite inclure. Les recettes peuvent obtenir les données à partir des attributs de configuration et de déploiement de pile en utilisant la syntaxe de nœud Chef standard. Pour de plus amples informations, veuillez consulter [Attributs de déploiement et de configuration de pile](workingcookbook-json.md). Avec les piles Chef 11.10, vous pouvez également utiliser la recherche Chef pour obtenir les données de configuration et de déploiement de pile. Pour de plus amples informations, veuillez consulter [Utilisation de Chef Search](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search).

`deploy`attributes fait référence à l'`[:deploy]`espace de noms, qui contient les attributs liés au déploiement définis via la console ou l'API, ou générés par le OpsWorks service Stacks. L'attribut `deploy` inclut un attribut pour chaque application déployée, nommé d'après le nom court de l'application. Chaque attribut d'application contient un ensemble d'attributs qui caractérisent l'application, tels que la racine du document (`[:deploy][:appname][:document_root]`).

La recette `context` s'assure d'abord que le service est défini pour l'exécution Chef en appelant [tomcat::service](create-custom-setup.md#create-custom-setup-service). Elle définit ensuite une variable `context_name` qui représente le nom du fichier de la configuration, à l'exception de l'extension `.xml`. Si vous utilisez la racine du document par défaut, `context_name` est défini comme nom court de l'application. Sinon, il est défini sur la racine du document spécifié. Comme l'exemple présenté dans [Créer une pile et exécuter une application](create-custom-stack.md) définit la racine du document sur `"ROOT"`, le contexte est ROOT et le fichier de configuration est nommé `ROOT.xml`.

La majeure partie de la recette parcourt la liste des applications déployées et, pour chaque application, utilise le modèle `webapp_context.xml.erb` pour créer un fichier de configuration du contexte. L'exemple ne déploie qu'une seule application, mais la définition de l'attribut `deploy` requiert que vous la traitiez comme une liste d'applications quelles qu'elles soient.

Comme le modèle `webapp_context.xml.erb` n'est pas spécifique au système d'exploitation, il se trouve dans le sous-répertoire `templates` du répertoire `default`.

La recette crée le fichier de configuration comme suit :
+ A l'aide des valeurs d'attribut par défaut, le fichier de configuration est défini sur `context_name.xml` et installé dans le répertoire `/etc/tomcat6/Catalina/localhost/`. 

  Le nœud `['datasources']` des attributs de configuration de la pile contient un ou plusieurs attributs, chacun d'eux mappant un nom de contexte et la ressource de données JDBC que l'application associée utilise pour communiquer avec la base de données. Le nœud et son contenu sont définis avec un JSON personnalisé lorsque vous créez la pile, comme décrit ultérieurement dans [Créer une pile et exécuter une application](create-custom-stack.md). L'exemple possède un attribut unique qui associe le nom de contexte ROOT à une ressource JDBC nommée jdbc/mydb.
+ A l'aide des valeurs d'attribut par défaut, l'utilisateur du fichier et le groupe sont tous deux définis avec les valeurs définies par le package Tomcat : `tomcat` (Amazon Linux) ou `tomcat6` (Ubuntu).
+ La ressource `template` ne crée le fichier de configuration que si le nœud `['datasources']`existe et inclut un attribut `context_name`.
+ La ressource définit `template` deux variables, `resource_name` et `webapp_name`.

  `resource_name`est défini avec le nom de ressource associé à `context_name` et `webapp_name` est défini avec le nom court de l'application.
+ La ressource modèle redémarre le service Tomcat pour charger et activer les modifications.

Le modèle `webapp_context.xml.erb` se compose d'un élément `Context` qui contient un élément `Resource` avec son propre ensemble d'attributs.

Les `Resource` attributs caractérisent la configuration du contexte :
+ **name — Le nom** de la ressource JDBC, défini sur la `resource_name` valeur définie dans. `tomcat::context`

  Pour l'exemple, le nom de ressource est jdbc/mydb.
+ **auth** et **type** : il s'agit des paramètres standard pour les connexions `DataSource` JDBC.
+ **MaxActive**, **MaxIdle** et **MaxWait** : nombre maximal de connexions actives et inactives, et temps d'attente maximal pour qu'une connexion soit renvoyée.
+ **nom d'utilisateur** et **mot de passe** : nom d'utilisateur et mot de passe root de la base de données, obtenus à partir des `deploy` attributs.
+ **driverClassName**—Le nom de classe du pilote JDBC, défini sur le pilote MySQL.
+ **url —URL** de connexion.

  Le préfixe dépend de la base de données. Il doit être défini sur `jdbc:mysql` pour MySQL, `jdbc:postgresql` pour Postgres et `jdbc:sqlserver` pour SQL Server. L'exemple définit l'URL sur`jdbc:mysql://host_IP_Address:3306:simplejsp`, où *simplejsp* est le nom abrégé de l'application.
+ **`DataSource`factory** : la fabrique requise pour les bases de données MySQL.

Pour plus d'informations sur ce fichier de configuration, consultez la DataSources rubrique [Utilisation](http://wiki.apache.org/tomcat/UsingDataSources) du wiki Tomcat.

# Recettes Deploy
<a name="create-custom-deploy"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Les recettes Deploy sont attribuées à l'[événement de cycle de vie](workingcookbook-events.md) Deploy de la couche. Cela se produit généralement sur toutes les instances de la pile chaque fois que vous déployez une application, bien que vous puissiez éventuellement limiter l'événement aux instances spécifiées uniquement. OpsWorks Stacks exécute également les recettes de déploiement sur les nouvelles instances, une fois les recettes de configuration terminées. Les recettes Deploy ont pour objectif principal de déployer le code et les fichiers associés d'un référentiel sur les instances de la couche serveur de l'application. Cependant, vous exécutez souvent les recettes sur d'autres couches également. Cela permet aux instances des couches de mettre à jour leur configuration, par exemple, pour accueillir l'application nouvellement déployée. Lorsque vous implémentez une recette Deploy, gardez à l'esprit qu'un événement Deploy ne signifie pas nécessairement que les applications sont déployées sur l'instance. Il peut s'agir d'une simple notification que les applications sont déployées sur d'autres instances de la pile pour permettre à l'instance effectuer les mises à jour nécessaires. La recette doit être capable de répondre de manière appropriée, ce qui implique de ne rien faire.

OpsWorks Stacks déploie automatiquement les applications des types d'applications standard sur les couches de serveur d'applications intégrées correspondantes. Pour déployer les applications sur une couche personnalisée, vous devez implémenter les recettes Deploy personnalisées qui téléchargent les fichiers de l'application depuis un référentiel sur l'emplacement approprié de l'instance. Cependant, vous pouvez souvent limiter la quantité de code que vous devez écrire à l'aide du [livre de recettes Deploy](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/deploy) intégré pour gérer certains aspects de déploiement. Par exemple, si vous stockez vos fichiers dans l'un des référentiels pris en charge, le livre de recettes intégré peut gérer les détails du téléchargement des fichiers depuis le référentiel sur les instances de la couche. 

La recette `tomcat::deploy` est destinée à être assignée à l'événement de cycle de vie Deploy.

```
include_recipe 'deploy'

node[:deploy].each do |application, deploy|
  opsworks_deploy_dir do
    user deploy[:user]
    group deploy[:group]
    path deploy[:deploy_to]
  end

  opsworks_deploy do
    deploy_data deploy
    app application
  end
...
```

La recette `tomcat::deploy` utilise le livre de recettes Deploy intégré pour les aspects du déploiement qui ne sont pas spécifiques à l'application. La recette `deploy` (qui est un raccourci de la recette `deploy::default` intégrée) est une recette intégrée qui gère les détails de la configuration des utilisateurs, groupes, etc., selon les données des attributs `deploy`.

La recette utilise deux définitions Chef intégrées, `opsworks_deploy_dir` et `opworks_deploy` pour installer l'application. 

La définition `opsworks_deploy_dir` configure la structure du répertoire, à partir des données du déploiement JSON de l'application. Les définitions sont essentiellement un moyen pratique d'empaqueter les définitions des ressources et se trouvent dans le répertoire `definitions` d'un livre de recettes. Les recettes peuvent utiliser les définitions tout comme les ressources, mais la définition elle-même n'a pas de fournisseur associé, seules les ressources qui sont incluses dans la définition. Vous pouvez définir les variables dans la recette, qui sont transmises aux définitions de ressources sous-jacentes. La recette `tomcat::deploy` définit les variables `user`, `group` et `path` en fonction des données du déploiement JSON. Elles sont transmises à la [ressource directory](https://docs.chef.io/chef/resources.html#directory) de la définition, qui gère les répertoires. 

**Note**  
Le groupe et l'utilisateur de votre application déployée sont déterminés par les attributs `[:opsworks][:deploy_user][:user]` et `[:opsworks][:deploy_user][:group]`, qui sont définis dans le [fichier d'attributs `deploy.rb` du livre de recettes Deploy intégré](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/deploy/attributes/deploy.rb). La valeur par défaut de `[:opsworks][:deploy_user][:user]` est `deploy`. La valeur par défaut de `[:opsworks][:deploy_user][:group]` dépend du système d'exploitation de l'instance :  
Pour les instances Ubuntu, le groupe par défaut est `www-data`.
Pour les instances Amazon Linux membres d'une couche Rails App Server utilisant Nginx et Unicorn, le groupe par défaut est. `nginx`
Pour toutes les autres instances Amazon Linux, le groupe par défaut est `apache`.
Vous pouvez changer les deux paramètres à l'aide d'un JSON personnalisé ou d'un fichier d'attributs personnalisés pour remplacer l'attribut approprié. Pour de plus amples informations, veuillez consulter [Remplacement des attributs](workingcookbook-attributes.md).

L'autre définition, `opsworks_deploy`, gère les détails de la vérification du code de l'application et des fichiers associés du référentiel et de leur déploiement sur l'instance, selon les données des attributs `deploy`. Vous pouvez utiliser cette définition pour tout type d'application ; les détails du déploiement tels que les noms de répertoire sont spécifiés dans la console ou via l'API, et placés dans les attributs `deploy`. Toutefois, `opsworks_deploy` fonctionne uniquement pour les quatre [types de référentiel pris en charge](workingcookbook-installingcustom-repo.md) : Git, Subversion, S3 et HTTP. Vous devez implémenter ce code vous-même si vous souhaitez utiliser un autre type de référentiel.

Vous installez les fichiers d'une application dans le répertoire Tomcat `webapps`. Une pratique classique consiste à copier les fichiers directement sur `webapps`. Cependant, le déploiement de OpsWorks Stacks est conçu pour conserver jusqu'à cinq versions d'une application sur une instance. Vous pouvez donc revenir à une version antérieure si nécessaire. OpsWorks Stacks effectue donc ce qui suit :

1. Déploie les applications sur un répertoire distinct dont le nom contient un horodatage, comme `/srv/www/my_1st_jsp/releases/20130731141527`.

1. Crée un lien symbolique nommé `current`, tel que `/srv/www/my_1st_jsp/current`, avec ce répertoire unique.

1. S'il n'existe pas déjà, crée un lien symbolique depuis le répertoire `webapps` vers le lien symbolique `current` créé à l'étape 2.

Si vous devez revenir à une version antérieure, modifiez le lien symbolique `current` pour pointer sur un répertoire distinct contenant l'horodatage approprié en changeant, par exemple, la cible du lien de `/srv/www/my_1st_jsp/current`.

La section centrale de `tomcat::deploy` définit le lien symbolique. 

```
  ...
  current_dir = ::File.join(deploy[:deploy_to], 'current')
  webapp_dir = ::File.join(node['tomcat']['webapps_base_dir'], deploy[:document_root].blank? ? application : deploy[:document_root])

  # opsworks_deploy creates some stub dirs, which are not needed for typical webapps
  ruby_block "remove unnecessary directory entries in #{current_dir}" do
    block do
      node['tomcat']['webapps_dir_entries_to_delete'].each do |dir_entry|
        ::FileUtils.rm_rf(::File.join(current_dir, dir_entry), :secure => true)
      end
    end
  end

  link webapp_dir do
    to current_dir
    action :create
  end
  ...
```

La recette crée d'abord deux variables, `current_dir` et `webapp_dir`, pour représenter les répertoires `current` et `webapp`, respectivement. Elle utilise ensuite une ressource `link` pour lier `webapp_dir` à `current_dir`. La `deploy::default` recette OpsWorks Stacks crée des répertoires stub qui ne sont pas obligatoires dans cet exemple, de sorte que la partie centrale de l'extrait les supprime.

La partie finale de `tomcat::deploy` redémarre le service Tomcat, si nécessaire.

```
  ...
  include_recipe 'tomcat::service'

  execute 'trigger tomcat service restart' do
    command '/bin/true'
    not_if { node['tomcat']['auto_deploy'].to_s == 'true' }
    notifies :restart, resources(:service => 'tomcat')
  end
end

include_recipe 'tomcat::context'
```

La recette exécute d'abord `tomcat::service`, afin de s'assurer que le service est défini pour cette exécution Chef. Elle utilise ensuite une [ressource execute](https://docs.chef.io/chef/resources.html#execute) pour demander au service de redémarrer, mais seulement si `['tomcat']['auto_deploy']` est défini sur `'true'`. Sinon, Tomcat écoute les modifications dans son répertoire `webapps`, ce qui rend superflu le redémarrage explicite du service Tomcat. 

**Note**  
La ressource `execute` n'exécute pas réellement quelque chose de substantiel ; `/bin/true` est un script shell factice qui retourne simplement un code de réussite. Il est utilisé ici simplement comme moyen pratique de générer une notification de redémarrage. Comme mentionné précédemment, l'utilisation des notifications garantit que les services ne soient pas trop souvent redémarrés.

Enfin, `tomcat::deploy` exécute `tomcat::context`, qui met à jour le fichier de configuration du contexte de l'application web si vous avez modifié la base de données principale. 

# Créer une pile et exécuter une application
<a name="create-custom-stack"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Cette section montre comment utiliser le livre de recettes Tomcat pour mettre en place une configuration de pile élémentaire qui exécute une simple application de pages serveur Java (JSP), nommée SimpleJSP. La pile se compose d'une couche personnalisée basée sur Tomcat nommée TomCustom et d'une couche MySQL. SimpleJSP est déployé sur la base de données MySQL TomCustom et affiche certaines informations à partir de celle-ci. Si vous n'êtes pas déjà familiarisé avec les bases de l'utilisation de OpsWorks Stacks, vous devez d'abord lire[Mise en route des piles Linux Chef 11](gettingstarted.md).

## Application SimpleJSP
<a name="create-custom-stack-jsp"></a>

L'application SimpleJSP illustre les bases de la configuration d'une connexion de base de données et de l'extraction des données à partir de la base de données MySQL de la pile.

```
<html>
  <head>
    <title>DB Access</title>
  </head>
  <body>
    <%@ page language="java" import="java.sql.*,javax.naming.*,javax.sql.*" %>
    <%
      StringBuffer output = new StringBuffer();
      DataSource ds = null;
      Connection con = null;
      Statement stmt = null;
      ResultSet rs = null;
      try {
        Context initCtx = new InitialContext();
        ds = (DataSource) initCtx.lookup("java:comp/env/jdbc/mydb");
        con = ds.getConnection();
        output.append("Databases found:<br>");
        stmt = con.createStatement();
        rs = stmt.executeQuery("show databases");
        while (rs.next()) {
          output.append(rs.getString(1));
          output.append("<br>");
        }
      }
      catch (Exception e) {
        output.append("Exception: ");
        output.append(e.getMessage());
        output.append("<br>");
      }
      finally {
        try {
          if (rs != null) {
            rs.close();
          }
          if (stmt != null) {
            stmt.close();
          }
          if (con != null) {
            con.close();
          }
        }
        catch (Exception e) {
          output.append("Exception (during close of connection): ");
          output.append(e.getMessage());
          output.append("<br>");
        }
      }
    %>
    <%= output.toString() %>
  </body>
</html>
```

SimpleJSP utilise un objet `DataSource` pour communiquer avec la base de données MySQL. Tomcat utilise les données du [fichier de configuration du contexte de l'application web](create-custom-configure.md#create-custom-configure-context) pour créer et initialiser un objet `DataSource` et le lier à un nom logique. Elle enregistre ensuite le nom logique avec un service d'attribution de noms JNDI (Java Naming et Directory Interface). Pour obtenir une instance de l'objet `DataSource` approprié, vous créez un objet `InitialContext` et passez le nom logique de la ressource à la méthode `lookup` de l'objet, qui récupère l'objet approprié. Le nom logique de l'exemple SimpleJSP, `java:comp/env/jdbc/mydb`, possède les éléments suivants :
+ L'espace de noms racine, `java`, qui est séparé du reste du nom par le signe deux points (:). 
+ Les espaces de noms supplémentaires, séparés par des barres obliques (/).

  Tomcat ajoute automatiquement les ressources à l'espace de noms `comp/env`.
+ Le nom de ressource, défini dans le fichier de configuration du contexte de l'application web et séparé des espaces de noms par une barre oblique.

  Le nom de la ressource pour cet exemple est `jdbc/mydb`. 

Pour établir une connexion à la base de données, SimpleJSP effectue les opérations suivantes :

1. Appelle la méthode `DataSource` de l'objet `getConnection`, qui retourne un objet `Connection`.

1. Appelle la méthode `Connection` de l'objet `createStatement` pour créer un objet `Statement`, qui vous permet de communiquer avec la base de données.

1. Communique avec la base de données en appelant la méthode `Statement` appropriée.

   SimpleJSP appelle `executeQuery` pour exécuter une requête SHOW DATABASES, qui répertorie les bases de données du serveur.

La méthode `executeQuery` retourne un objet `ResultSet`, qui contient les résultats de la requête. SimpleJSP obtient les noms de base de données à partir de l'objet `ResultSet` retourné et les concatène pour créer une chaîne de sortie. Enfin, l'exemple ferme les objets `ResultSet`, `Statement` et `Connection`. Pour plus d'informations sur JSP et JDBC, consultez [JavaServer Pages Technology](http://docs.oracle.com/javaee/5/tutorial/doc/bnagx.html) et [JDBC](http://docs.oracle.com/javase/tutorial/jdbc/basics/) Basics, respectivement.

Pour utiliser SimpleJSP avec une pile, vous devez la placer dans un référentiel. Vous pouvez utiliser l'un des référentiels pris en charge, mais pour utiliser SimpleJSP avec l'exemple de pile présenté dans la section suivante, vous devez la placer dans une archive S3 publique. Pour plus d'informations sur l'utilisation des autres référentiels standard, consultez [Référentiels de livres de recettes](workingcookbook-installingcustom-repo.md).

**Pour placer SimpleJSP dans un référentiel d'archivage S3**

1. Copiez l'exemple de code dans un fichier nommé `simplejsp.jsp` et placez le fichier dans un répertoire nommé `simplejsp`.

1. Créez une archive `.zip` du répertoire `simplejsp`.

1. Créez un compartiment Amazon S3 public, `simplejsp.zip` chargez-le dans le compartiment et rendez le fichier public.

   Pour obtenir une description de l'exécution de cette tâche, consultez [Mise en route avec Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html).

## Créez une pile
<a name="create-custom-stack-stack"></a>

Pour exécuter SimpleJSP, vous avez besoin d'une pile avec les couches suivantes.
+ Une couche MySQL, qui prend en charge le serveur principal MySQL.
+ Une couche personnalisée qui utilise le livre de recettes Tomcat pour prendre en charge les instances serveur Tomcat.

**Pour créer la pile**

1. Sur le tableau de bord OpsWorks Stacks, cliquez sur **Ajouter une pile** pour créer une nouvelle pile, puis sur **Avancé >>** pour afficher toutes les options. Configurez la pile comme suit.
   + **Nom** : nom de pile défini par l'utilisateur ; cet exemple utilise TomStack.
   + **Utiliser des livres de recettes Chef personnalisés** : réglez le bouton sur **Oui** pour afficher des options supplémentaires.
   + **Type de dépôt** —Git.
   + **URL du référentiel** —`git://github.com/amazonwebservices/opsworks-example-cookbooks.git`.
   + **Custom Chef JSON** —Ajoutez le JSON suivant :

     ```
     {
       "tomcat": {
         "base_version": 7,
         "java_opts": "-Djava.awt.headless=true -Xmx256m"
       },
       "datasources": {
         "ROOT": "jdbc/mydb"
       }
     }
     ```

   Pour le reste des options, vous pouvez accepter les valeurs par défaut.

   Le JSON personnalisé exécute les tâches suivantes :
   + Remplace l'attribut `['base_version']` du livre de recettes Tomcat pour définir la version Tomcat sur 7 ; la valeur par défaut est 6.
   + Remplace l'attribut `['java_opts']` du livre de recettes Tomcat pour spécifier que l'instance est sans périphérique de contrôle et définir la taille maximale de segment de machine virtuelle Java sur 256 Mo ; la valeur par défaut ne définit aucune option pour les instances exécutant Amazon Linux.
   + Spécifie la valeur d'attribut `['datasources]`, qui attribue un nom de ressource JDBC (jdbc/mydb) au nom du contexte de l'application web (ROOT), comme indiqué dans [tomcat::context](create-custom-configure.md#create-custom-configure-context).

     Ce dernier attribut n'a aucune valeur par défaut ; vous devez la définir avec le JSON personnalisé.  
![\[Configuration Management interface showing Chef version options and custom JSON input field.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/tom_add_stack.png)

1. Cliquez sur **Add a layer (Ajouter une couche)**. Pour **Layer type (Type de couche)**, sélectionnez **MySQL**. Puis, cliquez sur **Add Layer (Ajouter une couche)**.

1. Dans le panneau de navigation, cliquez sur **Instances**, puis cliquez sur **Add an instance (Ajouter une instance)**. Cliquez sur **Add Instance (Ajouter une instance)** pour accepter les valeurs par défaut. Sur la ligne de l'instance, cliquez sur **start (démarrer)**.

1. Revenez à la page **Layers (Couches)** et cliquez sur **\$1 Layer (\$1 Couche)** pour ajouter une couche. Pour **Layer type (Type de couche)**, cliquez sur **Custom (Personnalisé)**. L'exemple utilise **TomCustom** et **tomcustom** comme nom de couche et nom court, respectivement.  
![\[Add Layer form with Custom layer type, Name, and Short name fields for creating a customized layer.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/tom_add_custom_layer.png)

1. Sur la page **Layers (Couches)**, pour la couche personnalisée, cliquez sur **Recipes (Recettes)**, puis cliquez sur **Edit (Modifier)**. Sous **Custom Chef Recipes (Recettes Chef personnalisées)**, affectez les recettes du livre de recettes Tomcat aux événements de cycle de vie de la couche, comme suit :
   + Pour **Setup**, tapez **tomcat::setup** et cliquez sur **\$1**.
   + Pour **Configure**, tapez **tomcat::configure** et cliquez sur **\$1**.
   + Pour **Deploy**, tapez **tomcat::deploy** et cliquez sur **\$1**. Puis, cliquez sur **Save (Enregistrer)**.

     .  
![\[Custom Chef Recipes interface showing setup, configure, and deploy steps with options.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/tom_events.png)

1. Dans le panneau de navigation, cliquez sur **Apps (Applications)**, puis cliquez sur **Add an app (Ajouter une application)**. Spécifiez les options suivantes, puis cliquez sur **Add App (Ajouter une application)** :
   + **Nom** : nom de l'application ; l'exemple utilise SimpleJSP et le nom abrégé généré par OpsWorks Stacks sera simplejsp.
   + **Type d'application** : définissez cette option sur **Autre**.

     OpsWorks Stacks déploie automatiquement les types d'applications standard sur les instances de serveur associées. Si vous définissez **App type (Type d'application)** avec la valeur Other, OpsWorks Stacks exécute simplement les recettes Deploy et leur laisse gérer le déploiement.
   + **Racine du document** —Définissez cette option sur. **ROOT**

     La valeur **Document root (Racine du document)** spécifie le nom du contexte.
   + **Type de référentiel** : définissez cette option sur **S3 Archive**.
   + **URL du référentiel** : définissez cette URL sur l'URL Amazon S3 de l'application que vous avez créée précédemment.

   Utilisez les paramètres par défaut pour les autres options.  
![\[Application settings form with fields for name, app type, document root, and source details.\]](http://docs.aws.amazon.com/fr_fr/opsworks/latest/userguide/images/tom_app.png)

1. Utilisez la page **Instances** pour ajouter une instance à la TomCustom couche et la démarrer. OpsWorks Stacks exécute automatiquement les recettes de déploiement sur une nouvelle instance une fois les recettes d'installation terminées. Le démarrage de l'instance déploie donc également SimpleJSP.

1. Lorsque l' TomCustom instance est en ligne, cliquez sur le nom de l'instance sur la page **Instances** pour voir ses détails. Copiez l'adresse IP publique. Créez ensuite une URL comme suit : http ://*publicIP**appname.jsp*/tc/. Pour l'exemple, cette URL doit se présenter ainsi : **http://50.218.191.172/tc/simplejsp.jsp**.
**Note**  
L'URL Apache qui achemine les requêtes vers Tomcat est définie avec l'attribut `['tomcat']['apache_tomcat_bind_path']` par défaut, `/tc/`. La racine du document SimpleJSP est définie sur `ROOT`, une valeur spéciale qui se résout en `/`. Par conséquent, l'URL est « .../tc/simplejsp.jsp ».

1. Collez l'URL de l'étape précédente dans votre navigateur. Vous devez voir ce qui suit :

   ```
   Databases found:
   information_schema
   simplejsp
   test
   ```
**Note**  
Si votre stack possède une instance MySQL, OpsWorks Stacks crée automatiquement une base de données pour chaque application, nommée avec le nom abrégé de l'application.

# Attributs de déploiement et de configuration de pile
<a name="workingcookbook-json"></a>

**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](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium.

Lorsque OpsWorks Stacks exécute une commande sur une instance, par exemple une commande de déploiement en réponse à un événement du cycle de vie de déploiement, il ajoute un ensemble d'attributs à l'objet nœud de l'instance qui décrit la configuration actuelle de la pile. Pour les [commandes Deploy events et Execute Recipes stack](workingstacks-commands.md), OpsWorks Stacks installe les attributs de déploiement, qui fournissent des informations de déploiement supplémentaires. Pour plus d'informations sur l'objet nœud, consultez [Remplacement des attributs](workingcookbook-attributes.md). Pour obtenir la liste des attributs de déploiement et de configuration de pile couramment utilisés, y compris les noms de nœud complets, consultez [Attributs de déploiement et de configuration de pile : Linux](attributes-json-linux.md) et [Attributs des livres de recettes intégrés](attributes-recipes.md).

**Note**  
Sur les piles Linux, vous pouvez obtenir une liste complète de ces attributs, mis en forme comme un objet JSON, à l'aide de la [commande get\$1json](agent-json.md) de l'interface de ligne de commande de l'agent. 

Les sections suivantes décrivent les attributs associés à un événement Configure et à un événement Deploy d'une pile simple, qui comprend les éléments suivants :
+ Une couche PHP App Server avec deux instances
+ Une HAProxy couche avec une instance

Les exemples proviennent de l'une des instances de PHP App Server, **php-app1**. Pour plus de commodité, les attributs sont mis en forme comme un objet JSON. La structure de l'objet est mappé avec les noms complets des attributs. Par exemple, l'attribut `node[:opsworks][:ruby_version]` apparaît comme suit dans une représentation JSON.

```
{
  "opsworks": {
    ...
    "ruby_version": "1.8.7",
    ...
  }
}
```

**Topics**
+ [Attributs Configure](#workingcookbook-json-configure)
+ [Attributs de déploiement](#workingcookbook-json-deploy)

## Attributs Configure
<a name="workingcookbook-json-configure"></a>

L'objet JSON suivant illustre les attributs d'un événement Configure, qui se produit sur chaque instance de la pile lorsqu'une instance est mise en ligne ou hors connexion. Les attributs incluent les attributs intégrés de configuration de pile intégrée et les [attributs JSON personnalisés](workingstacks-json.md) qui ont été définis pour la pile avant l'événement (aucun dans cet exemple). Il a été modifié quant à la longueur. Pour une description détaillée des différents attributs, consultez [Attributs de déploiement et de configuration de pile : Linux](attributes-json-linux.md) et [Attributs des livres de recettes intégrés](attributes-recipes.md).

```
{
  "opsworks": {
    "layers": {
      "php-app": {
        "id": "4a2a56c8-f909-4b39-81f8-556536d20648",
        "instances": {
          "php-app2": {
            "elastic_ip": null,
            "region": "us-west-2",
            "booted_at": "2013-02-26T20:41:10+00:00",
            "ip": "192.0.2.0",
            "aws_instance_id": "i-34037f06",
            "availability_zone": "us-west-2a",
            "instance_type": "c1.medium",
            "private_dns_name": "ip-10-252-0-203.us-west-2.compute.internal",
            "private_ip": "10.252.0.203",
            "created_at": "2013-02-26T20:39:39+00:00",
            "status": "online",
            "backends": 8,
            "public_dns_name": "ec2-192-0-2-0.us-west-2.compute.amazonaws.com"
          },
          "php-app1": {
            ...
          }
        },
        "name": "PHP Application Server"
      },
      "lb": {
        "id": "15c86142-d836-4191-860f-f4d310440f14",
        "instances": {
          "lb1": {
           ...
          }
        },
        "name": "Load Balancer"
      }
    },
    "agent_version": "104",
    "applications": [

    ],
    "stack": {
      "name": "MyStack"
    },
    "ruby_version": "1.8.7",
    "sent_at": 1361911623,
    "ruby_stack": "ruby_enterprise",
    "instance": {
      "layers": [
        "php-app"
      ],
      "region": "us-west-2",
      "ip": "192.0.2.0",
      "id": "45ef378d-b87c-42be-a1b9-b67c48edafd4",
      "aws_instance_id": "i-32037f00",
      "availability_zone": "us-west-2a",
      "private_dns_name": "ip-10-252-84-253.us-west-2.compute.internal",
      "instance_type": "c1.medium",
      "hostname": "php-app1",
      "private_ip": "10.252.84.253",
      "backends": 8,
      "architecture": "i386",
      "public_dns_name": "ec2-192-0-2-0.us-west-2.compute.amazonaws.com"
    },
    "activity": "configure",
    "rails_stack": {
      "name": null
    },
    "deployment": null,
    "valid_client_activities": [
      "reboot",
      "stop",
      "setup",
      "configure",
      "update_dependencies",
      "install_dependencies",
      "update_custom_cookbooks",
      "execute_recipes"
    ]
  },
  "opsworks_custom_cookbooks": {
    "recipes": [

    ],
    "enabled": false
  },
  "recipes": [
    "opsworks_custom_cookbooks::load",
    "opsworks_ganglia::configure-client",
    "ssh_users",
    "agent_version",
    "mod_php5_apache2::php",
    "php::configure",
    "opsworks_stack_state_sync",
    "opsworks_custom_cookbooks::execute",
    "test_suite",
    "opsworks_cleanup"
  ],
  "opsworks_rubygems": {
    "version": "1.8.24"
  },
  "ssh_users": {
  },
  "opsworks_bundler": {
    "manage_package": null,
    "version": "1.0.10"
  },
  "deploy": {
  }
}
```

La plupart des informations se trouvent sous l'attribut `opsworks`, qui est souvent désigné par l'appellation espace de noms. La liste suivante décrit les attributs clés :
+ `layers`attributs : ensemble d'attributs, dont chacun décrit la configuration de l'une des couches de la pile.

  Les couches sont identifiées par leurs noms courts, `php-app` et `lb` dans cet exemple. Pour plus d'informations sur les noms courts des autres couches, consultez [OpsWorks Référence de la couche Stacks](layers.md). 
+ `instances`attributs — Chaque couche possède un `instances` élément, qui inclut un attribut pour chacune des instances en ligne des couches, nommé avec le nom abrégé de l'instance.

  La couche PHP App Server possède deux instances, `php-app1` et`php-app2`. La HAProxy couche possède une instance,`lb1`. 
**Note**  
L'élément `instances` contient uniquement les instances qui sont dans l'état en ligne lorsque les attributs de configuration et de déploiement de pile sont créés.
+ Attributs d'instance : chaque attribut d'instance contient un ensemble d'attributs qui caractérisent l'instance, tels que l'adresse IP privée et le nom DNS privé de l'instance. Pour des raisons de brièveté, l'exemple ne montre que l'attribut `php-app2` en détail ; les autres attributs contiennent des informations similaires.
+ `applications`— Liste des applications déployées, non utilisées dans cet exemple.
+ `stack`— Le nom de la pile ; `MyStack` dans cet exemple.
+ `instance`— L'instance sur laquelle ces attributs sont installés ; `php-app1` dans cet exemple. Les recettes peuvent utiliser cet attribut pour obtenir des informations sur l'instance sur laquelle elles s'exécutent, telles que l'adresse IP publique de l'instance.
+ `activity`— L'activité qui a produit les attributs ; un événement de configuration dans cet exemple.
+ `rails_stack`— La pile Rails pour les piles qui incluent une couche Rails App Server.
+ `deployment`— Si ces attributs sont associés à un déploiement. Défini sur `null` pour cet exemple, car ils sont associés à un événement Configure.
+ `valid_client_activities`— Une liste des activités valides des clients.

L'attribut `opsworks` est suivi de plusieurs autres attributs de niveau supérieur, y compris les attributs suivants :
+ `opsworks_custom_cookbooks`— Si les livres de recettes personnalisés sont activés. Si tel est le cas, l'attribut inclut une liste de recettes personnalisées.
+ `recipes`— Les recettes élaborées dans le cadre de cette activité.
+ `opsworks_rubygems`— RubyGems Version de l'instance.
+ `ssh_users`— Une liste d'utilisateurs SSH ; aucun dans cet exemple.
+ `opsworks_bundler`— La version du bundler et son activation.
+ `deploy`— Informations sur les activités de déploiement ; aucune dans cet exemple.

## Attributs de déploiement
<a name="workingcookbook-json-deploy"></a>

Les attributs d'un événement Deploy ou d'une [commande de pile Execute Recipes](workingstacks-commands.md) se composent des attributs intégrés de configuration et de déploiement de pile, et des attributs personnalisés de pile ou de déploiement (aucun pour cet exemple). L'objet JSON suivant montre les attributs de **php-app1** qui sont associés à un événement Deploy ayant déployé l'application SimplePHP sur les instances PHP de la pile. Une grande partie de l'objet se compose d'attributs de configuration de pile, similaires à ceux de l'événement Configure décrit dans la section précédente ; par conséquent, l'exemple se concentre principalement sur les attributs spécifiques au déploiement. Pour une description détaillée des différents attributs, consultez [Attributs de déploiement et de configuration de pile : Linux](attributes-json-linux.md) et [Attributs des livres de recettes intégrés](attributes-recipes.md).

```
{
   ...
  "opsworks": {
    ...
    "activity": "deploy",
    "applications": [
      {
        "slug_name": "simplephp",
        "name": "SimplePHP",
        "application_type": "php"
      }
    ],
    "deployment": "5e6242d7-8111-40ee-bddb-00de064ab18f",
    ...
  },
  ...
{
  "ssh_users": {
  },
  "deploy": {
    "simplephpapp": {
      "application": "simplephpapp",
      "application_type": "php",
      "environment_variables": {
        "USER_ID": "168424",
        "USER_KEY": "somepassword"
      },
      "auto_bundle_on_deploy": true,
      "deploy_to": "/srv/www/simplephpapp",
      "deploying_user": "arn:aws:iam::123456789012:user/guysm",
      "document_root": null,
      "domains": [
        "simplephpapp"
      ],
      "migrate": false,
      "mounted_at": null,
      "rails_env": null,
      "restart_command": "echo 'restarting app'",
      "sleep_before_restart": 0,
      "ssl_support": false,
      "ssl_certificate": null,
      "ssl_certificate_key": null,
      "ssl_certificate_ca": null,
      "scm": {
        "scm_type": "git",
        "repository": "git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git",
        "revision": "version1",
        "ssh_key": null,
        "user": null,
        "password": null
      },
      "symlink_before_migrate": {
        "config/opsworks.php": "opsworks.php"
      },
      "symlinks": {
      },
      "database": {
      },
      "memcached": {
        "host": null,
        "port": 11211
      },
      "stack": {
        "needs_reload": false
      }
    }
  },
}
```

L'attribut `opsworks` est largement identique à l'exemple de la section précédente. Les sections suivantes sont plus pertinentes pour le déploiement :
+ `activity`— L'événement associé à ces attributs ; un événement Deploy dans cet exemple.
+ `applications`— Contient un ensemble d'attributs pour chaque application qui fournissent les noms, les noms des slugs et les types des applications.

  Le nom du slug est le nom abrégé de l'application, que OpsWorks Stacks génère à partir du nom de l'application. Le nom slug de SimplePHP est simplephp.
+ `deployment`— L'ID de déploiement, qui identifie de manière unique un déploiement.

L'attribut `deploy` inclut des informations sur les applications qui sont déployées. Par exemple, les recettes intégrées Deploy utilisent les données de l'attribut `deploy` pour installer les fichiers dans les répertoires appropriés et créer les fichiers de connexion de base de données. L'attribut `deploy` inclut un attribut pour chaque application déployée, nommé d'après le nom court de l'application. Chaque attribut d'application contient les attributs suivants :
+ `environment_variables`— Contient toutes les variables d'environnement que vous avez définies pour l'application. Pour de plus amples informations, veuillez consulter [Variables d’environnement](workingapps-creating.md#workingapps-creating-environment).
+ `domains`— Par défaut, le domaine est le nom abrégé de l'application, qui est simplephpapp dans cet exemple. Si vous avez attribué des domaines personnalisés, ils apparaissent ici aussi bien. Pour de plus amples informations, veuillez consulter [Utilisation des domaines personnalisés](workingapps-domains.md).
+ `application`— Le nom abrégé de l'application.
+ `scm`— Cet élément contient les informations requises pour télécharger les fichiers de l'application depuis son dépôt, un dépôt Git dans cet exemple.
+ `database`— Informations de base de données, si la pile inclut une couche de base de données.
+ `document_root`— La racine du document, qui est définie sur `null` dans cet exemple, indique que la racine est publique.
+ `ssl_certificate_ca`,`ssl_support`, `ssl_certificate_key` — Indique si l'application prend en charge le protocole SSL. Si oui, les attributs `ssl_certificate_key` et `ssl_certificate_ca` sont définis avec les certificats correspondants.
+ `deploy_to`— Le répertoire racine de l'application.