隨著IT行業(yè)的發(fā)展和變遷，IT應(yīng)用的底層支持也從大型機(jī)、小型機(jī)、PC服務(wù)器、虛擬化技術(shù)，到如今的容器化?；诿艚蓍_(kāi)發(fā)的持續(xù)迭代，持續(xù)部署，以及多樣化的技術(shù)棧，傳統(tǒng)的底層架構(gòu)變得越來(lái)越冗雜，運(yùn)維管理越來(lái)越力不從心，運(yùn)維人員也逐步陷落在無(wú)盡的“救火”運(yùn)維模式。
容器技術(shù)的出現(xiàn)，從根本上改變了這一切。而容器高效的編排與管理，才是讓其風(fēng)光無(wú)限的前提條件。Kubernetes經(jīng)過(guò)多年的發(fā)展，已經(jīng)成為行業(yè)的事實(shí)標(biāo)準(zhǔn)。而如何利用好Kubernetes，為企業(yè)的發(fā)展助力，成為很多企業(yè)，尤其是初創(chuàng)企業(yè)無(wú)法忽略的一道難題。
? 本文將介紹利用Amazon EKS打造企業(yè)級(jí)容器云平臺(tái)，通過(guò)一系列的實(shí)踐操作，讓大家直觀地了解AWS是如何幫助企業(yè)高效地部署、管理容器化應(yīng)用。
1. 傳統(tǒng)應(yīng)用架構(gòu)的容器化之路
? 說(shuō)到“傳統(tǒng)”二字，大家第一反應(yīng)，就是“落后”，“守舊”，然而現(xiàn)實(shí)情況卻是----絕大部分傳統(tǒng)應(yīng)用，依然在良好地運(yùn)行在這些傳統(tǒng)架構(gòu)中。這些被服務(wù)的對(duì)象不會(huì)因?yàn)槟承┮蛩貙?duì)整個(gè)系統(tǒng)資源的需求發(fā)生很大變化，也不會(huì)有頻繁的系統(tǒng)功能的迭代開(kāi)發(fā)需求。
? 但是隨著互聯(lián)網(wǎng)、大數(shù)據(jù)、AI等技術(shù)的發(fā)展，各行各業(yè)都在努力地從信息化向智能化轉(zhuǎn)型。而轉(zhuǎn)型的過(guò)程中，越來(lái)越多的應(yīng)用場(chǎng)景，和頻繁地迭代開(kāi)發(fā)，也讓“傳統(tǒng)”架構(gòu)越來(lái)越龐大。隨之而來(lái)的是運(yùn)維人員疲于奔命的“救火”，系統(tǒng)服務(wù)越來(lái)越不穩(wěn)定，以及系統(tǒng)成本的失控飛漲。
? 如何才能從根本上一勞永逸地解決這些問(wèn)題？ 容器化/微服務(wù)化是很多企業(yè)寄予厚望的方向。
容器化真的那么有效嗎？
? 我們以下圖為例。這是一個(gè)很通用的架構(gòu)，在多臺(tái)服務(wù)器上分別部署Tomcat，使用反向代理軟件（Nginx）把請(qǐng)求均勻分發(fā)到每個(gè)Tomcat中。假定由于11.11促銷，我們需要將現(xiàn)有的3臺(tái)Tomcat擴(kuò)充到10臺(tái)，運(yùn)維人員需要完成哪些工作？（假設(shè)服務(wù)器硬件已經(jīng)準(zhǔn)備好）
傳統(tǒng)系統(tǒng)的擴(kuò)容步驟：
1. 安裝OS，設(shè)置安全和權(quán)限相關(guān)
2. 分配IP，聯(lián)網(wǎng)
3. 部署Tomcat
4. 以上動(dòng)作做7遍
? 僅僅一個(gè)擴(kuò)容，就需要一個(gè)資深的運(yùn)維人員花費(fèi)幾個(gè)小時(shí)才能完成。如果要擴(kuò)充到100個(gè)節(jié)點(diǎn)呢，工作量成倍增加。
容器化系統(tǒng)擴(kuò)容步驟：
? 如果我們使用容器化技術(shù)來(lái)完成剛剛這件事，就會(huì)節(jié)省很多人力。
1. 安裝OS，并由Kubernetes統(tǒng)一管理
2. 一條命令足以，并且在秒級(jí)完成擴(kuò)展
kubectl scale rc tomcat --replicas=10
3. 完成
? 簡(jiǎn)單的一個(gè)對(duì)比，即可發(fā)現(xiàn)，在資源分配，系統(tǒng)穩(wěn)定（自愈），運(yùn)維管理等多個(gè)方面，容器化技術(shù)都可有效地降低企業(yè)的成本和運(yùn)維壓力，并且讓企業(yè)保持技術(shù)的敏捷性和先進(jìn)性。
2. 容器化應(yīng)用場(chǎng)景
? 剛剛討論過(guò)容器化對(duì)于企業(yè)的價(jià)值，接下來(lái)要繼續(xù)分析哪些場(chǎng)景適合容器化。
? 容器化很重要的特點(diǎn)，就是輕量化和無(wú)狀態(tài)。而像傳統(tǒng)的企業(yè)應(yīng)用軟件，承載業(yè)務(wù)模塊眾多，功能流程繁瑣，因此并不適合容器化改造。具體哪些應(yīng)用場(chǎng)景比較適合呢？主要包含以下幾種場(chǎng)景（當(dāng)然，這只是幾種常見(jiàn)情況，業(yè)務(wù)場(chǎng)景滿足輕量化、無(wú)狀態(tài)的特點(diǎn)都是可以嘗試容器化技術(shù)）
2.1. 應(yīng)用打包
2.2. 多版本混合部署
2.3. 升級(jí)回滾
2.4. 多租戶資源隔離
2.5. 內(nèi)部開(kāi)發(fā)環(huán)境
? 我們一直在說(shuō)容器化（Docker為代表）的各種優(yōu)勢(shì)，但是企業(yè)在真正的生產(chǎn)環(huán)境中，如果只是通過(guò)Docker來(lái)實(shí)現(xiàn)容器化，是無(wú)法滿足高可用、彈性擴(kuò)展和高并發(fā)等場(chǎng)景需求。而Kubernetes的出現(xiàn)，才讓Docker真正在生產(chǎn)環(huán)境中被大規(guī)模使用起來(lái)。Kubernetes提供了應(yīng)用部署、規(guī)劃、更新、維護(hù)的一種機(jī)制，讓容器化應(yīng)用的部署和管理更簡(jiǎn)單、更高效，。
Kubernetes的特點(diǎn)：
· 可移植: 支持公有云，私有云，混合云，多云（multi-cloud）
· 可擴(kuò)展: 模塊化，插件化，可掛載，可組合
· 自動(dòng)化: 自動(dòng)部署，自動(dòng)重啟，自動(dòng)復(fù)制，自動(dòng)伸縮/擴(kuò)展
? Kubernetes結(jié)合Docker，讓企業(yè)容器化之路變得更加容易，從而更快地滿足業(yè)務(wù)需求。 但是，事物都是有兩面性，并不是所有項(xiàng)目都適合容器化改造，而且任何的改動(dòng)都有可能產(chǎn)生未知的影響，要對(duì)技術(shù)保持敬畏，對(duì)生產(chǎn)保持敬畏，才能在容器化的道路上走的更穩(wěn)。
? Kubernetes雖好，但是對(duì)于很多初創(chuàng)企業(yè)，和沒(méi)有太多相關(guān)技術(shù)積累的傳統(tǒng)企業(yè)，Kubernetes的學(xué)習(xí)成本過(guò)高，企業(yè)會(huì)在底層架構(gòu)的高可用性、網(wǎng)絡(luò)、機(jī)房等方面遇到一系列問(wèn)題，從而讓容器化之路滿是荊棘。
3. Amazon EKS助力企業(yè)快速實(shí)現(xiàn)容器化轉(zhuǎn)型
? 如何快速、高效地?fù)碛凶约旱娜萜骰脚_(tái)呢？下面一段，就是AWS官網(wǎng)上Amazon EKS的介紹：
? Amazon EKS 是一項(xiàng)托管服務(wù),可讓您在 AWS 上輕松運(yùn)行 Kubernetes,而無(wú)需安裝、操作和維護(hù)您自己的 Kubernetes 控制層面或節(jié)點(diǎn)。Kubernetes 是一個(gè)用于實(shí)現(xiàn)容器化應(yīng)用程序的部署、擴(kuò)展和管理的自動(dòng)化的開(kāi)源系統(tǒng)。
? Amazon EKS 跨多個(gè)可用區(qū)運(yùn)行 Kubernetes 控制層面實(shí)例以確保高可用性。Amazon EKS 可以自動(dòng)檢測(cè)和替換運(yùn)行狀況不佳的控制層面實(shí)例，并為它們提供自動(dòng)版本升級(jí)和修補(bǔ)。
? Amazon EKS 與許多 AWS 服務(wù)集成以便為您的應(yīng)用程序提供可擴(kuò)展性和安全性,包括:
· 用于容器鏡像的 Amazon ECR
· 用于負(fù)載分配的 Elastic Load Balancing
· 用于身份驗(yàn)證的 IAM
· 用于隔離的 Amazon VPC
? Amazon EKS 運(yùn)行最新版本的開(kāi)源 Kubernetes 軟件,因此您可以使用 Kubernetes 社區(qū)中的所有現(xiàn)有插件和工具。在 Amazon EKS 上運(yùn)行的應(yīng)用程序與在任何標(biāo)準(zhǔn) Kubernetes 環(huán)境中運(yùn)行的應(yīng)用程序完全兼容，無(wú)論此類環(huán)境是在本地?cái)?shù)據(jù)中心還是在公有云中運(yùn)行都是如此。這意味著,您可以輕松地將任何標(biāo)準(zhǔn) Kubernetes 應(yīng)用程序遷移到 Amazon EKS,而無(wú)需修改任何代碼。
4. 理論結(jié)合實(shí)際，讓容器化更直觀
? 理論說(shuō)了一大堆，不如動(dòng)手玩起來(lái)。下面，我設(shè)計(jì)一個(gè)場(chǎng)景，在Amazon EKS上逐步完成容器化部署，并逐步在每個(gè)環(huán)節(jié)介紹技術(shù)細(xì)節(jié)。
1） 通過(guò)Nginx，做三個(gè)頁(yè)面web1，web2，web3
2）將三個(gè)web頁(yè)面作為一組服務(wù)，由Amazon EKS管理
3） 通過(guò)http訪問(wèn)，輪詢到三個(gè)不同的頁(yè)面，來(lái)看到效果
? 注釋：web1，web2，web3實(shí)際生產(chǎn)應(yīng)該是一個(gè)業(yè)務(wù)，只不過(guò)為了顯示實(shí)驗(yàn)效果，通過(guò)不同的頁(yè)面，展示輪詢的效果
4.1. 環(huán)境準(zhǔn)備
4.1.1. 需要一個(gè)AWS賬號(hào)
4.1.2. 賬號(hào)資源限制檢查，確保有足夠的IGW,VPC，EIP等
4.1.3. 安裝awscli（包含eksctl）及配置kubectl：
4.1.3.1. awscli安裝：
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
檢查安裝結(jié)果
$ aws --version
安裝方法參考鏈接：
https://docs.aws.amazon.com/zh_cn/cli/latest/userguide/cli-chap-install.html
4.1.3.2. 配置kubectl，
aws eks --region cn-northwest-1 update-kubeconfig --name my-zhy-eks
官方配置方法鏈接：
https://docs.amazonaws.cn/eks/latest/userguide/create-kubeconfig.html
4.2. 創(chuàng)建****Amazon EKS集群：
4.2.1. 創(chuàng)建命令
#命令，參數(shù)注釋
--node-type 工作節(jié)點(diǎn)類型
--nodes 工作節(jié)點(diǎn)數(shù)量
CLUSTER_NAME 集群名稱
AWS_REGION cn-northwest-1：寧夏區(qū)； cn-north-1：北京區(qū)
創(chuàng)建命令:
AWS_REGION=cn-northwest-1
AWS_DEFAULT_REGION=cn-northwest-1
CLUSTER_NAME=my-zhy-eks
eksctl create cluster --name=${CLUSTER_NAME} --version 1.15 --nodes=3 --node-type t3.medium --managed --alb-ingress-access --region=${AWS_REGION}
4.2.2. 成功執(zhí)行的輸出：
eksctl create cluster --name=${CLUSTER_NAME} --version 1.15 --nodes=3 --node-type t3.medium --managed --alb-ingress-access --region=${AWS_REGION}
[?] eksctl version 0.32.0
[?] using region cn-northwest-1
[?] setting availability zones to [cn-northwest-1b cn-northwest-1c cn-northwest-1a]
[?] subnets for cn-northwest-1b - public:192.168.0.0/19 private:192.168.96.0/19
[?] subnets for cn-northwest-1c - public:192.168.32.0/19 private:192.168.128.0/19
[?] subnets for cn-northwest-1a - public:192.168.64.0/19 private:192.168.160.0/19
[?] using Kubernetes version 1.15
[?] creating EKS cluster "my-zhy-eks" in "cn-northwest-1" region with managed nodes
[?] will create 2 separate CloudFormation stacks for cluster itself and the initial managed nodegroup
[?] if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=cn-northwest-1 --cluster=my-zhy-eks'
[?] CloudWatch logging will not be enabled for cluster "my-zhy-eks" in "cn-northwest-1"
[?] you can enable it with 'eksctl utils update-cluster-logging --enable-types={SPECIFY-YOUR-LOG-TYPES-HERE (e.g. all)} --region=cn-northwest-1 --cluster=my-zhy-eks'
[?] Kubernetes API endpoint access will use default of {publicAccess=true, privateAccess=false} for cluster "my-zhy-eks" in "cn-northwest-1"
[?] 2 sequential tasks: { create cluster control plane "my-zhy-eks", 2 sequential sub-tasks: { no tasks, create managed nodegroup "ng-e5146e45" } }
[?] building cluster stack "eksctl-my-zhy-eks-cluster"
[?] deploying stack "eksctl-my-zhy-eks-cluster"
[?] building managed nodegroup stack "eksctl-my-zhy-eks-nodegroup-ng-e5146e45"
[?] deploying stack "eksctl-my-zhy-eks-nodegroup-ng-e5146e45"
[?] waiting for the control plane availability...
[?] saved kubeconfig as "/root/.kube/config"
[?] no tasks
[?] all EKS cluster resources for "my-zhy-eks" have been created
[?] nodegroup "ng-e5146e45" has 3 node(s)
[?] node "ip-192-168-5-37.cn-northwest-1.compute.internal" is ready
[?] node "ip-192-168-58-97.cn-northwest-1.compute.internal" is ready
[?] node "ip-192-168-65-234.cn-northwest-1.compute.internal" is ready
[?] waiting for at least 3 node(s) to become ready in "ng-e5146e45"
[?] nodegroup "ng-e5146e45" has 3 node(s)
[?] node "ip-192-168-5-37.cn-northwest-1.compute.internal" is ready
[?] node "ip-192-168-58-97.cn-northwest-1.compute.internal" is ready
[?] node "ip-192-168-65-234.cn-northwest-1.compute.internal" is ready
[?] kubectl command should work with "/root/.kube/config", try 'kubectl get nodes'
[?] EKS cluster "my-zhy-eks" in "cn-northwest-1" region is ready
4.2.3. Eksctl執(zhí)行之后，需要等待10分鐘左右。模式很簡(jiǎn)單的步驟，其實(shí)是AWS通過(guò)調(diào)用cloudformation在后臺(tái)做了許多工作才完成的。下圖是cloudformation的stack步驟：
4.2.4. Amazon EKS完成后的，cloudformation狀態(tài)
4.2.5. 查詢node狀態(tài)信息
# kubectl get node
NAME STATUS ROLES AGE VERSION
ip-192-168-5-37.cn-northwest-1.compute.internal Ready <none> 11m v1.15.12-eks-31566f
ip-192-168-58-97.cn-northwest-1.compute.internal Ready <none> 11m v1.15.12-eks-31566f
ip-192-168-65-234.cn-northwest-1.compute.internal Ready <none> 11m v1.15.12-eks-31566f
4.2.6. 擴(kuò)展集群節(jié)點(diǎn)方法
? 我們之前通過(guò)eksctl創(chuàng)建了一個(gè)3節(jié)點(diǎn)的集群[WHE5] [XX6] ，如果由于業(yè)務(wù)的增加，希望擴(kuò)容的話，如何操作呢？具體命令參考如下，將當(dāng)前集群，擴(kuò)容到10個(gè)節(jié)點(diǎn)：
NODE_GROUP=$(eksctl get nodegroup --cluster ${CLUSTER_NAME} --region=${AWS_REGION} -o json | jq -r '.[].Name')
eksctl scale nodegroup --cluster=${CLUSTER_NAME} --nodes=10 --name=${NODE_GROUP} --region=${AWS_REGION}
檢查結(jié)果
eksctl get nodegroup --cluster ${CLUSTER_NAME} --region=${AWS_REGION}
eksctl get cluster
NAME REGION
my-zhy-eks cn-northwest-1
4.3.Amazon ECR的使用
? 針對(duì)一個(gè)企業(yè)，很多image都是定制化的，而定制化的私有image管理，在AWS是如何操作的呢？ Amazon ECR，讓image的管理，變得更簡(jiǎn)單易用。下面通過(guò)httpd的image，定制化并生成私有httpdok的image之后，并上傳到Amazon ECR，作為步驟演示：
4.3.1. 首先創(chuàng)建一個(gè)Amazon ECR Repositories ，選擇并點(diǎn)擊View push commands.
4.3.2. 根據(jù)”View puhs commands”步驟，將本地創(chuàng)建好的image，上傳到Amazon ECR。
具體命令步驟：
# aws ecr get-login-password --region cn-northwest-1 | docker login --username AWS --password-stdin <account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn
查看本地鏡像
# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
httpdok v1 df353399ffe4 7 seconds ago 299MB
為鏡像打標(biāo)簽
# docker tag httpdok:latest <account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn/httpdok:latest
在查看本地Docker的images，可以看到已經(jīng)出現(xiàn)一個(gè)新的，有ECR連接串的image
# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
<account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn/httpdok latest 9028c4373343 4 minutes ago 299MB
httpdok latest 9028c4373343 4 minutes ago 299MB
推送image到ECR上
# docker push <account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn/httpdok:latest
The push refers to repository [<account_id>.dkr.ecr.cn-northwest-1.amazonaws.com.cn/httpdok]
回到aws控制臺(tái)，已經(jīng)可以看到上傳的image
4.4.Amazon EKS實(shí)例演示
下面開(kāi)始部署容器到Amazon EKS中，通過(guò)Nginx來(lái)演示如何部署image到Amazon EKS，并輪詢?cè)L問(wèn).
4.4.1. 啟動(dòng)三個(gè)nginx pod 的 ReplicaSet
準(zhǔn)備yaml文件
cat <<EOF > nginx-deployment.yaml
apiVersion: Apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
EOF
執(zhí)行以下命令，進(jìn)行部署
kubectl apply -f nginx-deployment.yaml
檢查創(chuàng)建狀態(tài)
kubectl get pods -o wide
4.4.2. 創(chuàng)建LoadBalancer 服務(wù)
準(zhǔn)備yaml文件
cat <<EOF > loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: LoadBalancer
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
EOF
執(zhí)行以下命令，進(jìn)行部署
kubectl create -f loadbalancer.yaml
4.4.3. 檢查創(chuàng)建狀態(tài)
kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-service LoadBalancer 10.100.212.244 ae8e75d7e149044eb905b6bbff796e7e-629951941.cn-northwest-1.elb.amazonaws.com.cn 80:31248/TCP 7m53s
4.4.4. 監(jiān)測(cè)網(wǎng)頁(yè)顯示情況
curl -silent ae8e75d7e149044eb905b6bbff796e7e-629951941.cn-northwest-1.elb.amazonaws.com.cn | grep title
<title>Welcome to nginx!</title>
至此，我們已經(jīng)開(kāi)始使用EKS上的Nginx集群了。但是為了建議Load balance的工作效果。我們繼續(xù)下面的小實(shí)驗(yàn)，可以更好的觀察load balance的效果
4.5. 輪詢效果展示
4.5.1. 獲取pod信息
kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-deployment-574b87c764-92jbs 1/1 Running 0 10h
nginx-deployment-574b87c764-hmz9t 1/1 Running 0 10h
nginx-deployment-574b87c764-nqpmc 1/1 Running 0 10h
4.5.2. 以下命令是確定pod中nginx的歡迎界面的index.html位置
kubectl exec -it nginx-deployment-574b87c764-92jbs -- /usr/sbin/nginx -t
kubectl exec -it nginx-deployment-574b87c764-92jbs -- cat /etc/nginx/nginx.conf
kubectl exec -it nginx-deployment-574b87c764-92jbs -- ls /usr/share/nginx/html
kubectl exec -it nginx-deployment-574b87c764-92jbs -- cat /usr/share/nginx/html/index.html
kubectl exec -it nginx-deployment-574b87c764-92jbs -- cp/usr/share/nginx/html/index.html /usr/share/nginx/html/index.html.bk
注釋：kubectl exce的格式如下：
kubectl exec -it <podName> -c <containerName> -n <namespace> -- shell comand
4.5.3. 更改index.html內(nèi)容
在本地編輯文件name.html，然后上傳到3個(gè)Pod的容器中，
kubectl cp name.html nginx-deployment-574b87c764-nqpmc:usr/share/nginx/html/index.html
注釋： pod和本地之間傳輸文件命令格式
Pod下載文件到本地
kubectl cp -n NAMESPACE_name POD_name:Pod_FILE_name Local_FILE_name
本地上傳文件到Pod
kubectl cp Local_FILE_name -n NAMESPACE_name POD_name:Pod_FILE_name
最終查詢輸出結(jié)果，多次查詢，可以看到load balance會(huì)將連接隨機(jī)分配到不同Pod節(jié)點(diǎn)
curl -silent ae8e75d7e149044eb905b6bbff796e7e-629951941.cn-northwest-1.elb.amazonaws.com.cn | grep Node
輸出結(jié)果如下：
5. 總結(jié)
? 通過(guò)本文，大家已經(jīng)對(duì)容器化有一個(gè)初步的了解，并且針對(duì)Amazon EKS打造的企業(yè)容器化平臺(tái)也有了初步認(rèn)知。Docker，Kubernetes對(duì)于企業(yè)的系統(tǒng)和業(yè)務(wù)的發(fā)展，有著不可忽視的“助推力”。
? 然而，Kubernetes的學(xué)習(xí)曲線，以及企業(yè)的Kubernetes人才的積累,都是需要較長(zhǎng)的“時(shí)間”成本。而借助云計(jì)算供應(yīng)商的成熟平臺(tái)和產(chǎn)品，可以降低企業(yè)的技術(shù)人才的積累成本，從而達(dá)到事半功倍的效果。
? 我們通過(guò)這次實(shí)戰(zhàn)的演練，可以看到，基于Amazon EKS創(chuàng)建容器化平臺(tái)，只需一條命令。Amazon EKS讓Kubernetes的創(chuàng)建，運(yùn)行與維護(hù)變得簡(jiǎn)單、可靠。通過(guò)AWS Fargate，企業(yè)甚至可以完全省去虛擬機(jī)（EC2）的管理，只關(guān)注Kubernetes頂層業(yè)務(wù)架構(gòu)的邏輯即可，進(jìn)而可以將更多的“時(shí)間”專注在業(yè)務(wù)的開(kāi)發(fā)，而不是被底層架構(gòu)的種種問(wèn)題所拖累，也可以讓運(yùn)維人員逃離無(wú)盡的“救火”式運(yùn)維模式。
作者：忘記她
出處：https://www.cnblogs.com/ma159753/p/14219854.html
