Some more stuff

Author: JasonGrace2282

docs/source/guides/architecture/manager.rst

@@ -1,3 +1,24 @@
 #######
 Manager
 #######
+
+The Manager is the driving force behind Director. It is a Django application
+that runs the actual `director site <https://director.tjhsst.edu>`_.
+For the most part, we'll only talk about the ``sites`` app in this section.
+
+The most useful models we use are the :class:`.Site` model and the :class:`.Operation` model.
+The :class:`.Operation` model is just a representation of a task that needs to be done (ex: updating
+an Nginx configuration).
+
+.. tip::
+
+  Given a :class:`.Operation`, you'll often see :func:`auto_run_operation_wrapper` being used to execute
+  the operation. This context manager returns a :class:`.OperationWrapper`.
+  The most important method you'll see used is :meth:`~.OperationWrapper.add_action`, which effectively schedules
+  a callback (see the overloads for how to use it as a method vs as a decorator).
+  Then, after running all of the callbacks, if all callbacks succeed, it will delete the original operation.
+
+
+Communication with other parts
+------------------------------
+Let's talk a little bit about how the Manager communicates with other parts.

docs/source/guides/architecture/orchestrator.rst

@@ -1,3 +1,37 @@
 ############
 Orchestrator
 ############
+
+The orchestrator is responsible for the
+high-level Nginx commands, as well as managing the docker containers.
+
+If you have not yet read :doc:`manager`, you should probably read that first.
+
+Nginx
+-----
+The Orchestrator manages it's own Nginx config to deal
+with incoming requests at ``site-{site-id}.conf``. This config is
+separate from the router's Nginx config, so we'll spend a moment talking
+about some features and how the Orchestrator works with it.
+
+If the website type is ``static``, the Nginx config is where the files in ``/public``
+are served from:
+
+.. code-block:: nginx
+
+   server {
+      # ...
+
+      location / {
+        root site_dir/public;
+      }
+   }
+
+Note that Jinja is used for turning a template into a functional Nginx configuration.
+The data to populate the template is NOT from the orchestrator, but rather from
+a request from the Manager to the Orchestrator. Importantly, the Manager can send a
+post request with the field ``custom_nginx_config`` to inject any other nginx configuration
+needed.
+
+When updating the Nginx config, the orchestrator first moves the old configuration into
+``site-{site-id}.conf.bak``. Only if that succeeds will it write the new configuration.

docs/source/guides/architecture/overview.rst

@@ -103,6 +103,14 @@ Director is made out of four main parts.
 - The Shell runs an ssh server using ``AsyncSSH`` to communicate with the Manager.
 
 
+If you want to learn about each part in more detail, check out
+the following articles (in the correct order):
+
+- :doc:`manager`
+- :doc:`orchestrator`
+- :doc:`router_shell`
+
+
 Manager
 ~~~~~~~
 

docs/source/guides/architecture/router_shell.rst

@@ -1,3 +1,25 @@
 ################
 Router and Shell
 ################
+
+If you haven't read :doc:`orchestrator` and :doc:`manager`,
+it's recommended to read those first to get an idea of how
+the router especially fits into the big picture.
+
+Router
+------
+Each part of Director serves a purpose: the manager for the frontend,
+the orchestrator for editing configs, and so on. The job of the
+router is much like an internet router: it is supposed to forward
+Nginx requests to the orchestrator. Additionally, it also
+is responsible for generating *Let's Encrypt* certificates if
+requested by the manager.
+
+To be more specific, each :class:`.Site` has a custom nginx config stored in a separate
+file (``site-{side-id}.conf`` at the time of writing). The router is responsible for managing
+this file, making sure it is valid, and reloading nginx as needed.
+This may be a little bit confusing because the Orchestrator also has a per-site Nginx config.
+However, this nginx config is NOT the same: it's used to reroute requests to the orchestrator
+app servers, and are stored in a different location then the orchestrators ``site-{site-id}.conf``.
+
+