Nginx+uWSGI+Django部署web伺服器

來源:互聯網
上載者:User

標籤:超出   rod   參考   error:   使用者組   簡單的   0.0.0.0   ges   效果   

目錄

  • Nginx+uWSGI+Django部署web伺服器
    • 環境說明
    • 前言
    • 搭建項目
    • Django部署
      • 編輯luffy/luffy/settings.py
      • 編輯luffy/app01/views.py
      • 編輯luffy/luffy/urls.py
      • 運行並測試
    • uWSGI部署
      • 測試回合uWSGI
      • 使用uWSGI運行django項目
      • uWSGi熱載入Djangoa項目
    • 部署nginx
      • nginx配置uwsgi和django
      • django部署static檔案
      • 重新載入nginx進行測試
      • 測試nginx 應用 uWSGI 和 test.py
      • 用UNIX socket取代TCP port
    • uwsgi部署加強
      • 使用uwsgi設定檔運行django項目
      • 安裝uWSGI到真實環境中
      • uwsgi設定檔更多參數
      • uWSGI開機啟動服務
Nginx+uWSGI+Django部署web伺服器環境說明
  • 進行本文操作前需己搭建好的環境
    • linux系統,我用的是openSUSE
      • 使用了operation使用者的家目錄做為測試環境
    • python3.5.6
    • virtualenv 16.0
    • pip3 18.0
    • nginx 1.13.1
  • 後面進行安裝的環境
    • django 1.11
    • uwsgi-2.0.17.1
前言

在多年前,基於python的web項目,常見的部署方法有:

  • fcgi:用spawn-fcgi或者架構內建的工具對各個project分別產生監聽進程,然後和http服務互動。
  • wsgi:利用http服務的mod_wsgi模組來跑各個project。

不過uwsgi出現後,大部份部署就不會使用以上的兩個協議了。
因為uwsgi它既不用wsgi協議也不用fcgi協議,而是自創了一個uwsgi的協議,據作者說該協議大約是fcgi協議的10倍那麼快。uWSGI的主要特點如下:

  • 超快的效能。
  • 低記憶體佔用(實測為apache2的mod_wsgi的一半左右)。
  • 多app管理。
  • 詳盡的日誌功能(可以用來分析app效能和瓶頸)。
  • 高度可定製(記憶體大小限制,服務一定次數後重啟等)。

所以在uwsgi協議的基礎上,配合nginx來做python(類如django的架構)的web項目部署就很常見了。

uwsgi 實際上也是一個 http 伺服器,只不過它只面向 python 的網路應用程式。
雖然 uwsgi 也是 http 伺服器,但是卻不便直接使用它部署 python web 應用程式。

uwsgi 所扮演的的角色是後端 http 伺服器,nginx 扮演的角色是前端 http 伺服器,django項目 是客戶所真正要訪問到的提供資料方。 使用者從網頁瀏覽器中發出請求,nginx 伺服器收到請求後,會通過它的 uwsgi 模組將使用者的請求轉寄給 uwsgi 伺服器,uwsgi 伺服器通過django處理完畢後將結果返回給 nginx,瀏覽器將最終的結果展現給使用者。

搭建項目
  • 建立一個虛擬環境
    • 建議個人學習和測試的話,直接建在家使用者目錄下,以避免許可權引起的各種拒絕問題
    • 或者正式點,系統再建一個dev使用者,在專門的工作目錄下給好dev使用者的許可權去運行。
    • 虛擬環境的目錄名建議就帶個env點明是虛擬環境,如果和後面的項目取相同的名字你會看到三重同名的串在一起,有點不太好認。
      virtualenv -p python3 py3env
  • 啟動虛擬環境
    source py3env/bin/activate

  • 安裝django1.11,之所以裝這個版本是學習所需要,後面自己的項目最好與時俱進。
    pip install django==1.11

  • 直接使用django-admin命令建立一個django項目
    • 建議不要放在py3env目錄下,而是在專門的工作目錄下建立
      django-admin startproject luffy

如下,己經初步搭建好簡單的項目:

cd luffy(py3env) [email protected]:~/work/luffy> tree -L 2.├── luffy│   ├── __init__.py│   ├── settings.py│   ├── urls.py│   └── wsgi.py└── manage.py
  • 建立新應用,例如app01
    python3 manage.py startapp app01
    結構如下
