关于 Kubernetes 规划的灵魂 n 问

alicloudnative阅读(934)评论(0)

作者 | 易立 阿里云资深技术专家

导读:Kubernetes 已经成为企业新一代云 IT 架构的重要基础设施,但是在企业部署和运维 Kubernetes 集群的过程中,依然充满了复杂性和困扰

阿里云容器服务自从 2015 年上线后,目前托管着上万的 K8s 集群来支撑全球各地的客户。我们对客户在规划集群过程中经常会遇见的问题,进行一些分析解答。试图缓解大家的“选择恐惧症”。

1.jpeg

如何选择 Worker 节点实例规格?

裸金属还是虚拟机?

在 Dimanti 2019 年的容器调查报告中,对专有云用户选择裸金属服务器来运行容器的主要原因进行了分析。

2.png

  1. 选择裸金属服务器的最主要原因(超过 55%)是:传统虚拟化技术 I/O 损耗较大;对于 I/O 密集型应用,裸金属相比传统虚拟机有更好的性能表现;
  2. 此外近 36% 的客户认为:裸金属服务器可以降低成本。大多数企业在初始阶段采用将容器运行在虚拟机的方案,但是当大规模生产部署的时候,客户希望直接运行在裸金属服务器上来减少虚拟化技术的 license 成本(这也常被戏称为“VMWare 税”);
  3. 还有近 30% 的客户因为在物理机上部署有更少的额外资源开销(如虚拟化管理、虚拟机操作系统等);还有近 24% 的客户选择的原因是:可以有更高的部署密度,从而降低基础设施成本;
  4. 超过 28% 的客户认为,在物理机上可以更加灵活地选择网络、存储等设备和软件应用生态。

在公共云上,我们应该如何选择呢?2017 年 10 月,阿里云“神龙架构”横空出世。弹性裸金属服务器(ECS Bare Metal Instance)是一款同时兼具虚拟机弹性和物理机性能及特性的新型计算类产品,实现超强超稳的计算能力,无任何虚拟化开销。阿里云 2019 年 8 月重磅发布了弹性计算第六代企业级实例,基于神龙架构对虚拟化能力进行了全面升级。

  • 基于阿里自研神龙芯片和全新的轻量化 Hypervisor – 极大减少虚拟化性能开销。基于阿里云智能神龙芯片和全新的轻量化 VMM,将大量传统虚拟化功能卸载到专用硬件上,大大降低了虚拟化的性能开销,同时用户几乎可以获得所有的宿主机 CPU 和内存资源,提高整机和大规格实例的各项能力,尤其是 I/O 性能有了大幅度提升;
  • 使用最新第二代英特尔至强可扩展处理器 – E2E 性能提升。使用最新一代 Intel Cascade Lake CPU, 突发主频提升至 3.2GHz, 各场景 E2E 性能大幅提升,并在深度学习的多种场景有数倍的提升;
  • 给企业级场景带来稳定和可预期的表现 – 全球最高水准 SLA。针对软硬件优化以及更加实施更细致的 QoS 手段,给企业级客户的负载提供更稳定可预期的性能。

3.png
4.png

一般而言建议:

  • 对性能极其敏感的应用,如高性能计算,裸金属实例是较好的选择;
  • 如果需要 Intel SGX,或者安全沙箱等技术,裸金属实例是不二选择;
  • 六代虚拟机实例基于神龙架构,I/O 性能有了显著提升,同时有更加丰富的规格配置,可以针对自身应用需求灵活选择,降低资源成本;
  • 虚拟机实例支持热迁移,可以有效降低运维成本。

阿里云 ACK K8s 集群支持多个节点伸缩组(AutoScalingGroup),不同弹性伸缩组支持不同的实例规格。在工作实践,我们会为 K8s 集群划分静态资源池和弹性资源池。通常而言,固定资源池可以根据需要选择裸金属或者虚拟机实例。弹性资源池建议根据应用负载使用合适规格的虚拟机实例来优化成本、避免浪费,提升弹性供给保障。此外由于裸金属实例一般 CPU 核数非常多,大规格实例在使用中的挑战请参见下文。

较少的大规格实例还是较多的小规格实例?

一个引申的问题是,如何选择实例规格?我们列表对比一下:

5.png

默认情况下,kubelet 使用 CFS 配额 来执行 pod 的 CPU 约束。当节点上运行了很多 CPU 密集的应用时,工作负载可能会迁移到不同的 CPU 核,工作负载的会受到 CPU 缓存亲和性以及调度延迟的影响。当使用大规格实例类型时,节点的 CPU 数量较多,现有的 Java,Golang 等应用在多 CPU 共享的场景,性能会出现明显下降。所有对于大规格实例,需要对 CPU 管理策略进行配置,利用 CPU set 进行资源分配。

此外一个重要的考虑因素就是 NUMA 支持。在 NUMA 开启的裸金属实例或者大规格实例上,如果处理不当,内存访问吞吐可能会比优化方式降低了 30%。Topology 管理器可以开启 NUMA 感知 。但是目前 K8s 对 NUMA 的支持比较简单,还无法充分发挥 NUMA 的性能。

https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/

阿里云容器服务提供了 CGroup Controller 可以更加灵活地对 NUMA 架构进行调度和重调度。

如何容器运行时?

Docker 容器还是安全沙箱?

在 Sysdig 发布的 2019 容器使用报告中,我们可以看到 Docker 容器占据市场规模最大的容器运行时 (79%),containerd 是 Docker 贡献给 CNCF 社区的开源容器运行时,现在也占据了一席之地,并且得到了厂商的广泛支持;cri-o 是红帽公司推出的支持 OCI 规范的面向 K8s 的轻量容器运行时,目前还处在初级阶段。

6.png

很多同学都关心 containerd 与 Docker 的关系,以及是否 containerd 可以取代 Docker?Docker Engine 底层的容器生命周期管理也是基于 containerd 实现。但是 Docker Engine 包含了更多的开发者工具链,比如镜像构建。也包含了 Docker 自己的日志、存储、网络、Swarm 编排等能力。此外,绝大多数容器生态厂商,如安全、监控、日志、开发等对 Docker Engine 的支持比较完善,对 containerd 的支持也在逐渐补齐。

所以在 Kubernetes 运行时环境,对安全和效率和定制化更加关注的用户可以选择 containerd 作为容器运行时环境。对于大多数开发者,继续使用 Docker Engine 作为容器运行时也是一个不错的选择。

7.png

此外,传统的 Docker RunC 容器与宿主机 Linux 共享内核,通过 CGroup 和 namespace 实现资源隔离。但是由于操作系统内核的攻击面比较大,一旦恶意容器利用内核漏洞,可以影响整个宿主机上所有的容器。

越来越多企业客户关注容器的安全性,为了提升安全隔离,阿里云和蚂蚁金服团队合作,引入安全沙箱容器技术。19 年 9 月份我们发布了基于轻量虚拟化技术的 RunV 安全沙箱。相比于 RunC 容器,每个 RunV 容器具有独立内核,即使容器所属内核被攻破,也不会影响其他容器,非常适合运行来自第三方不可信应用或者在多租户场景下进行更好的安全隔离。

阿里云安全沙箱容器有大量性能优化,可以达到 90% 的原生 RunC 性能:

  • 利用 Terway CNI 网络插件,网络性能无损;
  • 利用 DeviceMapper 构建了⾼速、稳定的容器 Graph Driver;
  • 优化 FlexVolume 和 CSI Plugin,把 mount bind 的动作下沉到沙箱容器内,从而避开了 9pfs 带来的性能损耗。

而且,ACK 为安全沙箱容器和和 RunC 容器提供了完全一致的用户体验,包括日志、监控、弹性等。同时,ACK 可以在一台神龙裸金属实例上同时混布 RunC 和 RunV 容器,用户可以根据自己的业务特性自主选择。

8.jpeg

同时,我们也要看到安全沙箱容器还有一些局限性,现有很多日志、监控、安全等工具对独立内核的安全沙箱支持不好,需要作为 sidecar 部署在安全沙箱内部。

对于用户而言,如果需要多租户隔离的场景,可以采用安全沙箱配合 network policy 来完成,当然也可以让不同租户的应用运行在不同的虚拟机或者弹性容器实例上,利用虚拟化技术来进行隔离。

注意:安全沙箱目前只能运行在裸金属实例上,当容器应用需要资源较少时成本比较高。可以参考下文的 Serverless K8s 有关内容。

如何规划容器集群?

一个大集群还是一组小集群?

在生产实践中,大家经常问到的一个问题是我们公司应该选择一个还是多个 Kubernetes 集群。

Rob Hirschfeld 在 Twitter 上做了一个调查:

  • 一个大一统的平台,支持多种应用负载、环境和多租户隔离;
  • 或者,一组以应用为中心的小集群,支持不同应用和环境的生命周期管理。

https://thenewstack.io/the-optimal-kubernetes-cluster-size-lets-look-at-the-data/

9.png

大多数的用户选择是后者,典型的场景是:

  • 开发、测试环境使用不同的集群
  • 不同的部门使用不同的集群进行隔离
  • 不同的应用使用不同的集群
  • 不同版本的 K8s 集群

在用户反馈中,采用以多个小集群的主要原因在于爆炸半径比较小,可以有效提升系统的可用性。同时通过集群也可以比较好地进行资源隔离。管理、运维复杂性的增加是采用多个小集群的一个不足之处,但是在公共云上利用托管的 K8s 服务(比如阿里云的 ACK)创建和管理 K8s 集群生命周期非常简单,可以有效解决这个问题。

我们可以比较一下这两种选择:
10.png

源自 Google Borg 的理念,Kubernetes 的愿景是成为 Data Center Operating System,而且 Kubernetes 也提供了 RBAC、namespace 等管理能力,支持多用户共享一个集群,并实现资源限制。但是这些更多是 “软多租” 能力,不能实现不同租户之间的强隔离。在多租最佳实践中,我们可以有如下的一些建议:

  • 数据平面:可以通过 PSP (PodSecurityPolicy) 或者安全沙箱容器,提升容器的隔离性;利用 Network Policy 提升应用之间网络隔离性;可以通过将 nodes 和 namespace 绑定在一起,来提升 namespace 之间资源的隔离;
  • 控制平面:Kubernetes 的控制平面包括 master 组件 API Server, Scheduler, etcd 等,系统 addon 如 CoreDNS, Ingress Controller 等,以及用户的扩展,如 3 方的 CRD (Customer Resource Definition) controller。这些组件大多不具备良好的租户之间的安全、资源和故障隔离能力。一个错误的 CRD contoller 实现有可能打挂一个集群的 API Server。

关于 Kubernetes 多租户实践的具体信息可以参考下文。目前而言,Kubernetes 对硬隔离的支持存在很多局限性,同时社区也在积极探索一些方向,如阿里容器团队的 Virtual Cluster Proposal 可以提升隔离的支持,但是这些技术还未成熟。

https://www.infoq.cn/article/NyjadtOXDemzPWyRCtdm?spm=a2c6h.12873639.0.0.28373df9R7x2DP

https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/virtualcluster?spm=a2c6h.12873639.0.0.28373df9R7x2DP

另一个需要考虑的方案是 Kubernetes 自身的可扩展性,我们知道一个 Kubernetes 集群的规模在保障稳定性的前提下受限于多个维度,一般而言 Kubernetes 集群小于 5000 节点。当然,运行在阿里云上还受限于云产品的 quota 限制。阿里经济体在 Kubernetes 规模化上有丰富的经验,但是对于绝大多数客户而言,是无法解决超大集群的运维和定制化复杂性的。

11.png

对于公共云客户我们一般建议,针对业务场景建议选择合适的集群规模:

  • 对于跨地域(region)场景,采用多集群策略,K8s 集群不应跨地域。我们可以利用 CEN 将不同地域的 VPC 打通;
  • 对于强隔离场景,采用多集群策略,不同安全域的应用部署在不同的集群上;
  • 对于应用隔离场景,比如 SaaS 化应用,可以采用单集群方式支持多租,并加强安全隔离;
  • 对于多个大规模应用,可以采用多集群策略,比如,在线应用、AI 训练、实时计算等可以运行在不同的 K8s 集群之上,一方面可以控制集群规模,一方面可以针对应用负载选择合适的节点规格和调度策略。

由于有 VPC 中节点、网络资源的限制,我们可以甚至将不同的 K8s 集群分别部署在不同的 VPC,利用 CEN 实现网络打通,这部分需要对网络进行前期规划。

  • 如果需要对多个集群的应用进行统一管理,有如下几个考虑;
  • 利用 Kubefed 构建集群联邦,ACK 对集群联邦的支持可以参考。

https://help.aliyun.com/document_detail/121653.html?spm=a2c6h.12873639.0.0.28373df9R7x2DP

利用统一的配置管理中心,比如 GitOps 方式来管理和运维应用。

https://github.com/fluxcd/flux?spm=a2c6h.12873639.0.0.28373df9R7x2DP

另外利用托管服务网格服务 ASM,可以利用 Istio 服务网格轻松实现对多个 K8s 集群的应用的统一路由管理。

如何选择 K8s 或者 Serverless K8s 集群?

