overview.rst 4.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126
  1. Overview
  2. ========
  3. Pagure is split over multiple components, each having their purpose and all
  4. but two (the core web application and its workers) being optional.
  5. These components are:
  6. .. contents::
  7. Before going into the overall picture, one should realize that most of the
  8. components listed above are optional.
  9. Here is a diagram representing pagure without all the optional components:
  10. .. image:: _static/overview_simple.png
  11. :target: _images/overview_simple.png
  12. And here is a diagram of all the components together:
  13. .. image:: _static/overview.png
  14. :target: _images/overview.png
  15. Pagure core application
  16. -----------------------
  17. The core application is the flask application and provide a web UI to
  18. the git repositories as well as tickets and pull-requests.
  19. This is the main application for the forge.
  20. Pagure workers
  21. --------------
  22. Interacting with git repos can be a long process, it varies depending on the
  23. size of the repository itself but also based on hardware performances or
  24. simply the load on the system.
  25. To make pagure capable of handling more load, since pagure 3.0 the interactions
  26. with the git repositories from the web UI is performed by dedicated workers,
  27. allowing async processing of the different tasks.
  28. The communication between the core application and its worker is based on
  29. `celery <http://www.celeryproject.org/>`_ and defaults to using `redis
  30. <https://redis.org>`_ but any of the queueing system supported by `celery
  31. <http://www.celeryproject.org/>`_ could be used instead.
  32. Pagure doc server
  33. -----------------
  34. While integrated into the main application at first, it has been split out
  35. for security concern, displaying information directly provided by the user
  36. without a clear/safe way of filtering for unsafe script or hacks is a
  37. security hole.
  38. For this reason we also strongly encourage anyone wanting to deploy their
  39. own instance of pagure with the doc server, to run this application on a
  40. completely different domain name (not just a sub-domain) in order to reduce
  41. the cross-site forgery risks.
  42. Pagure can be run just fine without the doc server, all you need to do is to
  43. **not** define the variable ``DOC_APP_URL`` in the configuration file.
  44. Pagure milter
  45. -------------
  46. The milter is a script, receiving an email as input and performing an action
  47. with it.
  48. In the case of pagure, the milter is used to allow replying on a comment
  49. of a ticket or a pull-request by directly replying to the notification sent.
  50. No need to go to the page anymore to reply to a comment someone made.
  51. The milter integrates with a MTA such as postfix or sendmail that you will
  52. have running and have access to in order to change its configuration.
  53. Pagure EventSource Server
  54. -------------------------
  55. Eventsource or Server Sent Events are messages sent from a server to a browser.
  56. For pagure this technology is used to allow live-refreshing of a page when
  57. someone is viewing it. For example, while you are reading a ticket if someone
  58. comments on it, the comment will automatically show up on the page without
  59. the need for you to reload the entire page.
  60. The flow is: the main pagure server does an action, sends a message over
  61. redis, the eventsource server picks it up and send it to the browsers waiting
  62. for it, then javascript code is executed to refresh the page based on the
  63. information received.
  64. Pagure web-hook Server
  65. ----------------------
  66. Sends notifications to third party services using POST http requests.
  67. This is the second notifications system in pagure with `fedmsg <https://fedmsg.readthedocs.io/>`_.
  68. These notifications are running on their own service to prevent blocking the
  69. main web application in case the third part service is timing-out or just
  70. being slow.
  71. The flow is: the main pagure server does an action, sends a message over
  72. redis, the web-hook server picks it up, build the query and performs the
  73. POST request to the specified URLs.
  74. Pagure load JSON service
  75. ------------------------
  76. The load JSON service is an async service updating the database based on
  77. information pushed to the ticket or pull-request git repositories.
  78. This allows updating the database with information pushed to the git
  79. repositories without keeping the connection open with the client.
  80. Pagure log com service
  81. ----------------------
  82. The log com (for log commit) service is an async service updating the log
  83. table of the database on every pushed made to any repository allowing to
  84. build the data for the calendar heatmap graph displayed on every user's
  85. page.