(py3env) [email protected]:~/work/luffy> tree -L 2.├── app01│   ├── admin.py│   ├── apps.py│   ├── __init__.py│   ├── migrations│   ├── models.py│   ├── tests.py│   └── views.py├── luffy│   ├── __init__.py│   ├── __pycache__│   ├── settings.py│   ├── urls.py│   └── wsgi.py└── manage.py
Django部署編輯 luffy/luffy/settings.py
# SECURITY WARNING: don‘t run with debug turned on in production!DEBUG = FalseALLOWED_HOSTS = [‘*‘, ]# Application definitionINSTALLED_APPS = [    ‘django.contrib.admin‘,    ‘django.contrib.auth‘,    ‘django.contrib.contenttypes‘,    ‘django.contrib.sessions‘,    ‘django.contrib.messages‘,    ‘django.contrib.staticfiles‘,    ‘app01‘,]

如上,主要是:

  • 將DEBUG由True改成False(雖然只是在學習和測試搭建的,也要顧及好安全)
  • 在ALLOWED_HOSTS 預設的空列表中填入你自己打算使用的網域名稱,我這裡測試的時候填的是*,真正上線部署的時候不建議填成萬用字元的*,而是要填允許訪問的主機網域名稱。一般django用於做後端伺服器,而前端會有一個網域名稱。詳情可見django官方文檔。
  • INSTALLED_APPS 列表下增加appo1,表示將app01應用給安裝註冊上。
  • 補充,後面配置好nginx和建立好網域名稱之後,我將ALLOWED_HOSTS = [‘*‘, ]修改成ALLOWED_HOSTS = [‘luffy.tielemao‘, ]了,通過網域名稱訪問仍然正常。而直接敲ip地址則會報400錯誤。
編輯 luffy/app01/views.py
from django.shortcuts import render,HttpResponse# Create your views here.def index(request):    return HttpResponse(‘Hello Hero‘)

由於只是簡單示範,所以上面只是讓使用者訪問index頁面後,得到一個顯示Hello Hero的頁面。

編輯 luffy/luffy/urls.py
from django.conf.urls import urlfrom django.contrib import adminfrom app01 import viewsurlpatterns = [    url(r‘^admin/‘, admin.site.urls),    url(r‘^index/‘, views.index),]
運行並測試

首先是運行,由於是單獨對django進行運行測試,所以只是在進入項目根目錄後命令列敲以下命令:

python manage.py runserver 0.0.0.0:8083
其中0.0.0.0表示捆綁監聽伺服器上的所有網卡IP地址,當然也就包括了127.0.0.1和外網的公網ip了。

最初我測試的是ALLOWED_HOSTS填的允許的HOSTS是自己的網域名稱.tielemao.com,結果直接在瀏覽器上敲IP加8083連接埠接index當然是報錯:

Bad Request(400)而由於我將DEBUG值設為了False,所以也不會將調試資訊暴露出來。

然後我將.tielemao.com改為了萬用字元*(不安全,表示允許所有主機頭)。
再訪問http://39.x.x.x:8083/index/的時候,就能正常訪問到了:

  • 注意,我使用的是8083連接埠並且在防火牆和雲控制平台上的安全性群組處己設定了開放該連接埠。

django能運行無誤後,ctrl+c將它停止,再接下來做下面的操作。

uWSGI部署

同樣為了環境的隔離和純淨,這次我也選擇在同樣的虛擬環境下安裝:
pip3 install uwsgi
安裝完成後可uwsgi --version查看版本,
uwsgi --python-version還可以間接查看到python的版本。

  • 編寫一個用於簡單測試uwsgi的python指令碼
    vim test-uwsgi.py,內容如下:
def application(env,start_response):    start_response(‘200 OK‘,[(‘Content-Type‘,‘text/html‘)])    return [b"Hello Hero, all for one "]
測試回合uWSGI

以下命令表示運行uwsgi服務,同樣是在8083連接埠上開放web訪問。

  • 注意--http 後是一個空格再接:連接埠號碼。
    uwsgi --http :8083 --wsgi-file test-uwsgi.py

訪問web伺服器8083連接埠,正常顯示test-uwsgi.py指令碼中返回顯示的文本。

