Migration de Chef Server vers AWS OpsWorks Stacks

Important

AWS OpsWorks Stacksn'accepte plus de nouveaux clients. Les clients existants pourront utiliser la OpsWorks console, l'API, la CLI et les CloudFormation ressources normalement jusqu'au 26 mai 2024, date à laquelle elles ne seront plus disponibles. Pour préparer cette transition, nous vous recommandons de transférer vos piles AWS Systems Manager dès que possible. Pour plus d’informations, consultez AWS OpsWorks StacksFAQ sur la fin de vie et Migration de vos AWS OpsWorks Stacks applications vers AWS Systems Manager Application Manager.

Comme AWS OpsWorks Stacks s'appuie sur Chef, la migration de Chef Server vers AWS OpsWorks Stacks est relativement simple. Cette rubrique présente les directives relatives à la modification du code Chef Server pour qu'il fonctionne avec AWS OpsWorks Stacks.

Note

Il est déconseillé de migrer vers les piles à l'aide des versions Chef antérieures à 11.10, car elles sont basées sur chef-solo et ne prennent pas en charge la recherche ou les conteneurs de données.

Mappage des rôles et des couches

Chef Server utilise des rôles pour représenter et gérer les instances ayant les mêmes objectif et configuration, telles qu'un ensemble d'instances qui hébergent chacune un serveur d'applications Java. Une couche AWS OpsWorks Stacks obéit pour l'essentiel au même objectif qu'un rôle Chef. Une couche est un modèle permettant de créer un ensemble d'instances Amazon Elastic Compute Cloud (Amazon EC2) avec la même configuration, les mêmes packages installés, la même procédure de déploiement d'applications, etc.

AWS OpsWorks Stacks inclut un ensemble de couches intégrées pour plusieurs types de serveur d'applications, un équilibreur de charge HAProxy, une base de données principale MySQL et un serveur maître de surveillance Ganglia. Par exemple, la couche Java App Server intégrée est un modèle pour créer des instances hébergeant un serveur Tomcat.

Pour migrer vers AWS OpsWorks Stacks vous devez associer chaque rôle à une couche qui fournit une fonctionnalité équivalente. Pour certains rôles, il se peut que vous puissiez simplement utiliser l'une des couches intégrées. D'autres rôles peuvent nécessiter différents degrés de personnalisation. Commencez par examiner les fonctionnalités des couches intégrées, y compris les recettes associées à chacune d'elles, pour voir si l'une offre au moins certaines fonctionnalités de votre rôle. Pour plus d'informations sur les couches intégrées, consultez Couches et Référence des couches AWS OpsWorks Stacks. Pour examiner les recettes intégrées, consultez le GitHub référentiel public AWS OpsWorks Stacks.

La façon dont vous procédez dépend étroitement de la manière dont vous pouvez associer une couche à chaque rôle, comme suit.

Une couche intégrée prend en charge toutes les fonctionnalités du rôle

Vous pouvez utiliser la couche intégrée directement, avec des personnalisations mineures, si nécessaire. Par exemple, si un rôle prend en charge un serveur Tomcat, les recettes de la couche Java App Server peuvent déjà gérer toutes les tâches du rôle, éventuellement avec une légère personnalisation. Par exemple, vous pouvez faire en sorte que les recettes intégrées de la couche utilisent les paramètres de configuration Tomcat ou Apache en remplaçant les attributs ou les modèles appropriés.

Une couche intégrée prend en charge certaines, mais pas toutes, fonctionnalités du rôle

Vous pouvez utiliser une couche intégrée en étendant la couche. Cette extension implique généralement d'implémenter des recettes personnalisées pour prendre en charge les fonctionnalités manquantes et d'affecter les recettes aux événements du cycle de vie de la couche. Par exemple, supposons que votre rôle installe un serveur Redis sur les mêmes instances qui hébergent un serveur Tomcat. Vous pouvez étendre la couche Java App Server pour qu'elle corresponde aux fonctionnalités du rôle en implémentant une recette personnalisée pour installer Redis sur les instances de la couche et en attribuant la recette à l'événement de configuration de la couche.

Aucune couche intégrée ne prend en charge de façon adéquate la fonctionnalité du rôle

Mettez en place une couche personnalisée. Par exemple, supposons que votre rôle prenne en charge un serveur de base de données MongoDB, qui n'est pris en charge par aucune des couches intégrées. Vous pouvez fournir cette prise en charge en implémentant des recettes pour installer les packages requis, configurer le serveur, etc., et attribuer les recettes aux événements du cycle de vie d'une couche personnalisée. Généralement, vous pouvez utiliser au moins certaines recettes du rôle à cet effet. Pour plus d'informations sur l'implémentation d'une couche personnalisée, consultez Création d'une couche serveur Tomcat personnalisée.

