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

alicloudnative阅读(2822)评论(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的安装实录

JFrog捷蛙阅读(6116)评论(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阅读(3808)评论(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阅读(2296)评论(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阅读(3100)评论(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自动化工具链

JFrog捷蛙阅读(4914)评论(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阅读(2319)评论(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持续集成实践

JFrog捷蛙阅读(4283)评论(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高可用集群的自动化部署实践

JFrog捷蛙阅读(3451)评论(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阅读(2267)评论(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 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

Rainbond v5.2.0-beta1发布,众多变化请查看详情

好雨云阅读(1879)评论(0)

下载安装

安装文档参考: https://v5.2-doc.rainbond.com/docs/quick-start/rainbond_install/

版本变更

安装与运维

  • Rainbond系统安装和运维管理重构为Operator模式,运行于Kubernetes集群内部。

  • 解除对Kubernetes的强依赖关系,Rainbond不再维护Kubernetes集群安装脚本,推荐使用 easzup

  • Rainbond-Operator安装采用Helm包管理工具安装。

  • Rainbond系统安装提供UI界面,实时把控安装进度,后续版本UI提供系统运维、升级等功能。

  • 安装提供多种参数可选配置,包括镜像仓库、数据库、ETCD集群等关键配置。

  • 系统组件生命周期由Kubernetes和Rainbond-Operator共同维护和管理。

一句话,你有Kubernetes集群(1.13及以上)就可以试试Rainbond带来的不一样的体验。

应用存储

  • Rainbond 组件存储抽象支持存储类型支持通过Kubernetes StorageClass 扩展,通过增加集群中的StorageClass即可扩充Rainbond支持的存储类型,目前测试接入的存储类型包括阿里云盘、Ceph块设备等

  • 组件存储模型增加容量、挂载状态属性。

  • 应用分享安装、跨集群迁移等用例中基于简要算法选择合适的存储类型,后续版本中将基于存储特性指标更加智能选择。

应用网关

  • 重构TCP/UDP类访问策略的负载均衡机制,Upstream的更新机制由过去生成Nginx配置文件并Reload修改为Lua控制的动态更新,无需触发Reload。

  • HTTP访问策略默认支持X-Forwarded-Proto X-Scheme等参数 #591

  • 新增对Rainbond数据中心API,控制台UI等外网控制入口的代理,集群所有请求统一由网关组件进入。

源码构建

  • 重构源代码构建任务运行模式,由管理节点运行变更为Kubernetes Job任务,在集群计算节点运行,进而支持高并发构建任务。

  • Golang语言Buildingpack升级,增加对Go mod模式依赖包管理的支持,支持Go 1.12 1.13 #613

  • Java相关语言Buildingpack升级,支持JDK 11 12 13, Maven 3.5.4 3.6.2

  • PHP语言Buildingpack升级,支持php 7.2.26 7.3.13 版本

  • NodeJS/NodeJS前端 两种语言类型支持UI设置构建参数

其他变更

  • 所有系统组件对ETCD的通信默认支持TLS认证

  • grctl命令行变更安装方式,新增grctl gateway grctl envoy 等功能辅助运维。

  • 组件支持使用privileged模式运行 #333

    移除功能

    • 移除命令行扩充集群节点功能,改由easzup 扩充Kubernetes集群后Rainbond节点自动扩充。

    • 移除“全局共享存储”存储类型的自动化安装(无权限操作宿主机),改由用户使用简化命令行工具安装。

    • rainbond-ansible 项目仅用于V5.1版本。

基于Jenkins打造符合DevOps能力成熟度三级标准的持续集成流水线

JFrog捷蛙阅读(5657)评论(0)

DevOps的核心是自动化,自动化的核心是标准化。而DevOps最重要的一环节是持续交付,持续交付中建设的重点是流水线,所以如何打造标准的持续交付流水线则为DevOps建设中最重要的一环,也是评估DevOps能力的一个重要的打分点。

本文内容参照《研发运营一体化(DevOps)能力成熟度模型 第3部分:持续交付》,基于jenkins,对持续集成流水线建设的一些关键点进行技术应答,带领大家把方法论落地到具体的技术点上。

 

文中涉及到的几个名词解释:

  • 流水线:pipeline,一个应用程序从构建、部署、测试和发布这个过程实现自动化
  • 制品:构建过程的输出物,包括软件包、测试报告、应用配置文件等。
  • 制品库:存储全语言制品的仓库,提供依赖解析及文件存储能力。
  • 元数据:软件生命周期全过程数据,如需求id、代码提交信息、构建环境、静态扫描结果、测试通过率、安全扫描结果等。

 

文章中涉及到的一些技术详解:见文章《打造企业级pipeline服务的18个疑问》

 

下面,我们来看一下持续集成流水线建设中的配置管理、构建与持续集成、测试管理、部署与发布管理、环境管理、数据管理、度量与反馈的七个维度的三级标准是如何定义的,并且哪些指标需要在jenkins流水线中体现,如何使用jenkins流水线达到此标准。

 

  • 配置管理
三级标准 Jenkins流水线落地建议方案
版本控制 版本控制系统 1)将配置文件、构建和部署等自动化脚本纳入版本控制系统管理。
2)有健全的版本控制系统管理机制,包括:代码库命名规范备份与可用性保障机制权限模型专人专岗管理。
流水线内容(Jenkinsfile)需要纳入版本管理
流水线的命名需要有明确规范
流水线应明确权限,开发人员应只有可读权限,模版由专门团队编写
技术点:可使用jenkins的Share library特性,由专门团队在源码仓库中统一管理流水线,
分支管理 短周期分支分支频繁地向主干合并 非流水线内容
制品管理 1)将依赖组件纳入制品库管理
2)将所有交付制品纳入制品库管理,比如:测试报告
3)制品库读写有清晰的权限管控制度
建设统一制品库,如Artifactory。设置完整的权限。
收集构建流水线过程中的所有工具的结果数据,并将此类数据定义成元数据,与制品绑定。如需求、代码提交信息、构建环境信息、依赖信息、静态扫描信息、单元测试信息、安全扫描信息等。
技术点:可采用商用制品库、如Artifactory。也可自行开发元数据管理系统,收集构建中过程数据。
单一可信数据源 版本控制系统和制品库作为单一可信数据源,覆盖生产部署环节 建立统一制品库,在jenkinsfile中指明制品库地址,构建时不使用pom文件中的依赖解析地址,而由其他方式修改依赖解析仓库到唯一可信仓库中
技术点:使用Artifactory统一管理制品库,保证唯一可信源
变更管理 变更过程 1)所有配置项变更由变更管理系统触发
2)针对每次变更内容进行评审,并使用自动化手段
不涉及流水线、注意配置与应用分离、及配置中心管理
变更追溯 实现版本控制系统和变更管理系统的自动化关联,信息双向同步和实时可追溯 不涉及流水线
变更回滚 1)实现变更管理系统和版本控制系统的同步回滚,保证状态的一致性
2)回滚操作实现自动化
不涉及流水线,

 

  • 构建与持续集成
三级标准 Jenkins流水线落地建议方案
构建实践 构建方式 1)定义结构化构建脚本,实现模块级共享复用
2)构建脚本由专人专岗统一维护
技术点:使用Jenkins ShareLibrary实现构建模块化管理,并实现全局共享
构建环境 1)构建环境配置实现标准化
2)有独立的构建资源池
打造少量固定的标准化构建节点作为独立的构建资源池,并用k8s集群创建动态构建节点作为动态资源池。
技术点:jenkins主从架构、jenkins on k8s
构建计划 1)实现定期自动执行构建和代码提交触发构建
2)明确定义构建计划和规则,并在研发团队内共享
技术点:jenkins触发器,可实现定时构建、轮询源码构建或webhook触发构建
构建职责 构建工具和环境由专门团队维护并细分团队人员职责 jenkins主从节点或构建镜像由统一团队维护。业务部门只使用,不能修改。
持续集成 集成服务 组建专门的持续集成团队,负责优化持续集成系统和服务 统一团队构建流水线模版与持续集成环境,供开发人员选择
技术点:可以通过jenkins on k8s方式,打造多种构建环境镜像,开发人员提交构建任务时定义所需环境。
集成频率 研发人员至少每天向代码主干集成一次 不涉及流水线
集成方式 每次代码提交触发自动化构建,构建问题通自动分析精准推送相关人员处理 每次提交代码触发jenkins进行构建,并在构建过程中执行完整的静态扫描、单元测试等步骤
技术点:jenkins的触发器功能,可以设置轮训scm或git的webhook触发
反馈周期 集成问题反馈和解决可以在几个小时内完成 jenkins pipeline中要通知构建工作完成或失败状态,发邮件或webhook给运维团队和业务团队

 

  • 测试管理
