🎹 個人簡介：大家好，我是 金魚哥，CSDN運維領域新星創作者，華為云·云享專家，阿里云社區·專家博主
📚個人資質：CCNA、HCNP、CSNA（網絡分析師），軟考初級、中級網絡工程師、RHCSA、RHCE、RHCA、RHCI、ITIL😜
💬格言：努力不一定成功，但要想成功就必須努力🔥

🎈支持我：可點贊👍、可收藏??、可留言📝

文章目錄

• • 📜管理OpenShift
  • • 📑OpenShift項目及應用
    • 📑使用Source-to-image構建映像
    • 📑管理OpenShift資源
  • 📜OpenShift網絡
  • • 📑OpenShift網絡概述
  • 📜OpenShift持久性存儲
  • • 📑永久存儲
  • 📜OpenShift高可用
  • • 📑OpenShift高可用概述
  • 📜Image Streams
  • • 📑Image Streams
• 摘自網上資料（摘自陳沙克老師的博客）
• • 📜虛擬化和容器–開源發展相似歷程（2017-10-25）
  • • 📑虛擬化
    • • 技術
      • 抽象層
      • 管理引擎
      • 產品化
    • 📑容器
    • • 技術
      • 抽象層
      • 管理引擎
      • 產品化
  • 📜OpenShift介紹（2017-10-19）
  • • 📑容器和Docker
    • 📑編排和kubernetes
    • 📑PaaS和OpenShift
    • 📑OpenShift版本
    • 📑OpenShift介紹
    • 📑OpenShift對手
    • 📑PaaS和IaaS關系
  • 📜OpenShift圖解（2017-11-9）
  • • 📑部署架構圖
    • 📑What isOpenShift
    • 📑Roadmap
    • 📑流程
    • 📑Compare
    • 📑Architecture
  • 📜OpenStack和Kubernetes相似的地方（2018-9-10）
  • • 📑看不到對手
    • 📑基金會管理
    • 📑架構
    • 📑部署
  • 💡總結

📜管理OpenShift

📑OpenShift項目及應用

除了Kubernetes的資源(如pods和services)之外，OpenShift還管理projects和users。一個projects對Kubernetes資源進行分組，以便用戶可以使用訪問權限。還可以為projects分配配額，從而限制了已定義的pod、volumes、services和其他資源。

OpenShift中沒有application的概念，OpenShift client提供了一個new-app命令。此命令在projects中創建資源，但它們都不是應用程序資源。這個命令是為標準開發人員工作流配置帶有公共資源

的proiect的快捷方式。OpenShift使用lables(標簽)對集群中的資源進行分類。默認情況下，OpenShift使用app標簽將相關資源分組到應用程序中。

---

📑使用Source-to-image構建映像

OpenShift允許開發人員使用標準源代碼管理倉庫(SCM)和集成開發環境(ide)來發布應用。

OpenShift中的source-to-lmage (S2I) 流程從SCM倉庫中提取代碼，自動判斷所需的runtime，基于runtime啟動一個pod，在pod中編譯應用。

當編譯成功時，將在runtime image中添加層并形成新的image，推送進入OpenShift internal registry倉庫，接著基于這個image將創建新的pod，運行應用程序。

S2I可被視為已經內置到OpenShift中的完整的CI/CD管道。

CI/CD有不同的形式，根據具體場景表現不同。例如，可以使用外部CI工具(如Jenkins)啟動構建并運行測試，然后將新構建的映像標記為成功或失敗，將其推送到QA或生產。

---

📑管理OpenShift資源

OpenShift資源定義,如image、container、pod、service、builder、template等，都存儲在Etcd中，可以由OpenShift CLI, web控制臺或REST API進行管理。

OpenShift的資源可通過JSON或YAML文件查看，并且在類似Git或版本控制的SCM中共享。OpenShift甚至可以直接從外部SCM檢索這些資源定義。

大多數OpenShift操作不需要實時響應，OpenShift命令和APIs通常創建或修改存儲在Etcd中的資源描述。Etcd然后通知OpenShift控制器，OpenShift控制器會就更改警告這些資源。

這些控制器采取行動，以便使得資源的最終態反應達到更改效果。例如，如果創建了一個新的pod資源，Kubernetes將在node上調度并啟動該pod，使用pod資源確定要使用哪個映像、要公開哪個端口，等等。或者一個模板被更改，從而指定應該有更多的pod來處理負載，OpenShift會安排額外的pod(副本)來滿足更新后的模板定義。

