标签归档:apache

Python Web框架,WSGI和CGI如何结合在一起

问题:Python Web框架,WSGI和CGI如何结合在一起

我有一个Bluehost帐户,可以在其中运行Python脚本作为CGI。我猜这是最简单的CGI,因为要运行,我必须在中定义以下内容.htaccess

Options +ExecCGI
AddType text/html py
AddHandler cgi-script .py

现在,每当我使用Python查找Web编程时,我都会听到很多关于WSGI以及大多数框架如何使用它的知识。但是我只是不明白它们之间的关系如何,特别是当我的Web服务器(在主机上运行Apache)并且没有我真正可以使用的东西(定义.htaccess命令除外)时尤其如此。

WSGI,CGI和框架如何连接?我想在基本的CGI配置上运行Web框架(例如web.pyCherryPy),该怎么办?如何安装WSGI支持?

I have a Bluehost account where I can run Python scripts as CGI. I guess it’s the simplest CGI, because to run I have to define the following in .htaccess:

Options +ExecCGI
AddType text/html py
AddHandler cgi-script .py

Now, whenever I look up web programming with Python, I hear a lot about WSGI and how most frameworks use it. But I just don’t understand how it all fits together, especially when my web server is given (Apache running at a host’s machine) and not something I can really play with (except defining .htaccess commands).

How are WSGI, CGI, and the frameworks all connected? What do I need to know, install, and do if I want to run a web framework (say web.py or CherryPy) on my basic CGI configuration? How to install WSGI support?


回答 0

WSGI,CGI和框架如何连接?

Apache侦听端口80。它获取HTTP请求。它解析请求以找到一种响应方式。Apache有很多可供选择的响应方式。一种响应方式是使用CGI运行脚本。另一种响应方式是简单地提供文件。

对于CGI,Apache准备一个环境并通过CGI协议调用脚本。这是标准的Unix Fork / Exec情况-CGI子进程继承了包括套接字和标准输出的OS环境。CGI子进程编写一个响应,该响应可以返回到Apache。Apache将此响应发送到浏览器。

CGI是原始且令人讨厌的。主要是因为它为每个请求派生一个子流程,并且该子流程必须退出或关闭stdout和stderr来表示响应结束。

WSGI是基于CGI设计模式的接口。它不一定是CGI,也不必为每个请求派生一个子进程。可以是CGI,但不一定如此。

WSGI以几种重要方式添加到CGI设计模式中。它为您解析HTTP请求标头,并将其添加到环境中。它提供任何面向POST的输入,作为环境中的类似文件的对象。它还为您提供了可以制定响应的功能,从而使您免于许多格式设置细节。

如果要在基本CGI配置上运行Web框架(例如web.py或cherrypy),我需要知道/安装/做什么?

回想一下,分叉子过程很昂贵。有两种方法可以解决此问题。

  1. 在Apache中嵌入mod_wsgimod_python嵌入Python;没有分叉的过程。Apache直接运行Django应用程序。

  2. 守护程序, mod_wsgimod_fastcgi允许Apache使用WSGI协议与单独的守护程序(或“长时间运行的进程”)进行交互。您启动长期运行的Django进程,然后配置Apache的mod_fastcgi与该进程进行通信。

请注意,它mod_wsgi可以在两种模式下工作:嵌入式或守护程序。

当您阅读mod_fastcgi时,您会发现Django使用flup从mod_fastcgi提供的信息创建与WSGI兼容的接口。管道的工作原理是这样的。

Apache -> mod_fastcgi -> FLUP (via FastCGI protocol) -> Django (via WSGI protocol)

Django为各种接口提供了多个“ django.core.handlers”。

对于mod_fastcgi,Django提供了一个manage.py runfcgi集成FLUP和处理程序的。

对于mod_wsgi,有一个核心处理程序。

如何安装WSGI支持?

请遵循以下说明。

https://code.google.com/archive/p/modwsgi/wikis/IntegrationWithDjango.wiki

对于背景,请参阅此

http://docs.djangoproject.com/en/dev/howto/deployment/#howto-deployment-index

How WSGI, CGI, and the frameworks are all connected?

Apache listens on port 80. It gets an HTTP request. It parses the request to find a way to respond. Apache has a LOT of choices for responding. One way to respond is to use CGI to run a script. Another way to respond is to simply serve a file.

In the case of CGI, Apache prepares an environment and invokes the script through the CGI protocol. This is a standard Unix Fork/Exec situation — the CGI subprocess inherits an OS environment including the socket and stdout. The CGI subprocess writes a response, which goes back to Apache; Apache sends this response to the browser.

CGI is primitive and annoying. Mostly because it forks a subprocess for every request, and subprocess must exit or close stdout and stderr to signify end of response.