因為我們現在要做的是基於nginx和uwsgi部署django,從用戶端發起請求到伺服器響應請求,會經過一下幾個環節:

the web client <-> the web server(nginx) <-> the socket <-> uwsgi <-> Django

而單獨測試uWSGI運行,訪問顯示正常的話,說明下面3個環節是通暢的:

the web client <-> uWSGI <-> Python

ctrl+c中止程式,再來進行以下的測試。

使用uWSGI運行django項目

在虛擬環境下,進入到django根目錄下後敲以下命令:

 uwsgi --http :8000 --module luffy.wsgi

效果和直接敲以下命令

python manage.py runserver 0.0.0.0:8000

是一樣的。

  • 註:--module luffy.wsgi為載入指定的wsgi模組,你項目起的是什麼名字,一般就是項目名.wsgi

這樣測試下來,可證明web用戶端通過uWSGI到Django是通暢的:

the web client <-> uWSGI <-> Django

ctrl+c中止程式,再來進行以下的測試

uWSGi熱載入Djangoa項目

在啟動命令後面加上參數:

uwsgi --http :8083 --module luffy.wsgi --py-autoreload=1

同樣,這個時候訪問伺服器8083連接埠,也就是訪問了django項目(luffy)。

而且還多了一個參數:
--py-autoreload 監控python模組以觸發重載(僅在開發中使用)

# 類似的發布命令/home/operation/work/py3env/bin/uwsgi --http 0.0.0.0 :8000 --chdir /home/operation/work/luffy --module luffy.wsgi# 此時修改django代碼,uWSGI會自動載入django程式,頁面生效# 除此外,還可以接上很多參數

ctrl+c中止程式,再進行下面環節:

部署nginxnginx配置uwsgi和django
  • uwsgi_params檔案拷貝到專案檔夾下。
  • uwsgi_params檔案一般在/etc/nginx/目錄下,也可以從nginx的github頁面下載。

uwsgi_params設定檔如下:

uwsgi_param  QUERY_STRING       $query_string;uwsgi_param  REQUEST_METHOD     $request_method;uwsgi_param  CONTENT_TYPE       $content_type;uwsgi_param  CONTENT_LENGTH     $content_length;uwsgi_param  REQUEST_URI        $request_uri;uwsgi_param  PATH_INFO          $document_uri;uwsgi_param  DOCUMENT_ROOT      $document_root;uwsgi_param  SERVER_PROTOCOL    $server_protocol;uwsgi_param  REQUEST_SCHEME     $scheme;uwsgi_param  HTTPS              $https if_not_empty;uwsgi_param  REMOTE_ADDR        $remote_addr;uwsgi_param  REMOTE_PORT        $remote_port;uwsgi_param  SERVER_PORT        $server_port;uwsgi_param  SERVER_NAME        $server_name;
  • 拷貝到項目下:
    sudo cp /etc/nginx/uwsgi_params /home/operation/work/luffy/

  • 屬主屬組等許可權重新修改
sudo chown operation:operation uwsgi_paramssudo chmod 664 /home/operation/work/luffy/uwsgi_params
  • 在專案檔夾下建立檔案luffy_nginx.conf,填入並修改下面內容:
# luffy_nginx.conf# the upstream component nginx needs to connect toupstream django {    # server unix:///path/to/your/mysite/mysite.sock;     # for a file socket    server 127.0.0.1:8083;     # for a web port socket (we‘ll use this first)}# configuration of the serverserver {    # the port your site will be served on    listen      8000;    # the domain name it will serve for    server_name luffy.tielemao.com;     # substitute your machine‘s IP address or FQDN    charset     utf-8;    # max upload size    client_max_body_size 75M;   # adjust to taste    # Django media    location /media  {        alias /home/operation/work/luffy/media;          # your Django project‘s media files - amend as required    }    location /static {        alias /home/operation/work/luffy/static;         # your Django project‘s static files - amend as required    }    # Finally, send all non-media requests to the Django server.    location / {        uwsgi_pass  django;        include     /home/operation/work/luffy/uwsgi_params;         # the uwsgi_params file you installed    }}

這個設定檔告訴nginx從檔案系統中拉起media和static檔案作為服務,
同時響應django的request。

為此,我也在相應的項目目錄下先建立起media和static檔案夾。

