谷歌大神們帶你進(jìn)行容器運(yùn)維最佳實(shí)踐

本文介紹了一組使容器更易于運(yùn)維的最佳實(shí)踐。這些實(shí)踐涉及安全性、監(jiān)控和日志記錄等廣泛的主題，旨在使應(yīng)用程序更容易在 Kubernetes Engine 和一般的容器中運(yùn)行。這里討論的許多實(shí)踐都受到 12 因素方法的啟發(fā) ，12 因素方法是一個(gè)構(gòu)建云原生應(yīng)用程序的優(yōu)質(zhì)資源。

使用容器的原生日志記錄機(jī)制

重要性：高

作為應(yīng)用程序管理的一部分，日志中包含寶貴的信息，可讓人了解應(yīng)用程序中發(fā)生的事件。Docker 和 Kubernetes 致力于簡(jiǎn)化日志管理。

在傳統(tǒng)服務(wù)器上，你可能需要將日志寫入特定文件并處理日志輪換以避免填滿磁盤。如果有高級(jí)日志系統(tǒng)，則可以將這些日志轉(zhuǎn)發(fā)到遠(yuǎn)程服務(wù)器來集中它們。

通過容器可以將日志寫入 stdout 和 stderr，因而容器提供了一種簡(jiǎn)單且標(biāo)準(zhǔn)化的方式來處理日志。Docker 捕獲這些日志行，并允許你使用 docker logs 命令訪問它們。作為應(yīng)用程序開發(fā)人員，你不需要實(shí)現(xiàn)高級(jí)日志記錄機(jī)制，試試用原生的日志記錄機(jī)制吧。

平臺(tái)運(yùn)營(yíng)商必須提供一個(gè)系統(tǒng)來集中日志并進(jìn)行搜索，你可以使用 Kubernetes Engine 提供的 fluentd 和 Stackdriver Logging。其他常見方法包括使用 EFK （Elasticsearch，F(xiàn)luentd，Kibana）棧。

圖 1. Kubernetes 中典型的日志管理系統(tǒng)圖

JSON 日志

大多數(shù)日志管理系統(tǒng)實(shí)際上是時(shí)序數(shù)據(jù)庫(kù)，用于存儲(chǔ)時(shí)間索引文檔。這些文檔通常以 JSON 格式提供。在 Stackdriver Logging 和 EFK 中，單個(gè)日志行和一些元數(shù)據(jù)（容器組、容器、節(jié)點(diǎn)等相關(guān)信息）一起被存儲(chǔ)為一個(gè)文檔。

你可以直接通過將不同字段以 JSON 格式進(jìn)行日志記錄。然后，可以根據(jù)這些字段更有效地搜索日志。

例如，考慮將以下日志轉(zhuǎn)換為 JSON 格式：

[2018-01-01 01:01:01] foo - WARNING - foo.bar - There is something wrong.

這是轉(zhuǎn)換后的日志：

{
  "date": "2018-01-01 01:01:01",
  "component": "foo",
  "subcomponent": "foo.bar",
  "level": "WARNING",
  "message": "There is something wrong."
}

通過這種轉(zhuǎn)換，你可以在日志中輕松搜索所有 WARNING 級(jí)別日志或 foo.bar 組件中的所有日志。

如果你決定記錄 JSON 格式的日志，請(qǐng)注意必須在每一行上加入事件才能正確解析。在實(shí)際中，它看起來是下面這樣：

{"date":"2018-01-01 01:01:01","component":"foo","subcomponent":"foo.bar","level": "WARNING","message": "There is something wrong."}

如你所見，結(jié)果遠(yuǎn)不如正常的日志可讀。如果決定使用此方法，請(qǐng)確保你的團(tuán)隊(duì)不會(huì)嚴(yán)重依賴手動(dòng)日志檢查。

邊車模式的記錄聚合器

某些應(yīng)用程序（如 Tomcat）無法通過簡(jiǎn)單配置來生成日志。這些應(yīng)用程序在磁盤上寫入不同的日志文件，所以在 Kubernetes 中處理它們的最佳方法是使用邊車模式進(jìn)行日志記錄。邊車是一個(gè)小容器，與應(yīng)用程序在同一個(gè) pod 中運(yùn)行。有關(guān)邊車的更詳細(xì)信息，請(qǐng)參閱 Kubernetes 官方文檔 （https://kubernetes.io/docs/concepts/cluster-administration/logging/#sidecar-container-with-a-logging-agent）。