三级标准 Jenkins流水线落地建议方案
测试分层策略 分层方法 1)采用代码级测试对模块的函数或类方法进行覆盖全面的单元测试;
2)系统全面的进行性能、容量、稳定性、可靠性、易用性、兼容性、安全性等非功能性测试
在流水线中进行单元测试,收集单元测试通过率作为元数据与制品绑定。
分层策略 1)测试设计以对接口/服务级测试为主,兼顾用户/业务级测试辅以少量的代码级测试
2)对非功能性测试进行全面系统的设计
在流水线中可以集成接口测试,并收集接口测试通过率作为元数据与制品绑定。
测试时机 1)测试在持续交付过程中的介入时间提前到开发的编码阶段
2)代码级测试在模块的函数或类方法开发完成后进行
提高单元测试覆盖率。
代码质量管理 质量规约 1)建立组织级代码质量规约
2)建立完整的质量规约,将安全漏洞检查、合规检查纳入规约
3)建立强制执行的质量门禁体系
4)建立规约固定更新机制
需要在jenkins流水线中增加安全扫描步骤,并对扫描测试结果设置质量关卡。
技术点:Xray作为安全扫描工具集成在流水线中、通过制品元数据作为质量门禁判断构建产物是否达标
检查方式 代码质量检查完全自动化,不需要手工干预 流水线集成sonar扫描工具,每次代码提交自动触发构建、自动化进行源码扫描,并将代买坏味道数量、代码重复率等结果数据以元数据方式回写制品库。
技术点:sonarqube代码静态扫描
反馈处理 根据代码质量检查结果反馈及时处理,根据质量规约维持一定的技术债 代码静态扫描结果与制品绑定,回写到制品库。通过制品携带的元数据是否通过质量门禁,来判断制品质量。
自动化测试 自动化设计 1)对接口/服务级测试进行自动化设计
2)对代码级测试进行自动化设计
jenkins 流水线增加接口测试及服务测试
自动化开发 1)建立统一的自动化测试框架,统一管理自动化测试用例
2)自动化测试脚本开发采用数据驱动、关键字驱动等方法;
不涉及流水线
自动化执行 1)对接口/服务级与代码级测试采用自动化测试
2)自动化测试由流水线自动化触发
在流水线中进行所需测试
自动化分析 对自动化测试结果具备较强的自动判断能力,误报少 流水线中收集各项测试结果,作为元数据与交付物关联,保障每个制品都能获取到完整的测试结果。

 

  • 部署与发布管理