---

**注意：**雖然Docker和Kubernetes是OpenShift的底層，但是必須主要使用OpenShift CLi和OpenShift APls來管理應用程序和基礎設施。OpenShift增加了額外的安全和自動化功能，當直接使用Docker或Kubernetes命令和APls時，這些功能必須手動配置，或者根本不可用。因此強烈建議不要使用docker或Kubernetes的命令直接管理應用。

---

📜OpenShift網絡

📑OpenShift網絡概述

Docker網絡相對簡單，Docker創建一個虛擬內核橋接器（docker0網卡），并將每個容器網絡接口連接到它。Docker本身沒有提供允許一個主機上的pod連接到另一個主機上的pod的方法。Docker也沒有提供向應用程序分配公共固定IP地址的方法，以便外部用戶可以訪問它。

但Kubernetes提供service和route資源來管理pods之間的網絡，以及從外部到pods的路由流量。service在不同pods之間提供負載均衡用于接收網絡請求，同時為service的所有客戶機(通常是其他

pods)提供一個內部IP地址。container和pods不需要知道其他pods在哪里，它們只連接到service。route為service提供一個固定的惟一DNS名稱，使其對OpenShift集群之外的客戶端可見。

Kubernetes service和route資源需要外部（功能）插件支持。service需要軟件定義的網絡(SDN)，它將在不同主機上的pod之間提供通信，route需要轉發或重定向來自外部客戶端的包到服務內部IP。OpenShift提供了一個基于Open vSwitch的SDN，路由由分布式HAProxy farm提供。

---

📜OpenShift持久性存儲

📑永久存儲

pod可以在一個節點上停止，并隨時在另一個節點上重新啟動。同時pod的默認存儲是臨時存儲，通過對于類似數據庫需要永久保存數據的應用不適合。

Kubernetes為管理容器的外部持久存儲提供了一個框架。Kubernetes提供了PersistentVolume資源，它可以在本地或網絡中定義存儲。pod資源可以使用PersistentVolumeClaim資源來訪問對應的持久存儲卷。

Kubernetes還指定了一個PersistentVolume資源是否可以在pod之間共享，或者每個pod是否需要具有獨占訪問權的自己PersistentVolume。當pod移動到另一個節點時，它將保持與相同的PersistentVolumeClaim和PersistentVolumne資源的關聯。這意味著pod的持久存儲數據跟隨它，而不管它將在哪個節點上運行。

OpenShift向Kubernetes提供了多種VolumeProvider，如NFS、iSCSI、FC、Gluster或OpenStack Cinder。

OpenShift還通過StorageClass資源為應用程序提供動態存儲。使用動態存儲，可以選擇不同類型的后端存儲。后面存儲根據應用程序的需要劃分為不同的“tiers”。例如，可以定義一個名為“fast”的存儲類和另一個名為“slow”的存儲類，前者使用更高速的后端存儲，后者提供普通的存儲。當請求存儲時，最終用戶可以指定一個Persistentvolumeclaim，并使用一個注釋指定他們所需的StorageClass。

---

📜OpenShift高可用

📑OpenShift高可用概述

OpenShift平臺集群的高可用性(HA)有兩個不同的方面：OpenShift基礎設施本身的HA(即主機)；以及在OpenShift集群中運行的應用程序的HA。

默認情況下，OpenShift為master提供了完全支持的本機HA機制。

對于應用程序或“pods”，如果pod因任何原因丟失，Kubernetes將調度另一個副本，將其連接到服務層和持久存儲。如果整個節點丟失，Kubernetes會為它所有的pod安排替換節點，最終所有的應用程序都會重新可用。pod中的應用程序負責它們自己的狀態，因此它們需要自己維護應用程序狀態(如HTTP會話復制或數據庫復制)。

---

📜Image Streams

📑Image Streams

要在OpenShift中創建一個新的應用程序，除了應用程序源代碼之外，還需要一個base image(S2I builder image)。如果源代碼或image任何一個更新，就會生成一個新的image，并且基于此新image創建新的pod，同時替換舊的pod。

即當應用程序代碼發生更改時，容器鏡像需要更新，但如果構建器鏡像發生更改，則部署的pod也需