為方便nginx使用,我在/etc/nginx/vhosts.d下建立了一個luffy_nginx.conf的軟連結。當然,也有人是直接用預設的sites-enabled目錄,自己看著來就行了。

sudo ln -s /home/operation/work/luffy/luffy_nginx.conf luffy.conf
django部署static檔案
  • 在專案檔夾下,建立好靜態檔案目錄:
    mkdir static

  • django的setting檔案中,添加一行:
    STATIC_ROOT = os.path.join(BASE_DIR, “static/”)

  • 運行
    python manage.py collectstatic

  • 在專案檔夾下,建立一個media媒體檔案目錄(用於存放圖片音樂等檔案做測試)
    mkdir media

在media目錄中,我傳入了一個圖片檔案princekin_fox.jpg用於測試nginx。

參數STATIC_ROOT用在哪?
通過python3 manage.py collectstatic收集所有你使用的靜態檔案儲存到STATIC_ROOT

STATIC_ROOT 檔案夾 是用來將所有STATICFILES_DIRS中所有檔案夾中的檔案,以及各app中static中的檔案都複製過來,把這些檔案放到一起是為了用nginx等部署的時候更方便。

重新載入nginx進行測試

先進行檢測,看之前的設定檔有無錯誤。
sudo /usr/sbin/nginx -t

重新載入nginx讓軟連結的luffy_nginx.conf生效。
sudo /usr/sbin/nginx -s reload

訪問http://luffy.tielemao.com:8000/media/princekin_fox.jpg看能否正常訪問到圖片資源:

注意在做這一步之前,我是己經配置好網域名稱和傳送了一個用於測試的圖片到伺服器上。

我己經能成功訪問到資源了,所以接下來再做下一步測試。

測試nginx 應用 uWSGI 和 test.py

還記得之前寫好的一個測試的test-uwsgi.py檔案嗎?
我們就用配置好的nginx來訪問uwsgi啟動的test-uwsgi.py好了。
首先,啟動uwsgi,並且連接埠是nginx配置中的負載平衡池8083連接埠:
uwsgi --socket :8083 --wsgi-file test-uwsgi.py

訪問http://luffy.tielemao.com:8000/,實際上訪問的就是uwsgi的8083連接埠。

如,能正常訪問。表明下面的環節通暢:

the web client <-> the web server <-> the socket <-> uWSGI <-> Python

測試成功後中止程式,以便進行下面環節。

用UNIX socket取代TCP port

修改luffy_nginx.conf

# luffy_nginx.conf# the upstream component nginx needs to connect toupstream django {    server unix:///home/operation/work/luffy/luffy.sock;    # for a file socket    # server 127.0.0.1:8083;     # for a web port socket (we‘ll use this first)}

上面其實是將原來的server 127.0.0.1:8083加以注釋,而原來加了#注釋的server unix:///home/operation/work/luffy/luffy.sock則取消了注釋,也就是不是直接指定連接埠,而是指定了一個sock檔案。

  • 要注意的是,這個luffy.sock並不是自己提前寫好的什麼設定檔,而是由程式自動產生的。

重新載入nginx,然後在項目下運行uWSGI

uwsgi --socket /home/operation/work/luffy/luffy.sock --wsgi-file test-uwsgi.py 

訪問http://luffy.tielemao.com:8000/ 報502網關錯誤。
檢查nginx的錯誤記錄檔error.log,一般位置會在/var/log/nginx/error.log,建議使用tail察看檔案尾部的後10行。
會發現類似以下報許可權受阻的錯誤:

2018/08/27 20:17:44 [crit] 25771#25771: *1847865 connect() to unix:///home/operation/work/luffy/luffy.sock failed (13: Permission denied) while connecting to upstream, client: 223.72.74.11, server: luffy.tielemao.com, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///home/operation/work/luffy/luffy.sock:", host: "luffy.tielemao.com:8000"

那麼就中止uwsgi進程,添加上socket許可權後再次運行:

uwsgi --socket /home/operation/work/luffy/luffy.sock --wsgi-file test-uwsgi.py --chmod-socket=664

還是報錯的話,就需將operation使用者添加到nginx組中了,當然某些系統中nginx組也可能是www-data

將operation使用者添加到nginx組中,記得要加上-a參數,不然operation將會離開原來的operation組。