三级标准 Jenkins流水线落地建议方案
部署与发布模式 部署方式 部署和发布实现全自动化 部署过程作为流水线的必要步骤
技术点:对接如saltstack、ansible等工具在流水线中部署
部署过程 1)使用相同的过程和工具完成所有环境部署
2)一次部署过程中使用相同的构建产物
为确保发布内容为测试过的内容,要实现一次构建多次部署。通过元数据与仓库名标识制品成熟度。流水线中要将制品在不同成熟度仓库移动,并收集各个环境中的结果数据作为元数据存储。
技术点:应用配置分离、Artifactory元数据及promotion功能
部署策略 1)采用定期部署策略,具备按天进行部署的能力
2)应用和环境整体作为部署的最小单位
3)应用和配置进行分离
不涉及流水线
部署质量 1)部署失败率低
2)部署活动集成自动化测试功能,并以测试结果为部署前置条件
3)每次部署活动提供变更范围报告和测试报告
部署后会在流水线中进行简单验证,收集验证结果数据。测试结果收集到元数据中,部署时验证元数据,判断是否通过质量门禁,来实现部署。               技术点:Artifactory元数据

 

持续部署流水线 协作模式 通过定义完整的软件交付过程和清晰的交付规范,保证团队之间交付的有序 标准化工具链及持续集成流水线,收集个阶段结果数据作为元数据,用元数据标识制品的质量标准,供各个团队间进行使用。
流水线过程 软件交付过程中的各个环节建立自动化能力以提升处理效率 不涉及流水线
过程可视化 1)交付过程在团队内部可见,信息在团队间共享
2)交付状态可追溯
流水线中收集整个构建过程结果数据,与制品绑定,供所有团队查看。
技术点:Artifactory元数据

 

  • 环境管理