在所有的调查中,K8s 的复杂性和缺乏相应的技能是阻碍 K8s 企业所采用的主要问题,在 IDC 中运维一个 Kubernetes 生产集群还是非常具有挑战的任务。阿里云的 Kubernetes 服务 ACK 简化了 K8s 集群的生命周期管理,托管了集群的 master 节点被,但是用户依然要维护 worker 节点,比如进行升级安全补丁等,并根据自己的使用情况进行容量规划。

针对 K8s 的运维复杂性挑战,阿里云推出了 Serverless Kubernetes 容器服务 ASK。

完全兼容现有 K8s 容器应用,但是所有容器基础设施被阿里云托管,用户可以专注于自己的应用。它具备几个特点:

  1. 首先它按照容器应用实际消耗的资源付费,而不是按照预留的节点资源付费;
  2. 对用户而言没有节点的概念,零维护;
  3. 所有资源按需创建,无需任何容量规划。

12.png

在 ASK 中,应用运行在弹性容器实例 – ECI (Elastic Container Instance)中,ECI 基于轻量虚拟机提供的沙箱环境实现应用安全隔离,并且完全兼容 Kubernetes Pod 语义。在 ASK 中我们通过对 Kubernetes 做减法,将复杂性下沉到基础设施,极大降低了运维管理负担,提升用户体验,让 Kubernetes 更简单,让开发者更加专注于应用自身。除了无需管理节点和 Master 外,我们将 DNS, Ingress 等能力通过阿里云产品的原生能力来实现,提供了极简但功能完备的 Kubernetes 应用运行环境。

Serverless Kubernetes 极大降低了管理复杂性,而且其自身设计非常适合突发类应用负载,如 CI/CD,批量计算等等。比如一个典型的在线教育客户,根据教学需要按需部署教学应用,课程结束自动释放资源,整体计算成本只有使用包月节点的 1/3。

在编排调度层,我们借助了 CNCF 社区的 Virtual-Kubelet,并对其进行了深度扩展。Virtual-Kubelet 提供了一个抽象的控制器模型来模拟一个虚拟 Kubernetes 节点。当一个 Pod 被调度到虚拟节点上,控制器会利用 ECI 服务来创建一个 ECI 实例来运行 Pod。

我们还可以将虚拟节点加入 ACK K8s 集群,允许用户灵活控制应用部署在普通节点上,还是虚拟节点上。

值得注意的是 ASK/ECI 是 nodeless 形态的 pod,在 K8s 中有很多能力和 node 相关,比如 NodePort 等概念不支持,此外类似日志、监控组件经常以 DaemonSet 的方式在 K8s 节点上部署,在 ASK/ECI 中需要将其转化为 Sidecar。

13.jpeg

用户该如何选择 ACK 和 ASK 呢?ACK 主要面向的是基础设施运维团队,具备和 K8s 高度的兼容性和灵活性控制性。而 ASK 则是面向业务技术团队或者开发者,用户完全不需具备 K8s 的管理运维能力,即可管理和部署 K8s 应用。而 ACK on ECI,则同时支持用户负载运行在 ECS 实例或者 ECI 实例上,可以允许用户进行灵活控制。

ACK on ECI/ASK 则可以将弹性的负载通过 ECI 的方式运行,有几个非常典型的场景:

  • 应对突发流量:ECI 基于面向容器的轻量安全沙箱,可以实现 30s 500Pod 的弹性伸缩能力,可以轻松应对突发的业务流量,在面对不确定的业务流量时,可以简化弹性配置;
  • 批量数据处理:我们可以实现 Serverless Spark/Presto 这样的计算任务, 按需为计算任务分配计算资源;
  • 安全隔离:有些业务应用需要运行 3 方不可信应用,比如一个 AI 算法模型,ECI 本身利用安全沙箱进行隔离,我们可以利用 ECI 隔离运行相关应用。

ACK on ECI 还可以和 Knative 这样的 Serverless 应用框架配合,开发领域相关的 Serverless 应用。

总结

合理规划 K8s 集群可以有效规避后续运维实践中的稳定性问题,降低使用成本。期待与大家一起交流阿里云上使用 Kubernetes 的实践经验。

关于作者

易立,阿里云资深技术专家,阿里云容器服务的研发负责人。之前曾在 IBM 中国开发中心工作,担任资深技术专员;作为架构师和主要开发人员负责或参与了一系列在云计算、区块链、Web 2.0,SOA 领域的产品研发和创新。阿里云容器平台团队求贤若渴!社招技术专家 / 高级技术专家,base 杭州 / 北京 / 深圳。欢迎发简历到 jiaxu.ljx@alibaba-inc.com

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

API Server 负载均衡问题被解决 | 云原生生态周报 Vol. 40

alicloudnative阅读(736)评论(0)

作者 | 何淋波、李鹏、陈俊、高相林、孙健波

业界要闻

  1. CNCF 宣布 2020 年中国 KubeCon 取消

由于新冠疫情影响,外国企业、开发者到访中国存在不确定性,加上召集演讲人、赞助商及参会者所遇到的困难,CNCF 宣布原定于 2020 年 7 月在上海举办的 KubeCon + CloudNativeCon + 开源峰会取消。

同时,原计划于 3 月 30 日 – 4 月 2 日在荷兰阿姆斯特丹举办的 KubeCon + CloudNativeCon 峰会欧洲场也因疫情影响,被推迟到 2020 年 7 月或 8 月举行。而 KubeCon + CloudNativeCon North America 2020 则将按计划在 2020 年 11 月 17 日至 20 日在波士顿举行。

  1. Kubeflow 1.0 发布

可以基于 Kubernetes 高效地构建、训练和部署AI应用。此次发布中包括的核心组件如下:

  • Jupyter Notebook controller: 用户可以方便使用 Jupyter Notebook 开发工具来开发新的机器学习模型;
  • TFJob and PyTorch Operator:用于模型训练;
  • kfctl:用于部署和管理 Kubeflow;
  • KFServing:机器学习模型的部署和管理;
  • Kubeflow UI:集中仪表板。
  1. 阿里云 ACK 1.16 版本正式灰度上线

阿里云 ACK 整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。Gartner 竞争格局国内唯一入选,Forrester 报告国内排名第一。欢迎试用!欢迎广大读者前来试用!

上游重要进展

Kubernetes

  1. 阿里经济体工程师解决困扰 K8s 社区多年的 API Server 负载均衡问题

由于 API Server 和 client 是使用 HTTP2 协议连接,HTTP2 的多个请求都会复用底层的同一个 TCP 连接并且长时间不断开。而在 API Server 发生 RollingUpdate 或者某个 API Server 实例重启时,又或者 API Server 使用 MaxSurge=Replica 方式升级后, Load Balance 没有及时的将所有副本挂载完毕,client 能敏感的感知到连接的断开并立刻发起新的请求,这时候很容易引起较后启动(或者较后挂载 Load Balance)的 API Server 没有一点流量,并且可能永远都得不到负载均衡。

蚂蚁金服的同学对这个问题做了修复,增加了一种通用的 HTTP filter,API Server 概率性(建议 1/1000)的随机关闭和 Client 的链接(向 Client 发送 GOAWAY)。关闭是优雅的关闭,不会影响  API Server 和 client 正在进行中的长时间请求(如 Watch 等),但是收到 GOAWAY 之后,client 新的请求就会重新建立一个新的 TCP 链接去访问 API Server 从而能让 Load Balance 再做一次负载均衡。

这个修复增加了通用的 HTTP filter,能轻易的 port 回老版本的 Kubernetes,其它 HTTP2 server 也有类似问题也可以快速 port 这个通用的 filter(只依赖较新版本 golang.org/x/net package)。

  1. add KEP for cgroups v2 support

给 kubelet 增加 cgroups v2 的支持。

  1. Disable HTTP2 while proxying a “Connection: upgrade” request

针对 proxy connection upgrade 请求,强制采用 http1.1 协议。

  1. Fix ExternalTrafficPolicy support for Service ExternalIPs

Service ExternalIPs 遵守 ExternalTrafficPolicy=local 规则,从而达到保留 Client 源 IP 目的。

  1. Allow signing controller to return intermediate certs

由于 kubelet 证书轮转机制要求给 kubelet 返回签发的证书时,同时也带上签发者的 CA 信息,用于解决 kube-controller-manager 和 kube-apiserver 的 CA 配置不一致的问题。该 PR 只解决 kube-controller-manager 这块的问题,后续 kubelet 还需要配合修改。

  1. Use ip address from CNI output

目前主要从容器的 eth device 获取容器 IP 信息,但是针对只使用 lo 和非 device(如: unix domain socket file)的容器当前的实现无法 cover,该 PR 利用 cni ADD 命令结果中返回的容器 IP 信息,而不从容器 eth device 获取 IP 信息。

Knative

  1. Knative Functions 支持

Knative 当前轻松支持基于 HTTP 和事件驱动的容器扩缩容,但是为什么不往前一步支持 FaaS 呢? 别急,Knative 社区已经开始计划支持通过 Events 和 HTTP 触发“function”。

开源项目推荐

  1. apiserver-network-proxy

基于 grpc 的隧道实现,用于定制 kube-apiserver 的 proxy 请求转发。

  1. kubectl-debug

新启动一个容器和目标 Pod 共享 pid/network/user/ipc 命名空间的方式,在新启动容器为目标 pod 定位问题。该工具可以以 kubectl plugin 方式运行。

本周阅读推荐

  1. 《Bring your ideas to the world with kubectl plugins》

推荐使用 kubectl-plugin 的方式往 kubectl 扩展用户的需求和功能。

  1. 《When You Do (and Don’t Need) a Service Mesh》

从微服务数量、导入的紧迫性以及时机等方面分析是否需要使用 Service Mesh。

  1. 《从零开始入门 K8s | Kubernetes 网络模型进阶》

本文将基于之前介绍的基本网络模型,进行了更深入的了解,希望给予读者一个更广更深的认知。

  1. 《Kubernetes 1.16 与 1.14 性能对比》

本文主要从三个方面对 Kubernetes 1.16 与 1.14 的性能进行了对比,分析了 1.16 版本和 1.14 版本的区别。

  1. 《Kubernetes Release Note 解读(1.15, 1.16)》

Kubernetes 1.16 版本相较于 1.14 版本有着众多演进和增强,本文对其一一进行了解读。

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

Golang 1.14 发布 | 云原生生态周报 Vol. 39

alicloudnative阅读(928)评论(0)

作者 | 陈俊、何淋波、李鹏、宋净超

业界要闻

  1. Golang 1.14 发布

Golang Release 了 1.14 版本。该版本包含生产级别 go module,改进 defer 性能,以及 Goroutine 抢占等功能。

  1. Cilium 1.7 版本发布

Cilium 是一款开源软件,负责以透明方式提供并保护由 Linux 容器管理平台(例如 Kubernetes)部署完成的各应用程序服务间的网络与 API 连接。

  1. Contributor Summit Amsterdam Schedule Announced

去阿姆斯特丹 KubeCon 的同学,不要忘记注册这个难得的开发者聚会。

  1. KubeCon + CloudNativeCon China 2020 议题提交即将结束

将于中国时间 2 月 28 日结束,请大家不要忘记时间点。

上游重要进展

Kubernetes

  1. Honor status.podIP over status.podIPs when mismatched

修复老版本 Pod API 里 Pod.Status.PodIP 兼容 Pod.Status.PodIPs。建议大家紧急 Port 这个 PR,否则 1.15 版本以下的 kubelet 向 1.16 或者以上的 API Server 更新 Pod Status。

  1. Adding AppProtocol to Services and Endpoints