在這種解決方案中，你為應(yīng)用程序的邊車容器添加一個(gè)日志代理（在同一 pod 中，）并在兩個(gè)容器之間共享 emptyDir 卷，可參考 GitHub 上的這個(gè) YAML 示例：https://github.com/kubernetes/contrib/blob/0.7.0/logging/fluentd-sidecar-gcp/logging-sidecar-example.yaml。然后，配置應(yīng)用程序?qū)⑷罩緦懭牍蚕砭�，接著配置日志代理進(jìn)行讀取，并轉(zhuǎn)發(fā)到需要的地方。

在此模式中，因?yàn)闆]有使用 Docker 和 Kubernetes 原生的日志記錄機(jī)制，所以必須處理日志輪換。如果你的日志代理程序不處理日志輪換，則同一 pod 中的另一個(gè)邊車容器會(huì)處理。

圖 2. 日志管理的邊車模式

確保容器是無狀態(tài)且不可變的

重要性：高

如果你是第一次嘗試容器，請(qǐng)不要將它們視為傳統(tǒng)服務(wù)器。比如，你可能想要在正在運(yùn)行的容器內(nèi)更新應(yīng)用程序，或者在出現(xiàn)漏洞時(shí)給正在運(yùn)行的容器打補(bǔ)丁。從根本上說，容器不是以這種方式工作的。它們被設(shè)計(jì)成了無狀態(tài)且不可改變。

無狀態(tài)

無狀態(tài)意味著任何狀態(tài)（任何類型的持久數(shù)據(jù)）都存儲(chǔ)在容器之外。這個(gè)外部存儲(chǔ)可以采取多種形式，具體取決于你的需求：

• 要存儲(chǔ)文件，我們建議使用 Cloud Storage 等對(duì)象存儲(chǔ)。

• 要存儲(chǔ)用戶會(huì)話等信息，我們建議使用外部的低延遲鍵值存儲(chǔ)，例如 Redis 或 Memcached。

• 如果需要塊級(jí)存儲(chǔ)（例如數(shù)據(jù)庫(kù)），則可以使用連接到容器的外部磁盤。對(duì)于 Kubernetes Engine，我們建議使用 持久化磁盤。

通過以上方法將數(shù)據(jù)從容器本身中移出，這意味著可以隨時(shí)干凈地關(guān)閉和銷毀容器，而不必?fù)?dān)心數(shù)據(jù)丟失。如果創(chuàng)建了一個(gè)新容器來替換舊容器，則只需將新容器連接到同一數(shù)據(jù)存儲(chǔ)區(qū)或?qū)⑵浣壎ǖ酵�一磁盤即可。

不變性

不可變意味著容器在其生命周期內(nèi)不會(huì)被修改：沒有更新，沒有補(bǔ)丁，沒有配置更改。如果必須更新應(yīng)用程序代碼或打補(bǔ)丁，則需要構(gòu)建新鏡像并重新部署。不變性使部署更安全，更可重復(fù)。如果需要回滾，只需重新部署舊鏡像即可。此方法允許你在每個(gè)環(huán)境中部署相同的容器鏡像，使它們盡可能一致。

為了在不同環(huán)境中使用相同的容器鏡像，我們建議你外部化容器配置（偵聽端口，運(yùn)行時(shí)選項(xiàng)等）。容器通常配置有環(huán)境變量或掛載到特定路徑上的配置文件。在 Kubernetes 中，你可以使用 Secrets 和 ConfigMaps 作為環(huán)境變量或文件將配置注入到容器中。

如果需要更新配置，請(qǐng)使用更新的配置部署新容器（基于相同的鏡像）。

圖 3. 如何使用掛載到 pod 配置文件中的 ConfigMaps 更新部署中的配置

無狀態(tài)和不變性的結(jié)合是基于容器的基礎(chǔ)設(shè)施的賣點(diǎn)之一。這種組合允許你自動(dòng)化部署并提高其頻率和可靠性。

避免使用特權(quán)容器

重要性：高

