exécuter la tâche planifiée dans AWS sans cron

AWS a annoncé la prise en charge des fonctions planifiées dans Lambda lors de sa conférence re: Invent 2015. Avec cette fonctionnalité, les utilisateurs peuvent exécuter des fonctions Lambda sur une base planifiée en utilisant une syntaxe de type cron. Les documents Lambda montrent un exemple d’utilisation de Python pour effectuer des événements planifiés.

Actuellement, la résolution minimale qu’un lambda programmé peut exécuter est de 1 minute (identique à cron, mais pas aussi fine que les temporisateurs systemd).

Le projet Lambder simplifie l’utilisation des fonctions planifiées sur Lambda.

L’exemple cron de λ Gordon a peut-être l’interface la plus simple pour déployer des fonctions lambda planifiées.

Réponse originale, sauvée pour la postérité.

Comme Eric Hammond et d’autres l’ont déclaré, il n’y a pas de service AWS natif pour les tâches planifiées. Il n’y a que des solutions de contournement et des demi-solutions, comme mentionné dans d’autres réponses.

Pour récapituler les options actuelles:

• Le groupe à mise à l’échelle automatique à instance unique qui démarre et s’arrête selon un calendrier, comme décrit par Eric Hammond.
• Utiliser un minuteur Simple Workflow Service , qui n’est pas du tout intuitif. Cette étude de cas mentionne que JPL a utilisé SWF pour construire un cron dissortingbué, mais il n’y a pas de détails d’implémentation. Il existe également une référence à un exemple de code enfoui dans les exemples de code SWF.
• Exécutez-le vous-même en utilisant quelque chose comme Cronlock .
• Utilisez quelque chose comme l’ horloge de ville non fiable (UTC) pour exécuter les fonctions Lambda selon un planning. Rappelez-vous que Lambda ne peut pas actuellement accéder aux ressources dans un VPC

Espérons qu’une meilleure solution viendra bientôt.

Amazon (AWS) propose-t-il un service qui peut exécuter une tâche récurrente à des intervalles planifiés?

C’est l’un des rares points de défaillance que les utilisateurs (y compris moi) ne cessent de mentionner lors de la conception d’architectures avec AWS. Jusqu’à ce que Amazon le résolve avec un service, voici un hack que j’ai publié et qui est activement utilisé par certaines entresockets.

AWS Auto Scaling peut exécuter et terminer des instances en utilisant une planification récurrente spécifiée au format cron.

http://docs.amazonwebservices.com/AutoScaling/latest/APIReference/API_PutScheduledUpdateGroupAction.html

Vous pouvez demander à l’instance d’exécuter automatiquement un processus au démarrage.

Si vous ne savez pas combien de temps le travail durera, vous pouvez configurer les choses pour que votre travail termine l’instance une fois terminée.

Voici un article que j’ai écrit qui passe en revue les commandes exactes nécessaires pour mettre en place ceci:

Exécution d’instances EC2 sur une planification récurrente avec Auto Scaling
http://alestic.com/2011/11/ec2-schedule-instance

Commencer une instance entière simplement pour lancer un ensemble de tâches semble un peu exagéré, mais si c’est un t1.micro, cela ne coûte que quelques sous.

Ce t1.micro n’a pas à faire le travail lui-même non plus. Votre instance pourrait injecter des messages dans SQS ou via SNS afin que les autres serveurs redondants reprennent les tâches.

Présentation d’ événements dans AWS Cloudwatch

Vous pouvez planifier par minute, heure, jour ou en utilisant une expression CRON en utilisant la console et sans Lambda ou une programmation.

Je viens de programmer mon API Web ASP.net (HTTP Post) en utilisant le sharepoint terminaison HTTP SNS pour exécuter chaque minute et cela fonctionne parfaitement.

Ceci est un site tiers hébergé qui peut régulièrement appeler des scripts programmés sur votre domaine.

Cela ne fonctionnera pas si vous avez besoin que votre script soit exécuté dans le shell, et non en tant qu’Apache.

Cela peut vous être utile: http://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-using-task-runner.html

Task Runner est une application d’agent de tâche qui interroge AWS Data Pipeline pour les tâches planifiées et les exécute sur des instances Amazon EC2, des clusters Amazon EMR ou d’autres ressources de calcul, à la manière des rapports. Selon votre application, vous pouvez choisir de:

• Autorisez AWS Data Pipeline à installer et gérer une ou plusieurs applications Task Runner pour vous sur des ressources de calcul gérées automatiquement. Dans ce cas, vous n’avez pas besoin d’installer ou de configurer Task Runner comme décrit dans cette section. Ceci est la configuration recommandée.

• Installez et configurez manuellement Task Runner sur une ressource informatique telle qu’une instance EC2 de longue durée ou un serveur physique. Pour ce faire, utilisez les procédures de cette section.

• Développez et installez un agent de tâche personnalisé au lieu de Runner de tâches. Les procédures à suivre dépendront de l’implémentation de l’agent de tâche personnalisé.

Amazon a introduit Lambda l’an dernier pour NodeJS, hier, Amazon a ajouté les fonctionnalités Fonctions planifiées, Support VPC et Support Python.

En exploitant la fonction programmée, vous pouvez obtenir un remplacement approprié pour CRON.

Plus d’infos – http://aws.amazon.com/lambda/details/

On dirait que c’est une option relativement nouvelle d’AWS BeanStalk:

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features-managing-env-tiers.html#worker-periodictasks

Fondamentalement, ils agissent comme des récepteurs SQS classiques, mais ils sont appelés sur un programme cron au lieu de répondre à un message SQS.

SWF est un service Web d’AWS pouvant être utilisé pour planifier des tâches. La majeure partie du travail consiste à spécifier ce qu’est une tâche et un calendrier.

http://milindparikh.blogspot.com/2015/07/introducing-diksha-aws-lambda-function.html est un planificateur évolutif écrit contre SWF.

AWS Elastic Load Balancers envoie une requête ping à vos instances pour vérifier qu’elles sont en bon état. Vous pouvez append vos tâches de type cron au script que l’ELB envoie en ping, et il s’exécutera très régulièrement.

Vous souhaitez append un peu de logique pour que chaque tâche soit exécutée le bon nombre de fois et au bon intervalle, mais cela peut être réalisé avec une table de firebase database qui suit les exécutions. Chaque fois que l’ELB envoie une requête ping à votre serveur, votre serveur vérifie la firebase database pour voir si un travail est en attente, puis exécute ce travail.

L’ELB expirera si le script met trop de temps à s’exécuter, il est donc important de ne pas créer une situation où le contrôle de l’intégrité de votre ELB prendra plusieurs secondes pour traiter les tâches cron. Pour résoudre ce problème, vous pouvez utiliser AWS Simple Notification Service. Votre script de contrôle d’intégrité ELB peut simplement publier un message sur un sujet SNS, puis ce sujet peut transmettre le message via une requête HTTP à votre serveur Web.

En d’autres termes: ELB envoie une requête à votre instance EC2 … L’instance EC2 vérifie les travaux en attente et envoie un message à SNS s’ils sont détectés … SNS avertit votre application via HTTP … Cron