BasPH commented on code in PR #36513:
URL: https://github.com/apache/airflow/pull/36513#discussion_r1438889862
##########
docs/apache-airflow/core-concepts/overview.rst:
##########
@@ -43,13 +43,26 @@ An Airflow installation generally consists of the following
components:
Basic airflow architecture
--------------------------
-This is the basic architecture of Airflow that you'll see in simple
installations:
+This is the basic architecture of Airflow that you'll see in simple
installations.
+
+Note that even in the simple installation, Airflow Webserver does not access
the DAG files directly
+(the code you see in the Code tab of the UI is synchronized via the metadata
database).
+
+This is to allow for a more secure deployment, where the webserver has never
the need or even
+possibility to executed code submitted by DAG authors, the only custom code
that webserver can
+execute are the plugins and those should be only installed and deployed by the
Airflow Deployment Manager.
Review Comment:
Would leave this out.
##########
docs/apache-airflow/img/diagram_dag_processor_airflow_architecture.py:
##########
@@ -64,10 +67,21 @@ def generate_dag_processor_airflow_diagram():
dag_processors = Custom("DAG\nProcessor(s)",
PYTHON_MULTIPROCESS_LOGO.as_posix())
dag_files = MultipleDocuments("DAG files")
+ with Cluster("Deploymet environment"):
Review Comment:
```suggestion
with Cluster("Deployment environment"):
```
##########
docs/apache-airflow/core-concepts/overview.rst:
##########
@@ -43,13 +43,26 @@ An Airflow installation generally consists of the following
components:
Basic airflow architecture
--------------------------
-This is the basic architecture of Airflow that you'll see in simple
installations:
+This is the basic architecture of Airflow that you'll see in simple
installations.
+
+Note that even in the simple installation, Airflow Webserver does not access
the DAG files directly
+(the code you see in the Code tab of the UI is synchronized via the metadata
database).
+
+This is to allow for a more secure deployment, where the webserver has never
the need or even
+possibility to executed code submitted by DAG authors, the only custom code
that webserver can
+execute are the plugins and those should be only installed and deployed by the
Airflow Deployment Manager.
.. image:: ../img/diagram_basic_airflow_architecture.png
-Most executors will generally also introduce other components to let them talk
to their workers - like a task queue - but you can still think of the executor
and its workers as a single logical component in Airflow overall, handling the
actual task execution.
+Note that executor is only briefly mentioned as a link between Scheduler and
workers.
+The executors will generally also introduce other components to let them talk
to their workers -
+like a task queue - but you can still think of the executor and its workers as
a single logical
+component in Airflow overall, handling the actual task execution - where
executor is controlled by the
+scheduler.
Review Comment:
What is the key message here?
##########
docs/apache-airflow/core-concepts/overview.rst:
##########
@@ -43,13 +43,26 @@ An Airflow installation generally consists of the following
components:
Basic airflow architecture
--------------------------
-This is the basic architecture of Airflow that you'll see in simple
installations:
+This is the basic architecture of Airflow that you'll see in simple
installations.
+
+Note that even in the simple installation, Airflow Webserver does not access
the DAG files directly
+(the code you see in the Code tab of the UI is synchronized via the metadata
database).
+
+This is to allow for a more secure deployment, where the webserver has never
the need or even
+possibility to executed code submitted by DAG authors, the only custom code
that webserver can
+execute are the plugins and those should be only installed and deployed by the
Airflow Deployment Manager.
.. image:: ../img/diagram_basic_airflow_architecture.png
-Most executors will generally also introduce other components to let them talk
to their workers - like a task queue - but you can still think of the executor
and its workers as a single logical component in Airflow overall, handling the
actual task execution.
+Note that executor is only briefly mentioned as a link between Scheduler and
workers.
+The executors will generally also introduce other components to let them talk
to their workers -
+like a task queue - but you can still think of the executor and its workers as
a single logical
+component in Airflow overall, handling the actual task execution - where
executor is controlled by the
+scheduler.
-Airflow itself is agnostic to what you're running - it will happily
orchestrate and run anything, either with high-level support from one of our
providers, or directly as a command using the shell or Python :doc:`operators`.
+Airflow itself is agnostic to what you're running - it will happily
orchestrate and run anything,
+either with high-level support from one of our providers, or directly as a
command using the shell
Review Comment:
Would add links here to the providers packages and specific operators
mentioned.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