要更新。

Image Streams包括由tag標識的大量的image。應用程序是針對Image Streams構建的。Image Streams可用于在創建新image時自動執行操作。構建和部署可以監視Image Streams，以便在添加新image時接收通知，并分別執行構建或部署。

OpenShift默認情況下提供了幾個Image Streams，包括許多流行的runtime和frameworks。Image Streams tag是指向Image Streams中的image的別名。通常縮寫為istag。它包含一個image歷史記錄，表示為tag曾經指向的所有images的堆棧。每當使用特定的istag標記一個新的或現有的image時，它都會被放在歷史堆棧的第一個位置(標記為latest)。之前tag再次指向舊的image。同時允許簡單的回滾，使標簽再次指向舊的image。

---

摘自網上資料（摘自陳沙克老師的博客）

感謝陳沙克（可自行百度一下，大神級人物，九州云副總裁）老師的文章分享讓我們能夠學習得更多。

📜虛擬化和容器–開源發展相似歷程（2017-10-25）

其實回顧一下虛擬化和容器的發展歷程，很大程度是驚人相似。我這里其實肯定不是很嚴謹的描述。僅僅是大概介紹一下過程。

---

📑虛擬化

技術

商業的虛擬化技術其實也不少。開源的的也是一樣。著名的就是Xen和KVM兩家。

Xen

KVM

Xen是2003年發布。KVM進入linux內核，真正第一個操作系統支持，當時據說是：ubuntu 8.04，也就是2008年，當時的KVM，還是一個玩具。

2010年，紅帽發布RHEL 6.0，KVM算是正式進入主流。當時全球虛擬化，公有云，基本都是Xen的天下。

經過了5年的PK，現在已經是KVM獨大。目前AWS，阿里云，已經全面轉向KVM。

Xen的沒落，很多原因，其中一個，就是intel搞了一套cpu虛擬化的東西，幫助kvm勝出。

KVM的想法其實應該是2006年，為了對抗Xen，intel，紅帽，IBM，聯手搞出一個KVM，放到內核里。

---

抽象層

那么多虛擬化引擎，那么肯定有人想到要做一個統一管理工具，這樣可以管理多個。這樣Libvirt就出現了。

Libvirt最擅長管理KVM，不過其實別的都是可以管理。

管理引擎

虛擬化的技術，其實需要有管理工具，那么他的管理工具有哪些呢

• OpenStack
• CloudStack
• Eucalptus
• OpenNebula

---

其實還要很多，這些管理工具，當時是能管理Xen和Kvm，也有專門針對某個虛擬化的管理工具

Xen Server，專門管理Xen

Ovirt，專門管理KVM

這些工具，從2008年，一直pk到2014年，終于分出的高低。最后是OpenStack+KVM勝出。

管理引擎，也是通過抽象層，Libvirt去管理KVM的。

---

產品化

其實就是針對管理引擎的產品化。你需要把管理引擎包裝出來，加上很多輔助的工具，讓用戶用的很爽。

紅帽TrippleO

Mirantis的Fuel

Kolla

其實Ubuntu和Suse，都有他們的產品。

Mirantis的Fuel和Suse的Crowbar，大概是2014年出現，到現在也經歷了3年多。從我的角度，最終就是Kolla徹底勝出，毫無懸念啊。

---

OpenStack的創業公司，目前還能有口飯吃，其實是要謝謝紅帽。紅帽因為在OpenStack上的策略有所失誤，導致沒能在OpenStack一統天下。要記住啊，

當年kolla項目可是TrippleO的一個子項目，

Kolla項目的創始人，也是紅帽的工程師，

ansible，Ceph都是紅帽自家產品啊，

Cobbler，也是Ansible公司的人在維護。

libvirt，qemu，kvm都是紅帽的

---

📑容器

技術

容器的技術，起源很早，我最早接觸是OpenVZ，這個讓國內很多賣虛擬機掙錢的軟件。對于開源，流行的容器來說

LXC

Docker

LXD

RTK

Clean container

LXC，國內互聯網2010年就開始使用。不過目前最流行的是Docker，

Docker從2013年發布到現在，其實發展速度很快，很多廠商都來不及響應，這個東西就成為主流。這個時候，intel又想重施故技，搞一個和cpu有關的容器技術，所謂的Clean Container。