sudo usermod -a -G nginx operation

然後將項目目錄也歸屬到nginx組中

sudo chown operation:nginx -R luffy

這樣就能保證nginx能對luffy.sock有足夠的許可權了。
果然,設定好許可權後,就能正常訪問了。

每次都運行上面命令來拉起django項目實在不方便,我們可以將這些配置寫在.ini檔案中,能大大簡化工作。

停掉uwsgi服務後,見下一環節。

uwsgi部署加強使用uwsgi設定檔運行django項目

uwsgi支援ini,xml等多種配置方式,以ini為例,在/home/operation/work/conf目錄下建立uwsgi_luffy.ini,樣本配置如下:

# luffy_uwsgi.ini file[uwsgi]# Django-related settings# the base directory (full path)# 指定運行目錄,其實就是項目的根目錄chdir = /home/operation/work/luffy# Django‘s wsgi file# 匯入django項目的wsgi模組module = luffy.wsgi:application# 載入wsgi-filewsgi-file = luffy/wsgi.py# the virtualenv (full path)# 配置虛擬環境python相關依賴包所在路徑home = /home/operation/work/py3env# 補充,uwsgi啟動時的使用者和使用者組,注意要按你自己的實際許可權進行配置# 我這邊是因為項目屬主是operation,而operation我設定了添加進了nginx組# 但這種情況下uid仍不能設定nginx,除非你的項目目錄所有檔案屬主都改為了nginxuid = operationgid = nginx# process-related settings# 開啟master主進程master = true # maximum number of worker processes# 開啟多少個進程數,workers項也等同processes# threads項則是設定運行線程,測試倒不用設定上線程processes = 4# the socket (use the full path to be safe)# 設定使用的socket連接埠或socket地址# socket = 0.0.0.0:8000# 上面的socket建議配置成一個luffy.socket檔案後使用nginx來串連uWSGI運行,不然容易報socket的要求標頭錯誤和許可權錯誤等。socket = /home/operation/work/luffy/luffy.socket# ... with appropriate permissions - may be needed# 配置產生的sock檔案的許可權chmod-socket = 664 # clear environment on exit# 退出時清空環境,其實就是將自動產生的luffy.sock和相關pid檔案給幹掉。vacuum = true

uwsgi指定設定檔啟動django項目,建議使用nginx使用者執行:
uwsgi --ini /home/operation/work/conf/uwsgi_luffy.ini

  • 註:以上啟動後如果你是在設定檔中直接指定的socket = 0.0.0.0:8000可能會產生如下問題:瀏覽器訪問伺服器8000連接埠加上url後,瀏覽器會報串連出錯,而伺服器運行後台也會看到如下錯誤資訊:
    invalid request block size: 21573 (max 4096)...skip

之前我們直接使用http協議的方式就不會出現塊請求大小超出

 uwsgi --http :8000 --module luffy.wsgi

究其原因,使用設定檔啟動是以socket方式提供通訊連接埠,預設的協議是tcp,和http不同。socket要求標頭預設大小是4096,所以要求標頭超出預設大小後就會出現錯誤。當然後面我們可以通過和nginx合作的方式解決。

而如果只是想測試,那麼只要在上面的命令後面再指定塊請求大小-b 24576之類的便可以解決。

我們中止uwsgi後重新指定塊大小,運行命令:
uwsgi -b 24576 --ini /home/operation/work/conf/uwsgi_luffy.ini
可以解決要求標頭錯誤。

不過ini設定檔主要是用於和nginx配合,這也是為什麼前面講述完nginx的部署後再回過頭來講uwsgi的ini設定檔。

  • 將uWSGI中使用的相同選項放入一個設定檔中,然後要求uWSGI使用該檔案運行。這會使得管理配置變得更加容易。

  • 要注意的是,因為要配合nginx,所以產生的項目名.sock檔案,nginx需要能有許可權讀寫。

如:

由於我前面執行uwsgi命令時使用的是operation使用者,
這樣子自動產生的luffy.sock檔案屬組並不是nginx的,所以ini設定檔中最好加上uid和gid的配置項使用nginx使用者執行uwsgi。

# uwsgi啟動使用者名稱和使用者組uid = operationgid = nginx

