如何使用AWS Elastic Beanstalk运行工作程序？

Question

我正在AWS Elastic beantalk上启动django应用程序。我想运行后台任务或工作者以便运行celery。

我找不到是否可能。如果是，如何实现？

这是我现在正在做的事情，但这每次都会产生一个事件类型错误。

container_commands:
  01_syncdb:
    command: "django-admin.py syncdb --noinput"
    leader_only: true
  50_sqs_email:
    command: "./manage.py celery worker --loglevel=info"
    leader_only: true

Answer 1

正如@ chris-wheadon在其评论中建议的那样，你应该尝试在后台将Celery作为恶魔运行。AWS Elastic Beanstalk 已使用supervisor运行某些守护进程。因此，你可以利用它来运行celeryd并避免为此创建自定义AMI。它对我很好。

我要做的是在EB将应用程序部署到实例之后，以编程方式将celeryd配置文件添加到实例。棘手的部分是，该文件需要设置守护进程所需的环境变量（例如，如果你在应用程序中使用S3或其他服务，则需要使用AWS访问密钥）。

下面是我使用的脚本的副本，将此脚本添加到.ebextensions配置EB环境的文件夹中。

安装脚本会在文件/opt/elasticbeanstalk/hooks/appdeploy/post/夹（文档）中创建一个文件，该文件位于所有EB实例上。部署后将执行其中的任何shell脚本。放置在那里的shell脚本的工作方式如下：

1. 在celeryenv变量中，virutalenv环境以遵循监督符号的格式存储。这是逗号分隔的env变量列表。
2. 然后，脚本创建一个变量celeryconf，该变量将配置文件包含为字符串，其中包括先前解析的env变量。
3. 然后将此变量通过管道传递到celeryd.confcelery守护程序的受监管配置文件中。
4. 最后，将新创建的配置文件的路径添加到主supervisord.conf文件（如果尚未存在）。
   这是脚本的副本：
   

files:
  "/opt/elasticbeanstalk/hooks/appdeploy/post/run_supervised_celeryd.sh":
    mode: "000755"
    owner: root
    group: root
    content: |
      #!/usr/bin/env bash

      # Get django environment variables
      celeryenv=`cat /opt/python/current/env | tr '\n' ',' | sed 's/export //g' | sed 's/$PATH/%(ENV_PATH)s/g' | sed 's/$PYTHONPATH//g' | sed 's/$LD_LIBRARY_PATH//g'`
      celeryenv=${celeryenv%?}

      # Create celery configuraiton script
      celeryconf="[program:celeryd]
      ; Set full path to celery program if using virtualenv
      command=/opt/python/run/venv/bin/celery worker -A myappname --loglevel=INFO

      directory=/opt/python/current/app
      user=nobody
      numprocs=1
      stdout_logfile=/var/log/celery-worker.log
      stderr_logfile=/var/log/celery-worker.log
      autostart=true
      autorestart=true
      startsecs=10

      ; Need to wait for currently executing tasks to finish at shutdown.
      ; Increase this if you have very long running tasks.
      stopwaitsecs = 600

      ; When resorting to send SIGKILL to the program to terminate it
      ; send SIGKILL to its whole process group instead,
      ; taking care of its children as well.
      killasgroup=true

      ; if rabbitmq is supervised, set its priority higher
      ; so it starts first
      priority=998

      environment=$celeryenv"

      # Create the celery supervisord conf script
      echo "$celeryconf" | tee /opt/python/etc/celery.conf

      # Add configuration script to supervisord conf (if not there already)
      if ! grep -Fxq "[include]" /opt/python/etc/supervisord.conf
          then
          echo "[include]" | tee -a /opt/python/etc/supervisord.conf
          echo "files: celery.conf" | tee -a /opt/python/etc/supervisord.conf
      fi

      # Reread the supervisord config
      supervisorctl -c /opt/python/etc/supervisord.conf reread

      # Update supervisord in cache without restarting all services
      supervisorctl -c /opt/python/etc/supervisord.conf update

      # Start/Restart celeryd through supervisord
      supervisorctl -c /opt/python/etc/supervisord.conf restart celeryd