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.
Recettes Configure
Important
Le AWS OpsWorks Stacks le service a pris fin 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 le AWS Support L'équipe sur AWS Re:post ou via
Les recettes Configure sont affectées à l'événement de cycle de vie 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
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.
-
La recette
tomcat::context
crée un fichier de configuration du contexte de l'application web.Ce fichier configure les JDBC ressources que les applications utilisent pour communiquer avec l'SQLinstance My, 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.
-
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 le mode personnalisé JSON 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_config et redémarre le service Tomcat.
tomcat::context
Le livre de recettes Tomcat permet aux applications d'accéder à un serveur My SQL database, qui peut être exécuté sur une instance distincte, à l'aide d'un objet DataSourceJ2EE
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 qui AWS OpsWorks Stacks s'installe avec l'événement Configure. Le AWS OpsWorks Le service 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. 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.
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 générés API par le AWS 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. 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é. L'exemple décrit dans Créer une pile et exécuter une application définit la racine du document sur"ROOT"
, donc 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
et installé dans le répertoirecontext_name
.xml/etc/tomcat6/Catalina/localhost/
.Le
['datasources']
nœud issu de la pile d'attributs de configuration contient un ou plusieurs attributs, chacun mappant un nom de contexte à la ressource de JDBC données que l'application associée utilisera pour communiquer avec la base de données. Le nœud et son contenu sont définis de manière personnalisée JSON lorsque vous créez la pile, comme décrit plus loin dansCréer une pile et exécuter une application. L'exemple possède un attribut unique qui associe le nom du ROOT contexte à une JDBC ressource 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) outomcat6
(Ubuntu). -
La ressource
template
ne crée le fichier de configuration que si le nœud['datasources']
existe et inclut un attributcontext_name
. -
La ressource définit
template
deux variables,resource_name
etwebapp_name
.resource_name
est défini avec le nom de ressource associé àcontext_name
etwebapp_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 JDBC ressource, défini sur la
resource_name
valeur définie danstomcat::context
.Pour l'exemple, le nom de ressource est jdbc/mydb.
-
auth et type : il s'agit des paramètres standard pour JDBC
DataSource
les connexions. -
maxActive, maxIdle, et maxWait—Le nombre maximum de connexions actives et inactives, ainsi que le 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 JDBC pilote, défini sur Mon SQL pilote.
-
url : connexionURL.
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 etjdbc:sqlserver
pour SQL Server. L'exemple définit le URL àjdbc:mysql://
, oùhost_IP_Address
:3306:simplejspsimplejsp
est le nom abrégé de l'application. -
factory
DataSource
—L'usine, requise pour Mes SQL bases de données.
Pour plus d'informations sur ce fichier de configuration, consultez la DataSources rubrique Utilisation