11/01~11/07精選Container新聞

#雲端大當機、#GitHub
GitHub十月事件分析出爐!43秒網路斷線衍生24小時當機大災難

十月21日時,全球最大開源專案代管平臺GitHub發生了長達24小時又11分鐘的資料庫大當機,導致部分使用MySQL資料庫的服務,例如Issue和合併請求功能都無法使用。這是兩個開發團隊協作,或多人合作開發最常用的兩個工作,這也意味著長達一天時間,託管在GitHub上的開發專案,不論公開或私有專案,都難以多人協同作業,也因此,儘管沒有資料遺失,但這次當機仍引起了開發社群大抱怨。

事隔一周後,GitHub終於找出的大當機的原因,因為要在GitHub美東資料中心和美東網路中心之間連線用一臺100G光纖設備故障,為了更新這臺設備,這兩地之間的連線中斷了43秒,卻造成了後續一連串的災難。GitHub有一套用來儲存GitHub後設資料的MySQL資料庫叢集,平均流量少則數百GB,高峰時則會達到5TB之多。因此,這套資料庫叢集採取了高可用性設計,並且搭配了一套Orchestrator工具,來管理龐大的MySQL叢集的自動擴充或縮減調度。
但因美東機房短暫停機,導致美東機房的主要MySQL資料庫(Primary)和美西機房內的MySQL副本不一致,不只如此,因為美東機房無法連線,Orchestrator自動調度工具還將全球要寫入後設資料的資料庫寫入流量,導向了美西的MySQL叢集,讓美西MySQL叢集變成主要叢集。

但開發團隊擔心,猛然將主要MySQL的角色,拉回給美東資料庫叢集來接手,會導致資料的遺失。等到GitHub內部團隊緊急手動鎖住自動化部署工具後,並開始手動進行資料庫重建,離第一次連線中斷快40分鐘了。美東和美西資料庫的資料差異也非常大,將更拉大了美東和美西MySQL叢集資料的落差,進一步提高了後續資料同步和復原上的困難,讓GitHub團隊花了數十小時重建,才能確保回覆後資料的正確性。

#PaaS、#Cloud Foundry
Cloud Foundry基金會也要向K8s靠攏,先聚焦通用的監控和Log機制開發

開源PaaS平臺Cloud Foundry基金會也開始擁抱Kubernetes,IBM發起了一項新專案,要來打造一個Kubernetes內建的Cloud Foundry應用Runtime,可以讓Cloud Foundry PaaS上的應用程式,更容易部署到Kubernetes上。先前Cloud Foundry基金會才剛推出了容器化版PaaS軟體,可以透過BOSH將Cloud Foundry軟體部署到K8s上,現在又進一步要讓Cloud Foundry上的PaaS應用更容易和Kubernetes整合,不在自己獨力建立一個應用程式生態環境。不過,最後,Cloud Foundry基金會初步決定先聚焦在通用Log機制和監控機制的開發,另外也希望透過Istio服務和OSBAPI來串接兩個平臺的網路通訊。

#GKE、#VPC
GKE新推私有叢集、共享虛擬私有雲功能,支援白名單過濾

在Kubernetes日漸往雲端基礎架構新標準發展時,雲端廠商相關的企業級功能,也越來越完整。在近日Google公有雲旗下GKE服務,陸續增加企業級安全功能,包含私有叢集、共享虛擬私有雲(Shared Virtual Private Cloud)等服務。
新版第一個亮點是支援私有Kubernetes叢集。在此環境執行的工作負載皆會搭配私有IP,將這些應用限縮在虛擬私有雲內,保障Master與各節點間通訊的安全。如果維運人員想要存取GKE Master,必須在本地環境透過VPN、私有連線,才能登入,如要透過公有網路連線Kubernetes環境,管理者必須預先建立白名單,定使用者僅能透過特定公有IP登入,同時阻擋未授權IP與其連線。
而Kubernetes叢集服務,還可搭配GCP其他服務一起使用,如雲端容器儲存庫服務Container Registry、監控服務Stackdriver,無論開發者要存取映像檔、傳送Log資料,都可以在私有網路環境中進行。

#Docker映像檔、#部署工具
Cloudbees推新打包工具Custom WAR Packager,發布Docker映像檔更方便

不少開發者選用的DevOps工具Jenkins,最近其開發商Cloudbees針對開發者,推出新客製打包工具Custom WAR Packager,使用者可以將自己專屬的Jenkins版本、套件及組態設定,打包成WAR檔、Docker映像檔,或者Jenkinsfile。
該工具可以Maven套件、Docker打包檔,或者CLI執行檔的格式取得。使用者將所需套件、組態配置撰寫成YAML檔格式,接著交由Custom WAR Packager及Jenkinsfile Runner進行打包,輸出成Docker格式。在實際運作流程中,每當儲存庫完成建置時,Custom WAR Packager就會開始運作,將開發者指定的輸入檔案,重新打包成WAR檔。

#邊緣運算、#Mesosphere
老牌容器商Mesosphere翻新DC/OS,強化多雲和邊緣運算支援

以資料中心作業系統解決方案為訴求的Mesosphere,今年3月的DC/OS 1.11版正式支援Kubernetes後,近日再釋出1.12版,加強對多雲架構、邊緣運算的支援。
Mesosphere也釋出了自家的Kubernetes引擎MKE,可以將Kubernetes叢集同步部署在裸機、本地虛擬化或公有雲環境,透過集中式的自助管理服務,降低維運難度,也可提高基礎架構的運算密度。另外也加入了Universal Cloud Installer,四個步驟就可用10分鐘完成DC/OS叢集建置。第二個亮點功能則是處於Beta階段的MJS,讓開發者能隨需存取運算資源,並且內建資料科學家所需的開發工具、函式庫、框架,讓Jupyter Notebook在DC/OS成為隨需供應的服務。

#Serverless、#Knative
無伺服器競爭越來越激烈,又一家新創要通管三大公雲無伺服器服務

這個新興領域市場,近日又有新對手加入戰局,目前核心業務為無伺服器管理平臺的TriggerMesh,以Google開源釋出的無伺服器管理專案Knative為基礎,推出自家的無伺服器管理平臺TriggerMesh,因應多雲市場,該平臺已同步支援三大公有雲的無伺服器服務,包含AWS Lambda、Azure Functions跟Google Cloud Functions。TriggerMesh平臺作為伺服器應用的管理平臺,當開發者完成程式碼開發時,可以上傳至GitHub、GitLab、Bitbucket抑或本地Kubernetes叢集,接著透過TriggerMesh,利用事件將Function建立起連結,並且部署於AWS、Azure或GCP的無伺服器環境執行。

責任編輯/王宏仁

更多Container動態

  • Canonical自家Kubernetes開始支援Arm架構
  • 紅帽和Nvidia聯手,要強化GPU對OpenShift的支援

@資料來源:iThome整理,2018年10月

 

 

 


Advertisement

更多 iThome相關內容