将一个应用程序用于多个 uwsgi 实例
Use one app for several uwsgi instances
我找到了很多例子来解释我们如何使用uwsgi和emperor模式来实现多应用部署。这对我来说意味着:几个应用程序文件夹,每个应用程序有一个 vassal(ini、套接字、application.py)。
我还没有找到只有一个应用程序文件夹和多个 vassal 的配置示例。这应该允许我为多租户应用程序提供服务(每个客户都有自己的数据库)。我用两个实例对此进行了测试。这 "seems" 很好用。
- 这是一个好的做法还是您有类似的设置?
- 这是否提供了 vassal 实例之间的完全隔离?
这是我的设置。我正在使用 nginx/uwsgi/python 堆栈(我使用 emperor_pg module)。此设置允许 uwsgi 为每个客户 A 和 B 生成一个 vassal。客户正在使用 url : customerN.mydomain.com/fe1/web
Nginx 配置:
# This virtual host catches all incoming traffic from port 80 (security should be considered if not talking on local
# network)
server {
listen 80;
# We capture here the subdomain. It is used to designate a customer entity.
server_name ~^(?<subdomain>.+)\.mydomain\.fr$;
# We use a pattern for creating sockets name and path.
# This allows to spawn vassals automatically by detecting changes in the vassals pg table (emperor_pg)
# Pattern used is : /tmp/$subdomain$appname.sock
location ~favicon\.ico$ {
root /opt/app-current/web/;
}
location ~^\/(?<app_name>.+)\/web\/ {
root /opt/web-content/$subdomain/;
}
location ~^\/(?<app_name>.+)\/ {
# Routing to socket designated by standard pattern
include uwsgi_params;
uwsgi_pass unix://tmp/$subdomain$app_name.sock;
}
# When calling root of entity's subdomain, we launch the default app by routing traffic to index.socket
location / {
include uwsgi_params;
uwsgi_pass unix://tmp/$subdomain.sock;
}
}
皇帝新贵脚本使用emperor_pg:
# Emperor configuration upstart script in `/etc/init/uwsgi.conf` :
# uWSGI - Manage uWSGI Application Server
description "uWSGI Emperor Mode"
start on (filesystem and net-device-up IFACE=lo)
stop on runlevel [!2345]
respawn
# We use pg mode. This allows to scan a postgresql database.
# requires sudo apt-get install uwsgi-plugin-emperor-pg
exec /usr/bin/uwsgi --uid www-data --gid www-data --plugin emperor_pg --emperor "pg://host=dbserver.com.com user=saasautomator dbname=saasautomator;SELECT name,config,ts,uid,gid,socket FROM vassals" --logto /var/log/uwsgi.log
以及数据库中 vassals 配置文件的示例。他们使用相同的应用程序文件夹:
saasautomator=> SELECT * FROM vassals;
idvassals | name | config | ts | uid | gid | socket
-----------+---------------------------------+----------------------------------------------------------------+---------------------+-------+-------+---------------------------------------
3 | customerAfe1.ini | [uwsgi] +| 2004-10-19 10:23:54 | uwsgi | uwsgi | /tmp/customerAfe1.sock
| | master = true +| | | |
| | vaccum = true +| | | |
| | chdir = /opt/app/ +| | | |
| | plugins = python +| | | |
| | wsgi-file = /opt/app/fe1/application.py +| | | |
| | processes = 4 +| | | |
| | threads = 2 +| | | |
| | stats = 127.0.0.1:9191 | | | |
4 | customerBfe1.ini | [uwsgi] +| 2004-10-19 10:23:55 | uwsgi | uwsgi | /tmp/customerBfe1.sock
| | master = true +| | | |
| | vaccum = true +| | | |
| | chdir = /opt/app/ +| | | |
| | plugins = python +| | | |
| | wsgi-file = /opt/app/fe1/application.py +| | | |
| | processes = 4 +| | | |
| | threads = 2 +| | | |
| | stats = 127.0.0.1:9192 | | | |
(2 rows)
谢谢!
"Is this a good practice or do you have similar setup ?"
我有类似的设置。我不会回答这是否是好的做法,因为它是基于意见的,但这与为每个客户复制代码库之间存在细微差别。主要区别是:如果有人闯入一个应用程序并且他将能够修改它的代码,它将影响所有应用程序......但是如果应用程序的配置没有差异将允许以这种方式闯入一个,但不是其他-没关系。如果有人闯入一个,他可以在其他人身上复制......
此外,使用共享代码库可以更轻松地修复破解您的应用后所做的更改。
我看不出任何其他重要的区别...
"Does this provide complete isolation between vassals instances ?"
如前所述,不完整,但可以隔离任何其他内容。这就像在系统中的应用程序之间共享一个库,这种情况一直在发生。通过适当的配置,您还可以将数据库和其他资源分开。
如果正确应用文件系统权限,您可以限制自己更改应用程序代码的能力,因此它将限制某些黑客更改代码的能力。
我找到了很多例子来解释我们如何使用uwsgi和emperor模式来实现多应用部署。这对我来说意味着:几个应用程序文件夹,每个应用程序有一个 vassal(ini、套接字、application.py)。
我还没有找到只有一个应用程序文件夹和多个 vassal 的配置示例。这应该允许我为多租户应用程序提供服务(每个客户都有自己的数据库)。我用两个实例对此进行了测试。这 "seems" 很好用。
- 这是一个好的做法还是您有类似的设置?
- 这是否提供了 vassal 实例之间的完全隔离?
这是我的设置。我正在使用 nginx/uwsgi/python 堆栈(我使用 emperor_pg module)。此设置允许 uwsgi 为每个客户 A 和 B 生成一个 vassal。客户正在使用 url : customerN.mydomain.com/fe1/web
Nginx 配置:
# This virtual host catches all incoming traffic from port 80 (security should be considered if not talking on local
# network)
server {
listen 80;
# We capture here the subdomain. It is used to designate a customer entity.
server_name ~^(?<subdomain>.+)\.mydomain\.fr$;
# We use a pattern for creating sockets name and path.
# This allows to spawn vassals automatically by detecting changes in the vassals pg table (emperor_pg)
# Pattern used is : /tmp/$subdomain$appname.sock
location ~favicon\.ico$ {
root /opt/app-current/web/;
}
location ~^\/(?<app_name>.+)\/web\/ {
root /opt/web-content/$subdomain/;
}
location ~^\/(?<app_name>.+)\/ {
# Routing to socket designated by standard pattern
include uwsgi_params;
uwsgi_pass unix://tmp/$subdomain$app_name.sock;
}
# When calling root of entity's subdomain, we launch the default app by routing traffic to index.socket
location / {
include uwsgi_params;
uwsgi_pass unix://tmp/$subdomain.sock;
}
}
皇帝新贵脚本使用emperor_pg:
# Emperor configuration upstart script in `/etc/init/uwsgi.conf` :
# uWSGI - Manage uWSGI Application Server
description "uWSGI Emperor Mode"
start on (filesystem and net-device-up IFACE=lo)
stop on runlevel [!2345]
respawn
# We use pg mode. This allows to scan a postgresql database.
# requires sudo apt-get install uwsgi-plugin-emperor-pg
exec /usr/bin/uwsgi --uid www-data --gid www-data --plugin emperor_pg --emperor "pg://host=dbserver.com.com user=saasautomator dbname=saasautomator;SELECT name,config,ts,uid,gid,socket FROM vassals" --logto /var/log/uwsgi.log
以及数据库中 vassals 配置文件的示例。他们使用相同的应用程序文件夹:
saasautomator=> SELECT * FROM vassals;
idvassals | name | config | ts | uid | gid | socket
-----------+---------------------------------+----------------------------------------------------------------+---------------------+-------+-------+---------------------------------------
3 | customerAfe1.ini | [uwsgi] +| 2004-10-19 10:23:54 | uwsgi | uwsgi | /tmp/customerAfe1.sock
| | master = true +| | | |
| | vaccum = true +| | | |
| | chdir = /opt/app/ +| | | |
| | plugins = python +| | | |
| | wsgi-file = /opt/app/fe1/application.py +| | | |
| | processes = 4 +| | | |
| | threads = 2 +| | | |
| | stats = 127.0.0.1:9191 | | | |
4 | customerBfe1.ini | [uwsgi] +| 2004-10-19 10:23:55 | uwsgi | uwsgi | /tmp/customerBfe1.sock
| | master = true +| | | |
| | vaccum = true +| | | |
| | chdir = /opt/app/ +| | | |
| | plugins = python +| | | |
| | wsgi-file = /opt/app/fe1/application.py +| | | |
| | processes = 4 +| | | |
| | threads = 2 +| | | |
| | stats = 127.0.0.1:9192 | | | |
(2 rows)
谢谢!
"Is this a good practice or do you have similar setup ?"
我有类似的设置。我不会回答这是否是好的做法,因为它是基于意见的,但这与为每个客户复制代码库之间存在细微差别。主要区别是:如果有人闯入一个应用程序并且他将能够修改它的代码,它将影响所有应用程序......但是如果应用程序的配置没有差异将允许以这种方式闯入一个,但不是其他-没关系。如果有人闯入一个,他可以在其他人身上复制......
此外,使用共享代码库可以更轻松地修复破解您的应用后所做的更改。
我看不出任何其他重要的区别...
"Does this provide complete isolation between vassals instances ?"
如前所述,不完整,但可以隔离任何其他内容。这就像在系统中的应用程序之间共享一个库,这种情况一直在发生。通过适当的配置,您还可以将数据库和其他资源分开。
如果正确应用文件系统权限,您可以限制自己更改应用程序代码的能力,因此它将限制某些黑客更改代码的能力。