不過這次由于Docker發展過于迅速，intel這次搞容器，完全是自己玩，不像當年和紅帽勾搭在一起。所以很難在市場立足。

---

抽象層

和虛擬化其實一樣道理，底層那么多容器技術，如何方便管理呢。

CRI Interface, Container RunTime Interface，就出現了，做了一層抽象后，各個廠商就可以和平共處。

---

管理引擎

對于容器來說，也叫編排引擎，這個大家就比較熟悉3大編排引擎

K8S

Swarm

Messos

K8S是從2014年7月份推出，到2017年7月份，基本上是完勝。廠商紛紛投降。K8s+Docker和虛擬化也是一樣，目前K8s，是通過CRI，去管理Docker。

---

產品化

用戶要用起來，要把k8s，或者messos用起來，那么還是需要做很多工作。業界最著名的產品就是

OpenShift

Racher

國內的很多容器公司，k8s公司，其實都是在做類似的工作，在K8s上增加自己定制，形成自己的產品。包括現在CloudFountry，都號稱要支持K8s。背后的故事也很多，Racher當時號稱要管理3個引擎，k8s，swarm和messos，最新的2.0的版本，就只管理K8s。

還是紅帽厲害，2014年K8s發布，馬上轉方向，全面發力K8s，包裝自己的OpenShift產品。當紅帽已經做出勢頭的時候，那是無人能敵的。這種K8s的產品化，基本也是毫無懸念，OpenShift勝出。

---

📜OpenShift介紹（2017-10-19）

現在開始搞PaaS平臺，那么OpenShift就必須研究一下，這里寫篇文章，把我過去一個月的理解，整理一下。

以前都是搞OpenStack，IaaS層面，發現對PaaS層面，了解不多。不過幸好當時搞Kolla，把OpenStack容器化，對我現在理解PaaS，還是有很大的幫助。

---

📑容器和Docker

其實這個對我來說，還是比較熟悉，可以說的清楚。市場上的容器，基本都是Docker，有很多其他容器廠商，不過目前看來還是很難和Docker來PK。

那么對于軟件行業來說，我自己是深刻體會Docker帶來的變化。是一個革命性的應用。Docker從2013年發布，到現在已經五年，已經進入比較穩定的階段。

---

📑編排和kubernetes

編排，這個詞，對于不是開發人員來說，還是不好理解。其實就是當你的應用放到容器里的時候，容器的啟動順序是有要求的。那么這個時候就需要用編排。

對容器的編排，其實很多工具可以實現。對于OpenStack容器化項目kolla來說。ansible目前是編排工具，其實也挺好。這主要一個原因就是在規模不大，容量數量不多，環境不復雜的情況下，ansible編排，是可以滿足需求的。

對編排一個需求，就是一個服務如果掛掉，編排工具可以自動啟動，壓力大的時候，會橫向擴容。不過在OpenStack的場景下，無狀態的服務，從來都不是瓶頸，nova api，服務我用了OpenStack那么久，沒遇到過掛掉的。

對于有狀態的服務，其實編排工具是無法實現所謂的橫向擴容。例如數據庫和消息隊列。

編排工具，目前最大的玩家，就是k8s。基本所有廠商都用它。

那么k8s和paas是什么關系。經常在會議上，很多講座，就把k8s當成PaaS來介紹。

K8S是一個容器編排工具，要實現PaaS的功能，其實還需要在上面做很多工作，監控，日志，CI，CD等。那么這些工具，你可以自己組合，結合自己的公司的需求，搞出一套PaaS平臺。

---

📑PaaS和OpenShift

真正意義上的PaaS，其實就是業界兩家：

• vmware 的CloudFoundry
• 紅帽的OpenShift

2015年的時候，這兩家的PaaS，都是ruby開發，思路基本都是一樣，江湖傳聞，兩位項目創始人酒吧喝完酒，各自搞了一個項目。不過在市場上，CloudFoundry聲音是比較大的。遠超過紅帽。

2015年的時候，華為，IBM，HP的所謂PaaS平臺，都是基于CloudFoundry來修改的。

K8s，2014年7月份發布第一個版本，2015年七月份，發布1.0的產品，那么這個時候紅帽看到的機會，也是在這個時候，業界的風向發生的改變，紅帽，華為，IBM，把底層都改成K8S。