WSGI is an interface that is based on the CGI design pattern. It is not necessarily CGI — it does not have to fork a subprocess for each request. It can be CGI, but it doesn’t have to be.

WSGI adds to the CGI design pattern in several important ways. It parses the HTTP Request Headers for you and adds these to the environment. It supplies any POST-oriented input as a file-like object in the environment. It also provides you a function that will formulate the response, saving you from a lot of formatting details.

What do I need to know / install / do if I want to run a web framework (say web.py or cherrypy) on my basic CGI configuration?

Recall that forking a subprocess is expensive. There are two ways to work around this.

  1. Embedded mod_wsgi or mod_python embeds Python inside Apache; no process is forked. Apache runs the Django application directly.

  2. Daemon mod_wsgi or mod_fastcgi allows Apache to interact with a separate daemon (or “long-running process”), using the WSGI protocol. You start your long-running Django process, then you configure Apache’s mod_fastcgi to communicate with this process.

Note that mod_wsgi can work in either mode: embedded or daemon.

When you read up on mod_fastcgi, you’ll see that Django uses flup to create a WSGI-compatible interface from the information provided by mod_fastcgi. The pipeline works like this.

Apache -> mod_fastcgi -> FLUP (via FastCGI protocol) -> Django (via WSGI protocol)

Django has several “django.core.handlers” for the various interfaces.

For mod_fastcgi, Django provides a manage.py runfcgi that integrates FLUP and the handler.

For mod_wsgi, there’s a core handler for this.

How to install WSGI support?

Follow these instructions.

https://code.google.com/archive/p/modwsgi/wikis/IntegrationWithDjango.wiki

For background see this

http://docs.djangoproject.com/en/dev/howto/deployment/#howto-deployment-index


回答 1

我认为Florian的答案回答了您有关“ WSGI是什么”的部分问题,特别是如果您阅读了PEP

至于您即将提出的问题:

WSGI,CGI,FastCGI等都是Web服务器运行代码并传递产生的动态内容的协议。与此相比,静态Web服务基本上是将纯HTML文件原样发送到客户端的静态Web服务。

CGI,FastCGI和SCGI与语言无关。您可以用Perl,Python,C,bash等编写CGI脚本。CGI 根据URL 定义将调用哪个可执行文件,以及如何调用它:参数和环境。它还定义了可执行文件完成后应如何将返回值传递回Web服务器。这些变化基本上是优化的,以便能够处理更多请求,减少延迟等。基本概念是相同的。

WSGI仅适用于Python。定义了标准功能签名,而不是语言无关协议:

def simple_app(environ, start_response):
    """Simplest possible application object"""
    status = '200 OK'
    response_headers = [('Content-type','text/plain')]
    start_response(status, response_headers)
    return ['Hello world!\n']

那是一个完整的(如果有限制的话)WSGI应用程序。具有WSGI支持的Web服务器(例如具有mod_wsgi的Apache)可以在请求到达时调用此功能。

之所以如此出色,是因为我们可以避免从HTTP GET / POST转换为CGI再转换为Python的繁琐步骤,并在退出过程中再次返回。这是一种更加直接,干净和有效的链接。

如果需要对请求进行的所有操作都是函数调用,那么使长时间运行的框架在Web服务器后运行也变得更加容易。使用普通的CGI,您必须为每个单独的请求启动整个框架

要获得WSGI支持,您需要安装WSGI模块(如mod_wsgi),或使用带有WSGI嵌入的Web服务器(如CherryPy)。如果两者都不可行,则可以使用PEP中提供的CGI-WSGI桥。

I think Florian’s answer answers the part of your question about “what is WSGI”, especially if you read the PEP.

As for the questions you pose towards the end:

WSGI, CGI, FastCGI etc. are all protocols for a web server to run code, and deliver the dynamic content that is produced. Compare this to static web serving, where a plain HTML file is basically delivered as is to the client.

CGI, FastCGI and SCGI are language agnostic. You can write CGI scripts in Perl, Python, C, bash, whatever. CGI defines which executable will be called, based on the URL, and how it will be called: the arguments and environment. It also defines how the return value should be passed back to the web server once your executable is finished. The variations are basically optimisations to be able to handle more requests, reduce latency and so on; the basic concept is the same.

WSGI is Python only. Rather than a language agnostic protocol, a standard function signature is defined:

def simple_app(environ, start_response):
    """Simplest possible application object"""
    status = '200 OK'
    response_headers = [('Content-type','text/plain')]
    start_response(status, response_headers)
    return ['Hello world!\n']

That is a complete (if limited) WSGI application. A web server with WSGI support (such as Apache with mod_wsgi) can invoke this function whenever a request arrives.