AppProtocol 可以使用应用层的协议名 (application protocols) 去标识每个 Service Port 的类型,相比之前只能使用 TCP/UCP 标识,提升了非常大的用户阅读体验。 (API PR

  1. Promote the EgressSelector API to beta

Egress API 从 alpha 阶段提升到 beta 阶段,API 定义和实现更加稳定。

Knative

  1. Eventing 2020 Roadmap

Eventing 2020 规划 Roadmap, 主要包括:

  • 支持 V1 APIs
  • Broker 生产可用(Production-ready)
  • 数据面安全策略
  • 数据面可扩缩(Serverless化)
  1. autoscaling of eventing components.

社区提交了 eventing 组件自动扩缩容 PR。基本思路是通过 Knative Service 部署 eventing 组件。通过新增一个基于 keda 的自动扩缩容插件来支持。

开源项目推荐

  1. rode

rode 基于 Kubernetes 完成软件的可信交付链。将软件的生命周期、Release 事件统一收集到 Kubernetes 系统,然后完成注册更新到 Grafeas,最后在 Kubernetes 入口层能够拦截不合法的应用实例创建请求。

本周阅读推荐

  1. 《建立 Helm chart 的持续集成》

持续集成和自动化的流水线能最大发挥声明式系统的力量。此文通过 CI 系统打通 Helm 的注册中心,完成自动化的应用交付。

  1. 《超详细的网络抓包神器 Tcpdump 使用指南》

你是不是还在头疼为什么自己的服务网络不通,在阅读了这篇文章之后,希望你能够使用 tcpdump 自己排查问题并解决问题。

  1. 《Serverless Workloads In Kubernetes With KEDA》

KEDA 是基于 Kubernetes 的事件驱动的自动伸缩工具,由微软、红帽等公司开源,厂商中立,可部署在任何 Kubernetes 集群。

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

Kubernetes上的“火眼金睛”——Prometheus的安装实录

JFrogchina阅读(1608)评论(0)

一、背景

Kubernetes是目前最为流行、成为事实标准的容器集群管理平台,为容器化应用提供了集群化部署运行、自动资源调度,和动态水平伸缩等一系列完整功能。虽然Kubernetes平台本身已经实现了应用状态的实时监控,但是监控的指标和方式还是比较基础,难以满足各种复杂和个性化的监控管理需求。因此,我们需要在Kubernetes的基础上,增加独立的、不影响现有应用集群的架构和部署的,而且功能全面、易于部署、便于监视分析、能够及时告警的监控体系。

在当前应用与Kubernetes的监控体系当中,Prometheus得到了更为广泛的关注和应用。本文就结合JFrog在Kubernetes落地实践当中的积累,介绍如何在Kubernetes环境中快速部署Prometheus系统,实现对Kubernetes环境状态的实时监视和告警。

二、Prometheus简介

Prometheus是一套开源的系统监控报警框架。和Kubernetes类似,它也发源于Google的Borg体系,其原型为Borgmon,是一个几乎与Borg同时诞生的内部监控系统,由工作在SoundCloud的Google前员工在 2012年创建。之后作为社区开源项目进行开发,并于2015年正式发布。2016年,Prometheus正式加入CNCF(Cloud Native Computing Foundation),是仅次于Kubernetes的第二个项目,目前已经全面接管了 Kubernetes项目的整套监控体系。

Prometheus的监控是基于时序数据的,即通过采样数据(metrics),不断获取监控目标的状态信息,即时地记录与展示,并根据设定的门限和方式及时发布告警。

作为应用与Kubernetes的监控体系,Prometheus具备诸多的优势,如:

  • Kubernetes默认支持,非常适合容器和微服务
  • 无依赖,安装方便,上手容易
  • 社区活跃,它不仅仅是个工具,而是生态
  • 已有很多插件或者exporter,可以适应多种应用场景的数据收集需要
  • Grafana默认支持,提供良好的可视化
  • 高效,单一Prometheus可以处理百万级的监控指标,每秒处理数十万的数据点

而当前Prometheus最大的缺点就是暂时还不支持集群化。当然,在社区的支持和推动下,可以预期在不久的将来,Prometheus也将会推出完善的集群化方案。

Prometheus的基本架构如下图所示:

其中:

  • Prometheus Server:是Prometheus架构中的核心部分,负责实现对监控数据的获取、存储及查询。Prometheus Server可以通过静态配置管理监控目标,也可以配合使用Service Discovery的方式动态管理监控目标,并从这些监控目标中获取数据。其次Prometheus Server本身也是一个时序数据库,将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。Prometheus Server对外提供了自定义的PromQL,实现对数据的查询以及分析。
  • Exporter:是提供监控数据的来源。Exporter分为两类:一类Exporter直接内置了对Prometheus监控的支持,如Kubernetes、etcd等;另一类是因为原有监控目标并不直接支持Prometheus,需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序,如Mysql、JMX等。对于Exporter,Prometheus Server采用pull的方式来采集数据。
  • PushGateway:同样是监控数据的来源。对于由于特定原因,如网络环境不允许等,Prometheus Server不能直接与Exporter进行通信时,可以使用PushGateway来进行中转。内部网络的监控数据主动Push到Gateway中,而和对Exporter一样,Prometheus Server也利用pull的方式从PushGateway采集数据。
  • Alertmanager:是Prometheus体系中的告警组件。在Prometheus Server中可以设定门限与警报规则。当采集到的数据满足相关规则后,就会产生一条告警。Alertmanager从 Prometheus Server接收到告警后,会根据事先设定的路径,向外发出告警。常见的告警发送路径有:电子邮件、PagerDuty、Webhook、Slack等。
  • 数据展示与输出:Prometheus Server有内置的UI用于展示采集到的监控数据。在该UI上,可以通过各种内置的数学公式对原始数据进行加工,并通过图形化的方式展现出来。当然,Prometheus Server原生UI的展示方式还是比较基础和单薄,所以目前更多的是通过对接Grafana来进行数据的展示,可以得到更好的展示效果。此外,Prometheus Server也提供API的方式来实现对监控数据的访问。

本文就将参照上述架构,介绍如何在Kubernetes环境中,快速地部署和配置Prometheus的监控体系。

三、Prometheus的安装实录

本节将基于JFrog在Kubernetes落地实践当中的积累,一步一步地介绍如何在Kubernetes环境中,从零开始搭建Prometheus系统,并实现监控数据的收集、展示与告警。本节所涉及的所有Kuberntes对象的yaml文件、kubectl命令,都可以在https://github.com/xingao0803/Prometheus上获得。该项目的README也详细记录的所有的操作步骤,供大家参考。(注:本文部署是基于Kubernetes 1.16.3版本的。)

 

1、创建命名空间

为管理需要,所有Prometheus组件都应运行在一个独立的命名空间当中。因此安装的第一步,就是要创建一个新的Namespace,此处为“monitoring”。

2、部署node-exporter

作为监控数据的来源,node-exporter用于提供*NIX内核的硬件以及系统指标,包括机器的loadavg、filesystem、meminfo等,类似于传统的主机监控数据。node-exporter由Prometheus官方提供维护,不会捆绑安装,但基本上是必备的exporter。

node-exporter是以DaemonSet对象的方式进行部署的,可以确保每个Kubernetes Node的数据都会被采集到Prometheus。

注意,node-exporter开放了hostPort:9100,所以可以通过直接访问<Node_IP>:9100来访问node-exporter采集到的数据。如下图所示:

 

除DaemonSet外,还需要部署对应的Service,供Prometheus Server对接使用。需要注意的是,该Service只开放了Cluster内部端口,不能直接从外部访问。

 

3、部署kube-state-metrics

除了node-exporter,还可以部署另一个数据来源,kube-state-metrics。kube-state-metrics关注于获取kubernetes各种资源的最新状态,如deployment或者daemonset等。kube-state-metrics轮询Kubernetes API,并将Kubernetes的结构化信息转换为metrics,将kubernetes的运行状况在内存中做个快照。

因为kube-state-metrics要访问API,所以要先创建ServiceAccount来提供权限。之后再部署相应的Deployment:

为了和Prometheus Server对接,也要部署对应的Service。和node-exporter一样,这个Service也只开放了Cluster内部端口,不能直接从外部访问。

4、部署Prometheus Server

部署Prometheus Server之前,同样首先要创建Service Account来提供权限。同时,需要通过创建两个ConfigMap来预先提供Prometheus Server的配置数据,和产生警报的门限和规则。Prometheus的各种配置可以到https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config查看相关详细定义。

之后,还需要创建一个Secret来设置Prometheus的缺省用户和密码。

一切就绪之后,就可以部署Prometheus Server的Deployment了:

注意,在参数当中预先设置了AlertManager的对接方式。

最后,再创建Prometheus的Service:

该Service开放了NodePort,但没有指定端口号,所以由Kubernetes自动分配。可以通过kubectl get service命令得到该端口,并通过<Node_IP>:<Node_Port>来访问Prometheus原生的UI界面:

在该界面上,可以直接看到所有采集上来的监控数据,并通过各种内置的数学公式进行加工,并以图形化的方式展示出来。

此外,根据设置的告警门限和规则,也会在UI上显示各种告警信息:

 

5、部署Grafana

Prometheus的原生UI,看起来还是有些基础和单薄,所以在日常应用当中,通常都会再对接Grafana来进行数据展示。

部署Grafana也首先要通过创建ConfigMap来设置Dashboard的模版设置。Grafana的模版设置参数可以参考https://grafana.com/grafana/dashboards

模版参数设置好之后,就可以部署Grafana的Deployment和Service了:

Grafana的Service也是开放了NodePort,但没有指定端口号。可以通过Node_IP和自动分配的Port来访问Grafana的界面:

还需要再运行一些脚本来和Prometheus连接,即添加数据源,并根据ConfigMap的设置来创建Dashboard。这些脚本是通过创建一个Job对象来运行的。Job运行结束之后,就可以在Grafana上看到监控数据了:

这个界面看起来就更为丰富和美观了。

当然,为了更好地对外展示Grafana,还可以再创建一个Ingress来通过域名的方式对外开放:

 

6、部署Alertmanager

之前Prometheus根据预设的门限和规则,已经从采集到的监控数据中产生了告警信息,下一步就需要通过Alertmanager把告警信息发送出去。

首先,还是通过创建ConfigMap来设置Alermanager对接的信息发送路径,和发送的信息格式模版。Alertmanager的配置可以参考https://prometheus.io/docs/alerting/configuration/。 Alertmanager可以对接的发送路径很多,如邮件、PagerDuty、Slack、Webhook等。本文的例子中只提供了邮件方式的设置。

之后,再分别部署Alertmanager的Deployment和Service:

Alertmanager的Service也是没有指定端口号的Node_Port,可以通过自动分配的端口访问到Alertmanager的界面:

在Alertmanager的界面上,可以看到即时接收到的告警信息。

根据发送路径的设置,可以在邮箱中收到相应的告警邮件:

 

至此,我们在Kubernetes的环境中快速部署了Prometheus的系统,并采集了Node和Kubernetes组件的各种状态数据,可以通过Grafana进行展示;系统产生的告警信息也可以通过Alertmanager设置的方式,以邮件的方式发送出来。

五、总结

Prometheus是Kubernetes体系中应用最为广泛的时序数据的监控系统。本文详细描述了如何从零开始,快速在Kubernetes环境中部署Prometheus系统,并实现监控数据的采集、展示,以及告警的全过程。本文安装的Prometheus系统架构如下图所示:

本文部署过程所涉及的所有Kuberntes对象的yaml文件、kubectl命令,都可以在https://github.com/xingao0803/Prometheus上获得。该项目的README也详细记录的所有的操作步骤,供大家参考。(注:本文部署是基于Kubernetes 1.16.3版本的。)

此外,本文中各种部署对象是基于Docker image的,因此过程中也需要本地Docker镜像中心的支持,保证部署过程的稳定、快速和可重复。本文在部署过程中采用了JFrog的JCR(JFrog Container Registry),只是一款免费的、功能强大的Docker镜像中心。具体信息请参见:https://www.jfrog.com/confluence/display/JCR/Overview。大家可以通过https://www.jfrog.com/confluence/display/JCR/Overview来下载免费使用。

 

更多精彩内容请微信搜索公众号: jfrogchina

更多技术分享可以关注3 3 日在线课堂:《杰蛙读书《凤凰项目》,一小时带你入门DevOps及敏捷转型》

 

课程介绍

通过本次课程,通过DevOps神书《凤凰项目,一个IT运维的传奇故事》中的一些故事点,明确DevOps建设中遇到的坑,以及通过这些坑孵化出的解决方法,了解一个IT运维如何帮助公司实现凤凰涅槃。本次课程比较轻松,听众可以按照听故事的方式,了解一个传统企业转型DevOps的一些趣事。

 

课程大纲

1.《凤凰项目》故事主线梳理

  1. 归纳故事中遇到的问题及处理方式
  2. 总结DevOps转型技术点及文化落地方案

 

课堂活动

本期课堂讲师会在结束前进行抽奖活动

第一名:小爱音响

第二名:JFrog 新版T 恤

 

报名链接: https://www.bagevent.com/event/6387696

架构师成长系列 | 云原生时代的 DevOps 之道

alicloudnative阅读(1339)评论(0)

作者 | 郝树伟(花名:流生)  阿里云高级研发工程师

本文整理自架构师成长系列 2 月17 日直播课程。

关注“阿里巴巴云原生”公众号,回复 “217”,即可获取对应直播回放链接及 PPT 下载链接。

导读:DevOps 是一种软件开发人员和 IT人员之间的合作过程,目标是高效地自动执行软件交付和基础架构更改流程。在云原生时代,企业又如何借助 DevOps 实现产品快速、稳定、高效和安全地迭代,释放业务价值呢?

什么是云原生

为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题无法快速解决等问题,云原生这一概念横空出世。

Pivotal 是云原生应用的提出者,并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架,成为云原生应用架构中先驱者和探路者。

1.png

早在 2015 年 Pivotal 公司的 Matt Stine 就写了一本叫做迁移到云原生应用架构的小册子,其中探讨了云原生应用架构的几个主要特征:

  • 符合 12 因素应用
  • 面向微服务架构
  • 自服务敏捷架构
  • 基于 API 的协作
  • 抗脆弱性

后来 Pivotal 对云原生的定义做过几次更新, 最新的 Pivotal 官网上对云原生应用的最新介绍是关注以下四点:

  • 集成 DevOps
  • 持续交付
  • 微服务
  • 容器化

2.png

  • DevOps 是软件开发人员和 IT 运营之间的合作,目标是自动执行软件交付和基础架构更改流程。它创造了一种文化和环境,可在其中快速、频繁且更可靠地构建、测试和发布软件;
  • 持续交付使得单个应用更改在准备就绪后即可发布,而不必等待与其它更改捆绑发布或等待维护窗口期等事件。持续交付让发布行为变得平淡可靠,因此企业可以以更低的风险频繁交付,并更快地获得最终用户的反馈,直到部署成为业务流程和企业竞争力必不可少的组成部分;
  • 微服务是将应用作为小型服务集合进行开发的架构方法,其中每个服务都可实施业务功能,在自己的流程中运行并通过 HTTP API 进行通信。每个微服务都可以独立于应用中的其他服务进行部署、升级、扩展和重新启动,通常作为自动化系统的一部分运行,可以在不影响最终客户的情况下频繁更新正在使用中的应用;
  • 与标准虚拟机相比,容器能同时提供效率和速度。单个操作系统实例使用操作系统 级的虚拟化,在一个或多个隔离容器之间进行动态划分,每个容器都具有唯一的可写文件系统和资源配额。创建和破坏容器的开销较低,再加上单个虚拟机中的高包装密度,使容器成为部署各个微服务的完美计算工具。

Google 主导成立了云原生计算基金会(CNCF),对云原生的定义为:

“云原生(Cloud Native)技技术帮助企业和机构在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、 服务网格、微服务、不可变基础设施和声明式 API;这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术可以使开发者轻松地对系统进行频 繁并可预测的重大变更 。”

3.png

目前云原生背后最大的推手就是 CNCF,关键技术包括容器、微服务、服务网格、devops,声明式的 API 等等。

4.png

云原生应用与传统应用的对比,云原生应用可以充分利用云的优势,灵活地在各个云厂商分发应用,释放企业生产力,聚焦到业务创新上,而不是花费更多的时间在适配和扩展不同的基础设施平台上。

云原生时代的 DevOps 新挑战

首先我们要清楚地知道, 站在企业的角度来看,在这样一个快捷商业的时代,企业最需要什么?

5.png

  • 唯快不破。这里的快可以解读出来两层含义,一是业务应用快速上线,有利于抢占市场先机,第二层意思就是在你的业务有爆炸式增长的时候,你如何在计算资源上给以充分的保证,这个时候其实追加巨额的 IT 投资购买软硬件也未必能跟得上业务的快速发展。这个其实就是企业研发效能的问题;
  • 稳中求变。业务或者应用的稳定性永远都是第一位的,如何既保证业务的“稳态”又要满足快捷商业的“敏态”需求,比如新业务的上线、应用的变更等。这个是企业 IT 架构的问题;
  • 节省资源,如何节省计算资源,根据业务是否高峰自动扩容缩容,这个是云平台建设的问题;
  • 开拓创新,开发运维一体化、微服务架构。

DevOps 最初的出现打破了开发人员和运维人员之间历来存在的壁垒和沟鸿,加强了开发、运营和质量保证人员之间的沟通、协作与整合。在后 DevOps 时代,我们可以借助容器技术更快地对应用进行迭代上线。

6.png

下面是应用发布的一般过程,开发者 push 代码,触发构建,构建过程是拉取源码,应用打包,容器镜像推送,部署。

7.png

这个模型其实已经有很多地方充分利用了云原生的优势,比如容器技术、Kubernetes、动态分配 slave pod 等。但还有一些挑战。
8.png

  • 如何应用在环境栈之间的安全推进发布
  • 如何管理应用发布的权限和安全审批
  • 如何提高应用的平均部署时间和平均恢复时间
  • 如何迅速对线上应用进行故障定位、复现和回滚

云原生时代下的 DevOps 之道

首先我们要充分利用云原生技术的优势,云原生可以改进应用开发的效率,改变企业的组织结构,甚至会在文化层面上直接影响一个公司的决策。在容器领域内,Kubernetes 已经成为了容器编排和管理的社区标准。它通过把应用服务抽象成多种资源类型,比如 Deployment、Service 等,提供了一个云原生应用通用的可移植模型。

在这样的背景下,我们如何在云原生的环境下实践更高效的 DevOps 来达到更有生产力的表现就成为了一个新的课题和诉求。
9.png

下面是一个企业应用平台的建设目标:

10.png

在此 PaaS 平台的基础上,我们设计了 GitOps 安全发布模型来解决前面我们提到的一些挑战。

在设计 GitOps 发布模型的时候是有以下这些核心诉求的:

  • 版本管理。我们希望每一个发布的应用的版本号都能跟 git commit id 关联,这样的好处就是每一个变更都有历史记录查询、可以更快进行故障定位和修复;
  • 基线管理。便于问题复现和快速回滚;
  • 安全发布。包括发布权限管理以及安全审批的内容;
  • 快速反馈。提高研发效能。

11.png

GitOps 发布模型有以下特性:

  • Git 仓库是任何 CICD 过程的唯一输入源
  • 声明式的应用编排、构建部署模型
  • 应用在环境栈之间的无差别、自动化推进
  • PR/MR 触发的拉取式流水线过程
  • 快速反馈机制

下面是使用 GitOps 管理应用发布到不同 Kubernetes 集群的架构图。

12.png

首先是应用源码与构建源码分离,我们可以看到橙色框起来的这两个源码项目,一个是我们的应用源码项目 application-java-demo, 左侧的这个源码项目是用来存放构建源码的,比如 preview pipeline 的 Jenkinsfile, staging pipeline 的 Jenkinsfile,production pipeline 的 Jenkinsfile, 除了 Jenkinsfile 之外,可能还有一些关于动态创建测试环境、连接预发环境或者生产环境的敏感信息,这些敏感信息也可以存放在数据库里,然后这里保存数据库的连接信息。

这个普通应用 application-java-demo 在 Git 仓库里是有不同的分支的,每个分支跟 Kubernetes 集群环境都有一定的对应关系,比如我们这里的设定,master 分支对应的是生产环境,latest 分支对应的是预发环境,其他开发分支对应的是测试环境,测试环境的动态创建和销毁、应用再测试环境的部署发布是开发测试人员自助的服务,但应用想要部署到预发环境和生产环境中的话是需要经过管理员安全审批的。

普通开发者的权限只有创建新代码分支和创建合并请求的权限,除此之外,剩下其他的部分都是管理员才有权限做的,绿色区域是 Jenkins 的流水线任务,当然你也可以是使用其他 cicd 引擎来做这个流水线任务的构建。普通开发者没有 Jenkins 环境的创建 Job 和构建 Job 的权限,也没有更改配置的权限,他有的只是构建 Job 的日志查看权限。

最后是一个时序图,演示一个应用从开发测试到业务上线迭代的一个完整流程:

13.png

  1. 开发者提交新的功能分支 feature;
  2. 开发者创建请求合并代码到 latest 分支的 Merge Request;
  3. 开发者创建 Merge Request 的动作自动触发名为 preview-pipeline 的 Jenkins 流水线任务的构建;
  4. preview-pipeline 流水线任务从 Git 服务器拉取 preview-pipeline 源码项目,并按照项目中 Jenkinsfile 文件中的声明式脚本运行源码编译、测试、容器镜像构建和推送、应用部署到 Preview 的容器集群、钉钉通知的流程;
  5. 管理员在 Git 服务器的 Merge Request 页面查看应用的预览连接并验证应用是否可以合并到 latest 分支,如果通过验证则接受 Merge Request 的合并,触发步骤 6, 如果不通过则通知开发者进行代码更新和提交,退回步骤 1;
  6. 管理员接受 Merge Request 合并的动作会自动触发 Jenkins 流水线任务 staging-pipeline 的构建;
  7. staging-pipeline 流水线任务从 Git 服务器拉取 staging-pipeline 源码项目,并按照项目中 Jenkinsfile 文件中的声明式脚本运行源码编译、测试、容器镜像构建和推送、应用部署到 Staging 的容器集群、钉钉通知的流程;
  8. Staging 环境中的应用服务在通过测试和验证后,管理员可以合并 latest 分支到 master 分支;
  9. 管理员合并 latest 分支到 master 分支后,会自动触发 Jenkins 流水线任务 production-pipeline 的构建;
  10. production-pipeline 流水线任务从 Git 服务器拉取 production-pipeline 源码项目,并按照项目中 Jenkinsfile 文件中的声明式脚本运行源码编译、测试、容器镜像构建和推送、应用部署到 Production 的容器集群、钉钉通知的流程。

GitOps 是一套方法论,所以其实是有多种实践的方式的,会有多种多样的好用的工具,比如使用 draft 可以帮助完成应用编排模板的自动化生成,skaffold 用来简化应用构建部署流程,kaniko 可以实现不依赖 docker daemon 的镜像构建和推送,helm 用作应用的包管理工具,还有其他 cicd 引擎像 jenkins,tekton,argo 以及为云原生而生的 jenkinsx 等等。

14.png

后面,我们会单独实战演示 GitOps 安全发布模型的工作过程。

参考文献:https://pivotal.io/cn/cloud-native

直播海报.png

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

手机淘宝短视频业务「哇哦视频」迁移上 FaaS 笔记公开

alicloudnative阅读(671)评论(0)

 作者 | 刘子健(繁易)  阿里巴巴高级前端工程师

前言

2019 年,在阿里巴巴集团内部技术论坛上对于 Serverless 和 FaaS 的讨论非常火热。

在看了那么多“技术原理/顶层设计/平台建设”相关的文章之后,我相信你对 FaaS 肯定产生过跃跃欲试的感觉,但也肯定存在诸多疑惑,例如:

  • FaaS 在业务中能落地吗?
  • FaaS 能帮助前端同学实现能力升级吗?
  • ……

而这些疑惑对于刚开始接触 FaaS 的我而言,只会多不会少。恰好,我所负责的“哇哦视频”业务是淘系第一个基于 Node FaaS 开发的线上业务,在线上已经稳稳当当的跑了 4 个月,这期间不仅接手了 Java 同学的工作,同时也顺利的承接了日常与双十一需求。

关于上面的这些疑惑,经过了这四个月的考验,我想我已经有了自己的答案。接下来我将会向大家分享我这四个月的历程,带大家一起看看,在一名一线业务同学的眼中,FaaS 究竟会给前端同学带来什么?

背景

哇哦视频是在手淘首页的短视频导购业务,业务核心目标如下:

打造围绕“人用物”为核心有 “温度”的短视频;引导更多的商家视频,商家模板化生产;增加首页分发效率,让用户快速的且容易定位到自己想看的视频内容。

而其作为手淘的导购业务,具有“三高”的特点:

1.png

由于是身处手淘首页的业务,其流量相对于普通业务而言是比较高的,属于大流量业务。而流量高的特点也带来了稳定性高的要求,由于用户众多,因此线上的任何不稳定都有可能产生舆情。

而作为导购业务,业务本身还有一个迭代频率高的特性。为了能实现更好的导购效果,业务需要不断的推陈出新,快速建场,从而获得更好的导购效果。

淘系导购研发模式

1. 中台化

在淘系,随着中台化战略的成熟与导购侧近几年的发展,导购业务的开发工作由独立开发各种能力向中台化支持转变。业务所需要的绝大部分能力均可以由中台提供。

这么做带来的好处是显而易见的。大部分常见的导购业务,都可以通过中台能力的组装从而实现快速上线,避免重复开发带来的人力物力的浪费。如下图所示,此时在哇哦视频,后端绝大多数的工作在于调用中台的在线服务与离线服务,编写相关的业务逻辑来完成相关需求。

2.png

2. 工作流

在淘系导购业务现今的开发中,一般都由一位前端搭配一位后端一起完成,每个需求的开发,都需要遵循开发 + 联调 + 测试的完整流程去进行。

而我也针对于哇哦视频最近的几次需求开发做了时间的分析,具体结果如下图所示:

3.png

后端同学得益于中台能力的完善支持,许多代码可以复用,因此开发工作量会小一些。而前端则由于 UI 开发的特性,许多东西需要推倒重来,难以复用(首页改版,整体样式都换了),所以工作量会稍微大一些。

这一套流程实际上已经相当成熟,但成熟并不代表完美。实际上开发过程中,痛点还是有很多的。

研发模式痛点

1. 联调成本过高

首当其冲的痛点则是联调。在联调期中前后端需要不断对数据字段、业务逻辑进行确认,从而确保需求实现的正确性,而这种密集的沟通所带来的成本是非常高的。

如下图所示,在业务开发中我们发现联调成本一般要占到开发成本的 30% 左右。

4.png

居高不下的联调成本,一方面使得工程师们精疲力尽,另一方面也不利于业务的快速迭代。

2. 前端资源化

值得一提还有前端资源化的痛点。

在目前前后端的分工模式中,前端只负责交互逻辑与相对应的 UI 实现,对于业务核心逻辑无需过多了解。虽然这使得前端团队可以快速完成某些业务,但同样也带来了前端资源化的隐患。而在强调前端要深入业务,具有商业化思考能力的今天,前端资源化实际上是不利于前端的自身发展的。

因为很多时候前端想去深入业务,想进一步升级自己的能力,但往往会苦于没有相关场景。至于说介入后端的工作领域,毕竟术业有专攻,很多事情也掺和不进去。

遇见 FaaS

吐槽归吐槽,但是工作还是要继续的。既然每天的工作有这么多痛点,那么是否有办法去尝试解决它呢?

恰好今年的四月份我开始参与淘宝导购体系 Node FaaS 相关建设的工作,开始接触到一些 Serverless & FaaS 相关的工作。在经过一段时间的基础建设后,我们需要一个业务作为试点业务来检验工作成果。

出于对自身能力升级的渴望,我主动梳理与分析了当前业务的特性,并且主动要求将哇哦视频作为 Node FaaS 的首个试点业务。

哇哦视频后端分析:

哇哦视频是一个主打纯视频的导购业务,流量高。基于对后端代码与日常需求的剖析,总结其特点为:运营位多、强依赖算法推荐、数据源多、无状态服务 四点。
其中运营位多 + 强依赖算法推荐的特性,使得业务具有一定的复杂度,改造工作量主要在于理解业务规则,填充数据。

而数据源多则代表其引用的外部服务较多,如视频服务、话题、特斯拉资源位定投等。该部分工作量主要在于熟悉上下游系统。

最后无状态服务是改造 FaaS 的大利好消息,无状态则意味着横向拓展极其便利,完美契合 FaaS 的工作场景。(其他导购业务应该也类似)

总结:哇哦视频复杂度适中,无状态的业务模型十分契合 FaaS 的业务场景,且个人在通读完代码后,有把握能 Hold 住整个后端业务迁移 FaaS 的需求。因此我认为哇哦视频迁移 FaaS 平台是具有高可行度的。

非常顺利,也没有任何波折的,哇哦视频成为了淘系首个 Node FaaS 试点业务。怀揣着对于能力升级的渴望,我开始尝试将现有的业务逻辑迁移至 Node FaaS 实现。

期望达到的效果如下图所示:

5.png

迁移进行中

在正式进行迁移前,我和业务方沟通了这个事情对于业务可能产生的影响以及后续规划。业务方对于技术侧的改造是没有意见的,只有一个诉求,那就是业务不受影响。

整个诉求看似简单,拆解下来包括以下三部分:

  • 不会为技术侧改造预留时间,原定需求要按时完成;
  • 迁移后线上不能出任何问题,线上对迁移无感知;
  • 后端工作交接至前端后,对后续需求推进无影响。

说起来就是既要快,又要稳,还要能扛住后续需求。

针对这个诉求与当时的实际情况,我采取了以下三个措施,来保障整个迁移对业务侧没有影响:

  • 快速 Copy Java 代码上线
  • 使用 Java 兜底,保障线上稳定性
  • 谨慎评估后续需求,确保需求可实现

1. Copy Java 代码上线

Copy & Paste 听起来像是不光彩的事情,但这并不是一件需要遮遮掩掩的事情。相反我现在还很庆幸自己在迁移刚开始时选择了这样的方式,而没有愣头青一样选择另起炉灶,从零开始。毕竟学会跑之前得先学会走路。

前面也提过,哇哦视频是一个大流量导购业务。即使诸多能力已经中台化,但必要的胶水代码 + 相关的业务逻辑代码,总行数也高达 5000 行左右。

选择从零开始固然炫酷,但是这样难以保障代码的稳定性,毕竟原有的业务代码不仅包含必要的业务逻辑,也包含了诸多的错误处理与边界处理,而技术侧改造是必须要考虑到稳定性问题的。

且对于原有 Java 代码的 Copy 也算是一种另类的学习方式了,在这个过程中对于 Java 开发也有了足够的了解,毕竟在整个集团都是 Java 技术栈的情况下,对于 Java 的学习与了解非常有利于后续工作的开展。

非常幸运的是,后端同学的代码质量很高,该有的注释一个不缺(如下图所示),因此整个读代码 & Copy 的过程非常流畅。

6.png

也因此在后续 FaaS 版本的哇哦视频提测时,是 0 BUG 直接上线的,节约了大量的返工时间,从而避免对业务需求造成影响。

2. 使用 Java 兜底

这其实算是一个开发中的小 Tricks 了,但却足够好用。

在之前的导购研发中,为了避免后端宕机对线上带来的影响,因此网关层做了一个 CDN 容灾方案,如下图所示:

注释:

  • XCtrl – 前端调用 mtop SDK
  • TCE – 淘宝导购网关

7.png

对于前端同学而言,当请求线上接口失败时,前端的请求 SDK 就会根据当前请求数据,去 CDN 上获取最近成功的数据,从而确保对于用户端产品是可用的。

但目前导购侧的业务基本都接入了千人千面的算法,而 CDN 容灾的一个缺点便在于只是随机取一份成功数据存入 CDN,并不支持千人千面。

非常不妙的是,在我迁移 FaaS 时,底层能力还相对羸弱,时不时会有宕机等问题,这时候即使有 CDN 容灾能保障产品可用,但用户侧的体验依然是有一定损失的,属于有损降级。

而此时其实产品需求并未发生较大的变更,原有的 Java 接口也能继续使用,因此灵机一动准备将 Java 作为兜底的数据源,确保在降级的请求用户体验是完整的。

整体思路其实非常简单,请求路径整理如下:

  • 之前的:Java 接口 – CDN容灾
  • 现在:FaaS 接口 – Java 接口 – CDN 容灾

得益于这种设计,哇哦视频在上线后,顽强的活了下来。即使那段时间底层时常不稳定,但对于用户体验来说并没有多少损失(两个接口 RT 都很短,请求两次基本无感)。

迁移之后

在完成代码迁移之后,便开始筹备上线的事情。上线的过程中倒是没有什么故事可以说,波澜不惊的按照既定节奏进行灰度、放量,慢慢的也就上线了。

在整个业务真正交接到自己手中的时候,我开始遇到了真正的麻烦。

这个需求我该怎么做?

随着技术侧改造的完成,业务交给我的新需求也得继续推进,于是迷迷蒙蒙的去参加了很多场业务需求会,接触了很多自己之前作为前端根本不会接触的方面。

但事情的进展并不顺利,自己刚转型成后端,很多事情都是迷迷糊糊的,似懂非懂。于是那段时间每天最大的疑惑就是:“这个需求我该怎么做?”虽说导购业务都是调用中台,但是一个需求到我手上,哪些应该调中台,哪些应该自己完成我都是不清晰的。

于是那段时间整个人的工作都变的非常拘谨,开始主动 Push 自己去学习和了解更多业务知识,了解更多后端的业务中台。整个人面对需求,进入了一种“谨慎评估”的状态。

遇到需求,首先做的不是一口答应承接下来,而是和业务确定具体要做的事情,然后拆分需求。根据业务方的指引与自己的认识,开始不断找各个对应的后端同学去学习和了解完成需求的方式。我记得有好几个下午,我都坐在之前哇哦视频后端同学的身边,不断询问和学习着后端完成问题的思路。

逐渐的,自己的状态从 “这个需求我该怎么做” 开始向 “这个需求我觉得应该这么做” 转变,整个人面对后端的工作状态从手忙脚乱像游刃有余转变。(其实这也算能力升级吧~毕竟可以 Hold 住更多的事情了)

总结

在整个迁移的过程中,个人最深刻的感受便是“撕裂”。因为 Serverless & FaaS 并不仅仅只是一种编程方式,它更多的是给了你去 Owner 业务的机会。

而为了把握住这个机会,你需要或主动或被动的去 Push 自己学非常多的东西,也需要思考比之前多的场景,比如:

  • 业务的完整链路
  • 业务需求与最终目标的关系
  • 后端的工作方式
  • 中间件、数据库、运维……
  • ……

不断的学习新东西,不断的思考更多,不断的对原有自己造成更大的冲击。如果要给我迁移 FaaS 期间的感受下一个总结,那么一定是:“在撕裂中成长”。

回到我们最初的疑惑,我想我可以对第一个问题进行解答了:

Q:FaaS 在业务中能落地吗?
A:能,虽然过程很辛苦,但现在你们落地应该会好很多,因为坑都被我们填的七七八八了

而关于第二个问题:“FaaS 能帮助前端同学实现能力升级吗?”,我想看完全文的你,心中已经有了答案。

Q:FaaS 能帮助前端同学实现能力升级吗?
A:能,且能力升级并不止于技术,更多的是业务思维的成长。FaaS 使得前端有机会可以更深入业务,从而更好的去支持业务。技术能力与业务思维共成长,非凡不止一面。

 

直播海报.png

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

操作指南:通过 OpenShfit 运行高可用 MySQL数据库

Portworx阅读(1169)评论(0)

如何通过 OpenShfit 运行高可用 MySQL数据库

Portworx通过RedHat技术认证

我们的文章包括了MySQL on Kubernetes在不同平台不同场景下的情况。相关文章的列表如下:

 

  • Running HA MySQL on Amazon Elastic Container Service for Kubernetes (EKS) (https://portworx.com/ha-mysql-amazon-eks/)
  • Running HA MySQL on Azure Kubernetes Service (AKS)  (https://portworx.com/run-ha-mysql-azure-kubernetes-service/)
  • Running HA MySQL on Google Kubernetes Engine (GKE) (https://portworx.com/run-ha-mysql-google-kubernetes-engine/)
  • How to Backup and Restore MySQL on Red Hat OpenShift (https://portworx.com/backup-restore-mysql-red-hat-openshift/)
  • Running HA MySQL on IBM Cloud Kubernetes Service (IKS) (https://portworx.com/run-ha-mysql-ibm-cloud-kubernetes-service/)
  • Running HA MySQL on Rancher Kubernetes Engine (RKE) (https://portworx.com/run-ha-mysql-rancher-kubernetes-engine/)
  • Running HA MySQL on IBM Cloud Private (https://portworx.com/run-ha-mysql-ibm-cloud-private/)
OpenShift Container Platform是Red Hat在私有云/本地部署的应用部署平台。许多用户使用OpenShift来运行无状态应用。但是通过OpenShift来运行类似数据库的有状态应用仍然是一个很大的挑战。Red Hat提供了一系列的企业级存储解决方案。但不论是GlusterFS (RedHat称之为容器原生存储),还是Ceph,都并不是被设计来运行高性能/低延迟数据库的。GlusterFS和Ceph是很不错的项目,但对于运行数据库来说都存在较多问题。这些问题使得OpenShift的用户不得不放弃通过OpenShift来运行数据服务。

但这些问题实际上是可以解决的。本篇文章中,我们将通过使用开源数据库MySQL为例,来演示,如何通过OpenShift来运行数据库。

在Openshift上运行数据库的关键,需要一个专为高性能数据库或其他有状态应用设计的,云原生存储解决方案。

Portworx是根据DevOps的原则,专为在容器中运行有状态应用和生产系统设计的解决方案。使用Portworx,用户可以使用任何容器排程器,在任何基础架构上,管理任何数据库或有状态服务。包括:

  • OpenShift (https://docs.portworx.com/scheduler/kubernetes/openshift-install.html)
  • Kubernetes (https://portworx.com/use-case/kubernetes-storage/)
  • Mesosphere DC/OS (https://portworx.com/use-case/persistent-storage-dcos/)
  • Docker Swarm (https://portworx.com/use-case/docker-persistent-storage/)

OpenShift发布的3.7版本支持外部的卷插件,从而用户能够使用Portworx的企业级存储功能来加密、快照、备份、确保高可用,来保护关键应用数据库。

在本篇文章中,我们会演示如何通过5个步骤,在OpenShift上运行高可用的MySQL数据库。

1.   为OpenShift安装外部卷插件,这样用户就可以使用快照、备份、高可用、以及加密功能

2.   创建一个Kubernetes存储类,含有复制因子=2,IO优先级=High,快照间隔=60。这些值也可以根据用户实际需要来配置

3.   在OpenShift里创建一个MySQL模板:导入JSON,配置OpenShift MySQL持久卷,包含内存上限、MySQL的参数、以及存储类的大小

4.   从这个模板创建一个MySQL 持久卷,部署OpenShift的Pods来使用这个卷

5.   验证MySQL高可用:通过关闭节点,删除Pod来看MySQL已经被自动重新排程了

如果你希望了解更多如何在OpenShift上运行高性能数据库,可以查看Portworx网站上的相关文档和视频。

在OpenShift 3.7上安装Portworx

安装Portworx

Portworx在OpenShift上作为一个Daemonset被安装。访问 https://install.portworx.com来创建你的px-spec.yaml文件,并且运行oc apply –f px-spec.yaml。

在OpenShift上安装Portworx的详细操作文档在这里:(https://docs.portworx.com/scheduler/kubernetes/openshift-install.html)

一旦Portworx安装完成,我们就继续创建一个存储类,用来为我们的MySQL实例做卷的动态部署。

下面是一个存储类的例子,我们用它来创建我们的卷,

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: px-demo-sc
provisioner: kubernetes.io/portworx-volume
parameters:
repl: “2”
priority_io: “high”
snap_interval: “60”

在这个存储类例子里,我们会创建一个叫做px-demo-sc的存储类,并且会配置一些Portworx的参数,

Replication – repl:  “2”

我们可以配置,在集群里我们需要多少份卷的副本。Portworx支持的复制因子包括1/2/3。配置复制因子为2或者3,可以确保Portworx在集群中同步地把卷复制到2或3个节点里,同时确保数据的持久性。如果某个节点死掉,Portworx和OpenShift会把Pod重新部署到集群中存在Portworx卷的另外一个Worker节点上。

IO Priority – priority_io:  “high”

Portworx允许你创建3个存储池:High、Medium和Low。你可以使用具备SSD、HDD和SATA存储的服务器。SSD是High,HDD是Medium,SATA是Low。如果是在云环境中也可以通过配置不同的IOPS来完成。当选择High的存储类,Portworx会把Pod排程到具备SSD存储的服务器上。

Snapshots – snap_interval:  “60”

Porworx会每60分钟创建一个快照。这些快照可以被用来回滚数据库,测试升级,以及做研发测试。

一个完整的存储类参数说明在这里:(https://docs.portworx.com/scheduler/kubernetes/dynamic-provisioning.html)

 

注意:Portworx也支持备份你的容器卷到云中或者本地的对象存储里。

(https://docs.portworx.com/cloud/backups.html)你可以创建备份的排程。这些备份可以被加密和恢复到同一个或者不同的Portworx集群里。

在OpenShift里创建一个MySQL模板

Portworx已经创建了一个样例MySQL OpenShift模板,参见(https://2.1.docs.portworx.com/samples/k8s/px-mysql-openshift.json?raw=true)

在OpenShift操作面板里选择导入YAML/JSON,copy和粘贴PortworxMySQL 模板,点击创建。

这将会出现Portworx MySQL (持久)模板配置界面。你可以选择内存上限以及其他MySQL参数,或者使用系统默认的参数。你也可以设定卷的大小,以及需要使用的存储类。确保你使用的存储类与之前创建的存储类相匹配。

进入项目,通过点击Storage验证PVC已经被创建并被绑定。

容器需要1到2分钟来出现,容器开始运行后,验证存储已经连上了: 点击Application、Pods;选择MySQLPod,在终端里输入df –H,你可以看到/var/lib/mysql/data目录已经被mounted到Portworx支持的PX-Volume里。

登入数据库并且创建一张表。

确认Pod运行在哪个节点上,

oc get pods -n mysql-openshift -o wide
NAME READY STATUS RESTARTS AGE IP NODE
mysql-1-f4xlw 1/1 Running 0 1h 10.130.0.34 70-0-107-155.pools.spcsdns.net

关闭(Cordon off)正在运行Pod的节点,

oc adm cordon  70-0-107-155.pools.spcsdns.net

验证节点上的排程已经被disable了,

oc get nodes
NAME STATUS AGE VERSION
70-0-107-155.pools.spcsdns.net Ready,SchedulingDisabled 23d v1.7.6+a08f5eeb62

删除MySQL Pod,

oc delete pod mysql-1-q88qq -n mysql-openshift
pod “mysql-1-q88qq” deleted

验证Pod已经被重新排程到集群上的另一个节点里。

oc get pods -n mysql-openshift -o wide
NAME READY STATUS RESTARTS AGE IP NODE
mysql-1-j97tw 1/1 Running 0 1m 10.128.0.63 70-0-40-193.pools.spcsdns.net

回到OpenShift控制面板,选择你的项目,到Application, Pods,点击新的MySQL Pod, 然后是终端,验证数据库表还在。

总结来看,我们通过5个步骤,在OpenShift中运行了高可用的MySQL数据库。

 

  1. 为OpenShift安装外部卷插件,这样用户就可以使用快照、备份、高可用、以及加密功能
  2. 创建一个Kubernetes存储类,含有复制因子=2,IO优先级=High,快照间隔=60。这些值也可以根据用户实际需要来配置
  3. 在OpenShift里创建一个MySQL模板:导入JSON,配置OpenShiftMySQL持久卷,包含内存上限、MySQL的参数、以及存储类的大小
  4. 从这个模板创建一个MySQL 持久卷,部署OpenShift的Pods来使用这个卷
  5. 验证MySQL高可用:通过关闭节点,删除Pod来看MySQL已经被自动重新排程了

 

如果你希望了解更多如何在OpenShift上运行高性能数据库,可以查看Portworx网站上的相关文档和视频。

利用开源软件搭建JAVA工程CI&CD自动化工具链

JFrogchina阅读(1751)评论(0)

JAVA传统项目交付流程的问题

  1. 开发和运维间环境有明显差异
  2. 代码缺乏统一质量度量
  3. 客户要求上线时间紧,人工测试慢,导致测试不充分,时常做线上BUG修复

 

打造工具链

  • 源码管理Gitlab
  • 持续集成Jenkins
  • 代码扫描SonarQube
  • 接口测试PostMan+NewMan
  • 制品管理ArtifactoryOSS版本(仅支持Maven)
  • 自动部署Ansible

 

GitLab安装

vim /etc/yum.repos.d/gitlab-ce.repo

[gitlab-ce]

name=gitlab-ce

baseurl=http://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el6

Repo_gpgcheck=0

Enabled=1

Gpgkey=https://packages.gitlab.com/gpg.key

sudo yum makecache

sudo yum intall gitlab-ce

sudo gitlab-ctl start    # 启动所有 gitlab 组件;

sudo gitlab-ctl stop        # 停止所有 gitlab 组件;

sudo gitlab-ctl restart        # 重启所有 gitlab 组件;

sudo gitlab-ctl status        # 查看服务状态;

sudo gitlab-ctl reconfigure        # 启动服务;

sudo vim /etc/gitlab/gitlab.rb        # 修改默认的配置文件;

gitlab-rake gitlab:check SANITIZE=true –trace    # 检查gitlab;

sudo gitlab-ctl tail        # 查看日志

访问http://localhost

会跳转到让你修改密码的网页

Jenkins安装

wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo

rpm –import https://jenkins-ci.org/redhat/jenkins-ci.org.key

yum install -y jenkins

systemctl start jenkins

 

访问:localhost:8080

初始密码在:/var/lib/jenkins/secrets/initialAdminPassword

SonarQube安装

#使用Docker安装

#下载启动Mysql使用Docker

docker run –name mysql5.7 -v /data/mysql5.7-data:/var/lib/mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456  -d mysql:5.7

#进入容器

docker exec -it mysql5.7 bash

#进入数据库

mysql -uroot -p123456

#创建数据库及授权

create database db_sonar character set utf8 collate utf8_general_ci;

flush privileges;

grant all privileges on db_sonar.* to ‘sonar’@’%’identified by ‘sonar’ with grant option;

flush privileges;

#查看容器IP地址

cat /etc/hosts

127.0.0.1       localhost

::1     localhost ip6-localhost ip6-loopback

fe00::0 ip6-localnet

ff00::0 ip6-mcastprefix

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

172.17.0.2      ec7039cd8020

#下载并启动SonarQube

docker run -d –name sonar -p 9000:9000 -p 9092:9092  -v /data/sonar/conf:/opt/sonarqube/conf  -v /data/sonar/data:/opt/sonarqube/data -v /data/sonar/logs:/opt/sonarqube/logs -v /data/sonar/extensions:/opt/sonarqube/extensions -e “SONARQUBE_JDBC_USERNAME=sonar”  -e “SONARQUBE_JDBC_PASSWORD=sonar” -e “SONARQUBE_JDBC_URL=jdbc:mysql://172.17.0.2:3306/db_sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true&useConfigs=maxPerformance&useSSL=false” sonarqube:6.7.5

PostMan & NewMan安装

安装NodeJS

注意: 如果已经安装NodeJS可以跳过此步

下载地址:https://nodejs.org/en/download/

下载 “Linux Binaries (x64)”

下载完解压以后配置环境变量NODE_HOME 和PATH

安装Newman

在Jenkins的slave节点安装Newman:

npm install -g newman

安装Postman

下载地址:https://www.postman.com/downloads/

安装在windows或者带UI的Linux机器

安装文档:https://learning.postman.com/docs/postman/launching-postman/installation-and-updates/

导出Postman测试集合

创建集合app1

app1为当前应用的名称,可以根据实际情况定义

名称填写 app1 , Authorization 选择 “Basic Auth”,并填入Artifactory的用户名密码,如下图

在Variables标签条件变量:base_url,值为artifactory“Custom Base URL”,例如: http://localhost:8081/artifactory

点击create按钮完成并保存

 

创建request

在集合app1右键点击,弹出的request选择”Add request”

Request name 填写 “ping”,然后点击”Save to app1”按钮

Api url :  {{base_url}}/api/system/ping

在Tests 标签填入一下内容:

pm.test(“Status code is 200”, function () {

pm.response.to.have.status(200);

});

pm.test(“Body is correct”, function () {

pm.response.to.have.body(“OK1”);

});

这是两个测试用例,分别测试返回值是否为200,返回内容是否为“OK1”,最后同时按 Ctrl+s 保存内容

 

导出集合

在集合app1右键点击,选择“Export”

导出的名字为:“app1.postman_collection.json”

安装Artifactory OSS版本

使用Yum方法安装

wget https://bintray.com/jfrog/artifactory-rpms/rpm -O bintray-jfrog-artifactory-rpms.repo

sudo mv bintray-jfrog-artifactory-rpms.repo /etc/yum.repos.d/

sudo yum install jfrog-artifactory-oss

初始账号和密码为:admin/password,登录成功后可以看到以下界面

其他安装方法可参考如下链接:

https://www.jfrog.com/confluence/display/RTF6X/Installing+on+Linux+Solaris+or+Mac+OS

安装Ansible

yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

yum install ansible

工具链使用要点

  1. GitLab源码管理要有良好的版本控制模型
  2. 使用Jenkins流水线作为统一的构建平台进行编译构建,抛弃传统的研发本地构建的模式
  3. 引入SonarQube代码质量检查工具建立代码质量度量,提升代码质量,减少低级BUG及技术债务
  4. 构建产物统一上传到制品库,运维从制品库中获取发布包,使用ansible自动部署到预发布环境。
  5. 通过开发接口测试脚本,从主到次的顺序,逐步完善系统的接口自动化测试,减少人工测试消耗的时间,缩短测试周期。
  6. 将自动部署和自动化测试的步骤也统一集成到流水线中。形成统一交付流水线,提升交付效率

进阶改造

  1. 使用Docker 容器化技术降低环境对软件的影响。
  2. 通过Selenium开发脚本,进行UI自动化测试,提升测试效率。
  3. 使用Artifactory Pro 版本,利用元数据,对制品生命周期进行管理。
  4. Artifactory Pro版本支持多语言,可以将自动化工具链扩展到其他语言上。
  5. 使用JFrog Xray对提升软件安全系数。

 

 

更多精彩内容请微信搜索公众号: jfrogchina

更多技术分享可以关注2月25日在线课堂:《深入解析Deployment》

 

课程介绍

Kubernetes以其先进的理念、活跃的社区,已成为当前容器集群化编排、部署和运行的事实标准。越来越多的企业和团队将Kubernetes引入了自己的研发和生产环境。

Deployment是Kubernetes上最常用的对象,用与创建和管理无状态Pod对象的集群,并实现集群自动化的扩容、缩容和升级等运维工作。要想应用好Deployment对象,首先要充分了解和熟悉Deployment的原理、机制和应用方式。

本期将深入、细致地分析Deployment的设计原则和运行机制,并通过实操演示的方式,来讲解Deployment如何实现对于Pod集群的自动化管理工作。

 

 

课堂收益

通过本期的讲解和演示,能够帮助大家深入理解Deployment的内部机制,熟悉Deployment的应用方式,掌握Deployment实现Pod集群自动化扩容、缩容和升级等运维的工作机制,使得大家能够在实际工作中更好的应用和管理Deployment对象。

 

本期话题

1 Deployment的定义和组成

2 Deployment实现自动化运维的工作原理

3 实操演示Deployment的应用方式

 

课堂活动

本期课堂讲师会在结束前进行抽奖活动

第一名:小爱音响

第二名:JFrog新版T恤

 

报名链接:https://www.bagevent.com/event/6377140

Heroku 的“得”与“失”

alicloudnative阅读(662)评论(0)

作者 | 孙健波(天元)  阿里巴巴技术专家

2011 年,Heroku 的联合创始人  Adam Wiggins 根据针对上百万应用托管和运维的经验,发布了著名的 “十二要素应用宣言(The Twelve-Factor App)”。不知那时候他们有没有想到,这份宣言会在今后数年时间里,成为 SaaS 应用开发的启蒙书。同时也奠定了 Heroku 在 PaaS 领域的地位,成为了云上应用开发规范化的基石。

Heroku 无疑是一家伟大的公司,它关注应用与开发者,“以应用为中心”的理念让我们至今受益。然而在过去这一两年里,我们看到许多 Heroku 的用户开始寻找别的选择。这不禁让我们好奇,站在“云原生”如火如荼的今天回望过去,Heroku 的“得”与“失”究竟在哪里?

“以应用为中心”的先进理念

Heroku 创办于 2007 年,是最早成熟的 PaaS 产品之一。Heroku 也是最早喊出“以应用为中心”,大规模帮助应用上云的产品。正是围绕“以应用为中心”这样先进的理念,使得 Heroku 从一开始便拥有了至今看来都非常诱人的功能:

  • 用户可以直接从开发语言出发,选择对应的技术栈,通过 heroku create 这样简单的命令,将应用托管到云上。主流的开发语言,均能在 Heroku 中找到对应的选择。从代码的变动自动触发软件的部署交付,清晰的工作流、多样的发布策略,直到后来的很多年都是 DevOps 们梦寐以求的功能;
  • 用户无需关心应用背后的基础设施是什么,Heroku 负责维护背后的一切。这句看似简单的话背后隐藏了巨大的复杂性,试想下某个软件或系统爆出安全漏洞后给你带来的窘境,又或者你想使用一个数据库服务时却不得不维护一个数据库实例。而在 Heroku, 这一切麻烦你都无需关心;
  • 高可用与弹性作为附加能力。Heroku  平台托管的服务具备高可用等附加能力,更让人惊喜的是,满足 12-factor 的应用还天然具备了扩缩容的能力,可以很轻松的抗住突发流量,这在当时无异于黑科技般的存在。

正是这样强大的能力,使得 Heroku 成为了 PaaS 领域事实上的标准,无论是后续的 Cloud Foundry 还是 OpenShift,似乎都没有对 Heroku 有实质性的超越。

Heroku 不再物超所值

众所周知,相对于只是提供纯粹计算能力的 IaaS 而言,以服务能力著称、提供众多开箱即用附加功能的 PaaS,价格上素来都是普遍偏贵的。毕竟 PaaS 可以使你专注于业务本身,贵一点自然也无可厚非。更何况 PaaS 通常根据开通附加能力的数量收费,刚开始甚至更便宜,Heroku 亦是如此。

一开始,用户可能感觉只是比自己在 IaaS 上搭建服务贵一点点。当你发现应用可以便捷绑定 Heroku 提供的高可用 PostgresSQL 数据库时,甚至会觉得它贵的物超所值。不过,随着业务逻辑逐渐复杂、部署规模越来越大,需求自然而然就变了。比如为了让用户的数据更安全,你可能需要一个只能私有网络访问的 PostgresSQL 实例,而 Heroku 默认不具备这样的功能,你必须要配置一个 VPC 才能做到,你自然要为这个 VPC 额外付费。这类需求逐渐覆盖了你每一个实例,增加的费用直接变成了增长的单价,成本快速上升。与此同时,IaaS 厂商的能力也正在爆炸式的增长。今天,几乎所有的云服务商都开始提供数据库服务,并且这些数据库实例的 VPC 通常是免费的。

另一方面,Heroku 从 13 年前诞生至今,一直是闭源的商业平台,关于 Heroku 的一切你都只能在其本身的平台上玩。这无疑给新人学习、上手造成了很高的门槛,甚至许多人因此不愿意体验该产品。这也导致周边生态的配套工具相当匮乏,只要官方不提供的能力,用户就得自己开发。然而无论是招聘 Heroku 熟练工,还是从零开始培养,这无疑都带来了不小的人力成本。

反观如今的云原生社区,任何人都可以通过几条简单的命令在自己的开发环境中运行 Kubernetes,开发者可以很轻易的体验和学习,积累经验。基础设施主动对接 Kubernetes 生态。周边的各类工具也在不断的繁荣演进。

黑盒化的运行时体验

提到 Heroku,另一个代表性的技术无疑就是 Buildpack。在 Docker 镜像机制出现之前,使用 Buildpack 管理用户应用的运行时构建,使得 PaaS 的运行时最终与语言无关,这无疑是非常聪明的做法。然而十多年过去,Buildpack 的模式早已暴露出许多问题。

  • 一方面是官方支持的 Buildpack 数量少,限制多,比如运行系统仅支持 Linux 的 Ubuntu 发行版;某些 Ubuntu 安装包在 Buildpack 中没有安装你便无法使用;相对小众的开发语言(如 Elixir)均不支持;又或者是你的应用包含多种语言,使用起来就变得复杂;
  • 另一方面,你也许能自定义或者找到第三方的 Buildpack 满足需求,但是没有人来保证它的稳定。一旦出了问题,你很难在本地运行 Buildpack 排查问题,而 Heroku 平台的错误信息透出方式并不直接,日志排查更是不便。

2017 年 9 月份,Heroku 最终还是支持了基于 Docker 镜像的运行时部署,然而至今为止依旧有不少限制,其中最大的限制是存储,只能使用 Heroku 的临时存储,这几乎就决定了你不可能自己编写像 etcd、TiDB 这类复杂的有状态应用。

一切的本质,都在于 Heroku 给用户提供的体验是黑盒化的,为用户屏蔽基础设施的同时,也使得用户失去了改造的自由。这也是为什么即便像 Cloudfoundry 这样理念极其类似的 PaaS 平台,即便是开源的,依旧存在同样的弊病。

事实上用户喜欢的是“白盒”,他们希望能够自定义基础设施,可以平行的替换或改造平台的已有功能,而非只能局限在平台提供的能力之上构建。就像我们买了一辆车,在雨雪的极端天气下,我们希望可以换雪地胎,而不是只能加装防滑链。

1.png

Kubernetes 的出现

而 Kubernetes 正是这样一个白盒化体验,它从未尝试去屏蔽基础设施,而是作为一个标准化接入层,把基础设施层的能力通过声明式 API 暴露出来,将选择权留给了用户。正是在这样一个开放世界里,复杂有状态应用的管理也终于得以在云上落地了。另一方面, Kubernetes 并不是 PaaS。相比于 Heroku 官方提供了将近两百个 add-ons(插件)) 用于增强包括数据库、监控、日志、缓存、搜索、分析、权限等能力,而 Kubernetes 则强调强可扩展能力,希望用户自己可以通过编写 CRD Operator 新增任意能力。

那么,这两种做法的区别是什么呢?

封闭、限制 vs 开放、自由

众所周知,Heroku 一直是一个“主观”的 PaaS 平台,12-factor 代表了应用必须云原生化的强硬观点,这一点毋庸置疑是正确的,而且非常了不起。但如果观念不能与时俱进,那么“主观”就会变得危险。就比如容器和虚拟机都已经相当普及的今天,Heroku 依旧坚持应用只能运行在 Heroku Dynos 上面。虽然这种统一很大程度上为管理提供了便利,但是这也使得用户丢掉了很多灵活性,更重要的是,运行时的巨大差异,开始让很多用户觉得自己与更广泛的社区“格格不入”。

不过,Heroku 有属于自己的封闭生态,除了上文提到官方维护的 Add-ons 以外,还有方便用户一键部署到 Heroku 平台的 4700 多个 Buttons 应用  和 用于自定义运行时和构建流程的 6300 多个 Buildpacks,这两大功能都允许用户自定义并可以申请注册到官方的应用市场中,数量着实惊人。这样繁荣的社区怎会被人诟病?出于好奇,笔者整体分析了一下这些项目。

下面两张图分别是 Heroku Buildpack 和 Buttons 的项目统计:

2.png
3.png

我们可以看到,Buildpack 只能在 Heroku 平台使用,所以 star 数量代表了大家对项目的关心,而下载量则代表了用户的使用频度。图中,6000 多个 Buildpack 的 star 数和下载安装量均在 50 以内,而超过 500 个 star 和 500 次下载部署的项目均只有 30 个左右。再来看 Buttons 中的项目,由于这些项目本身还可以部署到 Heroku 以外的其他平台,所以就只看在 Heroku 的部署下载量反映大家的使用频度,而图中超过 500 次部署的 Buttons 项目只有 6 个。原来这一切竟只是表面繁荣。

面对这样一个统计数据,我们很难说 Heroku 的封闭生态是成功的。

Buildpack 本质上是对进程的构建和打包,同样的工作业界几乎都已经统一通过 Dockerfile 构建镜像解决。与 Buildpack 只能在 Heroku 平台上使用的封闭生态不同,Docker 镜像以及 OCI 容器和镜像规范的出现,大大推动了基于容器镜像的应用打包方式走向了全面繁荣。而用于存储镜像的 Docker Registry 也是人人都可以搭建的镜像仓库。从数字上看,仅官方镜像仓库上的镜像数量就超过了 300 万,更有数千镜像下载量超过了 100 万,这才是成功生态应该有的力量。

而在 Kubernetes 生态中帮助应用打包并可以一键部署 CRD Operator 的 Helm Chats 也与 Heroku 的 Buttons 类似。同样, Helm Charts 的托管平台是可以自由搭建的,而 Chart 本身则在任何一个开源或者商业版本的 Kubernetes 上均能运行。虽然没有明确的统计数据,但是像 Helm Hub、Kubeapps Hub、CloudNative App Hub 等 Charts 托管网站里的内容看起来也已经取得了不小的成功。

Heroku 们的未来?

从上述观察来看,Heroku 过去最重要的教训,在于不够开放而错失了原本属于自己的云原生应用生态。而在 Kubernetes 项目成为基础设施主流之后,Heroku 以及它的开源继任者 Cloud Foundry 还是很难走出“被故意忽视”的困境。这个困境的关键并不在于它们是不是基于 K8s 构建的,而是它们能不能带来像 K8s 一样的开放与自由。

可是,另一方面,Kubernetes 本身从始至终都不是一个面向最终用户的体验,也不是最终用户想要的东西。Kubernetes 自身“白盒化”的体验正在为越来越多的业务研发和运维带来“太复杂”的困扰。而这个社区里大量的 CRD Operator 则像一个个烟囱,彼此孤立,不能联动,而且有大量的冗余(比如:Kubernetes 中永无止尽的 Ingress 实现 )。这一切都说明,纯粹使用 Kubernetes 并非托管云原生应用的“标准答案”。而那些试图“给 K8s 写个界面”的 PaaS 构建者们,似乎又陷入了 Heroku 的困境。这种变化,也让 PaaS 与 Kubernetes 之间的关系越来越复杂和不清晰。

从 Kubernetes 到“以应用为中心”的美好未来之间,全世界的 PaaS 工程师其实都在期待一项全新的技术能够弥补这之间的鸿沟。阿里云原生应用平台团队的做法是,通过为应用“建模”的方式来解决这个问题,这也正是 Open Application Model (OAM) 开源项目得以创建的重要目的。

最后

OAM(Open Application Model)开放应用模型是阿里联合微软针对云原生应用的模型,第一次对“以应用为中心”的基础设施和构建规范进行了完整的阐述。应用管理者只要遵守这个规范,就可以编写出一个自包含、自描述的“应用定义文件”。

OAM 相关内容在 github 上完全开源,同时我们也为 Go 生态编写了 oam-go-sdk 方便快速实现 OAM。

目前,阿里巴巴团队正在上游贡献和维护这套技术,如果大家有什么问题或者反馈,也非常欢迎与我们在上游或者钉钉联系。

参与方式:

  • 钉钉扫码进入 OAM 项目中文讨论群

4.png

钉钉扫码加入交流群

5.png

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

Artifactory & GitLab CI持续集成实践

JFrogchina阅读(1113)评论(0)

GitLab CI支持创建多个构建,并评估每次代码提交是否通过测试和以及对您产品的影响。在构建过程中,会生成大量二进制文件,如果不能正确的大规模管理这些文件,就会导致二进制文件管理混乱。为了克服这个问题,Artifactory被无缝地集成到GitLab CI构建过程中,以便更好的发布和管理这些二进制文件,并通过JFrog CLI, GitLab CI缓存、发布您的依赖包、制品包和构建信息到Artifactory。

这篇文章描述了如何将 GitLab CI 与 Artifactory 集成在一起,不仅可以解析和部署二进制文件,还可以从 Artifactory 的 Build Integration 功能中获取更多帮助。

将 Artifactory 与 GitLab CI 集成后,您可以存储和查看以下信息:

  • 构建信息和发布的模块
  • 使用的依赖
  • 环境变量
  • 许可证摘要
  • 链接到您的 Jira issue
  • 构建之间的差异

 

一、 环境配置

  • 安装Gitlab Runner配置Gitlab 此处不再赘述
  • 准备一个示例项目

https://gitlab.com/guoyunzong/maven-example.git

  • Artifactory 中创建仓库(2 local,1 remote,1 virtual):maven-dev-local、maven-pro-local、maven-remote、maven-virtual
  • 在项目目录下编写配置文件 conf

version: 1

type: maven

resolver:

snapshotRepo: maven-virtual

releaseRepo: maven-virtual

serverID: Default-Server

deployer:

snapshotRepo: maven-virtual

releaseRepo: maven-virtual

serverID: Default-Server

 

在项目目录下编写配置文件 jira-cli.conf

version: 1

issues:

serverID: Default-Server

trackerName: JIRA

regexp: (.+-[0-9]+)\s-\s(.+)

keyGroupIndex: 1

summaryGroupIndex: 2

trackerUrl: http://my-jira.com/issues

aggregate: true

aggregationStatus: RELEASED

  • 在gitlab中配置artifactory的环境变量,Settings—CI/CD–Variables ,如:

ARTIFACTORY_URL http://192.168.230.32:8081/artifactory

ARTIFACTORY_USER admin

ARTIFACTORY_PASS password

MAVEN_REPO_KEY maven-virtual

 

二、编写 Gitlab CI 脚本并执行构建

  • 在项目目录下编写脚本.gitlab-ci.yml

image: docker:git

services:

– docker:dind

 

stages:

– build

 

build:

image: maven:3.5.4-jdk-8-alpine

stage: build

script:

# Install

– apk add git

 

# Set the M2_HOME environment variable

– export M2_HOME=/usr/share/maven

 

# Download JFrog CLI

– curl -fL https://getcli.jfrog.io | sh

 

# Configure Artifactory instance with JFrog CLI

– ./jfrog rt config –url=$ARTIFACTORY_URL –user=$ARTIFACTORY_USER –password=$ARTIFACTORY_PASS

– ./jfrog rt c show

 

# Mvn clean install

– ./jfrog rt mvn “clean install” maven.conf –build-name=gitlabci-maven-artifactory –build-number=$CI_JOB_ID

 

# Collect the environment variables

– ./jfrog rt bce gitlabci-maven-artifactory $CI_JOB_ID

 

# Add jira issue

– ./jfrog rt bag gitlabci-maven-artifactory $CI_JOB_ID –config jira-cli.conf

 

# Add sonaroptional

– ./jfrog rt sp “maven-dev-local/org/jfrog/test/multi3/3.7-SNAPSHOT/*.war” “qulity.gate.sonarUrl=http://192.168.230.156:9000/dashboard/index/gitlabci-maven-artifactory”

 

# Add propertiesoptional

– ./jfrog rt sp “maven-dev-local/org/jfrog/test/multi3/3.7-SNAPSHOT/*.war” “deploy.tool=ansible”

– ./jfrog rt sp “maven-dev-local/org/jfrog/test/multi3/3.7-SNAPSHOT/*.war” “ip=127.0.0.1”

 

# Pass the build information to Artifactory   

– ./jfrog rt bp gitlabci-maven-artifactory $CI_JOB_ID

 

# Promote

– ./jfrog rt bpr gitlabci-maven-artifactory $CI_JOB_ID maven-pro-local

 

# Xray scanoptional

– ./jfrog rt bs gitlabci-maven-artifactory $CI_JOB_ID –fail=false

 

# Downloadoptional

– ./jfrog rt dl maven-dev-local/org/jfrog/test/multi3/3.7-SNAPSHOT/multi3-3.7-20191213.050538-8.war all-my-frogs/

 

when: manual

 

  • 提交代码,输入git commit message,格式如下

HAP-1007 – This is a sample issue

 

  • 执行构建(可配置手动自动执行)

CI/CD–Pipelines

  • Job中查看构建输出

 

  • artifactory中的issue信息可点击 HAP-1007 链接至 Jira 地址

 

 

更多 精彩内容 请微信搜索公众号:jfrogchina

更多技术分享 可以关注 2  20 日在线课堂:《Artifactory & GitLab CI持续集成实践》

 

课程介绍

现在随着开源项目越来越多,大部分开发人员都会去引用大量第三方依赖,开源第三方组件的使用频率大幅增加。引用第三方已经开发好的组件给我们所有开发者带来极大的便利,减少了大量的重复性工作,提升了开发效率。但同时也给我们带来了一些隐患,因为开源并不代表这个软件是安全的,如何对引用第三方包进行安全管控是企业需要关注的问题

 

课程收益

本次课程主要介绍JFrog Xray如何解决第三方组件的安全问题。

 

本期话题

  1. 第三方组件的介绍
  2. Xray介绍
  3. Xray使用场景及实践

 

课堂活动

本期课堂讲师会在结束前进行抽奖活动

第一名:小米蓝牙耳机

第二名:JFrog新版T恤

第三名:JFrog新版T恤

 

 

报名链接:https://www.bagevent.com/event/6370474

CapitalOne – Artifactory高可用集群的自动化部署实践

JFrogchina阅读(959)评论(0)

背景:

本文为大家介绍Capital One如何利用自动化流水线实现Artifactory HA集群进行自动化运维。Capital One银行是美国最大的数字化银行之一,在Capital One的devops体系中应用了JFrog Artifactory HA集群进行软件制品管理。由于Capital One规模庞大并且为满足业务连续性要求,其部署的Artifactory HA拥有primary和DR(灾备)两套集群的架构。在运维Artifactory HA集群维护中通过建设和运行自动化的流水线,在不影响用户使用和业务连续性的前提下,自动地完成了版本升级、配置更新、功能更新,安全检测等工作,并且在检测到问题时,实现自动化的回滚。

流水线总体介绍:

通过Jenkins与Github集成驱动流水线。每个PULL请求触发一个小规模测试并提供快速反馈。每个Merge会触发研发环境HA集群范围的部署,并进行相关测试。标签(Tag)被用来标记代码更新的验证阶段和对应的环境。

使用Terraform创建基础设施,实现蓝/绿的发布。并通过Chef Cookbook完成整个集群内所有角色服务器配置

 

流水线构成

静态分析流水线

 

通过对代码静态分析对代码结构进行快速反馈,确保其符合行业标准。同时使用一系列的Linters进行不同类型的代码分析。

 

安全扫描流水线

 

 

Capital One引入DevSecOps概念,能够在产品上线之前进行安全扫描和漏洞检测。安全检查主要使用了静态安全检测通过代码扫描来完成漏洞发现。除了静态检测还通过对比分析,使用Jfrog Xray对依赖进行安全扫描,提高第三方依赖的安全性,并提供修复建议。

 

单元测试流水线

 

单元/集成测试,用于验证代码的更新不会破坏预期的功能。主要应用于用户自定user plugin的测试。流水线通过容器方式拉起Artifactory安装并测试这些custom plugin,确保其正确工作,避免在生产环境中进行测试。

 

构建阶段流水线

 

本阶段的所有文件都需要部署在一个高可靠的位置,以便在系统运行时进行自动扩展不需要去依赖其他任何系统包括Artifactory。Capital One选择了S3进行外部存储。所有制品与chef cookbook都从Artifactory拉取并存到s3中。

 

用于部署的流水线

 

部署流水线需要确保新集群部署不会影响到现有Artifactory提供正常服务。

1 流量切换到DR区域

2 缩容现有集群,减少节点数量并释放license给新的集群使用,Aritfactory集群采用多主架构在所容时不会影响剩余节点的正常工作

3 新部署集群复用原油的数据库与s3存储内容做到无痕切换

4 当新集群完成部署后,业务流量进行回切

5 主集群完成升级后,DR集群进行升级

由于Artifactory使用数据同步机制,因此新节点加入集群的过程对用户透明。

 

配置测试流水线

 

 

在工作节点上线前需要对其配置进行检测,Jenkins通过ssh方式驱动新节点进行测试,确保Artifactory,Nginx,Datadog,Splunk这些工作节点运行正常。

确保所有的工作节点配置文件的内容、位置、权限都部署正确,以及所有的网络端口都正常开通。

 

系列测试流水线

 

系列测试是确保Artifactory的各个repositories运行正常。通过容器拉取所有种类的repositories中的包进行测试,同时检测所有virtual repositories,并且需要测新的系统配置是否会影响制品依赖的解析。

 

性能测试流水线

 

确保发布产品不会存在性能问题。Capital One使用Jmeter工具模拟生产级流量并分析,15分钟的负载测试作为流水线的一部分,使用1小时负载测试主线升级以及重大变更场景。

由于Artifactory支持多种类型的包因此在流量模型是一个挑战,Capital One通过分析日志获取常用API,并在流量峰值时期测试API调用速度。

 

回滚策略流水线

 

Capital One设计了两个回滚策略:

  1. In-region回滚。当部署后的测试失败时,马上启动自动化回滚,删除新的集群,并恢复旧的集群。
  2. DR容错回滚。当主集群升级成功后,或监测几天用户流量,没有问题的时候再更新容灾集群。如果在这几天中发现问题,就会启动容错回滚:用户流量切换到DR集群,主集群回滚到之前版本,数据库回滚到之前的快照,再通过Artifactory Replication同步数据,最后再把流量切换回回滚后的工作集群。目前

由于数据库的回滚可能会有DataBase schema的变化,Capital One目前在数据库回滚操作上依然使用手动方式完成。

 

自动化流水线部署带来的收益

 

 

Capital One通过自动化流水线部署Artifactory HA为团队带来的收益:

*加快部署进度并且使开发人员能更专注于代码开发本身,不再需要花费时间维护制品管理的工具。

*Capital One更好的扩展性,整个集群的扩缩容都可以由流水线完成

*全面的测试流程确保用户体验

*自动化回滚策略,加快故障检测和响应,减少对生产业务影响

 

 

更多精彩内容请关注公众号:JFrog杰蛙DevOps

更多技术分享可以关注218日在线课堂:《Artifactory企业版介绍》

报名链接:https://www.bagevent.com/event/6365977

 

课程介绍

在企业数字化转型的背景下,应用的更新迭代周期正在不断加速,如何在多语言环境下建设一套高性能,高可用的应用制品管理平台成为企业在数字化转型中的一个新课题。

 

课程收益

本期通过演示事例说明如何通过Artifactory企业版实现制品管理,元数据管理,制品与依赖安全管理。并且实现Artifactory与Jenkins的集成使用。

 

本期话题

1 artifactory企业版的特性以及高可用架构

2 如何通过Artifactory实现多语言环境的制品管理

3 通过Artifactory建立企业级制元数据管理平台

4 如何实现制品依赖安全管理

 

课堂活动

本期课堂讲师会在结束前进行抽奖活动

第一名:小爱音响

第二名:JFrog新版T恤

第三名:JFrog新版T恤

国内首个 Kubernetes SIG-Cloud-Provider 子项目揭秘 | 云原生生态周报 Vol. 37

alicloudnative阅读(531)评论(0)

作者 | 高相林、陈俊、陈有坤、敖小剑

业界要闻

  1. 国内首个 Kubernetes SIG-Cloud-Provider 子项目揭秘 

阿里云作为坚定的云原生计算推动者,贡献了阿里云上运行 Kubernetes 的最佳开源组件,成为 SIG Cloud Provider 子项目的国内首个云厂商。2020 年 2 月 12 日上午 10:00,阿里云 Kubernetes 团队召开了首次线上网络研讨会。

  1. 什么技术,让阿里拿下国家技术发明奖?

新年伊始,国家科学技术奖励大会在北京人民大会堂隆重举行。阿里云获得国家技术发明奖、国家科技进步奖两项国家大奖。这是互联网公司首次同时荣获两大国家科技奖,也实现了互联网公司在国家技术发明奖上零的突破。

  1. CNCF 发布 containerd 旅程报告

该报告对 containerd 发展过程进行了总结和分析。

上游重要进展

Kubenetes

  1. Build Kubelet without Docker

该 KEP 旨在提出一个方案,使得编译 Kubelet 不再依赖 Docker 相关的代码。

  1. Fix statefulset conversion

修复了 statefulset 相关资源转换中的 bug,该 bug 会导致无法多次 apply 同一个 statefulset。

  1. Add code to fix kubelet/metrics memory issue.

修复 kubelet metrics 中关于内存统计的 bug。

  1. Fixing Potential Race Condition in EndpointSlice Controller.

修复了在 EndpointSlice Controller 所潜在的竞争风险。

  1. add *Options to Create, Update, and Patch in generated clientsets

为 clientsets 中的 Create, Update, 和 Patch 操作添加对应的 Options。

Knative

  1. Knative Serving 0.12.1 版本发布

本次发布依然是稳定性变更,网络层引入了Contour。

Istio

  1. Istio 引入 EGDS 以支持 Endpoint 的增量推送

Istio 和 Envoy 开始引入新的 xDS 资源类型 EGDS(Endpoint Group Discovery Service)  ,以支持通过 EGDS 来实现 Endpoint 的动态更新。EDS 可以包括任意个 EGDS 资源,而每个 EGDS 包含一定数量的 Endpoint。引入 EGDS 的背景是当 Cluster 很大时,比如拥有 10000 个 Endpoint,即使只有少量 Endpoint 发生变化也将导致完整的 EDS 推送,为提升考虑需要考虑 Endpoint 的增量推送。

  1. Istio 新加入 Virtual Service chaining 功能

Virtual Service链 是对 Istio Virtual Service 规范的改进,容许在多个可组合的 VirtualService 资源中指定 mesh 的路由配置,这些 VirtualService 资源可以被链接起来以对用户友好的方式来创建高级流量路由功能。可组合的 VirtualService 资源容许拥有多个团队的组织为他们创建的服务维护路由资源的所有权,并容许运维人员管理 Gateway 和 Ingress 级别的路由,来让流量进入Mesh并引导到合适的后端服务路由资源。

开源项目推荐

  1.  kube-storage-version-migrator

可以将集群内资源老版本的 ApiVersion 迁移到新的版本。

  1. kubepug

kubepug 是一个 kubectl 插件,可以在集群升级之前对集群进行扫描,如果有集群中存在着在目标版本中废弃或者删除的资源,则会给出相应的警告。

  1. kind

kind 是一个可以在 docker 的软件,我们可以通过本地拉起的 K8s 集群进行测试。

本周阅读推荐

  1.  《The Missing Kubernetes Platform for Developers》

文章阐述了一些对于开发者来说,使得 K8s 更加易用的措施。也对其理想中的 K8s 开发平台进行描述。

  1. 《Kubernetes Networking Demystified: A Brief Guide》

K8s 网络揭秘文章,对 K8s 网络进行了介绍。

  1. 《一文教你一次性完成 Helm 3 迁移》

这篇官方指南十分直观地告诉了你,将版本分别迁移到 Helm 3 所需准备的一切。

  1. 《OAM 深入解读:OAM 为云原生带来哪些价值?》

OAM 是阿里巴巴联合微软在社区推出的一款用于构建和交付云原生应用的标准规范,旨在通过全新的应用定义、运维、分发与交付模型,推动应用管理技术向“轻运维”的方向迈进,全力开启下一代云原生 DevOps 的技术革命。

首次 sig-cloud-provider-alibaba 网研会

2020 年 2 月 12日上午 10:00, 首次 sig-cloud-provider-alibaba 网研会召开。

本次研讨会阿里云首次完整介绍了阿里云对 Kubernetes 社区的布局;详细介绍了阿里云围绕 Kubernetes 提供的十个类别、20 多个开源项目,帮助开发者完整管理 Kubernetes 生命周期。

Slack 地址:https://app.slack.com/client/T09NY5SBT/CRX9UN2DN/

该会议的完整视频记录:https://www.bilibili.com/video/av88668762

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”