Utilisation des conteneurs de données

Chef Server vous permet de transmettre à vos recettes des données définies par l'utilisateur à l'aide de conteneurs de données.

• Vous stockez les données avec vos livres de recettes et Chef les installe sur chaque instance.

• Vous pouvez utiliser les conteneurs de données chiffrées pour les données sensibles telles que les mots de passe.

AWS OpsWorks Stacks prend en charge les conteneurs de données ; les recettes peuvent extraire les données en utilisant exactement le même code qu'avec Chef Server. Cependant, la prise en charge présente les différences et limites suivantes :

• Les conteneurs de données ne sont pris en charge que sur les piles Linux Chef 11 .10 et versions ultérieures.

  Les piles Windows et les piles Linux exécutant des versions antérieures de Chef ne prennent pas en charge les conteneurs de données.

• Vous ne stockez pas les conteneurs de données dans votre référentiel de livres de recettes.

  Au lieu de cela, vous utilisez un JSON personnalisé pour gérer les données de vos conteneurs de données.

• AWS OpsWorks Stacks ne prend pas en charge les conteneurs de données chiffrées.

  Si vous devez stocker des données sensibles sous une forme chiffrée, telle que mots de passe ou certificats, nous vous recommandons de les stocker dans un compartiment S3 privé. Vous pouvez ensuite créer une recette personnalisée qui utilise le Kit SDK Amazon pour Ruby pour récupérer les données. Pour obtenir un exemple, consultez Utilisation du kit SDK pour Ruby.

Pour plus d’informations, consultez Utilisation des conteneurs de données.

Utilisation de Chef Search

Chef Server stocke les informations de configuration de pile, telles que les adresses IP et les configurations de rôle, sur le serveur. Les recettes utilisent la recherche Chef pour récupérer ces données. AWS OpsWorks Stacks utilise une approche quelque peu différente. Par exemple, les piles Linux Chef 11.10 reposent sur le mode local client Chef, option qui exécute localement une version légère de Chef Server (souvent appelé Chef Zero) sur l'instance. Chef Zero prend en charge la recherche sur les données stockées dans l'objet nœud de l'instance.

Au lieu de stocker les données de la pile sur un serveur distant, AWS OpsWorks Stacks ajoute un ensemble d'attributs de configuration et de déploiement de pile à l'objet nœud de chaque instance pour tous les événements du cycle de vie. Ces attributs représentent un instantané de la configuration de la pile. Ils utilisent la même syntaxe que Chef Server et représentent la plupart des données dont les recettes ont besoin pour récupérer des données à partir du serveur.

Il est souvent inutile de modifier le code de recherche de vos recettes pour AWS OpsWorks Stacks. Comme la recherche Chef fonctionne sur l'objet nœud, qui inclut les attributs de configuration et de déploiement de pile, les requêtes de recherche dans AWS OpsWorks Stacks fonctionnent généralement de la même façon qu'elles le font avec Chef Server.

La principale exception est due au fait que les attributs de configuration et de déploiement de pile contiennent uniquement les données qu'AWS OpsWorks Stacks connaît quand il installe les attributs sur l'instance. Si vous créez ou modifiez un attribut localement sur une instance particulière, ces modifications ne sont pas répercutées en retour sur AWS OpsWorks Stacks et ne sont pas intégrées aux attributs de configuration et de déploiement de pile qui sont installés sur les autres instances. Vous pouvez utiliser la recherche pour récupérer la valeur d'attribut uniquement sur cette instance. Pour plus d’informations, consultez Utilisation de Chef Search.

Pour des raisons de compatibilité avec Chef Server, AWS OpsWorks Stacks ajoute un ensemble d'attributs role à l'objet nœud, chacun contenant l'un des attributs de couche de la pile. Si votre recette utilise roles comme clé de recherche, vous n'avez pas besoin de modifier le code de recherche. La requête retourne automatiquement les données de la couche correspondante. Par exemple, les requêtes suivantes interrogent toutes deux les attributs de la couche php-app.

phpserver = search(:node, "layers:php-app").first

phpserver = search(:node, "roles:php-app").first

Gestion des recettes et des livres de recettes

AWS OpsWorks Stacks et Chef Server gèrent les livres de recettes et les recettes quelque peu différemment. Avec Chef Server :

• Vous fournissez tous les livres de recettes, en les mettant en œuvre vous-même ou en utilisant les livres de recettes de la communauté.

• Vous stockez les livres de recettes sur le serveur.

• Vous exécutez les recettes manuellement ou selon une planification régulière.

Avec AWS OpsWorks Stacks :