在虛擬機(jī)或裸機(jī)服務(wù)器中，你會(huì)避免使用 root 用戶運(yùn)行應(yīng)用程序，原因很簡(jiǎn)單：如果應(yīng)用程序受到攻擊，攻擊者就可以完全訪問服務(wù)器。出于同樣的原因，請(qǐng)避免使用特權(quán)容器。特權(quán)容器是一個(gè)容器，可以訪問主機(jī)的所有設(shè)備，繞過容器的幾乎所有安全功能。

如果你認(rèn)為需要使用特權(quán)容器，請(qǐng)考慮以下備選方案：

• 通過 Kubernetes 的 securityContext 選項(xiàng)或 Docker 的 --cap-add 標(biāo)志為容器提供特定功能 。該 Docker 文檔（https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities） 同時(shí)列出了默認(rèn)啟用和必須明確啟用的功能。

• 如果你的應(yīng)用程序必須修改主機(jī)設(shè)置才能運(yùn)行，請(qǐng)?jiān)谶呠嚾萜骰虺跏蓟�容器中修改這些設(shè)置 。與你的應(yīng)用程序不同，這些容器不需要暴露于內(nèi)部或外部流量，更加獨(dú)立。

• 如果需要在 Kubernetes 中修改 sysctls，請(qǐng)使用 專用注解。

在 Kubernetes 中，特權(quán)容器可以被特定的 Pod 安全策略禁止 。Pod 安全策略是集群管理員配置和管理的 Kubernetes 對(duì)象，它強(qiáng)制執(zhí)行對(duì) pod 的特定要求。在 Kubernetes 集群中，你無法創(chuàng)建違反這些要求的 pod。

使應(yīng)用程序易于監(jiān)控

重要性：高

與日志一樣，監(jiān)控是應(yīng)用程序管理的一個(gè)組成部分。在許多方面，監(jiān)控容器化應(yīng)用的原則與非容器化應(yīng)用的監(jiān)控相同。但是，由于容器化的基礎(chǔ)架構(gòu)往往是高度動(dòng)態(tài)的，伴隨著頻繁創(chuàng)建或刪除的容器，你無法每次都去重新配置監(jiān)控系統(tǒng)。

你可以區(qū)分兩種主要的監(jiān)控類型：黑盒監(jiān)控和白盒監(jiān)控。黑盒監(jiān)控是指從外部檢查應(yīng)用程序，你就是最終用戶。如果你想要最終提供的服務(wù)可用且有效，則黑盒監(jiān)控非常有用。由于它位于基礎(chǔ)設(shè)施外部，因此黑盒監(jiān)控在傳統(tǒng)基礎(chǔ)設(shè)施和容器化基礎(chǔ)設(shè)施之間沒有區(qū)別。

白盒監(jiān)控是指使用某種特權(quán)訪問檢查應(yīng)用程序，并收集最終用戶無法查看的度量指標(biāo)。由于白盒監(jiān)控必須檢查基礎(chǔ)架構(gòu)的最深層，因此傳統(tǒng)基礎(chǔ)架構(gòu)和容器化基礎(chǔ)架構(gòu)的差異很大。

Prometheus 是 Kubernetes 社區(qū)中用于白盒監(jiān)控的一個(gè)流行選擇，可以自動(dòng)發(fā)現(xiàn)必須監(jiān)控的容器。Prometheus 以期望的特定格式獲取容器組的指標(biāo)。Stackdriver 能夠監(jiān)控 Kubernetes 集群，應(yīng)用也可以運(yùn)行自己的的 Prometheus。

以下是一個(gè) Stackdriver Kubernetes Monitoring 的演示實(shí)例：

圖 4. Stackdriver Kubernetes Monitoring 中的儀表板

要從 Prometheus 或 Stackdriver Kubernetes Monitoring 中受益，應(yīng)用程序需要按照 Prometheus 的格式公開指標(biāo)。你可以按照以下兩種方法來做。

HTTP 端點(diǎn)度量

HTTP 端點(diǎn)度量的工作方式與下文提到的公開應(yīng)用程序的運(yùn)行狀況的端點(diǎn)類似 。它通常在 /metrics URI 上公開應(yīng)用程序的內(nèi)部指標(biāo)。響應(yīng)如下：

http_requests_total{method="post",code="200"} 1027
http_requests_total{method="post",code="400"}    3
http_requests_total{method="get",code="200"} 10892
http_requests_total{method="get",code="400"}    97