The reason this is so great is that we can avoid the messy step of converting from a HTTP GET/POST to CGI to Python, and back again on the way out. It’s a much more direct, clean and efficient linkage.

It also makes it much easier to have long-running frameworks running behind web servers, if all that needs to be done for a request is a function call. With plain CGI, you’d have to start your whole framework up for each individual request.

To have WSGI support, you’ll need to have installed a WSGI module (like mod_wsgi), or use a web server with WSGI baked in (like CherryPy). If neither of those are possible, you could use the CGI-WSGI bridge given in the PEP.


回答 2

如Pep333所示,您可以在CGI上运行WSGI。但是,每次有一个请求时,都会启动一个新的Python解释器,并且需要构建整个上下文(数据库连接等),这都需要时间。

如果要运行WSGI,最好的方法是主机安装mod_wsgi并进行适当的配置以将控制权交给您的应用程序。

对于任何会说FCGISCGI或AJP的Web服务器,Flup是与WSGI一起运行的另一种方式。根据我的经验,只有FCGI确实有效,并且可以通过mod_fastcgi在Apache中使用它,或者可以通过mod_proxy_fcgi运行单独的Python守护程序。

WSGI是与CGI非常相似的协议,它定义了一组Web服务器和Python代码如何交互的规则,其定义为Pep333。这使得许多不同的Web服务器可以使用同一应用程序协议来使用许多不同的框架和应用程序。这是非常有益的,并使其非常有用。

You can run WSGI over CGI as Pep333 demonstrates as an example. However every time there is a request a new Python interpreter is started and the whole context (database connections, etc.) needs to be build which all take time.

The best if you want to run WSGI would be if your host would install mod_wsgi and made an appropriate configuration to defer control to an application of yours.

Flup is another way to run with WSGI for any webserver that can speak FCGI, SCGI or AJP. From my experience only FCGI really works, and it can be used in Apache either via mod_fastcgi or if you can run a separate Python daemon with mod_proxy_fcgi.

WSGI is a protocol much like CGI, which defines a set of rules how webserver and Python code can interact, it is defined as Pep333. It makes it possible that many different webservers can use many different frameworks and applications using the same application protocol. This is very beneficial and makes it so useful.


回答 3

如果您不清楚这个领域中的所有术语,并且让我们直面它,这是一个令人困惑的首字母缩写词,那么还有一个很好的背景阅读器,形式为官方python HOWTO,其中讨论了CGI,FastCGI,WSGI等。上:http : //docs.python.org/howto/webservers.html

If you are unclear on all the terms in this space, and lets face it, its a confusing acronym-laden one, there’s also a good background reader in the form of an official python HOWTO which discusses CGI vs. FastCGI vs. WSGI and so on: http://docs.python.org/howto/webservers.html


回答 4

