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.
# Extension d'une couche
**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
**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
**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
**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
**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).