在這個(gè)例子中，http_requests_total 是度量，method 和 code 是標(biāo)簽，最右邊的數(shù)字是該指標(biāo)對(duì)于這些標(biāo)簽的值。上圖中所示，自啟動(dòng)以來，該應(yīng)用程序已使用 400 錯(cuò)誤碼響應(yīng)了 97 次 HTTP 的 GET 請(qǐng)求。

通過已有的多種語(yǔ)言的 Prometheus 客戶端庫(kù)，可以輕松生成此 HTTP 端點(diǎn) 。 OpenCensus 還可以使用此格式（以及許多其他功能）導(dǎo)出指標(biāo)。不要將此端點(diǎn)暴露給公共網(wǎng)絡(luò)。

Prometheus 官方文檔 （https://prometheus.io/docs/introduction/overview/）詳細(xì)介紹了該主題。你還可以閱讀站點(diǎn)可靠性工程的第 6 章 ，以了解有關(guān)白盒（和黑盒）監(jiān)控的更多信息。

監(jiān)控中使用邊車模式

并非所有應(yīng)用程序都可以使用 /metrics HTTP 端點(diǎn)進(jìn)行檢測(cè)。為了保持標(biāo)準(zhǔn)化監(jiān)控，我們建議使用邊車模式以正確的格式導(dǎo)出指標(biāo)。

日志聚合邊車模式 部分介紹如何使用邊車容器來管理應(yīng)用程序日志。你可以使用相同的模式進(jìn)行監(jiān)控：邊車容器托管監(jiān)控代理程序，該代理程序?qū)��?yīng)用程序公開的度量標(biāo)準(zhǔn)轉(zhuǎn)換為全局監(jiān)控系統(tǒng)可以理解的格式和協(xié)議。

考慮一個(gè)具體示例：Java 應(yīng)用程序和 Java Management Extensions（JMX）。許多 Java 應(yīng)用程序使用 JMX 公開指標(biāo)。利用 jmx_exporter，你可以不必重寫應(yīng)用程序就公開 Prometheus 格式的指標(biāo)。jmx_exporter 通過 JMX 從應(yīng)用程序收集指標(biāo)，并通過 Prometheus 可以讀取的 /metrics 端點(diǎn)公開它們。這種方法還具有限制 JMX 端點(diǎn)暴露的優(yōu)點(diǎn)，因?yàn)樗�可以用來修改�?yīng)用程序設(shè)置。

圖 5. 用于監(jiān)控的邊車模式

暴露應(yīng)用程序的健康狀況

重要性：中等

為了便于在生產(chǎn)中進(jìn)行管理，應(yīng)用程序必須將其狀態(tài)傳達(dá)給整個(gè)系統(tǒng)：應(yīng)用程序是否正在運(yùn)行？它健康嗎？它準(zhǔn)備好接收流量嗎？它是如何表現(xiàn)的？

Kubernetes 有兩種類型的健康檢查：活性探針（liveness probes ）和就緒探針（readiness probes）。如下文所述，每個(gè)都有特定的用途。你可以通過多種方式實(shí)現(xiàn)這兩種方式（包括在容器內(nèi)運(yùn)行命令或檢查 TCP 端口），但首選方法是使用此最佳實(shí)踐中描述的 HTTP 端點(diǎn)。

注意：本節(jié)中給出的路徑只是一種約定。HTTP 端點(diǎn)的實(shí)際路徑可能因應(yīng)用程序而異。

活性探針

實(shí)現(xiàn)活性探針的推薦方法是讓應(yīng)用程序公開 /health HTTP 端點(diǎn)。在此端點(diǎn)上收到請(qǐng)求后，如果認(rèn)為健康，應(yīng)用程序應(yīng)發(fā)送“200 OK”響應(yīng)。在 Kubernetes 中，健康意味著容器不需要被殺死或重新啟動(dòng)。影響健康的因素因應(yīng)用程序而異，但通常意味著以下內(nèi)容：

• 應(yīng)用程序正在運(yùn)行。

• 它的主要依賴性得到滿足（例如，它可以訪問其數(shù)據(jù)庫(kù)）。

就緒探針

實(shí)現(xiàn)就緒探針的推薦方法是讓應(yīng)用程序公開 /ready HTTP 端點(diǎn)。在此端點(diǎn)上收到請(qǐng)求后，如果應(yīng)用程序已準(zhǔn)備好接收流量，則應(yīng)發(fā)送“200 OK”響應(yīng)。準(zhǔn)備接收流量意味著以下內(nèi)容：

