first-steps-with-celery.rst 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197
  1. .. _tut-celery:
  2. ========================
  3. First steps with Celery
  4. ========================
  5. .. contents::
  6. :local:
  7. .. _celerytut-simple-tasks:
  8. Creating a simple task
  9. ======================
  10. In this tutorial we are creating a simple task that adds two
  11. numbers. Tasks are defined in normal Python modules.
  12. By convention we will call our module :file:`tasks.py`, and it looks
  13. like this:
  14. :file: `tasks.py`
  15. .. code-block:: python
  16. from celery.task import task
  17. @task
  18. def add(x, y):
  19. return x + y
  20. Behind the scenes the `@task` decorator actually creates a class that
  21. inherits from :class:`~celery.task.base.Task`. The best practice is to
  22. only create custom task classes when you want to change generic behavior,
  23. and use the decorator to define tasks.
  24. .. seealso::
  25. The full documentation on how to create tasks and task classes is in the
  26. :doc:`../userguide/tasks` part of the user guide.
  27. .. _celerytut-conf:
  28. Configuration
  29. =============
  30. Celery is configured by using a configuration module. By default
  31. this module is called :file:`celeryconfig.py`.
  32. The configuration module must either be in the current directory
  33. or on the Python path, so that it can be imported.
  34. You can also set a custom name for the configuration module by using
  35. the :envvar:`CELERY_CONFIG_MODULE` environment variable.
  36. Let's create our :file:`celeryconfig.py`.
  37. 1. Configure how we communicate with the broker (RabbitMQ in this example)::
  38. BROKER_URL = "amqp://guest:guest@localhost:5672//"
  39. 2. Define the backend used to store task metadata and return values::
  40. CELERY_RESULT_BACKEND = "amqp"
  41. The AMQP backend is non-persistent by default, and you can only
  42. fetch the result of a task once (as it's sent as a message).
  43. For list of backends available and related options see
  44. :ref:`conf-result-backend`.
  45. 3. Finally we list the modules the worker should import. This includes
  46. the modules containing your tasks.
  47. We only have a single task module, :file:`tasks.py`, which we added earlier::
  48. CELERY_IMPORTS = ("tasks", )
  49. That's it.
  50. There are more options available, like how many processes you want to
  51. use to process work in parallel (the :setting:`CELERY_CONCURRENCY` setting),
  52. and we could use a persistent result store backend, but for now, this should
  53. do. For all of the options available, see :ref:`configuration`.
  54. .. note::
  55. You can also specify modules to import using the :option:`-I` option to
  56. :mod:`~celery.bin.celeryd`::
  57. $ celeryd -l info -I tasks,handlers
  58. This can be a single, or a comma separated list of task modules to import
  59. when :program:`celeryd` starts.
  60. .. _celerytut-running-celeryd:
  61. Running the celery worker server
  62. ================================
  63. To test we will run the worker server in the foreground, so we can
  64. see what's going on in the terminal::
  65. $ celeryd --loglevel=INFO
  66. In production you will probably want to run the worker in the
  67. background as a daemon. To do this you need to use the tools provided
  68. by your platform, or something like `supervisord`_ (see :ref:`daemonizing`
  69. for more information).
  70. For a complete listing of the command line options available, do::
  71. $ celeryd --help
  72. .. _`supervisord`: http://supervisord.org
  73. .. _celerytut-executing-task:
  74. Executing the task
  75. ==================
  76. Whenever we want to execute our task, we use the
  77. :meth:`~celery.task.base.Task.delay` method of the task class.
  78. This is a handy shortcut to the :meth:`~celery.task.base.Task.apply_async`
  79. method which gives greater control of the task execution (see
  80. :ref:`guide-executing`).
  81. >>> from tasks import add
  82. >>> add.delay(4, 4)
  83. <AsyncResult: 889143a6-39a2-4e52-837b-d80d33efb22d>
  84. At this point, the task has been sent to the message broker. The message
  85. broker will hold on to the task until a worker server has consumed and
  86. executed it.
  87. Right now we have to check the worker log files to know what happened
  88. with the task. Applying a task returns an
  89. :class:`~celery.result.AsyncResult`, if you have configured a result store
  90. the :class:`~celery.result.AsyncResult` enables you to check the state of
  91. the task, wait for the task to finish, get its return value
  92. or exception/traceback if the task failed, and more.
  93. Keeping Results
  94. ---------------
  95. If you want to keep track of the tasks state, Celery needs to store or send
  96. the states somewhere. There are several
  97. built-in backends to choose from: SQLAlchemy/Django ORM, Memcached, Redis,
  98. AMQP, MongoDB, Tokyo Tyrant and Redis -- or you can define your own.
  99. For this example we will use the `amqp` result backend, which sends states
  100. as messages. The backend is configured via the ``CELERY_RESULT_BACKEND``
  101. option, in addition individual result backends may have additional settings
  102. you can configure::
  103. CELERY_RESULT_BACKEND = "amqp"
  104. #: We want the results to expire in 5 minutes, note that this requires
  105. #: RabbitMQ version 2.1.1 or higher, so please comment out if you have
  106. #: an earlier version.
  107. CELERY_TASK_RESULT_EXPIRES = 300
  108. To read more about result backends please see :ref:`task-result-backends`.
  109. Now with the result backend configured, let's execute the task again.
  110. This time we'll hold on to the :class:`~celery.result.AsyncResult`::
  111. >>> result = add.delay(4, 4)
  112. Here's some examples of what you can do when you have results::
  113. >>> result.ready() # returns True if the task has finished processing.
  114. False
  115. >>> result.result # task is not ready, so no return value yet.
  116. None
  117. >>> result.get() # Waits until the task is done and returns the retval.
  118. 8
  119. >>> result.result # direct access to result, doesn't re-raise errors.
  120. 8
  121. >>> result.successful() # returns True if the task didn't end in failure.
  122. True
  123. If the task raises an exception, the return value of `result.successful()`
  124. will be :const:`False`, and `result.result` will contain the exception instance
  125. raised by the task.
  126. Where to go from here
  127. =====================
  128. After this you should read the :ref:`guide`. Specifically
  129. :ref:`guide-tasks` and :ref:`guide-executing`.