我是修改完luffy.sock的屬組為nginx後就能正常訪問到django項目了,不然會被nginx報502錯誤。

安裝uWSGI到真實環境中

到目前為止,我們都是在虛擬環境下工作的,接下來介紹將uwsgi裝在實際環境中,且將uwsgi加入到nginx組(有的是www-data組)中,就可避免現在所遇到的許可權等問題。

  • 退出虛擬環境
    deactivate

  • 安裝uWSGI,注意要使用python3中的pip3來進行安裝。我系統中是python2.7和python3.5.6共存的,不過預設的環境是2.7。
    sudo /usr/local/python3.5.6/bin/pip3 install uwsgi

  • 之前我使用預設的pip進行安裝,結果是python2版本的uwsgi,在運行虛擬環境中的python3的django項目時會報以下錯誤:
Python version: 2.7.13 (default, Jan 03 2017, 17:41:54) [GCC]Set PythonHome to /home/operation/work/py3envImportError: No module named siteVACUUM: unix socket /home/operation/work/luffy/luffy.sock removed.

報模組匯入錯誤,原因還是在於我真實環境使用的是python2.7版本的原因,ini中配置了虛擬環境家目錄是python3的依賴庫,pip安裝的uwsgi不能正確匯入。

  • 再次檢查,在真實環境中是否能如同虛擬環境之前一樣能運行django項目。
    當然,由於我前面的python3沒有匯入系統內容中,所以此處仍然要像前面使用python3的pip3一樣,需要打全路徑:
sudo /usr/local/python-3.5.6/bin/uwsgi --ini /home/operation/work/conf/uwsgi_luffy.ini
  • 模組無法匯入的錯誤己排除了,但是還會報一個bind綁定拒絕的錯誤。

出現這個錯誤還是和檔案許可權有關,因為我之前uwsgi的ini設定檔中uid設定的使用者是nginx,而項目真正的屬主是operation這個使用者,所以我將uid設定回operation就解決問題了,當然將項目整個屬主設為nginx使用者也是可行的。

# 因為許可權問題踩了不少坑,在此繼續加強強調。# 注意的是你要按自己的實際環境配置uid = operationgid = nginx

成功運行uwsgi的我也放出給大家對比一下看吧。
當然,訪問頁面成功的就不放了,和之前測試成功的是一樣的。

uwsgi設定檔更多參數

前面己經給大家看到了uwsgi的ini檔案的一些配置參數,在此以luffy項目為例,再介紹一些常用到的參數:

# set an environment variable# 設定變數環境,其實就是應用上django項目中的settingsenv = DJANGO_SETTINGS_MODULE=luffy.settings# create a pidfile# 建立pid檔案,注意許可權,所以一般放置在tmp目錄下pidfile = /tmp/project-master.pid # background the process & log# 後台運行,有用,基本都會設定上,同時還會輸出日誌daemonize = /var/log/uwsgi/luffy.log # 以固定的檔案大小(單位kb),進行切割日誌# 下例為50M大小一個記錄檔log-maxsize = 50000000# 不記錄請求資訊的日誌。只記錄錯誤以及uWSGI內部訊息到日誌中。disable-logging = true## 在指定的地址上,開啟狀態服務。應該就是你訪問該地址,就能看到整個uwsgi的狀態,類似nginx也有。所以一般會只在迴路位址上開放。stats = 127.0.0.1:8009# 以下都是一些效能和資源上的限制和調配# respawn processes taking more than 20 secondsharakiri = 20 # limit the project to 128 MB# 控制進程的總記憶體量limit-as = 128 # respawn processes after serving 5000 requestsmax-requests = 5000 
  • 訪問stats狀態服務頁面大致如下:
uWSGI開機啟動服務

繼續以django的luffy項目為例,讓uWSGI開機就啟動服務,編輯檔案/etc/rc.local, 添加下面內容到這行代碼之前exit 0:

/usr/local/python-3.5.6/bin/uwsgi --ini /home/operation/work/conf/uwsgi_luffy.ini

要注意的是記得ini設定檔中設定好使用者使用者組,sock檔案,sock檔案的許可權和後台運行等配置。

end
by 鐵樂與貓

參考

  • uwsgi官方文檔
  • py魚部落格相關文章

Nginx+uWSGI+Django部署web伺服器

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.