2015年，紅帽推出基于k8s的OpenShift。

Openshift 3.0的產品，就全面轉向K8S。可以這樣理解，以前的代碼全部扔掉，重新來過一次。很神奇的事情，2016年，紅帽就宣布OpenShift掙大錢。同時也加大投入。

---

OpenShift對紅帽有多么重要呢？已經成為的第二大收入來源。第一大肯定是操作系統。

那么新版的OpenShift和以前的OpenShift有啥區別呢？

---

其實以前的PaaS平臺一個通病，就是要把應用放到PaaS上，你是必須對代碼進行修改才行。例如大家可能以前也去紅帽的OpenShift官網測試過一個wordpress的實驗，這個wordpress，是要經過代碼修改的。一旦進行了update更新，就肯定會掛掉。

現在的OpenShift，不需要你做任何的代碼修改，就可以放上去PaaS平臺，所以肯定也是能update。

CloudFoundry，剛剛也對外宣布，底層也要支持K8s，不過已經晚了。紅帽的勢頭已經起來。你就完全沒有機會了。

我和朋友開玩笑說：紅帽的OpenStack勢頭沒做起來，導致OpenStack廠商還能有口飯吃。紅帽的PaaS平臺，K8s已經勢頭起來了，別的廠商，其實已經空間不大了。

---

📑OpenShift版本

紅帽的一貫風格，都是開源版本，商業版本，命名也不一樣。從上面圖其實就可以看出來，也讓用戶感覺很混亂。

到了OpenShift 3.6的版本，集成的K8s 1.6的版本，版本就清晰很多

開源版本：OpenShift Origin 3.6

商業版本：OpenShift 3.6

我的理解，代碼都是一樣，就是一個商業支持的區別。

---

從紅帽的發布OpenShift版本可以看出，基本是一年4個版本，緊跟K8S。目前K8S最新版本是1.8。落后2個版本。

k8s 1.5的版本是2016年12月23日，紅帽的OpenShift 3.5，是2017年4月份發布

K8s 1.6的版本是2017年3月22日發布的，紅帽的OpenShift 3.6是2017年7月底。紅帽需要4個月時間發布一個版本。

https://www.kubernetes.org.cn/1353.html

2017年12月13日 k8s v1.9.0正式版本發布！

Kubernetes 1.1的版本是，2015年11月9日發布。

---

📑OpenShift介紹

很多人說紅帽的OpenShift就是一個K8S，其實這是一個不算太正確的理解。OpenShift，目前的版本，可以理解成一個真正意義上的PaaS。

紅帽在K8S上封裝了一層，你基本上已經用不上K8S的命令。上面提供紅帽的UI，集成了日志，監控，鏡像倉庫等功能。也集成的CI，CD。

比如你希望在K8s跑一個mysql的群集，Redis的群集，那么這些都是需要廠商做很多工作才能實現，紅帽提供全套的服務。

---

📑OpenShift對手

很多廠商基于K8S做出自己的PaaS平臺，例如IBM的Bluemix。但是真正能產品化的，也就

OpenShift和Racher。

目前市場上OpenShift肯定是領先的。紅帽的開源優勢發揮出來。

---

📑PaaS和IaaS關系

大家可以受那張圖的影響，認為PaaS必須跑在IaaS上。那么其實兩者可以沒任何關系，也是可以密切聯系。

紅帽的OpenShift，基本支持所有的平臺，物理機器的部署，OpenStack里部署，和虛擬機里部署。

目前OpenShift的部署，是通過Ansible來實現，非常方便。

IaaS平臺上，很多組件可以是PaaS通過軟件提供，也可以是IaaS提供，例如負載均衡，DNS服務，Nas服務，如果Iaas平臺提供這些服務，那么跑PaaS平臺，OpenShift，就更加方便可靠。

對于實際的PaaS應用來說，微服務用到有狀態的服務，例如數據庫，mysql，redis。目前業界都是推薦直接使用IaaS平臺的，目前在PaaS層跑有狀態的應用，業界的測試還是不夠的。

---

📜OpenShift圖解（2017-11-9）

📑部署架構圖

---

📑What isOpenShift

---

📑Roadmap

---

📑流程

developer provides git repo

Developer chooses image from grgistry

layer is applied to image

layer is added back to registry

