Archives de
Catégorie : Automatisation

Employee Advocacy : déléguez la publication de news AWS sur Twitter avec Slack

Employee Advocacy : déléguez la publication de news AWS sur Twitter avec Slack

La réception des nouveautés AWS nous permettant déjà de nous informer quotidiennement des dernières annonces, nous avions besoin d’une solution de diffusion, ouverte à tous et à toutes, vers le compte Twitter de Corexpert. Pour cela, nous avons développé une application, nommée « NewsBot », basée sur plusieurs services AWS, et proposant de tweeter une actualité par l’intermédiaire de Slack.

 

1 – Architecture

L’application se compose de deux micro-services, le Notifier (Amazon Lambda) et le Publisher (Amazon API Gateway + Amazon Lambda), ainsi que d’une base de données (Amazon DynamoDB).

newsbot

2 – Base de données

Les informations reçues depuis le topic Amazon SNS sont stockées dans une table Amazon DynamoDB. En outre, un champ supplémentaire, que nous avons appelé « actions », contient la liste des réseaux sociaux pour lesquels l’article a déjà été publié.

Afin de restreindre la publication sur Twitter de certaines news en fonction de leur date de publication, nous avons également ajouté un champ TTL, indiquant à Amazon DynamoDB à partir de quelle date il est nécessaire de supprimer l’item de cette table.

dynamodb

 

3 – Le Notifier

Il est composé d’une unique fonction Amazon Lambda, déclenchée par le service Amazon SNS ; cette fonction va parser l’évènement reçu, pour ensuite l’insérer dans la table Amazon DynamoDB et envoyer un message dans un channel Slack.

Commençons par créer une application Slack ; pour notre Notifier, il est nécessaire d’activer les Incoming Webhooks, et d’en ajouter un à notre channel de notifications.

incoming-webhooks

Slack nous donne alors une URL, sur laquelle nous pouvons envoyer nos requêtes POST, contenant la nouvelle notification au format JSON.
Voici un exemple de notification générée par le NewsBot :

aws-newsbot-slack-1

 

4 – Le Publisher

 

a. Publication sur Twitter

Le Publisher est composé des services Amazon API Gateway et Amazon Lambda, permettant de publier un article sur Twitter.
Le fonctionnement du service est le suivant :

  • Une requête HTTP POST est envoyée depuis Slack à notre fonction Amazon Lambda.
  • On vérifie que le token reçu dans le body de la requête est le même que celui de notre application Slack. Ce token est renseigné dans l’onglet “Basic Information”.
  • On vérifie dans la table Amazon DynamoDB que l’article n’a pas déjà été publié sur Twitter.
  • On envoie une requête à Twitter pour créer l’article.
  • La table Amazon DynamoDB est mise à jour pour que la requête ne soit pas traitée deux fois.

Afin de :

  • rendre le bouton utilisable, il est nécessaire d’activer les Interactive Components, et ainsi indiquer à Slack l’URL à appeler (celle fournie par Amazon API Gateway) ;
  • publier sur Twitter, il faut d’abord créer une application, et générer les Consumer Keys et Access Token.

 

b. Modification du message original

Le corps de la requête POST envoyée par Slack est encodé, et contient un objet JSON  nous permettant de récupérer l’utilisateur ou l’utilisatrice ayant cliqué sur le bouton.

Cette information va donc nous servir à remplacer le bouton par un texte, informant toutes les personnes présentes sur le channel que l’article a déjà été publié sur Twitter, à quelle date, et par qui.

Bonus : à la publication de l’article, Twitter nous retourne l’identifiant du tweet qu’il vient de créer ; nous allons donc pouvoir utiliser les WebIntents et ainsi proposer à chacun et chacune de retweeter l’information sur son propre compte.

aws-newsbot-slack-2

 

5 – Conclusion

Le NewsBot va donc permettre de déléguer l’activité du compte Twitter d’une entreprise aux personnes présentes sur un channel Slack, d’une manière simple et rapide, depuis un (ou plusieurs) topic(s) Amazon SNS.

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…