• 該應(yīng)用程序是健康的。

• 完成任何潛在的初始化步驟。

• 發(fā)送到應(yīng)用程序的任何有效請(qǐng)求都不會(huì)導(dǎo)致錯(cuò)誤。

Kubernetes 使用就緒探針來編排應(yīng)用程序的部署。如果更新部署，Kubernetes 將對(duì)屬于該部署的 pod 進(jìn)行滾動(dòng)更新。默認(rèn)更新策略是一次更新一個(gè) pod：Kubernetes 在更新下一個(gè) pod 之前等待新 pod 準(zhǔn)備就緒（如就緒探針?biāo)�示）�?/p>

注意：在許多應(yīng)用程序中，/health 和 /ready 端點(diǎn)合并為一個(gè) /health 端點(diǎn)，因?yàn)樗鼈兊慕】禒顟B(tài)和就緒狀態(tài)之間沒有真正的區(qū)別。

避免以 root 身份運(yùn)行

重要性：中等

容器提供隔離：使用默認(rèn)設(shè)置，Docker 容器內(nèi)的進(jìn)程無法訪問來自主機(jī)或其他并置容器的信息。但是，由于容器共享主機(jī)的內(nèi)核，因此隔離不像虛擬機(jī)那樣完整。攻擊者可以找到未知的漏洞（在 Docker 或 Linux 內(nèi)核本身中），這些漏洞將允許攻擊者從容器中逃脫。如果攻擊者確實(shí)發(fā)現(xiàn)了漏洞并且你的進(jìn)程在容器內(nèi)以 root 身份運(yùn)行，則他們將獲得對(duì)主機(jī)的 root 訪問權(quán)限。

圖 6. 左側(cè)，虛擬機(jī)使用虛擬化硬件。右側(cè)，容器中的應(yīng)用程序使用主機(jī)內(nèi)核。

為避免這種可能性，最佳做法是不在容器內(nèi)以 root 身份運(yùn)行進(jìn)程。你可以使用 PodSecurityPolicy 在 Kubernetes 中強(qiáng)制執(zhí)行此行為 。在 Kubernetes 中創(chuàng)建 pod 時(shí)，使用 runAsUser 選項(xiàng) 指定正在運(yùn)行該進(jìn)程的 Linux 用戶。這種方法會(huì)覆蓋 Dockerfile 中的 USER 指令。

實(shí)際上，存在挑戰(zhàn)。許多軟件包都以 root 身份運(yùn)行其主進(jìn)程。如果要避免以 root 用戶身份運(yùn)行，設(shè)計(jì)你的容器使用未知的非特權(quán)用戶運(yùn)行。這種做法通常意味著你必須調(diào)整各種文件夾的權(quán)限。在容器中，如果按照一個(gè)容器一個(gè)應(yīng)用的最佳實(shí)踐，并且一個(gè)應(yīng)用一個(gè)用戶（最好不是 root 用戶），則授予所有用戶對(duì)文件夾和文件的讀寫權(quán)限不是問題 。

檢查容器是否符合此最佳實(shí)踐的一種簡(jiǎn)單方法是在本地使用隨機(jī)用戶運(yùn)行容器并測(cè)試是否正常工作。替換 [YOUR_CONTAINER] 為你的容器名稱。

docker run --user $（（RANDOM + 1））[YOUR_CONTAINER]

如果容器需要外部卷，則可以配置 fsGroup Kubernetes 選項(xiàng) 以將此卷的所有權(quán)授予給特定的 Linux 組。此配置解決了外部文件所有權(quán)的問題。

如果你的進(jìn)程由非特權(quán)用戶運(yùn)行，則它將無法綁定到 1024 以下的端口。這不是什么大問題，因?yàn)槟憧梢耘渲?Kubernetes 服務(wù)將流量從一個(gè)端口路由到另一個(gè)端口。例如，你可以配置 HTTP 服務(wù)器綁定到 8080 端口，并通過 Kubernetes 服務(wù)從 80 端口將流量重定向回來。

仔細(xì)選擇鏡像版本

重要性：中等

當(dāng)你使用 Docker 鏡像時(shí)，無論是作為 Dockerfile 中的基礎(chǔ)鏡像，還是作為 Kubernetes 中部署的鏡像，你都必須選擇正在使用的鏡像的標(biāo)簽。