image is scheduled and deployed

Developer can declare webhooks

updated image is added back to the registry

New Images is depoyed as rooling update

---

📑Compare

📑Architecture

---

📜OpenStack和Kubernetes相似的地方（2018-9-10）

我也算是折騰了一年的OpenShift，OpenShift，就是Kubernetes的一個發行版，我的感覺，其實他們相似的地方還是很多，對我的改變并沒有想象那么大。

下面總結一下他們的相同的地方

---

📑看不到對手

無論是OpenStack還是kubernetes，都是在重圍中殺出來，一騎絕塵，根本看不到對手。

OpenStack干掉CloudStack，Eucalyptus，OpenNebula。

Kubernetes，干掉swam ，messos

都是壓倒性的優勢勝出。

區別就在于，OpenStack勝出以后，就迷失了方向，往自己不擅長的邊緣計算，最終只能是一條不歸路。

K8s勝出后，社區的想法還是很多，還保持1年4個版本的迭代。

一個是python最大的開源項目，一個是Go語言最大的開源項目。

---

📑基金會管理

OpenStack專門成立基金會管理，不過基金會不涉及技術方向，技術方向有專門的TC，技術委員會管理，當big tent，大帳篷策略后，TC的用途也就不大，而且TC混日子的人也多了。

OpenStack官方目前有60多個項目，其實大部分都是僵尸項目，停留在實驗室階段，根本就沒生產使用案例。真的能用的項目，應該不超過15個。

k8s，其實也歸屬CNCF基金會。吸取OpenStack基金會的教訓。對項目是加入，孵化，畢業，有了嚴格的流程。這個可以很好避免。

OpenStack技術設計的時候，很糾結規模優先還是功能優先。公有云為主，還是私有云為主。這個也導致一直無法明確。

我的理解，K8s的功能，逐步的玩企業級發展。無論是用k8s支持有狀態的應用，還是讓k8s管理vm，方向都非常明確。

---

📑架構

看完OpenStack的架構演變過程，再看k8s，感覺相似的地方很多的。

• Nova==CRI-O
• cinder=CSI
• Neutron=CNI

計算，存儲，網絡，都搞一個，無論是OpenStack，還是k8s，基本都是一樣的玩法，讓廠商都能參與進來。

---

目前k8s上沒有統一的身份認證，就沒有keystone，k8s上，沒提供鏡像倉庫，就沒有glance。

事實上也是有一堆的應用，對于OpenStack組件

• keystone+ldap=keycloak+ldap
• glance=Quay or harbor

---

📑部署

大家都感覺OpenStack很復雜，如果和k8s比起來，其實算是簡單的。k8s的部署，單單是一個雙向的證書，都能讓你折騰一個半天。

但是用戶一般感覺k8s比較簡單，一個原因，就是k8s自己做的部署管理工具比較成熟。目前紅帽的OpenShift，已經采用全容器化的部署方案部署OpenShift，并且容器的管理，也是在Openshift上，真的比較完善。升級的問題，也就變得很簡單。

OpenStack目前部署方案的方向也是容器化部署，不過還無法實現用k8s來管理，只能通過ansible來管理。

對我來說，

• kolla-ansible 部署OpenStack
• openshift-ansible 部署OpenShift

都是通過ansible來實現。

---

💡總結

RHCA認證需要經歷5門的學習與考試，還是需要花不少時間去學習與備考的，好好加油，可以噶🤪。

以上就是【金魚哥】對 第一章 介紹紅帽OPENSHIFT容器平臺–管理OpenShift與課外補充 的簡述和講解。希望能對看到此文章的小伙伴有所幫助。

💾紅帽認證專欄系列：
RHCSA專欄：戲說 RHCSA 認證
RHCE專欄：戲說 RHCE 認證
此文章收錄在RHCA專欄：RHCA 回憶錄

如果這篇【文章】有幫助到你，希望可以給【金魚哥】點個贊👍，創作不易，相比官方的陳述，我更喜歡用【通俗易懂】的文筆去講解每一個知識點。

如果有對【運維技術】感興趣，也歡迎關注?????? 【金魚哥】??????，我將會給你帶來巨大的【收獲與驚喜】💕💕！

總結

以上是生活随笔為你收集整理的DO280介绍红帽OPENSHIFT容器平台--管理OpenShift与课外补充的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。