Archives de
Catégorie : Automatisation

Planifiez vos tâches CRON avec AWS

Planifiez vos tâches CRON avec AWS

Utilisé en conjonction avec Amazon CloudWatch Events, Amazon SNS permet le déclenchement de tâches CRON appelant des web services. Nous allons voir dans ce post comment mettre cela en place facilement.

Dans un premier temps, il nous faut créer un topic SNS.
create_topic

Puis, créer une subscription vers la route du web service. Ainsi, à chaque publication dans le topic SNS par l’event Cloud Watch, une notification sera envoyée à la route HTTP définie.create-subscription

Avant de créer cette subscription, il faut savoir que toute subscription nécessite une confirmation dont la demande est envoyée à la cible. La demande de confirmation est envoyée lors de la création de la subscription mais celle-ci peut être faite manuellement via la console AWS.

Voici un exemple de code PHP qui vérifie la signature des messages envoyés par Amazon SNS et confirme automatiquement la subscription au topic :

Enfin, il ne nous reste plus qu’a créer une rule pour déclencher un Event Amazon CloudWatch selon un Schedule qui publiera dans ce topic tous les x minutes/heures/jours . create_cw_rule

Et voilà ! notre web service est maintenant appelé toutes les 5 minutes.

Conjuguer les services Run Command et Auto Scaling Group

Conjuguer les services Run Command et Auto Scaling Group

Une commande à lancer sur la centaine de machines de votre Auto-Scaling Group ? Rien de plus facile avec le « Systems Manager Run Command » !

Configuration des droits

Les instances cibles doivent avoir un rôle contenant la policy AmazonEC2RoleforSSM.

iam-policy-ssm

L’utilisateur lançant les commandes doit avoir la policy AmazonSSMFullAccess.

 

Installation de l’agent sur les instances

L’agent est responsable de l’exécution de la commande. Sur les instances Windows, il est déjà installé. Pour Linux, il faut l’installer manuellement : soit en se connectant à l’instance et en lançant les commandes, soit via les user data (à utiliser pour l’Auto-Scaling Group).

Toutes les commandes d’installation de l’agent sont disponibles dans la page de documentation « Installing SSM Agent ».

Exemple de launch configuration avec une instance Amazon Linux AMI:

launch-configuration

 

Identification des instances

Les instances de l’Auto-Scaling Group doivent être identifiables par un tag dont la key/value est spécifique à celui-ci.

autoscalinggroup-tag

 

Lancement d’une commande depuis la console

Dans le menu de l’interface EC2, aller dans « Systems Manager Services » -> « Run command » et cliquer sur le bouton « Run command ».

goto-runcommand

Remplir le formulaire avec les informations suivantes :

  • Command document : sélectionner « AWS-RunShellScript »
  • Select targets by : sélectionner « Specifiying a Tag » et entrer le tag de l’auto scaling group

select-targets-by-tag

  • Commands : entrer « ps -aux »

Appuyer sur le bouton « Run » en bas à droite.

Vous pouvez alors suivre l’état d’avancement de la commande :

run-command-table

Le résultat de la commande est accessible via l’onglet « Output »:

run-command-output

 

Lancement d’une commande depuis AWS CLI

A la fin du formulaire précédent, un cadre donne la commande AWS CLI équivalente :

cli-from-form

 

Il est alors possible d’intégrer cette commande dans un scheduler afin de lancer des commandes de maintenance telles qu’un vidage de cache.

 


Sources :

Jenkins CI – Identifiants AWS

Jenkins CI – Identifiants AWS

Aujourd’hui, un petit article concernant l’automatisation et l’utilisation des services AWS depuis une instance Jenkins. AWS fournit de nombreux outils permettant l’automatisation de votre infrastructure, de vos déploiements, de vos backups, et j’en passe. On pense notamment au AWS CLI, AWS SDK et AWS CloudFormation. Cependant, il est nécessaire de contrôler la façon dont vous vous identifiez pour utiliser ces outils, par exemple vous pouvez avoir besoin de vous identifier sur plusieurs comptes AWS ou encore gérer différents droits en fonction du type d’environnement.

Tout d’abord, il faut vous munir d’identifiants AWS, liés à un utilisateur qu’il faudra créer :

add_user

Ensuite, rendez-vous sur votre instance Jenkins (si vous n’en avez pas encore, je vous conseille de suivre ce tutoriel). Jenkins permet de centraliser tous vos identifiants nécessaires pour les appels à tous les services externes dont vous avez besoin (Git, SSH, AWS, etc). Afin d’ajouter des identifiants AWS dans ce « Credentials Manager », il faut au préalable installer le CloudBees AWS Credentials Plugin. Il est maintenant possible d’ajouter les identifiants de notre utilisateur AWS :aws_credentials

Vous avez enfin vos identifiants AWS managés par Jenkins. Il ne reste plus qu’à les utiliser dans vos jobs. Pour cela, il faut se rendre dans la section « Build Environment » de votre job et sélectionner l’option « Use secret text(s) or file(s) ». Ajoutez un binding « AWS access key and secret » et choisissez les identifiants de votre choix :

job_aws_credentials

Par défaut, le plugin va ajouter les variables d’environnement AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY au runtime de votre job. Ces variables sont reconnues automatiquement par les outils AWS (CLI et SDK) et vous permettront de réaliser les actions de votre choix sur votre compte AWS (ex : aws s3api list-buckets).

Si cette article vous a été utile, n’hésitez pas à commenter, le partager ou nous contacter. Plus d’articles à venir sur l’automatisation…