【问题标题】:Setting up a scheduled / cron job with Django on Elastic Beanstalk with a Worker Tier在具有 Worker Tier 的 Elastic Beanstalk 上使用 Django 设置计划/cron 作业
【发布时间】:2016-06-30 17:49:01
【问题描述】:

我目前正在将 Django 网站从我自己的运行 Ubuntu 的托管服务器迁移到 AWS Elastic Beanstalk。

到目前为止,我发现该过程有些简单 - 直到尝试为我的应用设置一些预定的作业。据我所知,我想使用 cron.yaml 文件在工作层环境中运行 cron 作业。我已经阅读了文档: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features-managing-env-tiers.html#worker-periodictasks

阅读博文: https://medium.com/@joelennon/running-cron-jobs-on-amazon-web-services-aws-elastic-beanstalk-a41d91d1c571#.mx7dq9ufo

还有各种 StackOverflow 帖子,但我觉得我仍然缺少一些关于实际构成我的工作层环境的基本概念。在我自己的服务器上,我可以简单地设置一个 cron 作业来满足这个需求——所以这个概念对我来说是相当新的。我还有一些在 Heroku 上运行的 Django 应用程序,它们使用 web 和 worker dynos、异步处理、Redis 和 Celery 以及计划作业,但我不知道如何将其转化为 Elastic Beanstalk 世界。

基本上,我想了解的概念是:

  1. 就代码而言,实际上是什么构成了我的工作层环境?显然不仅仅是 cron.yaml 文件。这是我的网络应用程序的精确克隆,也部署到了这个环境吗?或者这可以以某种方式引用我的网络环境中的代码并以这种方式运行吗?
  2. 或者工作应用程序完全是它自己的全新应用程序?我是否需要创建一个单独的成熟 Django / Flask 应用来执行此操作?
  3. 我的工作应用程序如何与我的 Web 应用程序进行物理通信? cron.yaml 中的 POST 消息实际上是如何在 Web 应用程序上执行作业的?如果它是一个独立的应用程序,worker 和 web 环境实际上是如何关联的?

我本质上想安排一些 Django 管理命令。我也将方法公开为 POST 端点,但不知道如何让工作环境与网络应用程序对话/执行作业。

请原谅我的天真,我非常感谢任何关于如何将这个概念结合在一起的建议和指导。

【问题讨论】:

    标签: python django amazon-web-services cron amazon-elastic-beanstalk


    【解决方案1】:

    所以我最终与一位更熟悉 AWS 服务的朋友交谈。他解释了这些概念,我通过如下设置工作环境来运行计划作业:

    • 为 Web 环境构建单独的独立应用程序。我构建了一个单独的“worker” Django 应用程序,但这可能是 Flask 或任何其他框架或语言
    • 创建了一个名为“cron”的应用程序,该应用程序具有处理发送到不同端点的 POST 消息的视图,这些端点本质上是我想要执行的计划作业。这些端点是我的 cron.yaml 文件中的作业直接指向的对象
    • 由于我的工作需要对 Web 应用程序进行数据库更改,我将工作应用程序设置为使用与 Web 应用程序相同的数据库。这就像将 RDS 环境变量添加到我的工作环境配置一样简单。例如。设置RDS_DB_NAME、RDS_HOSTNAME、RDS_USERNAME指向web环境数据库

    瞧,计划的作业按计划执行并根据需要进行数据库更改。

    【讨论】:

    • 另一个想法是在您的主要网络/非工作应用程序中包含 1 个 cron 端点,该应用程序以编程方式运行 django-cron's runcrons 管理命令,并制作 1 个工作程序应用程序端点来请求网络应用程序的端点.两个服务器都知道的任意密钥(由工作人员发送,由 Web 应用程序验证)将阻止用户触发您的 crons。优点是不需要在worker上用模型、数据库连接等重新发明轮子。但是,如果 crons 是资源密集型和/或频繁的,这可能是 Web 服务器上的问题。
    • @jmq 实际上我更喜欢您的解决方案。我的解决方案需要将我所有的模型克隆到一个单独的应用程序中并连接到同一个数据库,这有点混乱。
    • 在再次面对这个问题并考虑更多之后,现在对我来说最好的方案似乎是在你的主仓库中开发 cron.yaml 并将你的代码库的副本推送到工作服务器。虽然这在某一方面感觉不是很干(你只是在两台服务器上运行完整的代码,而且它们的目的不同),但它会将 cron 任务的实际工作卸载到工作层,这就是重点AWS 提供该层级。它还最小化/消除了需要编写的新代码(与我上面的第一条评论相反)。
    • 那么如果“worker”层上的这个单独的 django 应用程序需要来自您的主 django web 应用程序的模型或函数会发生什么?
    猜你喜欢
    • 2023-03-31
    • 2017-04-20
    • 2016-11-25
    • 2014-11-27
    • 1970-01-01
    • 2016-11-26
    • 2014-12-12
    • 2019-03-12
    • 2018-05-11
    相关资源
    最近更新 更多