三级标准 Jenkins流水线落地建议方案
环境管理 环境类型 建立标准的研发环境 不涉及流水线
环境构建 1)环境的构建通过自服务的资源交付平台来完成
2)环境准备时间小时级
可在流水线中自动创建所需环境。
技术点:使用k8s的helm自动拉起整套环境,helm是最佳的实现方式
环境依赖于配置管理 以应用为中心,有服务级依赖的配置管理能力,比如:依赖的关联服务,数据库服务、缓存服务、关联应用服务等等 不涉及流水线

 

  • 数据管理
三级标准 Jenkins流水线落地建议方案
测试数据管理 数据来源 导出部分生产环境数据并清洗敏感信息后形成基准的测试数据集 不涉及流水线
数据覆盖 建立体系化测试数据,进行数据依赖管理,覆盖全部测试分层策略要求的测试类型 不涉及流水线
数据独立性 1)每个测试用例拥有专属的测试数据有明确的测试初始状态
2)测试用例的执行不依赖其他测试用例执行所产生的数据
不涉及流水线
数据变更管理 变更过程 将数据变更纳入持续部署流水线,经人工确认后自动完成 流水线与审批系统集成。
兼容回滚 每次数据变更同时提供明确的回滚机制,并实现进行变更测试,如:提供升级和回滚两个自动化脚本 不涉及流水线
数据监控 针对不同环境和危险程度对数据变更建立分级监控机制 不涉及流水线

 

  • 度量与反馈
三级标准 Jenkins流水线落地建议方案
度量指标 度量指标定义 建立跨组织度量指标,进行跨领域综合维度的度量 不涉及流水线
度量指标类型 度量指标覆盖过程指标,客观反映组织研发现状 流水线中需要收集元数据,作为后续度量指标
度量数据管理 持续收集度量数据历史度量数据有明确的管理规则 流水线中需要收集元数据,作为后续度量指标
度量指标更新 1)度量指标可以按照需求定期更新
2)度量指标的优先级在团队内部达成一致
不涉及流水线
度量驱动改进 内容和生成方式 度量报告进行分类分级并按需生成内容 流水线中需要收集元数据,作为后续度量指标。对元数据进行二次清晰,生成报告
数据时效性 通过可视化看板实时展示数据 看板需要展示流水线状态,如构建时间、通过率、故障率等
覆盖范围 全部团队成员均可查看报告 不涉及流水线
反馈改进 度量反馈问题纳入研发迭代的待办事项列表,作为持续改进的一部分 不涉及流水线

 

通过上述数据及分析,可以看出,打造出一个标准的流水线服务可以匹配到60%的三级标准。那么我们可以在整个DevOps的建设中投入较大的力量来打造流水线。一套标准的流水线服务和稳定的工具链将会成为DevOps建设的一个基石,并且成为贯穿你的整个建设周期中。

 

 

学习更多技术知识可以关注我们的在线课堂

关注微信公众号:JFrog杰蛙DevOps, 获取课程通知