这是用于Python的简单抽象层,类似于Servlet规范用于Java。尽管CGI确实是低级的,只是将内容转储到流程环境和标准输入/输出中,但是以上两个规范将http请求和响应建模为该语言的构造。但是,我的印象是,在Python中,人们还不太习惯实际的实现,因此您混合使用了参考实现和其他提供WSGI支持(例如Paste)的实用程序类型的库。当然,我可能是错的,我是Python的新手。“网络脚本”社区正从不同的方向提出问题(共享托管,CGI旧版,

It’s a simple abstraction layer for Python, akin to what the Servlet spec is for Java. Whereas CGI is really low level and just dumps stuff into the process environment and standard in/out, the above two specs model the http request and response as constructs in the language. My impression however is that in Python folks have not quite settled on de-facto implementations so you have a mix of reference implementations, and other utility-type libraries that provide other things along with WSGI support (e.g. Paste). Of course I could be wrong, I’m a newcomer to Python. The “web scripting” community is coming at the problem from a different direction (shared hosting, CGI legacy, privilege separation concerns) than Java folks had the luxury of starting with (running a single enterprise container in a dedicated environment against statically compiled and deployed code).


代码更改后自动重新加载python Flask应用

问题:代码更改后自动重新加载python Flask应用

我正在研究如何使用Python开发像样的Web应用程序。由于我不希望遇到一些高级结构,因此我选择了轻量级的Flask框架。时间会证明这是否是正确的选择。

因此,现在我已经使用mod_wsgi设置了Apache服务器,并且我的测试站点运行正常。但是,我想通过使我对py或模板文件进行的任何更改自动重新加载网站,从而加快开发流程。我看到站点的.wsgi文件中的任何更改都会导致重新加载(即使在apache配置文件中没有WSGIScriptReloading On的情况下),但我仍然必须手动进行操作(即,插入额外的换行符,保存)。编辑某些应用的py文件时,有什么方法可以引起重新加载?还是希望我使用IDE来刷新.wsgi文件?

I’m investigating how to develop a decent web app with Python. Since I don’t want some high-order structures to get in my way, my choice fell on the lightweight Flask framework. Time will tell if this was the right choice.

So, now I’ve set up an Apache server with mod_wsgi, and my test site is running fine. However, I’d like to speed up the development routine by making the site automatically reload upon any changes in py or template files I make. I see that any changes in site’s .wsgi file causes reloading (even without WSGIScriptReloading On in the apache config file), but I still have to prod it manually (ie, insert extra linebreak, save). Is there some way how to cause reload when I edit some of the app’s py files? Or, I am expected to use IDE that refreshes the .wsgi file for me?


回答 0

当前推荐的方法是使用flask命令行实用程序。

https://flask.palletsprojects.com/zh-CN/1.1.x/quickstart/#debug-mode

例:

$ export FLASK_APP=main.py
$ export FLASK_ENV=development
$ flask run

或在一个命令中:

$ FLASK_APP=main.py FLASK_ENV=development flask run

如果您想要的端口与默认(5000)添加--port选项不同。

例:

$ FLASK_APP=main.py FLASK_ENV=development flask run --port 8080

更多选项可用于:

$ flask run --help

The current recommended way is with the flask command line utility.

https://flask.palletsprojects.com/en/1.1.x/quickstart/#debug-mode

Example:

$ export FLASK_APP=main.py
$ export FLASK_ENV=development
$ flask run

or in one command:

$ FLASK_APP=main.py FLASK_ENV=development flask run

If you want different port than the default (5000) add --port option.

Example:

$ FLASK_APP=main.py FLASK_ENV=development flask run --port 8080

More options are available with:

$ flask run --help

回答 1

如果您在谈论测试/开发环境,则只需使用debug选项。发生代码更改时,它将自动重新加载flask应用程序。

app.run(debug=True)

或者,从外壳:

$ export FLASK_DEBUG=1
$ flask run

http://flask.pocoo.org/docs/quickstart/#debug-mode

If you are talking about test/dev environments, then just use the debug option. It will auto-reload the flask app when a code change happens.

app.run(debug=True)

Or, from the shell:

$ export FLASK_DEBUG=1
$ flask run

http://flask.pocoo.org/docs/quickstart/#debug-mode


回答 2

在测试/开发环境中

werkzeug调试器已经具有“自动重新加载”功能,可以通过执行以下任一操作来启用该功能:

app.run(debug=True)

要么

app.debug = True

如果需要,还可以使用单独的配置文件来管理所有设置。例如,我将’settings.py’与’DEBUG = True’选项一起使用。导入该文件也很容易。

app.config.from_object('application.settings')

但是,这不适用于生产环境。

生产环境

我个人选择Nginx + uWSGI而不是Apache + mod_wsgi是出于一些性能原因以及配置选项。该触摸重装选项允许你指定一个文件/文件夹会导致uWSGI应用程序重新加载新部署的烧瓶应用。

例如,您的更新脚本会下拉您的最新更改并触摸’reload_me.txt’文件。您的uWSGI ini脚本(由Supervisord保留-显然)在某处包含以下行:

touch-reload = '/opt/virtual_environments/application/reload_me.txt'

我希望这有帮助!

In test/development environments

The werkzeug debugger already has an ‘auto reload’ function available that can be enabled by doing one of the following:

app.run(debug=True)

or

app.debug = True

You can also use a separate configuration file to manage all your setup if you need be. For example I use ‘settings.py’ with a ‘DEBUG = True’ option. Importing this file is easy too;

app.config.from_object('application.settings')

However this is not suitable for a production environment.

Production environment

Personally I chose Nginx + uWSGI over Apache + mod_wsgi for a few performance reasons but also the configuration options. The touch-reload option allows you to specify a file/folder that will cause the uWSGI application to reload your newly deployed flask app.

For example, your update script pulls your newest changes down and touches ‘reload_me.txt’ file. Your uWSGI ini script (which is kept up by Supervisord – obviously) has this line in it somewhere:

touch-reload = '/opt/virtual_environments/application/reload_me.txt'

I hope this helps!


回答 3

如果您正在使用uwsgi运行,请查看python自动重载选项:

uwsgi --py-autoreload 1

示例uwsgi-dev-example.ini:

[uwsgi]
socket = 127.0.0.1:5000
master = true
virtualenv = /Users/xxxx/.virtualenvs/sites_env
chdir = /Users/xxx/site_root
module = site_module:register_debug_server()
callable = app
uid = myuser
chmod-socket = 660
log-date = true
workers = 1
py-autoreload = 1

site_root / __ init__.py

def register_debug_server():
    from werkzeug.debug import DebuggedApplication

    app = Flask(__name__)
    app.debug = True
    app = DebuggedApplication(app, evalex=True)
    return app

然后运行:

uwsgi --ini uwsgi-dev-example.ini

注意:此示例还启用调试器。

我通过Nginx设置尽可能地模仿生产。仅在Nginx后面的内置Web服务器中运行flask应用程序时,就会导致严重的网关错误。

If you’re running using uwsgi look at the python auto reload option:

uwsgi --py-autoreload 1

Example uwsgi-dev-example.ini:

[uwsgi]
socket = 127.0.0.1:5000
master = true
virtualenv = /Users/xxxx/.virtualenvs/sites_env
chdir = /Users/xxx/site_root
module = site_module:register_debug_server()
callable = app
uid = myuser
chmod-socket = 660
log-date = true
workers = 1
py-autoreload = 1

site_root/__init__.py

def register_debug_server():
    from werkzeug.debug import DebuggedApplication

    app = Flask(__name__)
    app.debug = True
    app = DebuggedApplication(app, evalex=True)
    return app

Then run:

uwsgi --ini uwsgi-dev-example.ini

Note: This example also enables the debugger.

I went this route to mimic production as close as possible with my nginx setup. Simply running the flask app with it’s built in web server behind nginx it would result in a bad gateway error.


回答 4

Flask 1.0及更高版本的一些更新

热重装的基本方法是:

$ export FLASK_APP=my_application
$ export FLASK_ENV=development
$ flask run
  • 您应该使用FLASK_ENV=development(不是FLASK_DEBUG=1
  • 作为安全检查,您可以运行 flask run --debugger以确保已将其打开
  • Flask CLI现在会自动读取以下内容FLASK_APPFLASK_ENV如果.env项目根目录中文件并且安装了python-dotenv

A few updates for Flask 1.0 and above

the basic approach to hot re-loading is:

$ export FLASK_APP=my_application
$ export FLASK_ENV=development
$ flask run
  • you should use FLASK_ENV=development (not FLASK_DEBUG=1)
  • as a safety check, you can run flask run --debugger just to make sure it’s turned on
  • the Flask CLI will now automatically read things like FLASK_APP and FLASK_ENV if you have an .env file in the project root and have python-dotenv installed

回答 5

我有一个不同的主意:

第一:

pip install python-dotenv

安装python-dotenv模块,该模块将读取您的项目环境的本地首选项。

第二:

.flaskenv在您的项目目录中添加文件。添加以下代码:

FLASK_ENV=development

完成!

使用Flask项目的此配置,当您运行时flask run,您将在终端中看到以下输出:

当您编辑文件时,只需保存更改即可。您会看到自动重新加载在那里:

详细说明:

当然,您可以export FLASK_ENV=development在需要时手动点击。但是使用不同的配置文件来处理实际的工作环境似乎是一个更好的解决方案,因此我强烈建议我使用此方法。

I got a different idea:

First:

pip install python-dotenv

Install the python-dotenv module, which will read local preference for your project environment.

Second:

Add .flaskenv file in your project directory. Add following code:

FLASK_ENV=development

It’s done!

With this config for your Flask project, when you run flask run and you will see this output in your terminal:

And when you edit your file, just save the change. You will see auto-reload is there for you:

With more explanation:

Of course you can manually hit export FLASK_ENV=development every time you need. But using different configuration file to handle the actual working environment seems like a better solution, so I strongly recommend this method I use.


回答 6

Flask应用程序可以选择在调试模式下执行。在这种模式下,默认情况下启用了开发服务器的两个非常方便的模块,分别称为重载调试器。启用重新加载器后,Flask会监视项目的所有源代码文件,并在修改任何文件时自动重新启动服务器。

默认情况下,调试模式是禁用的。要启用它,FLASK_DEBUG=1在调用flask之前设置一个环境变量run

(venv) $ export FLASK_APP=hello.py for Windows use > set FLASK_APP=hello.py

(venv) $ export FLASK_DEBUG=1 for Windows use > set FLASK_DEBUG=1

(venv) $ flask run

* Serving Flask app "hello"
* Forcing debug mode on
* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
* Restarting with stat
* Debugger is active!
* Debugger PIN: 273-181-528

在开发过程中,启用启用重新加载程序的服务器非常有用,因为每次修改和保存源文件时,服务器都会自动重新启动并获取更改。

Flask applications can optionally be executed in debug mode. In this mode, two very convenient modules of the development server called the reloader and the debugger are enabled by default. When the reloader is enabled, Flask watches all the source code files of your project and automatically restarts the server when any of the files are modified.

By default, debug mode is disabled. To enable it, set a FLASK_DEBUG=1 environment variable before invoking flask run:

(venv) $ export FLASK_APP=hello.py for Windows use > set FLASK_APP=hello.py

(venv) $ export FLASK_DEBUG=1 for Windows use > set FLASK_DEBUG=1

(venv) $ flask run

* Serving Flask app "hello"
* Forcing debug mode on
* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
* Restarting with stat
* Debugger is active!
* Debugger PIN: 273-181-528

Having a server running with the reloader enabled is extremely useful during development, because every time you modify and save a source file, the server automatically restarts and picks up the change.


回答 7

要在PyCharm中实现这一目标,请将“环境变量”部分设置为:

PYTHONUNBUFFERED=1;
FLASK_DEBUG=1

对于Flask的“运行/调试配置”。

To achieve this in PyCharm set ‘Environment Variables’ section to:

PYTHONUNBUFFERED=1;
FLASK_DEBUG=1

For Flask ‘run / debug configurations’.


Zulip-Zulip服务器和web应用-功能强大的开源团队聊天

Zulip概述

Zulip是一款功能强大的开源群聊应用程序,它结合了实时聊天的即时性和线程化对话的生产力优势。Zulip被开源项目、财富500强公司、大型标准机构和其他需要实时聊天系统的人使用,该系统允许用户每天轻松处理数百或数千条消息。每月有700多名贡献者合并500多条提交,Zulip也是规模最大、增长最快的开源群聊项目

快速入门

单击下面的相应链接。如果什么都不适用,请加入我们的Zulip community server告诉我们怎么回事!

您可能会对以下内容感兴趣:

您可能还会有兴趣阅读我们的blog或者跟着我们走TwitterZulip分布在Apache 2.0许可证

Airflow-Apache Airflow 以编程方式创作、调度和监控工作流的平台

Apache Airflow(或简称Airflow)是以编程方式创作、计划和监控工作流的平台

将工作流定义为代码后,它们将变得更具可维护性、可版本化、可测试性和协作性

使用Airflow将工作流创作为任务的有向无环图(DAG)。气流调度器在遵循指定依赖关系的同时对一组工作人员执行任务。丰富的命令行实用程序使在DAG上执行复杂操作变得轻而易举。丰富的用户界面使您可以轻松地可视化生产中运行的管道、监控进度以及在需要时排除问题故障

目录

项目重点

气流与主要为静电且变化缓慢的工作流配合使用效果最好。当DAG结构从一次运行到下一次运行类似时,它允许围绕工作单元和连续性保持清晰。其他类似的项目包括LuigiOozieAzkaban

Airflow通常用于处理数据,但认为任务理想上应该是幂等的(即,任务的结果将是相同的,并且不会在目标系统中创建重复数据),并且不应该将大量数据从一个任务传递到下一个任务(尽管任务可以使用Airflow的传递元数据Xcom feature)。对于大容量、数据密集型任务,最佳做法是将任务委托给专门从事该类型工作的外部服务

Airflow不是一种流解决方案,但它通常用于处理实时数据,成批地将数据从流中拉出

原则

  • 动态的:气流管道配置为代码(Python),允许动态生成管道。这允许编写动态实例化管道的代码
  • 可扩展的:轻松定义您自己的运算符、执行器和扩展库,使其符合适合您的环境的抽象级别
  • 优雅的:气流管道是精干而清晰的。将脚本参数化内置到气流的核心中,使用功能强大的金家模板引擎
  • 可扩展:Airflow采用模块化架构,并使用消息队列来编排任意数量的工作人员

要求

Apache Airflow使用以下各项进行测试:

主版本(Dev) 稳定版本(2.1.1)
python 3.6、3.7、3.8、3.9 3.6、3.7、3.8
库伯内斯 1.20、1.19、1.18 1.20、1.19、1.18
PostgreSQL 9.6、10、11、12、13 9.6、10、11、12、13
MySQL 5.7,8 5.7,8
SQLite 3.15.0+ 3.15.0+
MSSQL(试验性) 2017、2019年

注:MySQL5.x版本不能运行多个调度程序或有限制–请参阅Scheduler docs未测试/推荐使用MariaDB

注:SQLite用于气流测试。请不要在生产中使用它。我们建议使用SQLite的最新稳定版本进行本地开发

快速入门

访问Airflow官方网站文档(最新稳定版本)以获取以下方面的帮助installing Airflowgetting started,或通过更完整的tutorial

注意:如果您正在查找主分支(最新开发分支)的文档:您可以在s.apache.org/airflow-docs

有关气流改善建议(AIP)的更多信息,请访问Airflow Wiki

相关项目的文档,如提供程序包、Docker映像、Helm Chart,您可以在the documentation index

从PyPI安装

我们将Apache Airflow发布为apache-airflowPyPI格式的包。然而,安装它有时可能会很棘手,因为Airflow既是一个库,也是一个应用程序。库通常使它们的依赖项保持打开,而应用程序通常将它们钉住,但是我们不应该同时做这两件事。我们决定使我们的依赖项尽可能地开放(在setup.py),因此如果需要,用户可以安装不同版本的库。这就是说,时不时地,明摆着pip install apache-airflow将无法工作或将产生无法使用的气流安装

但是,为了实现可重复安装,我们还在孤儿中保留了一组“已知可以工作”的约束文件constraints-mainconstraints-2-0树枝。对于每个主要/次要Python版本,我们将那些“已知正在工作”的约束文件分开保存。从PyPI安装气流时,可以将它们用作约束文件。请注意,您必须在URL中指定正确的气流标签/版本/分支和Python版本

  1. 仅安装气流:

注:仅限pip目前官方支持安装

虽然他们使用其他工具(如poetrypip-tools,它们共享的工作流不同于pip-尤其是在约束与需求管理方面。通过以下方式安装Poetrypip-tools当前不支持

如果要使用这些工具安装气流,则应使用约束文件并将其转换为工具所需的适当格式和工作流

pip install apache-airflow==2.1.1 \
 --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.1.1/constraints-3.7.txt"
  1. 使用附加软件安装(例如Postgres、Google)
pip install apache-airflow[postgres,google]==2.1.1 \
 --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.1.1/constraints-3.7.txt"

有关安装提供程序包的信息,请查看providers

官方源代码

阿帕奇气流是一种Apache Software Foundation(ASF)项目,我们的官方源代码发布:

遵循ASF规则,发布的源包必须足以让用户构建和测试版本,前提是他们可以访问适当的平台和工具

便利套餐

还有其他安装和使用气流的方法。这些都是“方便”的方法–它们不是“官方发布”,正如ASF Release Policy,但是它们可以由不想自己构建软件的用户使用

这些是-按照人们安装气流的最常见方式的顺序:

  • PyPI releases使用标准安装风量的步骤pip工具
  • Docker Images要通过以下方式安装风量,请执行以下操作docker工具,在Kubernetes,Helm图表中使用它们,docker-composedocker swarm等。您可以在中阅读有关使用、自定义和扩展图像的更多信息Latest docs中的内部结构的详细信息。IMAGES.rst文档
  • Tags in GitHub要检索用于通过git生成官方源码包的git项目源代码,请执行以下操作:

所有这些工件都不是官方发布的,但它们都是使用官方发布的来源准备的。其中一些工件是“开发”或“预发布”的,它们按照ASF政策被清楚地标记为“开发”或“预发布”

用户界面

  • DAGS:环境中所有DAG的概述

  • :跨时间的DAG的树表示形式

  • 图表:可视化特定运行的DAG依赖项及其当前状态

  • 任务工期:一段时间内花在不同任务上的总时间

  • 甘特图:DAG的持续时间和重叠

  • 代码:查看DAG源代码的快捷方式

语义版本化

从Airflow 2.0.0开始,我们支持严格SemVer适用于已发布的所有软件包的方法

我们几乎没有达成一致的特定规则来定义不同包的版本控制细节:

  • 气流:SemVer规则仅适用于核心气流(不包括对供应商的任何更改)。更改气流依赖性版本的限制本身并不是突破性的更改
  • 气流供应器:SemVer规则仅适用于特定提供程序代码中的更改。软件包的SemVer主要版本和次要版本独立于气流版本。例如google 4.1.0amazon 3.0.3提供程序可以随同安装在一起Airflow 2.1.1如果提供程序和气流包之间存在交叉依赖限制,则它们在提供程序中显示为install_requires限制。我们的目标是保持供应商与之前发布的所有Airflow 2版本的向后兼容性,但有时会有突破性的更改,这可能会使一些或所有供应商指定最低气流版本。更改最低支持气流版本对提供商来说是一项突破性更改,因为安装新提供商可能会自动升级气流(这可能是升级提供商的不良副作用)
  • 气流舵图:SemVer规则仅适用于图表中的更改。该图表的SemVer主要版本和次要版本独立于气流版本。我们的目标是保持头盔图表与所有发布的Airflow 2版本的向后兼容性,但一些新功能可能只能从特定的Airlfow版本开始工作。但是,我们可能会将舵图限制为依赖于最小气流版本
  • Airflow API客户端:SemVer主要版本和次要版本跟随气流的主要版本和次要版本。气流的第一个主要或次要X.Y.0版本之后应始终跟随所有客户端的X.Y.0版本。然后,客户端可以独立于气流补丁版本,发布其自己的带有错误修复的补丁版本

版本生命周期

Apache Airflow版本生命周期:

版本 当前修补程序/次要修补程序 状态 第一个版本 有限的支持 停产/终止
2个 2.1.1 支持 2020年12月17日 2021年12月 待定
1.10 1.10.15 停产 2018年8月27日 2020年12月17日 2021年6月17日
1.9 1.9.0 停产 2018年1月03日 2018年8月27日 2018年8月27日
1.8 1.8.2 停产 2017年3月19日 2018年1月03日 2018年1月03日
1.7 1.7.1.2 停产 2016年3月28日 2017年3月19日 2017年3月19日

有限的支持版本将仅受安全和关键错误修复支持。EOL版本将不会得到任何修复,也不会获得支持。我们始终建议所有用户针对正在使用的任何主要版本运行最新的可用次要版本。我们高度建议在最早方便的时间并在停产日期之前升级到最新的Airflow主要版本

支持Python和Kubernetes版本

从AirFlow2.0开始,我们同意使用某些规则来支持Python和Kubernetes。它们基于Python和Kubernetes的官方发布时间表,在Python Developer’s GuideKubernetes version skew policy

  1. 当Python和Kubernetes版本达到EOL时,我们不再支持它们。我们在EOL日期之后立即在Main中取消对这些EOL版本的支持,当我们发布第一个新的次要版本(或如果没有新的次要版本,则为主要版本)时,它将被有效地删除。例如,对于Python 3.6,这意味着我们在2021年12月23日之后立即在Main中停止支持,并且在此之后发布的第一个主要或次要版本将不会包含它
  2. 支持Python/Kubernetes的“最旧”版本是默认版本。“默认”仅在使用DockerHub中提供的此默认版本和默认参考图像运行的配置项PR中的“冒烟测试”方面有意义。目前apache/airflow:latestapache/airflow:2.1.1图像都是Python 3.6图像,但是,2021年12月23日之后的Airflow版本的第一个次要/主要版本将成为Python 3.7图像
  3. 正式发布后,我们在Main中支持新版本的Python/Kubernetes,一旦我们让它们在我们的CI管道中工作(这可能不是立即进行的,因为大多数情况下依赖于Python的新版本),我们就会基于工作CI设置发布新的图像/Airflow中的支持

有关Python版本要求的其他说明

  • 以前的版本requires使用Python 3时至少使用Python 3.5.3

贡献

想要帮助构建Apache Airflow吗?请查看我们的contributing documentation

中描述了Apache Airflow的官方Docker(容器)图像IMAGES.rst

谁使用Apache Airflow?

400多个组织正在使用Apache Airflowin the wild

谁维护阿帕奇气流?

气流是community,但是core committers/maintainers负责审核和合并PR,并围绕新功能请求指导对话。如果您想成为一名维护员,请查看Apache Airflowcommitter requirements

我可以在演示文稿中使用Apache Airflow徽标吗?

是!一定要遵守阿帕奇基金会trademark policies和阿帕奇气流Brandbook有关最新徽标的信息,请参阅this repo和Apache软件基金会website

气流商品

如果你想要阿帕奇气流贴纸、t恤等,那就去看看吧。Redbubble Shop

链接

赞助商

Apache Airflow的CI基础设施由以下各方赞助:


Superset-Apache Superset是一个数据可视化和数据探索平台

现代的、企业就绪的商业智能Web应用程序

为什么是超集?

超集提供:

  • 用于可视化数据集和制作交互式仪表板的直观界面
  • 一系列精美的可视化效果,可展示您的数据
  • 用于提取和显示数据集的无代码可视化构建器
  • 世界级的SQL IDE,用于准备用于可视化的数据,包括丰富的元数据浏览器
  • 轻量级语义层,使数据分析师能够快速定义自定义维度和指标
  • 对大多数SQL语言数据库的开箱即用支持
  • 无缝的内存中异步缓存和查询
  • 一种可扩展的安全模型,允许配置关于谁可以访问哪些产品功能和数据集的非常复杂的规则
  • 与主要身份验证后端(数据库、OpenID、LDAP、OAUTH、REMOTE_USER等)集成
  • 能够添加自定义可视化插件
  • 用于编程自定义的API
  • 从头开始为规模而设计的云原生架构

支持的数据库

超集可以从任何使用SQL语言的数据存储或数据引擎(例如,Presto或Athena)查询具有Python DB-API驱动程序和SQLAlChemy方言的数据

更全面的支持数据库列表以及配置说明可以找到:here

想要添加对您的数据存储区或数据引擎的支持吗?阅读更多内容here关于技术要求

安装和配置

Extended documentation for Superset

参与进来吧

投稿人指南

有兴趣做贡献吗?请查看我们的CONTRIBUTING.md查找有关贡献的资源,以及有关如何设置开发环境的详细指南

资源