• AWS OpsWorks Stacks fournit un ou plusieurs livres de recettes pour chacune des couches intégrées. Ces livres de recettes gèrent les tâches standards, telles que l'installation et la configuration des logiciels d'une couche intégrée, et le déploiement d'applications.

  Pour gérer des tâches qui ne sont pas exécutées par les livres de recettes intégrés, vous ajoutez des livres de recettes personnalisés à votre pile ou utilisez les livres de recettes de la communauté.

• Vous stockez les livres de recettes AWS OpsWorks Stacks dans un référentiel distant, tel qu'un compartiment S3 ou un référentiel Git.

  Pour plus d’informations, consultez Stockage des livres de recettes.

• Vous pouvez exécuter manuellement les recettes, mais, généralement, vous faites en sorte qu'AWS OpsWorks Stacks exécute automatiquement les recettes en réponse à un ensemble d'événements du cycle de vie qui se produisent à des instants clés pendant le cycle de vie d'une instance.

  Pour plus d’informations, consultez Exécution des recettes.

• AWS OpsWorks Stacks ne prend en charge Berkshelf que sur les piles Chef 11.10. Si vous utilisez Berkshelf pour gérer les dépendances de vos livres de recettes, vous ne pouvez pas utiliser les piles exécutant Chef 11.4 ou versions antérieures.

  Pour plus d’informations, consultez Utilisation de Berkshelf.

Rubriques

• Stockage des livres de recettes
• Exécution des recettes

Stockage des livres de recettes

Avec Chef Server, vous stockez vos livres de recettes sur le serveur et les déployez depuis le serveur vers les instances. Avec AWS OpsWorks Stacks, vous stockez des livres de recettes dans un dépôt : une archive S3 ou HTTP ou un dépôt Git ou Subversion. Vous spécifiez les informations dont AWS OpsWorks Stacks a besoin pour télécharger le code depuis le référentiel vers les instances d'une pile lorsque vous installez les livres de recettes.

Pour migrer à partir de Chef Server, vous devez placer vos livres de recettes dans l'un de ces référentiels. Pour plus d'informations sur la façon de structurer un référentiel de livres de recettes, consultez Référentiels de livres de recettes.

Exécution des recettes

Dans AWS OpsWorks Stacks, chaque couche est associée à un ensemble d'événements du cycle de vie (installation, configuration, déploiement, annulation du déploiement et arrêt) qui se produisent chacun à un moment clé du cycle de vie d'une instance. Pour exécuter une recette personnalisée, vous l'assignez généralement à l'événement approprié de la couche appropriée. Lorsque l'événement se produit, AWS OpsWorks Stacks exécute les recettes associées. Par exemple, l'événement Setup se produit après qu'une instance a fini de démarrer et, par conséquent, vous lui assignez généralement les recettes qui exécutent des tâches telles que l'installation et la configuration de packages, ou le démarrage de services.

Vous pouvez exécuter les recettes manuellement grâce à la commande de pileExecute Recipes. Cette commande est utile pour le développement et les tests, mais vous pouvez également l'utiliser pour exécuter des recettes qui ne sont pas mappées avec un événement du cycle de vie. Vous pouvez aussi utiliser la commande Execute Recipes pour déclencher manuellement les événements Setup et Configure.

En plus de la console AWS OpsWorks Stacks, vous pouvez utiliser l'interface de ligne de commande AWS ou les kits SDK AWS pour exécuter les recettes. Ces outils prennent en charge toutes les actions d'API AWS OpsWorks Stacks, mais sont plus simples à utiliser que l'API. Utilisez la commande create-deployment de l'interface de ligne de commande pour déclencher un événement de cycle de vie, qui exécute toutes les recettes associées. Vous pouvez également utiliser cette commande pour exécuter une ou plusieurs recettes sans déclencher un événement. Le code équivalent du kit de développement logiciel dépend de la langue, mais il est généralement similaire à la commande de la ligne de commande.

Les exemples suivants décrivent deux façons d'utiliser la commande create-deployment de l'interface de ligne de commande pour automatiser le déploiement d'applications.

• Déployez votre application selon un calendrier régulier en ajoutant à votre pile une couche personnalisée avec une seule instance.

  Ajoutez à la couche une recette Setup personnalisée qui crée un travail cron sur l'instance pour exécuter la commande selon un calendrier spécifié. Pour obtenir un exemple d'utilisation d'une recette pour créer un travail cron, consultez Exécution de tâches cron sur les instances Linux.

• Ajoutez une tâche à votre pipeline d'intégration continue qui utilise la commande create-deployment de l'interface de ligne de commande pour déployer l'application.

Utilisation des environnements Chef

AWS OpsWorks Stacks ne prend pas en charge les environnements Chef ; node.chef_environment retourne toujours _default.