大多數(shù)公共和私有鏡像都遵循構(gòu)建容器最佳實(shí)踐（https://cloud.google.com/solutions/best-practices-for-building-containers#properly_tag_your_images）中所述的標(biāo)簽系統(tǒng) 。如果鏡像使用語(yǔ)義版本控制的系統(tǒng) ，則必須考慮一些標(biāo)簽細(xì)節(jié)。

最重要的是，“l(fā)atest”標(biāo)簽可以在鏡像之間頻繁移動(dòng)。結(jié)果是你無法依賴此標(biāo)簽進(jìn)行可預(yù)測(cè)或可重現(xiàn)的構(gòu)建。例如，采用以下 Dockerfile：

FROM debian:latest

RUN apt-get -y update && \
    apt-get -y install nginx

如果你在不同的時(shí)間使用這個(gè) Dockerfile 構(gòu)建兩次鏡像，你最終會(huì)得到兩個(gè)不同版本的 Debian 和 NGINX。相反，考慮這個(gè)修訂版：

FROM debian:9.4

RUN apt-get -y update && \
    apt-get -y install nginx

通過使用更精確的標(biāo)簽，你可以確保生成的鏡像始終基于 Debian 的特定子版本。因?yàn)樘囟ǖ?Debian 版本還附帶了特定的 NGINX 版本，所以你可以更好地控制正在構(gòu)建的鏡像。

這個(gè)結(jié)果不僅適用于構(gòu)建時(shí)，也適用于運(yùn)行時(shí)。如果你在 Kubernetes 清單中引用“l(fā)atest”標(biāo)簽，則無法保證 Kubernetes 將使用的版本。集群的不同節(jié)點(diǎn)可能會(huì)在不同時(shí)刻拉取相同的“l(fā)atest”標(biāo)簽。如果標(biāo)簽已經(jīng)在拉動(dòng)之間的某個(gè)點(diǎn)更新，則最終可能會(huì)在不同的節(jié)點(diǎn)運(yùn)行不同的鏡像（這是因?yàn)橥瑫r(shí)打上了“l(fā)atest”標(biāo)簽）。

理想情況下，你應(yīng)始終在 FROM 行中使用不可變標(biāo)簽。此標(biāo)簽允許你重現(xiàn)構(gòu)建。但是，存在一些安全性權(quán)衡：你固定使用的版本越多，安全補(bǔ)丁在鏡像中的自動(dòng)化程度就越低。如果你使用的鏡像使用正確的語(yǔ)義版本控制，則補(bǔ)丁版本（即“X.Y.Z”中的“Z”）不應(yīng)具有向后不兼容的更改：你可以使用“X.Y”標(biāo)簽并自動(dòng)修復(fù)錯(cuò)誤。

注意：標(biāo)簽在 Docker 中不是真正不變的。只要鏡像的所有者決定更改標(biāo)簽。但是，“X.Y.Z”標(biāo)簽實(shí)際上幾乎總是不變的。

設(shè)想一個(gè)名為“SuperSoft”的軟件。假設(shè) SuperSoft 的安全過程是通過新的補(bǔ)丁版本來修復(fù)漏洞。你想自定義 SuperSoft，并編寫了以下 Dockerfile：

FROM supersoft:1.2.3

RUN a-command

一段時(shí)間后，供應(yīng)商發(fā)現(xiàn)了一個(gè)漏洞，并發(fā)布了 SuperSoft 的 1.2.4 版本來解決這個(gè)問題。在這種情況下，你可以隨時(shí)了解 SuperSoft 的補(bǔ)丁并相應(yīng)地更新 Dockerfile。如果你在 Dockerfile 中使用 FROM supersoft:1.2 進(jìn)行替換，則會(huì)自動(dòng)拉取新版本。

最后，你必須仔細(xì)檢查正在使用的每個(gè)外部鏡像的標(biāo)簽系統(tǒng)，判定你對(duì)構(gòu)建這些鏡像的人員的信任程度，并確定要使用的標(biāo)簽。

 

來自：https://mp.weixin.qq.com/s/FEqVWBQ1LkQAf6sdX7MPng

 

標(biāo)簽： Google linux 安全 代碼 訪問服務(wù)器 服務(wù)器 谷歌 漏洞 權(quán)限 數(shù)據(jù)庫(kù) 搜索 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。