Container周报第89期：43秒网络断线衍生24小时GitHub当机大灾难
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月
