灵雀云

你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!

灵雀云

2019企业IT现状和趋势调研报告：70.7%的企业有云原生相关计划

灵雀云发表了文章 • 0 个评论 • 136 次浏览 • 2019-06-03 11:00 • 来自相关话题

2019年第一季度，灵雀云发起了“企业IT应用现状和云原生技术落地情况”的调研，通过定向邀请，3个月内共收集了400余份有效调研问卷，这些调研问卷80%以上都来自于国内政府、金融、能源、制造、汽车等传统行业的IT从业者。发起本次调研 ...查看全部

2019年第一季度，灵雀云发起了“企业IT应用现状和云原生技术落地情况”的调研，通过定向邀请，3个月内共收集了400余份有效调研问卷，这些调研问卷80%以上都来自于国内政府、金融、能源、制造、汽车等传统行业的IT从业者。

发起本次调研的初衷，是我们希望了解当前企业，尤其是传统企业目前IT应用开发现状、以及以DevOps、Kubernetes、微服务等为代表的云原生技术在企业的应用情况，从而勾勒出传统行业IT发展趋势，并对于判断国内用户对云原生相关技术的认知度提供一个有价值的参考。
核心要点解读：
1、约70%的参与调研者所在企业2019年IT预算有上浮；

2、 24.4%的参与调研者表示公司IT系统基本全靠自研，企业开始自建软件研发团队，主导IT应用的研发；

3、 70.7%的参与调研者所在企业表示在2019年有容器、DevOps和微服务方面的规划；

4、 11.4%的参与调研者所在企业已经试点了具有标杆意义的云原生实践，如精英团队的DevOps实践，小范围非核心应用的微服务拆分改造实践等。

本次调研的400多位调研对象中，80%以上来自金融、能源、制造、汽车等传统行业，其中17.3%来自基础架构部门， 22.5%来自运维部门，34.1%来自研发部门，还有约10%的被调研对象为企业的CIO/CTO等高级IT管理者。

被调研企业中，服务器规模在100-500台的比例为26.8%，500-1000台的企业占比22%，1000台服务器以上规模的14.6%。

IT系统自研还是外包

在数字化转型的背景下，传统外包的做法在被逐渐改变。在此次调查中，70.7%的参与调研者表示目前IT系统是自研外包兼而有之，其中核心业务系统以自己开发为主，24.4%的参与调研者表示公司IT系统基本全靠自研，只有4.9%的参与调研者选择了纯外包选项。这表明，企业开始不再将大部分业务系统，尤其是核心业务需求开发外包，开始自建软件研发团队，主导IT应用的研发。只有企业自己主导IT研发，才能够打造IT核心竞争力。

软件能力成为企业的核心竞争力，这恰好是数字化转型的本质之一。何谓成功的数字化转型？灵雀云认为，有三大衡量标志：IT部门由成本中心转为收入中心；企业自己主导IT产品的研发；改进工具、流程、文化来提高交付速度和质量。最终，实现客户满意度的提升、打造差异化竞争优势、加速产品上市。

IT系统更新频率

在IT系统更新频率方面，每月都要更新、升级的比例达到了51.2%的高占比。同时，每3-6个月更新一次的比例达22%。每个传统领域，都受到了来自Fintech金融科技、车联网、物联网、新零售等新技术驱动的创新业务的挑战，传统企业只有借助IT手段才能实现持续发展，在速度和规模上保持竞争力。

IT系统和研发团队TOP 3挑战

本次参与调研的企业以中大型企业为主，其中研发团队规模达到100人以上的比例高达44.3%，20-100人规模的占32.4%。

今天，许多企业都经过了大量IT建设，从分散到集中，造成IT系统越来越复杂，信息孤岛林立，架构臃肿等问题突出。调研中企业IT系统支撑所面临的压力位列前三的挑战分别是：系统复杂性越来越高（65.9%）；应用交付压力大，交付速度无法满足业务需求（61.4%）；运维管理复杂度提升，IT部门很难构建一支全功能团队（53.7%）。

同时，研发团队所面临的挑战前三甲分别是：部署和运维复杂，运维成本高（74.6%）；研发、测试、运维等角色之间相互孤立（62.3%）；升级和变更流程复杂，IT服务和应用交付周期长（45.7%）。此外，比较突出的挑战还有，工具链无法完整集成，工具使用困难（32.3%），单体应用过于庞大，迭代效率低下（20.4%）。

上述结果充分表明，面对高度创新、快速变化和充满不确定性的新型业务需求，传统开发模式和IT架构已经成为掣肘。70.7%的参与调研企业表示2019年有容器、DevOps和微服务方面的规划和实施计划。

只有朝着持续交付、敏捷部署、快速迭代，通过敏捷IT赋予业务足够的敏捷，才能够满足不断变化的业务需求，重塑自身的生产力，形成竞争优势，带来更好的用户体验，这最终落到以Kubernetes/容器、DevOps和微服务为核心的云原生技术的落地上。云原生架构和理念与数字化转型一脉相承，帮助企业更加顺畅地实施数字化转型。

业务上云需求最强烈，开源、数字化转型受追捧

在企业最关注的新兴技术趋势方面，云计算占比82.9%，企业将业务上云，提升IT资源效率作为首要关注对象。大数据和人工智能紧随其后，占比分别为73.2%和46.3%。其中开源解决方案在调研对象中的关注程度达到24.4%。

当前开源技术正在进入快速发展阶段，向着企业应用的方方面面深入。开源及开源社区不断将新的工具、方法和最佳实践用于云原生的实际业务用例，解决云原生用户的关键问题。借助许多开源解决方案，云原生部署的复杂性和难度也在得以降低。

此外，数字化转型的关注度为33.6%。如今每位IT从业者言必称数字化转型，IT能力也直接指向助力数字化转型。CIO和其他IT管理者已将企业的数字化计划置于新的高度，希望通过数字化来改变企业的商业和业务模式，数字化业务将从初步试验走向大规模应用。伴随企业数字化业务的不断成熟，预计未来几年，数字化转型将进入爆发阶段。

传统企业2019年IT预算稳中有升

本次调研中，被调研企业今年IT工作的重点包括业务上云（56.1%），云原生、大数据、人工智能等新技术采用（53.7%），打造数字化团队，引领企业的数字化创新（43.9%），选择传统业务应用的比例不足20%。越来越多的企业将工作负载放在云端，将正在开发的应用或服务托管在云平台上，云市场不断增长。

在IT预算方面，比客观经济形势略显乐观，和2018年IT预算相比，接近70%参与调研企业2019年的IT预算略有上浮，其中增长5%以内的企业占比37.5%，增长5-10%的企业占比21.2%，增长10%以上的企业达到12.7%。

此外，调研结果显示，数字化转型是一项需要通盘考虑的工作，需要项目管理部门、技术管理部门、开发部门、运维部门共同参与，制定统一的数字化转型方案和决策并推进。有些参与调研的企业特别强调2018年已经在全公司范围内试点了具有标杆意义的云原生实践，如精英团队的DevOps实践，小范围非核心应用的微服务拆分改造实践等，并且这些都将在2019年进行大范围推广。

浅析 Kubernetes原生NetworkPolicy 网络策略，让更安全的容器运行环境唾手可得

灵雀云发表了文章 • 0 个评论 • 152 次浏览 • 2019-05-29 10:33 • 来自相关话题

k8s中的网络策略主要分为原生 NetworkPolicy 和第三方网络插件提供的网络策略。本文将主要分析原生Networkpolicy的网络策略。什么是网络策略 ...查看全部

k8s中的网络策略主要分为原生 NetworkPolicy 和第三方网络插件提供的网络策略。本文将主要分析原生Networkpolicy的网络策略。

什么是网络策略

网络策略（NetworkPolicy）是一种关于 Pod 间及 Pod 与其他网络端点间所允许的通信规则的规范。NetworkPolicy 资源使用标签选择 Pod，并定义选定 Pod 所允许的通信规则。

k8s中的网络策略由实现了CNI接口的网络插件提供，网络插件监听集群中 NetworkPolicy 资源的创建/删除/更新事件生成对应的规则来控制 Pod 的流量是否放行。

常见的支持 NetworkPolicy 的网络插件有：

Calico
Cilium
Kube-router
Romana
Weave Net

默认情况下 Pod 间及 Pod 与其他网络端点间的访问是没有限制的。

如下是一个 NetworkPolicy 定义的例子，该策略的含义是阻止所有流量访问有`app=web`这个 label 的 Pod。经常有人会问网络策略要怎么写，或者是这个网络策略代表了什么含义。笔者认为这个问题主要是因为使用者不了解网络策略的省缺行为。NetworkPolicy 字段含义NetworkPolicy 这个资源属于命名空间级别的，因此metadata 中的 namespace 不可省略，否则只会对default 命名空间下的满足条件的 Pod 生效。下面介绍下 NetworkPolicy 中各字段的含义，并说明各字段省缺值及其含义，主要看 (http://www.alauda.cn]Spec.io/docs/reference/generated/kubernetes-api/v1.14/#networkpolicyspec-v1-networking-k8s-io) 中的字段，podSelector: 必填字段，Pod 的标签选择器，表示该网络策略作用于哪些 Pod。如果为空`{}`则表示选中本命名空间下所有 Pod。policyTypes: 可选字段，字符串，策略规则类型，表示该网络策略中包含哪些类型的策略，可选为"Ingress", "Egress", 或 "Ingress,Egress"。未填时，这个值依据下面的 ingress 和 egress 来定。如果该字段未设置且下面只出现了 ingress，则对 egress 不做限制。如果填了这个值，同时后续没有设定对应的规则，则认为设定的规则对应的流量全部禁止。例如：

该规则就限制了所有 Pod 的出流量。ingress: 可选字段，数组，入站规则。互相间为或的关系，满足其中一条则放行。ports: 可选字段，数组，放行端口信息。互相间为或的关系，如果为空表示端口不受约束，如果非空，则表示除了出现的端口放行，其他未指定的端口都禁止。 -port: 可选字段，数字，协议端口号。如果不写，表示协议所有端口。 -protocol: 可选字段，字符串，协议。允许取值为 TCP，UDP，SCTP。省缺为 TCP。from: 可选字段，数组，放行源地址信息。互相间为或的关系，如果为空表示不约束源地址，如果非空，则表示除了出现的源地址放行外，其他源地址都禁止。 -ipBlock: 可选字段，放行 ip 段。 cidr: 标准 cidr，除了指定的cidr放行外其他都禁止。 except: 标准 cidr 字符串数组，表示前面cidr 中的放行的 cidr 段需要再排除掉 except 中指定的。 -namespaceSelector: 可选字段，namespace 的标签选择器，表示放行集群中的哪些命名空间中过来的流量。如果为空`{}`或未出现则表示选中所有命名空间。 -podSelector: 可选字段，Pod 的标签选择器，表示放行哪些 Pod 过来的流量，默认情况下从NetworkPolicy 同命名空间下的 Pod 中做筛选，如果前面设定了`namespaceSelector`则从符合条件的命名空间中的 Pod 中做筛选。如果为空`{}`则表示选中满足`namespaceSelector` 条件的所有 Pod。egress: 可选字段，数组，出站规则。互相间为或的关系，满足其中一条就放行。ports: 可选字段，数组，放行端口信息。互相间为或的关系，如果为空表示端口不受约束，如果非空，则表示除了出现的端口放行，其他未指定的端口都禁止。（详细字段同 ingress 中的 ports）to: 可选字段，数组，放行目的地址信息。互相间为或的关系，如果为空表示不约束目的，如果非空，则表示除了出现的目的地址放行外，其他目的地址都禁止。（详细字段同ingress 中的 from）介绍完 Spec 中各字段的含义及其默认行为后，做个简单的小结，NetworkPolicy 定义了放行规则，规则间是或的关系，只要命中其中一条规则就认为流量可以放行。下面以一个kubernetes官网中的例子来回顾下前面的知识。

首先该规则指定了命名空间为 default，选择了其中所有包含 `role=db` 这个 label 的 Pod，定义了入站流量规则与出站流量规则。对于入站流量，放行源地址来自 cidr 172.17.0.0/16 除了 172.17.1.0/24 之外的流量，放行来自有`project=myproject` 这个label的namespace中的流量，放行 default 命名空间下有 label `role=frontend` 的 Pod 的流量，并限定这些流量只能访问到 `role=db` 这个 label 的 Pod 的 TCP 6379端口。对于出站流量，只放行其访问目的地址属于 cidr 10.0.0.0/24 中，且端口为 TCP 5978的流量。需要注意的是 NetworkPolicy 选中的 Pod 只能是与 NetworkPolicy 同处一个 namespace 中的 Pod，因此对于有些规则可能需要在多个命名空间中分别设置。或者使用非原生的网络策略定义，例如 Calico 中的 GlobalNetworkPolicy。 NetworkPolicy 变更历史v1.6 以及以前的版本需要在 kube-apiserver 中开启 extensions/v1beta1/networkpolicies；v1.7 版本 Network Policy 已经 GA，API 版本为 networking.k8s.io/v1；v1.8 版本新增 Egress 和 IPBlock 的支持；附录

推荐观看Securing Cluster Networking with Network Policies - Ahmet Balkan, Google

一些常见的策略样例ahmetb/kubernetes-network-policy-recipes

使用 Jenkins + Ansible 实现 Spring Boot 自动化部署101

灵雀云发表了文章 • 0 个评论 • 233 次浏览 • 2019-05-22 10:43 • 来自相关话题

本文要点：设计一条 Spring Boot 最基本的流水线：包括构建、制品上传、部署。使用 Docker 容器运行构建逻辑。自动化整个实验环境：包括 Jenkins 的配置，Jenkins agent 的配置等。 ...查看全部

本文要点：
设计一条 Spring Boot 最基本的流水线：包括构建、制品上传、部署。
使用 Docker 容器运行构建逻辑。
自动化整个实验环境：包括 Jenkins 的配置，Jenkins agent 的配置等。

1. 代码仓库安排

本次实验涉及以下多个代码仓库：

% tree -L 1

├── 1-cd-platform # 实验环境相关代码

├── 1-env-conf # 环境配置代码-实现配置独立

└── 1-springboot # Spring Boot 应用的代码及其部署代码

1-springboot 的目录结构如下：

% cd 1-springboot

% tree -L 1 

├── Jenkinsfile # 流水线代码

├── README.md

├── deploy # 部署代码

├── pom.xml 

└── src # 业务代码

所有代码，均放在 GitHub：https://github.com/cd-in-practice

2. 实验环境准备

笔者使用 Docker Compose + Vagrant 进行实验。环境包括以下几个系统：
Jenkins * 1 Jenkins master，全自动安装插件、默认用户名密码：admin/admin。
Jenkins agent * 2 Jenkins agent 运行在 Docker 容器中，共启动两个。
Artifactory * 1 一个商业版的制品库。笔者申请了一个 30 天的商业版。
使用 Vagrant 是为了启动虚拟机，用于部署 Spring Boot 应用。如果你的开发机器无法使用 Vagrant，使用 VirtualBox 也可以达到同样的效果。但是有一点需要注意，那就是网络。如果在虚拟机中要访问 Docker 容器内提供的服务，需要在 DNS 上或者 hosts 上做相应的调整。所有的虚拟机的镜像使用 Centos7。
另，接下来笔者的所有教程都将使用 Artifactory 作为制品库。在此申明，笔者没有收 JFrog——研发 Artifactory 产品的公司——任何广告费。笔者只是想试用商业产品，以便了解商业产品是如何应对制品管理问题的。
启动 Artifactory 后，需要添加 “Virtual Repository” 及 “Local Repository”。具体请查看 Artifactory 的官方文档。如果你当前使用的是 Nexus，参考本教程，做一些调整，问题也不大。
如果想使用已有制品库，可以修改 1-cd-platform 仓库中的 settings-docker.xml 文件，指向自己的制品库。
实验环境近期的总体结构图如下：

之所以说是“近期的”，是因为上图与本篇介绍的结构有小差异。本篇文章还没有介绍 Nginx 与 Springboot 配置共用，但是总体不影响读者理解。如果你想和更多Jenkins技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

3. Springboot 应用流水线介绍

Springboot 流水线有两个阶段：

构建并上传制品
部署应用
流水线的所有逻辑都写在 Jenkinsfile 文件。接下来，分别介绍这两个阶段。
3.1 构建并上传制品
此阶段核心代码：



docker.image('jenkins-docker-maven:3.6.1-jdk8')

.inside("--network 1-cd-platform_cd-in-practice -v $HOME/.m2:/root/.m2") {

    sh """

      mvn versions:set -DnewVersion=${APP_VERSION}

      mvn clean test package

      mvn deploy

    """

}

它首先启动一个装有 Maven 的容器，然后在容器内执行编译、单元测试、发布制品的操作。
而 mvn versions:set -DnewVersion=${APP_VERSION} 的作用是更改 pom.xml 文件中的版本。这样就可以实现每次提交对应一个版本的效果。
3.2 部署应用
注意：这部分需要一些 Ansible 的知识。
首先看部署脚本的入口 1-springboot/deploy/playbook.yaml：

---





[list]

[*]hosts: "springboot"[/*]

[/list]  become: yes

  roles:

    - {"role": "ansible-role-java", "java_home": "{{JAVA_HOME}}"}

    - springboot

先安装 JDK，再安装 Spring Boot。JDK 的安装，使用了现成 Ansible role: https://github.com/geerlingguy/ansible-role-java。
重点在 Spring Boot 部署的核心逻辑。它主要包含以下几部分：
创建应用目录。
从制品库下载指定版本的制品。
生成 Systemd service 文件（实现服务化）。
启动服务。
以上步骤实现在 1-springboot/deploy/roles/springboot 中。
流水线的部署阶段的核心代码如下：



docker.image('williamyeh/ansible:centos7').inside("--network 1-cd-platform_cd-in-practice") {



  checkout([$class: 'GitSCM', branches: [[name: "master"]], doGenerateSubmoduleConfigurations: false,

            extensions: [[$class: 'RelativeTargetDirectory', relativeTargetDir: "env-conf"]], submoduleCfg: [],

            userRemoteConfigs: [[url: "https://github.com/cd-in-practice/1-env-conf.git"]]])



  sh "ls -al"



  sh """

    ansible-playbook --syntax-check deploy/playbook.yaml -i env-conf/dev

    ansible-playbook deploy/playbook.yaml -i env-conf/dev --extra-vars '{"app_version": "${APP_VERSION}"}'

  """

}

它首先将配置变量仓库的代码 clone 下来，然后对 playbook 进行语法上的检查，最后执行 ansible-playbook 命令进行部署。--extra-vars 参数的 app_version 用于指定将要部署的应用的版本。

3.3 实现简易指定版本部署

在 1-springboot/Jenkinsfile 中实现了简易的指定版本部署。核心代码如下：
流水线接受参数
parameters { string(name: 'SPECIFIC_APP_VERSION',
defaultValue: '', description: '') }
如果指定了版本，则跳过构建阶段，直接执行部署阶段



stage("build and upload"){

      // 如果不指定部署版本，则执行构建

      when {

        expression{ return params.SPECIFIC_APP_VERSION == "" }

      }

      // 构建并上传制品的逻辑

      steps{...}

}

之所以说是“简易”，是因为部署时只指定了制品的版本，并没有指定的部署逻辑和配置的版本。这三者的版本要同步，部署才真正做到准确。

4. 配置管理

所有的配置项都放在 1-env-conf 仓库中。Ansible 执行部署时会读取此仓库的配置。
将配置放在 Git 仓库中有两个好处：
配置版本化。
任何配置的更改都可以被审查。
有好处并不代表没有成本。那就是开发人员必须开始关心软件的配置（笔者发现不少开发者忽视配置项管理的重要性。）。
本文重点不在配置管理，后面会有文章重点介绍。

5. 实验环境详细介绍

事实上，整个实验，工作量大的地方有两处：一是 Spring Boot 流水线本身的设计；二是整个实验环境的自动化。读者朋友之所以能一两条简单的命令就能启动整个实验环境，是因为笔者做了很多自动化的工作。笔者认为有必要在本篇介绍这些工作。接下来的文章将不再详细介绍。

5.1 解决流水线中启动的 Docker 容器无法访问 http://artifactory

流水线中，我们需要将制品上传到 artifactory（settings.xml 配置的仓库地址是 http://artifactory:8081），但是发现无法解析 host。这是因为流水线中的 Docker 容器所在网络与 Docker compose 创建的网络不同。所以，解决办法就是让流水线中的 Docker 容器加入到 Docker compose 的网络。
具体解决办法就是在启动容器时，加入参数：--network 1-cd-platform_cd-in-practice

5.2 Jenkins 初次启动初始化

在没有做任何设置的情况启动 Jenkins，会出现一个配置向导。这个过程必须是手工的。笔者希望这一步也是自动化的。Jenkins 启动时会执行 init.groovy.d/目录下的 Groovy 脚本。
5.3 虚拟机中如何能访问到 http://artifactory ？
http://artifactory 部署在 Docker 容器中。Spring Boot 应用的制品要部署到虚拟机中，需要从 http://artifactory 中拉取制品，也就是要在虚拟机里访问容器里提供的服务。虚拟机与容器之间的网络是不通的。那怎么办呢？笔者的解决方案是使用宿主机的 IP 做中转。具体做法就是在虚拟机中加一条 host 记录：



machine.vm.provision "shell" do |s|

    s.inline = "echo '192.168.52.1 artifactory' >> /etc/hosts"

end

以上是使用了 Vagrant 的 provision 技术，在执行命令 vagrant up 启动虚拟机时，就自动执行那段内联 shell。192.168.52.1 是虚拟宿主机的 IP。所以，虚拟机里访问 http://artifactory:8081 时，实际上访问的是 http://192.168.52.1:8081。
网络结构可以总结为下图：

后记

目前遗留问题：
部署时制品版本、配置版本、部署代码版本没有同步。
Springboot 的配置是写死在制品中的，没有实现制品与配置项的分离。
这些遗留问题在后期会逐个解决。就像现实一样，经常需要面对各种遗留项目的遗留问题。
附录
使用 Jenkins + Ansible 实现自动化部署 Nginx：https://jenkins-zh.cn/wechat/articles/2019/04/2019-04-25-jenkins-ansible-nginx/
简单易懂 Ansible 系列 —— 解决了什么：https://showme.codes/2017-06-12/ansible-introduce/

本文转自公众号 jenkins
作者翟志军

基于 Jenkins 的 DevOps 平台应该如何设计凭证管理

灵雀云发表了文章 • 0 个评论 • 213 次浏览 • 2019-05-20 11:06 • 来自相关话题

背景了解到行业内有些团队是基于 Jenkins 开发 DevOps 平台。而基于 Jenkins 实现的 DevOps 平台，就不得不考虑凭证的管理问题。本文就此问题进行讨论，尝试找出相对合理的管理凭证的方案。 ...查看全部

背景

了解到行业内有些团队是基于 Jenkins 开发 DevOps 平台。而基于 Jenkins 实现的 DevOps 平台，就不得不考虑凭证的管理问题。
本文就此问题进行讨论，尝试找出相对合理的管理凭证的方案。
一开始我们想到的方案可能是这样的：用户在 DevOps 平台增加凭证后，DevOps 再将凭证同步到 Jenkins 上。Jenkins 任务在使用凭证时，使用的是存储在 Jenkins 上的凭证，而不是 DevOps 平台上的。
但是，仔细想想，这样做会存在以下问题：
Jenkins 与 DevOps 平台之间的凭证数据会存在不一致问题。
存在一定的安全隐患。通过 Jenkins 脚本命令行很容易就把所有密码的明文拿到。哪天 Jenkins 被注入了，所有的凭证一下子就被扒走。
无法实现 Jenkins 高可用，因为凭证存在 Jenkins master 机器上。
那么，有没有更好的办法呢？

期望实现的目标

先定我们觉得更合理的目标，然后讨论如何实现。以下是笔者觉得合理的目标：
用户还是在 DevOps 管理自己的凭证。但是 DevOps 不需要将自己凭证同步到 Jenkins 上。Jenkins 任务在使用凭证时，从 DevOps 上取。

实现方式

Jenkins 有一个 Credentials Binding Plugin 插件，在 Jenkins pipeline 中的用法如下：



withCredentials([usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')]) {

    sh '''

      curl -u "$USERPASS" https://private.server/ > output

    '''

  }

withCredentials 方法做的事情就是从 Jenkins 的凭证列表中取出 id 为 mylogin 的凭证，并将值赋到变量名为 USERPASS 的变量中。接下来，你就可以在闭包中使用该变量了。
说到这里，不知道读者朋友是否已经有思路了？
思路就是实现一个和 Credentials Binding Plugin 插件类似功能的方法，比如叫 zWithCredentials（后文还会提到）。与 withCredentials 不同的是，zWithCredentials 根据凭证 id 获取凭证时，不是从 Jenkins 上获取，而是从 DevOps 平台获取。

会遇到的坑

需要适配只认 Jenkins 凭证的插件
withCredentials 方法是将凭证的内容存到变量中，这可以满足一大部分场景。但是有一种场景是无法满足的。就是某些 Jenkins 插件的步骤接收参数时，参数值必须是 Jenkins 凭证管理系统中的 id。比如 git 步骤中 credentialsId 参数：



git branch: 'master',

    credentialsId: '12345-1234-4696-af25-123455',

    url: 'ssh://git@bitbucket.org:company/repo.git'

这种情况，我们不可能修改现有的插件。因为那样做的成本太高了。
那怎么办呢？
笔者想到的办法是在 zWithCredentials 中做一些 hack 操作。也就是 zWithCredentials 除了从 DevOps 平台获取凭证，还在 Jenkins 中创建一个 Jenkins 凭证。在 Jenkins 任务执行完成后，再将这个临时凭证删除。这样就可以适配那些只认 Jenkins 凭证 id 的插件了。
对凭证本身的加密
DevOps 平台在存储凭证、传输凭证给 Jenkins 时，都需要对凭证进行加密。至于使用何种加密方式，交给读者思考了。

小结

以上解决方案对 Jenkins 本身的改造几乎没有，我们只通过一个插件就解耦了 Jenkins 的凭证管理和 DevOps 平台的凭证管理。
思路已经有了。具体怎么实现，由于一些原因不能开源，虽然实现起来不算难。还请读者见谅。
最后，希望能和遇到同样问题的同学进行交流。看看是否还可以有更好的设计思路。

本文转自公众号 Jenkins
作者：翟志军

深度解析Kubernetes核心原理之Scheduler

灵雀云发表了文章 • 0 个评论 • 231 次浏览 • 2019-05-17 10:56 • 来自相关话题

Kubernetes是一个容器编排引擎，它被设计为在被称为集群的节点上运行容器化应用。通过系统建模的方法，本系列文章的目的是为了能够深入了解Kubernetes以及它的深层概念。 Kubernetes Scheduler ...查看全部

Kubernetes是一个容器编排引擎，它被设计为在被称为集群的节点上运行容器化应用。通过系统建模的方法，本系列文章的目的是为了能够深入了解Kubernetes以及它的深层概念。

Kubernetes Scheduler是Kubernetes的一个核心组件：在用户或者控制器创建一个Pod后，Scheduler在对象存储数据里监控未被分配的Pod，并将Pod分配到某个节点。然后Kubelet在对象存储数据里监控已分配的Pod，并运行该Pod。

本文提供了一个Kubernetes Scheduler的更简洁、更详细的模型表述。该模型部分基于TLA+规范。

图 1. Pod处理流程

调度

Kubernetes Scheduler的任务是选择一个placement(位置)。一个placement是一个部分的，非内射的Pod集合到节点集合的分配。

图 2. 调度示例

调度是一个最优化问题：首先，Scheduler确定feasible placements(可用的位置)，这些是满足给定约束的placement集合。然后，Scheduler确定viable placements(可行的位置)，这些是得分最高的feasible placements集合。

图 3. Possible(可能), Feasible(可用)和Viable(可行)的调度

Kubernetes Scheduler是一个保证局部最优解的多步调度器，而不是一个保证全局最优解的单步调度器。

图 4. 多步 vs. 单步

Kubernetes Scheduler

图 5. Kubernetes Pod对象和Node对象

图5描述了Kubernetes Scheduler所感兴趣的Kubernetes对象和属性。在Kubernetes里： 一个Pod表示为一个Kubernetes Pod对象 一个Node表示为一个Kubernetes Node对象 * 一个Pod分配给一个Node表示为Pod的Spec.NodeName属性



BoundTo(Pod, Node, Snapshot)≝ 

  ∧ Pod ∈Snapshot

  ∧Pod.Kind = "Pod"

  ∧ Node∈ Snapshot

  ∧Node.Kind = "Node"

  ∧Pod.Spec.NodeName = Node.Name



Bound(Pod, Snapshot) ≝ 

  ∃ Node∈ Snapshot:

   BoundTo(Pod, Node, Snapshot)

如果一个Pod的Spec.NodeName等于一个Node的Name，则表示这个Pod对象绑定到了这个Node对象。

Kubernetes Scheduler的任务现在可以更规范地表述为：对于一个Pod p，Kubernetes Scheduler选择一个Node n，且更新(*)这个Pod的Spec.NodeName使得BoundTo(p, n)为true。

控制循环逻辑



Scheduler ≝

  LETUnbound ≝ {Pod \in Objects : Pod.Kind = "Pod" ∧ ~ Bound(Pod,Objects)} IN

    ∃ Pod∈ { Pod ∈ Unbound : ∀ Other ∈ Unbound : Other.Spec.Priority ≤ Pod.Spec.Priority}:

        CASE SchedulingEnabled(Pod) ⟶ Scheduling(Pod)

          [] PreemptionEnabled(Pod) ⟶ Preemption(Pod)

          [] OTHER ⟶ UNCHANGED(Objects)

Kubernetes Scheduler监控Kubernetes对象存储并且选择一个未绑定的最高优先级的Pod来执行调度流程或者抢占流程。

调度流程



SchedulingEnabled(Pod) ≝

  ∃ Node∈ {Node ∈ Objects : Node.Kind = "Node"}: 

   Feasibility(Pod, Node, Objects)



Scheduling(Pod) ≝

  LETFeasibile ≝ {Node ∈ Objects : n.Kind = "Node" ∧ Feasibility(Pod, n,Objects)} IN

    ∃Node ∈ Feasibile : 

      ∧ ∀Other ∈ Feasibile : Viability(Pod, Other, Objects) ≤ Viability(Pod, Node,Objects)

      ∧Objects' = {

       IF Pod = Object THEN 

         [Pod EXCEPT !["Spec"] = [Pod.Spec EXCEPT!["NodeName"] = Node.Name]] 

       ELSE 

         Object : Object ∈ Objects}

对于一个给定的Pod，如果存在至少一个Node可以运行该Pod，则启用调度流程。

如果调度流程启用，Scheduler将绑定该Pod到一个可选的Node，使得绑定能达到最优的可行性。

如果调度流程未启用，则Sheduler将尝试执行抢占流程。

抢占流程



PreemptionEnabled(Pod) ≝

  ∃ Node∈ {Node \in Objects : Node.Kind = "Node"}:

    ∃Pods ∈ SUBSET(Jeopardy(Pod, Node, Objects)):

     Feasibility(Pod, Node, Objects \ Pods)



Preemption(Pod) ==

  LETPreemptable == {Node ∈ Objects : Node.Kind = "Node" ∧ ∃ Pods ∈SUBSET(Jeopardy(p, Node, Objects)): Feasibility(Pod, Node, Objects \ Pods)} IN

    ∃Node ∈ Preemptable:

      ∃Pods ∈ SUBSET(Jeopardy(Pod, Node, Objects)): 

        ∀OtherNode ∈ qualified: 

         ∀ OtherPods ∈ SUBSET(Jeopardy(Pod, OtherNode, Objects)): 

           ∧ Casualty(Pods) ≤ Casualty(OtherPods)

           ∧ Objects' = (Objects \ Pods)

对于一个给定的Pod，如果存在至少一个Node，在删除绑定到该Node的较低优先级Pod子集后可以运行该Pod，则启用抢占流程。

如果抢占流程启用，Scheduler将触发绑定到Node的低优先级Pod子集的删除操作，使得抢占流程造成的损害最小。

(抢占损害是用Pod Disruption Budget来评估的，超出了本文的主题)

注意的是Scheduler不保证触发抢占流程的Pod在后续的调度流程中能绑定到Node。

1. 可用性(Feaisbility)

对于每一个Pod，Kubernetes Scheduler确定可用的Node集合，这些Node满足了该Pod的约束。

从概念上讲，Kubernetes Scheduler定义了一个过滤函数集合。给定一个Pod和一个Node，过滤函数决定该Node是否满足该Pod的约束。所有过滤函数都必须返回true才表示该Node可以运行该Pod。



Feasibility(Pod, Node,Snapshot) ==

 (Filter_1(Pod, Node, Snapshot) ∧ Filter_2(Pod, Node, Snapshot) ∧ ...)

下面小节详细描述了目前一些可用的过滤函数：

1.1 可调度性和生命周期阶段（Schedulability and LifecyclePhase）

该过滤函数基于Node的可调度性和生命周期阶段来确定Node的可用。Nodeconditions通过taints和tolerations来说明(如下所示)。

图 1.1 可调度性和生命周期阶段



Filter(Pod, Node) ≝

  \* Onlyconsider Nodes that accept new Pods

  ∧Node.Spec.Unschedulable = False

  \* Onlyconsider Nodes that are ready to accept new Pods (Lifecycle Phase)

  ∧Node.Status.Phase = "Running"

1.2 资源需求和资源可用性

该过滤函数基于Pod的资源需求和Node的资源可用性来确定Node的可用。

图 1.2 资源需求和资源可用性



Resources(Pod, Node) ≝

  ∧ 1 ≤Node.Status.Allocatable["pods"]

  \* Usethe maximum resource requirements of init containers

  ∧ Max({i \in DOMAIN p.Spec.InitContainer :p.Spec.InitContainer[i].Resources.Required["cpu"] }) ≤Node.Status.Allocatable["cpu"]

  ∧ Max({i \in DOMAIN p.Spec.InitContainer :p.Spec.InitContainer[i].Resources.Required["mem"] }) ≤Node.Status.Allocatable["mem"]

  ∧ ...

  \* Usethe sum of resource requirements of main containers

  ∧ Sum({i \in DOMAIN p.Spec.Container :p.Spec.Container[i].Resources.Required["cpu"] }) ≤Node.Status.Allocatable["cpu"]

  ∧ Sum({i \in DOMAIN p.Spec.Container :p.Spec.Container[i].Resources.Required["mem"] }) ≤Node.Status.Allocatable["mem"]

  ∧ ...

1.3 Node Selector

该过滤函数基于Pod的node selector值和Node的label值来确定Node的可用。

图 1.3 Node Selector



Filter(Pod, Node) ==

  ∀ Label∈ DOMAIN(Pod.Spec.NodeSelector): 

      ∧Label ∈ DOMAIN(Node.Labels) 

      ∧Pod.Spec.NodeSelector[Label] = Node.Labels[Label]

1.4 Node Taints和Pod Tolerations

该过滤函数基于Pod的taints键值对和Node的tolerations键值对来确定Node的可用。

图 1.4 Node Taints和Pod Tolerations



Filter(Pod, Node) == 

    ∀Taint ∈ Node.Spec.Taints:

        ∃Toleration ∈ Pod.Spec.Tolerations: Match(Toleration, Taint)



Match(Toleration, Taint) ==

    ∧CASE Toleration.Operator = "Exists" 

          ⟶ Toleration.key = Taint.key 

       [] Toleration.Operator = "Equal" 

          ⟶ Toleration.key = Taint.key ∧ Toleration.value = Taint.value

       [] OTHER 

          ⟶ FALSE

    ∧Toleration.Effect = Taint.Effect

如果某个Node的taints匹配Pod的tolerations, 一个Pod可能被绑定到该Node。如果某个Node的taints不匹配Pod的tolerations, 一个Pod不能被绑定该Node。

1.5 亲和性

该过滤函数基于Pod需要的Node亲和项，Pod亲和项和Pod反亲和项来确定Node的可用。

图 1.4 Node Taints和Pod Tolerations



Filter(Pod, Node) ≝

    \*Node, Affinity

    ∧ ∃NodeSelectorTerm ∈ Pod.Spec.Affinity.NodeAffinity.Required.NodeSelectorTerms : 

           Match_NS(NodeSelectorTerm, Node)

    \*Pod, Affinity

    ∧ ∀PodAffinityTerm ∈ Pod.Spec.Affinity.PodAffinity.Required : 

           P_Affinity(PodAffinityTerm, Node)

    \*Pod, Anit-Affinity

    ∧ ∀PodAffinityTerm ∈ Pod.Spec.Affinity.AntiPodAffinity.Required : 

         ¬ P_Affinity(PodAffinityTerm, Node)



\* Node, Affinity, Match Node Selector Term

Match_NS(NodeSelectorRequirement, Node) ≝

    CASENodeSelectorRequirement.Operator = "In" 

         ⟶   (NodeSelectorRequirement.Key ∈DOMAIN(Node.Labels) ∧ Node.Labels[NodeSelectorRequirement.Key] ∈NodeSelectorRequirement.Value)

      []NodeSelectorRequirement.Operator = "NotIn" 

         ⟶¬ (NodeSelectorRequirement.Key ∈ DOMAIN(Node.Labels) ∧Node.Labels[NodeSelectorRequirement.Key] ∈ NodeSelectorRequirement.Value)

      []NodeSelectorRequirement.Operator = "Exits" 

         ⟶   (NodeSelectorRequirement.Key ∈DOMAIN(Node.Labels))

      []NodeSelectorRequirement.Operator = "DoesNotExist" 

         ⟶¬ (NodeSelectorRequirement.Key ∈ DOMAIN(Node.Labels))

      []_NodeSelectorRequirement.Operator = "Gt" ∧ ∀ Value ∈NodeSelectorRequirement.Value: Value ∈ Int

         ⟶   (NodeSelectorRequirement.Key ∈DOMAIN(Node.Labels) ∧ Node.Labels[NodeSelectorRequirement.Key] ∈ Int ∧Node.Labels[NodeSelectorRequirement.Key] >Max(NodeSelectorRequirement.Value))

      []_NodeSelectorRequirement.Operator = "Lt" ∧ ∀ Value ∈NodeSelectorRequirement.Value: Value ∈ Int

         ⟶   (NodeSelectorRequirement.Key ∈DOMAIN(Node.Labels) ∧ Node.Labels[NodeSelectorRequirement.Key] ∈ Int ∧Node.Labels[NodeSelectorRequirement.Key] 
      []OTHER 

         ⟶FALSE



\* Pod, (Anti)Affinity, Match Pod Affinity Term

P_Affinity(PodAffinityTerm, Node) ==

    IFPodAffinityTerm.TopologyKey \in DOMAIN(Node.Labels) THEN

        ∃Other ∈ {Other ∈ Objects : Other.Kind = "Node" ∧PodAffinityTerm.TopologyKey ∈ DOMAIN(Other.Labels) ∧Other.Labels[PodAffinityTerm.TopologyKey] =Node.Labels[PodAffinityTerm.TopologyKey]}: 

           ∃ Pod ∈ {Pod ∈ objects : Pod.kind = "Pod" ∧ BoundTo(Pod, Node)∧ Pod.Namespace ∈ PodAffinityTerm.Namespaces}:

               Match_LS(PodAffinityTerm.LabelSelector, Pod.Labels)

    ELSE

       FALSE



\* Pod, (Anti)Affinity, Match Label Selector

Match_LS(LabelSelector, Labels) ≝

    ∧ ∀Key ∈ DOMAIN(LabelSelector) : Key ∈ DOMAIN(Labels) ∧ LabelSelector[Key] =Labels[Key]

    ∧ ∀LabelSelectorRequirement ∈ LabelSelector.MatchExpression:

         CASE LabelSelectorRequirement.Operator = "In"

              ⟶   (LabelSelectorRequirement.Key∈ DOMAIN(Labels) ∧ Labels[LabelSelectorRequirement.Key] ∈LabelSelectorRequirement.Values)

           [] _LabelSelectorRequirement.Operator = "NotIn"

              ⟶ ¬ (LabelSelectorRequirement.Key ∈ DOMAIN(Labels) ∧Labels[LabelSelectorRequirement.key] ∈ LabelSelectorRequirement.Values)

           [] _LabelSelectorRequirement.Operator = "Exists"

              ⟶   (LabelSelectorRequirement.Key∈ DOMAIN(Labels))

           [] _LabelSelectorRequirement.Operator = "DoesNotExist"

              ⟶ ¬ (LabelSelectorRequirement.Key ∈ DOMAIN(Labels))

Node亲和
一个Pod必须分配给label匹配Pod的Node亲和需求的Node。另外，一个Pod不能分配给label不匹配Pod的Node亲和需求的Node。

Pod亲和
一个Pod必须分配给匹配TopologyKey的Node, 且该Node上至少有一个Pod匹配Pod的亲和需求。

Pod反亲和
一个Pod必须分配给匹配TopologyKey的Node, 且该Node上没有Pod匹配Pod的反亲和需求。

可行性(Viability)

对于每一个Pod，Kubernetes Scheduler确定可用的Node集合，这些Node满足了该Pod的约束。然后，Kubernetes Scheduler从可用Node集合中确定最高可行性的Node。

从概念上讲，Kubernetes Scheduler定义了一个评分函数集合。给定一个Pod和一个Node，评分函数确定Pod和Node配对的可行性。这些结果最后相加。



Viability(Pod, Node,Snapshot) ==

 Sum(<>)

下面小节详细描述了目前一些可用的过滤函数：

2.1 亲和偏好

这些过滤函数基于Pod的偏好Node亲和项，Pod亲和项和Pod反亲和项，对Node的可行性进行评分。

图 1.4 Node Taints和Pod Tolerations



Rating(Pod, Node) ≝

 Sum(<<

   Sum(LAMBDA Term: Term.Weight, {NodeSelectorTerm ∈Pod.Spec.Affinity.NodeAffinity.Preferred.NodeSelectorTerms :Match_NS(NodeSelectorTerm, Node) }),

   Sum(LAMBDA Term: Term.Weight, {PodAffinityTerm ∈Pod.Spec.Affinity.PodAffinity.Preferred : P_Affinity(PodAffinityTerm, Node) }),

   Sum(LAMBDA Term: Term.Weight, {PodAffinityTerm ∈Pod.Spec.Affinity.AntiPodAffinity.Preferred : ~ P_Affinity(PodAffinityTerm,Node)})

 >>)

最终评分是下列项的总和： 对于每一个匹配的Node Selector项的权重的总和 对于每一个匹配的Pod亲和项的权重的总和 * 对于每一个匹配的Pod反亲和项的权重的总和

用例分析
图6描述了包含2个不同类型的节点和2个不同类型的Pod的例子： 没有GPU资源的9个节点 有GPU资源的6个节点

这个用例的目标是保证： 不需要GPU的Pod被分配到没有GPU的节点 需要GPU的Pod被分配到有GPU的节点

灵雀云Kube-OVN：基于OVN的开源Kubernetes网络实践

灵雀云发表了文章 • 0 个评论 • 452 次浏览 • 2019-05-09 14:34 • 来自相关话题

近日，灵雀云发布了基于OVN的Kubernetes网络组件Kube-OVN，并正式将其在Github上开源。Kube-OVN提供了大量目前Kubernetes不具备的网络功能，并在原有基础上进行增强。通过将OpenStack领域成熟的网络功能平移到Kubern ...查看全部

近日，灵雀云发布了基于OVN的Kubernetes网络组件Kube-OVN，并正式将其在Github上开源。Kube-OVN提供了大量目前Kubernetes不具备的网络功能，并在原有基础上进行增强。通过将OpenStack领域成熟的网络功能平移到Kubernetes，来应对更加复杂的基础环境和应用合规性要求。
目前Kube-OVN项目代码已经在Github 上开源，项目地址为：https://github.com/alauda/kube-ovn。项目使用宽松的Apache 2.0 协议，欢迎更多技术开发者和爱好者前去试用和使用。

网络插件那么多，为什么还需要Kube-OVN？

网络插件千千万，为什么还要开发Kube-OVN？从当前Kubernetes网络现状来看，Kubernetes 网络相关的组件非常分散。例如，CNI 负责基础容器网络，它本身只是个接口标准，社区和市场上都有很多各自的实现；集群内的服务发现网络需要依赖 kube-proxy，而 kube-proxy 又有 iptables 和 ipvs 两种实现；集群内的 DNS 需要依赖额外组件kube-dns 或coredns；集群对外访问的负载均衡器服务需要依赖各个云厂商提供的Cloud-Provider；网络策略的 NetworkPolicy 本身只是一个标准接口，社区中也有各自不同的实现。此外还有 ingress，Kubernetes提供的只是一个标准接口，社区中同样有各自的实现。
分散的网络组件导致容器网络流量被分散到了不同的网络组件上，一旦出现问题需要在多个组件间游走逐个排查。在实际运维过程中网络问题通常是最难排查的，需要维护人员掌握全链路上所有组件的使用、原理以及排查方式。因此，如果有一个网络方案能够将所有数据平面统一，那么出现问题时只需要排查一个组件即可。
其次，现有网络插件种类繁多，但是在落地时会发现，每个网络插件由于覆盖的功能集合不同，很难在所有场景使用同一套方案。为了满足不同的客户需求，很多厂商一度同时支持多种网络方案，给自身带来很大负担。在落地过程中，还发现很多传统的网络方案在容器网络中是缺失的。一些高级功能是所有网络插件都无法满足的，比如：子网划分、vlan 绑定、nat、qos、固定 IP、基于acl的网络策略等等。
现有 Kubernetes网络能力是否足够？答案很明显，如果真的已经做够强大落地的时候就不会出现这么多的问题。从更大格局来看，Kubernetes本质上是提供了一层虚拟化网络。而虚拟化网络并不是一个新问题。在OpenStack社区，虚拟网络已经有了长足的发展，方案成熟，OVS 基本已经成为网络虚拟化的标准。于是，灵雀云开始把目光投向OVS 以及 OVS 的控制器OVN。

OVN 简介

OVS 是一个单机的虚拟网络交换机，同时支持 OpenFlow 可以实现复杂的网络流量编程，这也是网络虚拟化的基础。通过OVS 和 OpenFlow 可以实现细粒度的流量控制。如果做个类比，OVS 相当于网络虚拟化里的 Docker。
OVS 只是个单机程序，想生成一个集群规模的虚拟网络就需要一个控制器，这就是 OVN。OVN 和 OVS 的关系就好比 Kubernetes 和 Docker 的关系。OVN 会将高层次的网络抽象转换成具体的网络配置和流表，下发到各个节点的OVS上，实现集群网络的管理。
由于 OVN 最初是为 OpenStack 网络功能设计的，提供了大量 Kubernetes 网络目前不存在的功能：
L2/L3 网络虚拟化包括：
• 分布式交换机，分布式路由器
• L2到L4的ACL
• 内部和外部负载均衡器
• QoS，NAT，分布式DNS
• Gateway
• IPv4/IPv6 支持

此外 OVN 支持多平台，可以在Linux，Windows，KVM，XEN，Hyper-V 以及 DPDK 的环境下运行。
综上可以看出 OVN 可以覆盖 CNI, Kube-Proxy, LoadBalancer, NetworkPolicy, DNS 等在内的所有 Kubernetes 网络功能，并在原有基础上有所增强。将之前在OpenStack领域内成熟的网络功能往 Kubernetes 平移，也就诞生了灵雀云的开源项目 Kube-OVN.

Kube-OVN 重要功能及实现

目前大部分网络插件的网络拓扑都是一个大二层网络，通过防火墙做隔离，这种形式非常类似公有云早期的经典网络。Kube-OVN在设计网络支出时同时把多租户的场景考虑进来，方便之后更好的扩展高级功能，因此采用了不同的网络拓扑。

Kube-OVN 网络拓扑

在Kube-OVN的网络拓扑里，不同 Namespace 对应着不同的子网。子网是其中最为重要的概念，之后的内置负载均衡器，防火墙，路由策略以及DNS的网络功能都是和子网绑定的。我们做到了同一台机器的不同 pod 可以使用不同的子网，多个子网之间使用一个虚拟路由器进行网络的联通。为了满足Kubernetes中主机可以和容器互通的网络要求，Kube-OVN在每个主机新增一块虚拟网卡，并接入一个单独的虚拟交换机和集群的虚拟路由器相连，来实现主机和容器网络的互通。
在容器访问外部网络的策略中，Kube-OVN设计了两种方案：一种是分布式 Gateway，每台主机都可以作为当前主机上 Pod 的出网节点，做到出网的分布式。针对企业需要对流量进行审计，希望使用固定IP出网的场景，还做了和 namespace 绑定的 Gateway，可以做到一个 namespace 下的 Pod 使用一个集中式的主机出网。在整个网络拓扑中，除了集中式网关，交换机，路由器，防火墙，负载均衡器，DNS都是分布在每个节点上的，不存在网络的单点。

Kube-OVN架构图

在实现的过程中，Kube-OVN对组件架构进行了大幅的简化，整个流程中只需要一个全局Controller 和分布在每台机器上的 CNI 插件，就可以组建网络，整体安装十分简单。其中全局Controller 负责监听 APIServer 事件，针对 Namespace，Pod，Service，Endpoint 等和网络相关的资源变化对 OVN 进行操作。同时 Controller 会把操作 OVN 的结果，例如 IP ，Mac，网关，路由等信息回写到对应资源的 annotation 中。而 CNI 插件则根据回写的 annotation 信息操作本机的 OVS 以及主机网络配置。通过这种架构Kube-OVN将 CNI 插件和、Controller 和 OVN 解耦，通过 Apiserver 传递所需的网络信息，方便快速开发迭代。

Kube-OVN选择使用最基础的 annotation ，而不是 CRD、API Aggregation 或者 Operator，也是出于降低复杂度的考虑，使用户和开发者都能够快速上手。

Kube-OVN主要具备五大主要功能：
1. Namespace 和子网的绑定，以及子网间访问控制；
2. 静态IP分配；
3. 动态QoS；
4. 分布式和集中式网关；
5. 内嵌 LoadBalancer；
子网是Kube-OVN中最重要的概念，由于子网和 namespace 关联，因此只需要在 namespace 中设置对应的 annotation 就可以完成子网的功能。Kube-OVN支持子网cidr，gateway，exclude_ips 以及 switch_name 的设置。同时支持基于子网的IP隔离，用户可以轻松实施基本的网络隔离策略。在后台实现上，Kube-OVN会监听 namespace 的变化，并根据变化在 ovn 中创建并设置虚拟交换机，将其和集群路由器关联，设置对应的 acl，dns 和 lb。

静态IP的使用可以直接在 Pod 中加入对应的 annotation，Controller 在发现相关 annotation 时会跳过自动分配阶段，直接使用用户指定的 IP/Mac。对应多 Pod 的工作负载，例如 Deployment、DaemonSet，可以指定一个 ip-pool，工作负载下的 Pod 会自动使用ip-pool中未使用的地址。

在QoS功能中，分别实现了 ingress 和 egress 的带宽限制，用户可以在 Pod 运行时通过动态调整 annotation 来实现 QoS 的动态调整，而无需重启 Pod。在后台的实现中， OVN 自带的 QoS 功能工作在 Tunnel 端口，无法对同主机间 Pod 的互访做 QoS 控制。因此Kube-OVN最终通过操作 OVS 的 ingress_policing_rate 和 port qos 字段来实现 QoS 的控制。

在网关设计中，OVN的网关功能有一些使用限制，需要单独的网卡来做 overlay 和 underlay 的流量交换，使用起来比较复杂，为了能够适应更广泛的网络条件并简化用户使用，Kube-OVN对网关部分进行了调整。使用策略路由的方式根据网络包的源 IP 选择下一跳的机器，通过这种方式将流量导入所希望的边界网关节点，然后在网关节点通过 SNAT 的方式对外进行访问。这种方式用户只需要在 namespace 中配置一个网关节点的 annotation 就可以配置对应的流量规则。此外，Kube-OVN也支持非SNAT将容器IP直接暴露给外网的场景，这种情况下只需要外部添加一条静态路由指向容器网络，就可以实现 Pod IP 直接和外部互通。
内嵌的 LoadBalancer 使用 OVN 内置的 L2 LB，这样集群内部的服务发现功能可以直接在 OVS 层面完成，不需要走到宿主机的 iptable 或者 ipvs 规则，可以将 kube-porxy 的功能整合到 Kube-OVN 中。

开源计划 & RoadMap

目前Kube-OVN已经在 github 上开源。OVN 安装比较繁琐，Kube-OVN特意做了安装的简化，现在只需要两个 yaml 就可以部署一个完整的 Kube-OVN。在使用方面也做了优化，通过直观的 annotation 即可对网络进行配置。此外还针对不使用任何 annotation的情况内置了一套默认配置。用户可以使用默认的子网，默认的IP分配策略，默认的分布式网关以及内嵌的负载均衡器，这些都不需要任何配置就可以默认启用。欢迎大家体验试用，多给我们提供反馈和意见。
关于Kube-OVN，近期灵雀云将主要着力于实现三大目标：第一，集中式网关的高可用，消灭整个架构中最后一个单点；第二，内嵌 DNS，去除 Kube-DNS/CoreDNS 的依赖，将整个数据平面用 OVN 进行统一；第三，NetworkPolicy实现。
长期来看，Kube-OVN未来将实现对DPDK 和 Hardware Offload 的支持，解决 Overlay 网络性能问题；将更多的 OVS 监控和链路追踪工具引入 Kubernetes；将OpenStack社区的网络功能向Kubernetes平移，打造更完整的网络体系。

Kubernetes 中的渐进式交付：蓝绿部署和金丝雀部署

灵雀云发表了文章 • 0 个评论 • 364 次浏览 • 2019-05-07 15:27 • 来自相关话题

渐进式交付是持续交付的下一步，它将新版本部署到用户的一个子集，并在将其滚动到全部用户之前对其正确性和性能进行评估，如果不匹配某些关键指标，则进行回滚。这里有一些有趣的项目，使得渐进式交付在 Kubernetes 中变得更简单。我 ...查看全部

渐进式交付是持续交付的下一步，它将新版本部署到用户的一个子集，并在将其滚动到全部用户之前对其正确性和性能进行评估，如果不匹配某些关键指标，则进行回滚。

这里有一些有趣的项目，使得渐进式交付在 Kubernetes 中变得更简单。我将使用一个 Jenkins X 示例项目对它们之中的三个进行讨论：Shipper、Istio 以及 Flagger。

Shipper

shipper 是来自 booking.com 的一个项目，它对 Kubernetes 进行了扩展，添加了复杂的部署策略和多集群编排（文档）。它支持从一个集群到多个集群的部署，允许多区域部署。
Shipper 通过一个 shipperctl 命令行进行安装。它增加不同集群的配置文件来进行管理。请注意这个与 GKE 上下文相关的问题。
Shipper 使用 Helm 包来部署，但是它们没有随着 Helm 一起安装，它们不会在 helm list 的输出显示。同样地，deployments 的版本必须是 apps/v1 ，否则 shipper 将不能编辑 deployment 来添加正确的标签和副本数量。
使用 shipper 部署都是与从旧版本(现有版本)过渡到新版本(竞争版本)相关。这是通过创建一个新的应用对象实现的，它定义了部署需要通过的多个阶段。例如下面 3 个步骤过程：
Staging：部署新版本到一个 pod ，没有流量
50 / 50：部署新版本到 50% 的 pods，50% 的流量
Full on：部署新版本到全部的 pods，全部的流量



strategy:

  steps:

  - name: staging

    capacity:

      contender: 1

      incumbent: 100

    traffic:

      contender: 0

      incumbent: 100

  - name: 50/50

    capacity:

      contender: 50

      incumbent: 50

    traffic:

      contender: 50

      incumbent: 50

  - name: full on

    capacity:

      contender: 100

      incumbent: 0

    traffic:

      contender: 100

      incumbent: 0

如果发布的某个步骤没有将流量发送到 pods ，则可以使用 kubectl port-forward 访问它们，如：kubectl port-forward mypod 8080:8080，这对于在用户看到新版本之前进行测试非常有用。
Shipper 支持多集群的概念，但是以相同的方式对待所有集群，仅使用区域并通过 capabilities （配置在集群对象中）进行筛选，所有对一个应用对象来说，这里没有一个 dev, staging, prod 集群的选项。但是我们可以有两个应用对象：
myapp-staging 部署到 "staging" 区域
myapp 部署到其它区域
在 GKE 中，你可以轻松地配置多集群 ingress ，该入口将公开在多个集群中运行的服务，并从离你所在位置最近的集群提供服务。
局限性
Shipper 中的主要的局限性有：
Chart 限制：Chart 必须有一个部署对象。Deployment 的名称必须使用 {{.Release.Name}} 模板化。Deployment 对象应该有 apiVersion：apps/v1 。
基于 Pod 的流量切换：这里没有细粒度的流量路由，例如：发送 1% 的流量到新版本，它基于正在运行的 Pod 数量。
如果 Shipper 不工作了，新的 Pod 将获取不到流量。

Istio

Istio 不是一个部署工具，而是一个服务网格。然而，它很令人感兴趣，因为它已经变得非常流行，并且允许流量管理，例如，将一定比例的流量发送到不同的服务和其他高级网络。
在 GKE 中，只需在集群配置中选中复选框即可启用 Istio 。在其它集群中，可以通过 Helm 手动安装。
有了 Istio ，我们可以创建一个网关，通过 Ingress 网关处理所有外部流量，并创建虚拟服务来管理到我们服务的路由。为此，只需找到 ingress 网关的 ip 地址并为其配置通配符 DNS 。然后创建一个网关，通过 Ingress 网关路由所有外部流量。



apiVersion: networking.istio.io/v1alpha3

kind: Gateway

metadata:

 name: public-gateway

 namespace: istio-system

spec:

 selector:

   istio: ingressgateway

 servers:

 - port:

     number: 80

     name: http

     protocol: HTTP

   hosts:

   - "*"

Isito 不管理应用的生命周期，只管理网络。我们可以创建一个虚拟服务，为所有进入 ingress 网关的请求向 pull request 或 master 分支中部署的服务发送 1% 的流量。



apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

 name: croc-hunter-jenkinsx

 namespace: jx-production

spec:

 gateways:

 - public-gateway.istio-system.svc.cluster.local

 - mesh

 hosts:

 - croc-hunter.istio.example.org

 http:

 - route:

   - destination:

       host: croc-hunter-jenkinsx.jx-production.svc.cluster.local

       port:

         number: 80

     weight: 99

   - destination:

       host: croc-hunter-jenkinsx.jx-staging.svc.cluster.local

       port:

         number: 80

     weight: 1

Flagger
Flagger 是一个由 Weaveworks 赞助的使用了 Istio 的项目，该项目使用 Prometheus 的指标进行自动化金丝雀发布和回滚。它超越了 Isito 提供了基于指标的自动化渐进式发布和回滚。
Flager 需要将 Istio与 Prometheus、Servicegraph 和某些系统的配置一起安装，另外还要安装 Flager 控制器本身。它也提供了一个 Grfana 面板来监控部署进度。

部署 rollout 通过 Canary 对象定义，它会生成主要的和金丝雀 Deployment 对象。编辑 Deployment 时，例如要使用新的镜像版本， Flagger 控制器将负载从 0% 切换到 50% ，每分钟增加 10% ，然后它将切换到新的 deployment 或者如果响应错误和请求持续时间等指标失败则进行回滚。

比较

此表总结了 Shipper 和 Flagger 在几个渐进式交付特性方面的优势和劣势。

综上所述，我看到了 Shipper 在多集群管理和简单性方面的价值，它不需要 Kubernetes 以外的任何东西，但是它有一些严重的局限性。
Flager 确实在自动部署和回滚以及对流量进行细粒度控制的过程中付出了额外的努力，它以更高的复杂性成本提供了所需的所有额外服务（ Isito、Prometheus ）。
这里可以查看 Shipper、Isito 和 Flager 的示例代码。

本文转自微信公众号 Jenkins

使用 Jenkins + Ansible 实现自动化部署 Nginx

灵雀云发表了文章 • 0 个评论 • 429 次浏览 • 2019-04-29 11:00 • 来自相关话题

本文介绍如何使用 Jenkins + Ansible 实现对 Nginx 的自动化部署。最终达到的效果有如下几点：只要你将 Nginx 的配置推送到 GitHub 中，Jenkins 就会自动执行部署，然后目标服务器的 Nginx 配置自动生效。 ...查看全部

本文介绍如何使用 Jenkins + Ansible 实现对 Nginx 的自动化部署。最终达到的效果有如下几点：
只要你将 Nginx 的配置推送到 GitHub 中，Jenkins 就会自动执行部署，然后目标服务器的 Nginx 配置自动生效。这个过程是幂等（idempotent）的，只要代码不变，执行多少遍，最终效果不变。
如果目标机器没有安装 Nginx，则会自动安装 Nginx。
自动设置服务器防火墙规则。

1. 实验环境介绍

本次实验使用 Docker Compose 搭建 Jenkins 及 Jenkins agent。使用 Vagrant 启动一台虚拟机，用于部署 Nginx。使用 Vagrant 是可选的，读者可以使用 VirtualBox 启动一个虚拟机。使用 Vagrant 完全是为了自动化搭建实验环境。
以下是整个实验环境的架构图

注意，图中的 5123 <-> 80 代表将宿主机的 5123 端口请求转发到虚拟机中的 80 端口。
Vagrant：虚拟机管理工具，通过它，我们可以使用文本来定义、管理虚拟机。
Ansible：自动化运维工具
Docker Compose：它是一个用于定义和运行多容器 Docker 应用程序的工具。可以使用 YAML 文件来配置应用程序的服务。

2. 启动实验环境

克隆代码并进入文件夹



git clone https://github.com/zacker330/jenkins-ansible-nginx.git

cd jenkins-ansible-nginx

构建 Jenkins agent 的镜像需要自定义 Jenkins agent 镜像有两个原因：



docker build -f JenkinsSlaveAnsibleDockerfile -t jenkins-swarm-ansible .

本次实验，使用 Swarm 插件实现 Jenkins master 与 agent 之间的通信，所以 Jenkins agent 需要启动 swarm 客户端。
Jenkins agent 必须支持 Ansible。
启动 Jenkins master 及 Jenkins agent



docker-compose up -d

通过 http://localhost:8080 访问 Jenkins master，如果出现“解锁密码”页面，如下图，则执行命令 docker-compose logs jenkins 查看 Jenkins master 启动日志。将日志中的解锁密码输入到表单中。然后就一步步按提示安装即可。

安装 Jenkins 插件本次实验需要安装以下插件：
Pipeline 2.6：https://plugins.jenkins.io/workflow-aggregator
Swarm 3.15：https://plugins.jenkins.io/swarm 用于实现 Jenkins master 与 Jenkins agent 自动连接
Git 3.9.3：https://plugins.jenkins.io/git
配置 Jenkins master 不执行任务进入页面：http://localhost:8080/computer/(master)/configure，如下图所示设置：

确认 Jenkins 安全配置有打开端口，以供 Jenkins agent 连接。我们设置 Jenkins master 开放的端口，端口可以是固定的 50000 ，也可以设置为随机。设置链接：http://localhost:8080/configureSecurity/。

启动目标机器，用于部署 Nginx 在命令行中执行以下命令：



vagrant up

注意，Vagrantfile 文件中的 config.vm.box 值必须改成你的 vagrant box 。
至此，实验环境已经搭建好了。接下来就可以新建 Jenkins 任务了。

3. 在 Jenkins 上创建部署任务

1、新建流水线任务

2、配置流水线配置 Jenkins 任务从远程仓库拉取 Jenkinsfile，如下图所示：

除此之外，不需要其它配置了，是不是很简单？

4. 手工触发一次自动化构建

点击“立即构建”：

最终执行日志如下：

至此，部署已经完成。以后修改 Nginx 的配置，只需要修改代码，然后推送到远程仓库，就会自动化部署。不需要手工登录到目标机器手工修改了。
最后，我们可以通过访问 http://localhost:5123，如果出现如下页面说明部署成功：

5. 代码讲解

以上步骤并不能看出自动化部署真正做了什么。那是因为我们所有的逻辑都写在代码中。是的，可以说是 everything is code。
接下来我们介绍代码仓库。



% tree -L 2

├── JenkinsSlaveAnsibleDockerfile # Jenkins agent 镜像 Dockerfile

├── Jenkinsfile  # 流水线逻辑

├── README.md

├── Vagrantfile # Vagrant 虚拟机定义文件

├── docker-compose.yml # Jenkins 实现环境

├── env-conf # 所有应用配置

│   └── dev   # dev 环境的配置

├── deploy  # Ansible 部署脚本所在文件夹

│   ├── playbook.yaml

│   └── roles

└── swarm-client.sh # Jenkins swarm 插件的客户端

5.1流水线逻辑

Jenkinsfile 文件用于描述整条流水线的逻辑。代码如下：



pipeline{

  // 任务执行在具有 ansible 标签的 agent 上

  agent { label "ansible"}

  environment{

     // 设置 Ansible 不检查 HOST_KEY

    ANSIBLE_HOST_KEY_CHECKING = false

  }

  triggers {

     pollSCM('H/1 [i] [/i] [i] [/i]')

  }

  stages{

    stage("deploy nginx"){

      steps{

        sh "ansible-playbook -i env-conf/dev  deploy/playbook.yaml"

      }

}}}

environment 部分：用于定义流水线执行过程中的环境变量。
triggers 部分：用于定义流水线的触发机制。pollSCM 定义了每分钟判断一次代码是否有变化，如果有变化则自动执行流水线。
agent 部分：用于定义整条流水线的执行环境。
stages 部分：流水线的所有阶段，都被定义在这部分。
以上只是定义流水线是如何执行的，目前整条流水线只有一个 deploy nginx 阶段，并且只执行了一条 ansible-playbook 命令。但是它并没有告诉我们部署逻辑是怎么样的。

5.2 部署逻辑

所有的部署逻辑，包括 Nginx 的安装启动、配置的更新以及加载，都放在 Ansible 脚本中。对 Ansible 不熟的同学，可以在本文末尾找到介绍 Ansible 的文章。
整个部署逻辑的入口在 deploy/playbook.yaml，代码如下：



[list]

[*]hosts: "nginx"[/*]

[/list]  become: true

  roles:

    # Nginx 的部署

    - ansible-role-nginx

    # 对防火墙的设置

    - ansible-role-firewall

hosts：定义了 playbook 部署的目标主机分组名为 nginx。
roles：包含了两个执行具体部署动作的 role，至于 role 内部逻辑，不在本文讨论范围，有兴趣的同学阅读源码。

5.3 配置管理

谈到部署，就不得不谈配置管理。
回顾前文中流水线中执行的 shell 命令：ansible-playbook -i env-conf/dev deploy/playbook.yaml 我们通过 -i 参数指定部署时所使用的环境配置。通过这种方式实现环境配置与执行脚本的分离。这样带来以下几个好处：
新增环境时，只需要复制现有的环境，然后将里面的变量的值改成新环境的即可。比如，要对测试环境进行部署，只需要将 -i 参数值改成：env-conf/test。
对配置版本化控制。
本次实验中，各个环境的配置放在 env-conf 目录中，目前只有 dev 环境，以下是 env-conf/ 目录结构：



% cd env-conf/

% tree

└── dev

    ├── group_vars

    │   └── nginx.yaml

    ├── host_vars

    │   └── 192.168.52.10

    └── hosts

hosts文件：Ansible 中通过“分组”来实现对主机的管理。hosts 文件内容如下：



[nginx]

192.168.52.10

host_vars 目录：用于存放主机级别的配置变量，本例中 192.168.52.10 是一个 YAML 格式文件。注意文件名是该主机的 IP。我们在文件中放主机相关的配置，比如 Ansible 连接主机时使用到的用户名和密码。
group_vars 目录：用于存放组级别的配置变量。比如 nginx.yaml 对应的就是

nginx

这个组的的配置变量。文件名与 hosts 中的组名对应

总结

到此，我们完整的自动化部署已经讲解完成。但是还遗留下一些问题：
本文只是安装了一个“空”的 Nginx，但是没有介绍 Nginx 真正配置。
目前主机的连接信息（SSH 密码）是明文写在` host_vars/192.168.52.10 `文件中的，存在安全风险。
没有介绍如何当 Java 应用部署时，如何自动更新 Nginx 的配置。
本文属于使用 Jenkins + Ansible 实现自动化部署的入门文章，笔者将根据读者的反馈决定是否写续集。
如果觉得本文讲的 Jenkins 流水线逻辑部分不够过瘾，可以考虑入手一本最近才出版的《Jenkins 2.x实践指南》。长按下图进行扫码购买。

本文转载自：微信公众号jenkins

关于 Jenkins master 共享 JENKINS_HOME 目录的实验

灵雀云发表了文章 • 1 个评论 • 323 次浏览 • 2019-04-24 14:45 • 来自相关话题

Jenkins master 的高可用是个老大难的问题。和很多人一样，笔者也想过两个 Jenkins master 共享同一个 JENKINS_HOME 的方案。了解 Jenkins 原理的人，都会觉得这个方案不可行。但是真的不可行吗？由于工作原 ...查看全部

Jenkins master 的高可用是个老大难的问题。和很多人一样，笔者也想过两个 Jenkins master 共享同一个 JENKINS_HOME 的方案。了解 Jenkins 原理的人，都会觉得这个方案不可行。但是真的不可行吗？
由于工作原因，笔者需要亲自验证以上猜想。

JENKINS_HOME 介绍

Jenkins 所有状态数据都存放文件系统的目录中，这个目录被称为 JENKINS_HOME 目录。
实验环境介绍
笔者通过 Docker compose 启动两个独立的 Jenkins master，分别为 jenkins-a 和 jenkins-b。它们共用同一个 JENKINS_HOME 目录。相应的代码仓库的链接放在文章底部。
将代码克隆到本地后，进入仓库，执行 docker-compose up -d 即可启动实验环境。启动完成，在浏览器中输入 http://localhost:7088 可访问 jenkins-a，jenkins-b 的地址是 http://localhost:7089 。但是你会发现它们启动后的界面显示是不一样的。

jenkins-b 的界面如下图所示：

而 jenkins-a 的界面如下图所示：

这时，将 jenkins-a 日志中的解锁密码（Unlock password）输入到 jenkins-b 的页面中，会得到报错信息：



ERROR: The password entered is incorrect, please check the file for the correct password

这时，再次 jenkins-b 日志中的解锁密码（Unlock password）输入到表单中即可进入下一步。接下来就是按照提示一步步完成了。在 jenkins-b 安装步骤的最后一步，我们设置了管理员的用户名密码：admin/admin。然后就算完成任务了。
然后我们再在 jenkins-a 使用 admin/admin 进行登录，登录是报错的：用户密码不正确。
接下来，执行 `docker-compose restart jenkins-a `docker-compose restart jenkins-a 命令重启 jenkins-a。再次使用 admin/admin 就可以登录成功了。
当两个 Jenkins 启动完成后，接下来开始做实验。

实验1：创建任务

在 jenkins-a 创建任务 x，刷新 jenkins-b 的页面，jenkins-b 上会不会显示出任务 x ？
结果：jenkins-b 不会出现任务 x。重启 jenkins-b 后，任务 x 出现在任务列表中。
实验2：任务结果可见性
jenkins-a 上任务执行，jenkins-b 上能否看到任务执行结果？
jenkins-a 执行任务 x，并且执行成功。刷新 jenkins-b 看不到任何执行记录。重启 jenkins-b 后，可看到执行记录。

实验3：两 master 同时执行同一任务

分别在两个 Jenkins master 上（几乎）开始同一个任务 x。其中一个任务的 build number 会更新，但是另一个不会。
其中 jenkins-a 任务 x 的 build number 会升到 2，而 jenkins-b 保持的是 1。这时，单独执行 jenkins-b 的任务 x，日志会出现错误：



jenkins-b_1  | WARNING: A new build could not be created in job x

jenkins-b_1  | java.lang.IllegalStateException: JENKINS-23152: /var/jenkins_home/jobs/x/builds/2 already existed; will not overwrite with x #2

实验4：编辑任务

jenkins-a 上设置任务 x 定时执行，刷新 jenkins-b 页面，任务 x 中并没有定时执行的设置。重启 jenkins-b 后，任务 x 更新。

实验5：定时任务的结果是什么？

如果 jenkins-a 和 jenkins-b 两个任务均为定时任务，而且都生效了。它们运行结果是什么的呢？
看到的现象是，两个任务都会按时执行，但是只有一个任务能将运行结果写入到磁盘中。界面如下图：

另，从日志中，可以确认 jenkins-a 和 jenkins-b 确实按时执行了。如下图日志中，看出 jenkins-a 定时执行 #6 次构建时报错，因为 jenkins-b 已经执行过 #6 次构建了：

小结
可以确认的是，当两个 Jenkins 进程共用同一个 JENKINS_HOME 目录时，其中一个 Jenkins 进程更新了 JENKINS_HOME 的内容，另一个是不会实时更新的。所以，同时启动两个 Jenkins master 共用同一个 JENKINS_HOME 的方案是不可行的。我们不能在 jenkins-a 挂了后，直接将流量切到 jenkins-b。因为 jenkins-b 必须重启。
最后结论：多个 Jenkins master 共享同一个 JENKINS_HOME 的方案是无法使用 Jenkins master 的高可用。

附录

Jenkins standby 实验环境：https://github.com/zacker330/jenkins-standby-experiment

本文转自微信公众号：Jenkins

Gartner容器市场指南中国语境：容器成为新常态，本地厂商在选择中占据优势

灵雀云发表了文章 • 0 个评论 • 394 次浏览 • 2019-04-23 10:30 • 来自相关话题

在2019年2月“ China Summary Translation: 'Market Guide for Container Management Software'”的报告中，Gartner认为，在中国市场，容器技术的使用是近期的热点。本地厂商由于能够贴 ...查看全部

在2019年2月“ China Summary Translation: 'Market Guide for Container Management Software'”的报告中，Gartner认为，在中国市场，容器技术的使用是近期的热点。本地厂商由于能够贴近客户实际需求，而在选择中占据优势，例如阿里云、灵雀云等中国本地厂商。

关于容器的未来

为了解容器当前和未来的状态，国外研究分析师 Tom Smith近期收集了30余位积极使用容器技术的IT高管的见解。大家一致的观点认为：容器继续成熟，采用率上升，复杂度下降，Serverless兴起。

成熟

我们期待与AI，AR和VR一起使用更多的技术，随着人们使用AI轻松地开发、部署和管理容器，容器将会被大量采用和创新，会有更多的计算能力来更快地完成任务。

预计会有越来越多的人采用，容器在企业中已经被高度渗透。CNCF表示容器已经有60%-70%的部署，但是运行在Kubernetes上的计算工作负载占比要低得多。因此，Kubernetes还有巨大的增长机会。

越来越多的公司将会发现容器的好处，不仅因为可以使用容器来构建新的应用程序，而且真正开始重构现有的应用程序，并有效利用底层平台提供的水平可伸缩性等功能。企业从谈论云和容器转向在生产中使用容器，容器的使用成为主流。与此同时，围绕安全性和合规性的思考也将改变。

容器在容器编排和调度环境中提供了更好的状态管理，以及更好的执行时间，以支持无服务器的用例。

容器使用率将继续增长。推动新技术快速部署的能力不容忽视，容器的快速部署、管理和短生命周期的快速发展将推动新功能的开发。公司不得不跟上容器技术环境的快速变化，安全、编排和开发等领域都充斥着破坏的机会!

未来，容器将作为企业应用部署和管理的关键基础设施。随着技术的成熟，它会变得更加稳定、标准化和便携。希望成熟的容器技术能够带来更多的用例，诸如应用程序智能、性能表现等。

就像所有优秀的技术一样，容器变得“Boring”。解决方案提供商在包装和分销方面做得更好，将会有更多关于如何在容器周围加入信任，确保不是恶意以及防止臃肿的知识。

围绕Kubernetes的编排正在标准化，这将加速开源和商业生态系统的发展，并推动工具开发。还将看到，随着云供应商提供一致的产品，这个堆栈也将成熟起来。甚至微软、亚马逊和IBM都支持Kubernetes。五年后，不运行Kubernetes和Docker的企业将成为少数。

清晰

容器将像任何优秀的技术一样继续消失于背景中，工具使得利用技术变得更容易，容器的部署和使用将有更大的简化。

容器是一种在本地或云中构建类云应用程序的机制，容器变得更容易处理和扩展，没有单点故障，也没有单一供应商。

容器使事情变得不那么复杂，成为新的常态。开发人员希望在容器中构建所有新应用程序，人们需要改变构建的方式，首先分析应用程序，以便在发布时，可以监控从构建到生产到建设和扩展的全流程。

1)今天Kubernetes不是以app开发者为核心角色而构建的。需要让Kubernetes更易于开发人员快速启动和运行。

2)我们看到了在Knative和OpenFast等Kubernetes之上构建抽象的趋势，在Kubernetes之上部署了无服务器功能，抽象了the knobs of Kubernetes。随着越来越多的项目成熟并以原生方式运行，更多开发人员可以更轻松地使用该技术。只有28％的应用程序在容器上运行，它还处于早期阶段，我们有机会让这项技术变得更加平易近人和实用。

容器仍然太复杂。如果比较一下现在开发人员所需要的知识量，就会发现间接需要的能力比五六年前要复杂得多。五年前，如果想构建一个Python应用程序，有一些众所周知的标准。现在开发人员不仅要学习如何生成Docker镜像，还要学习如何在编排系统上部署，如何将配置传递到容器，以及所有关于安全性的细节。最终，开发人员将不必处理容器，因为更高级别的抽象是构建在容器之上的。

无服务器和FaaS已经在路上

在开发人员体验和开发速度方面，容器的价值得到坚实地证明。然而，在容器安全性方面肯定会有所改进。未来，我们设想一个更安全的容器，运行沙箱在Nano VMs，就像Kata容器或AWS Firecracker一样。Serverless函数将代替传统API应用程序的大量工作。

在运营框架和如何描述自动化之间有两个巨大的机会。Kubernetes已经成为标准。快速脚本工作。运营者有可能在非常强大的环境中实现这一目标。我们一直在寻找可以使用的80/20工具。当使用标准化的YAML语言进入Kubernetes时，标准化的应用程序自动化将为我们提供一个功能强大的地方，在这里我们可以看到一个真正的服务目录。无服务器FaaS也非常令人兴奋，因为它允许您只专注于应用程序的逻辑。

容器使每个人都可以轻松实现无服务器。没有必要依赖虚拟机，虚拟机正在消失。它更容易转向Serverless，容器随着时间的推移会有所改善。将有更多选项可以在容器内运行更多应用程序。他们将继续改变，改善，变得更加稳定，更快地从失败中恢复，同时省下大笔资金。

无服务器和FaaS已经在路上。更高级别的抽象有助于在系统中获得更小的组件。随着颗粒越来越小，必须弄清楚如何管理和知道在哪里运行，这时候 Istio作为一种服务网格产品，可以帮助跟踪所有组件。

1)在去年的KubeCon上，“Serverless”计算的概念是指向容器创新未来的一个重要话题和热点——即构建和部署几乎任何类型的应用程序，而无需配置或管理运行这些应用程序的服务器。此外，用户将根据使用模式付费，只支付所消耗的计算时间，不运行时不收费。

2) 容器最终将取代虚拟机。与vm相比，容器提供了显著的优势，如降低了部署成本、显著降低了启动性能、减少了机器占用空间，且具备易用性。随着越来越多的公司和IT组织使用容器，将会出现应用程序从虚拟机到容器的大规模迁移。

3) 容器的采用幅度将远远超出仅以Docker为主要容器类型的情况。竞争产品将被更广泛地接受和使用。Docker作为市场领导者，已经偏离了标准容器技术的开发，而是更加专注于开发和营销一个全面的应用程序开发平台。导致其他容器产品的普及和使用的大幅增长。

参考资料：

Gartner “China Summary Translation: 'Market Guide for Container Management Software'“，by Kevin Ji & Dennis Smith, Published on 18 February 2019， ID: G00382483.
2.The Future of Containers

https://dzone.com/articles/the ... ers-1
3.Cloud 2019 Predictions (Part 5)
https://dzone.com/articles/clo ... art-5

【精贴】（神速）5分钟内拉取Dockerhub镜像附带Mesos中文版下载链接

挑灯看剑回复了问题 • 10 人关注 • 5 个回复 • 6345 次浏览 • 2016-04-08 17:13 • 来自相关话题

请教下灵雀云是如何做到自动构建镜像的？

oilbeater 回复了问题 • 4 人关注 • 2 个回复 • 4207 次浏览 • 2015-10-13 14:24 • 来自相关话题

灵雀云的mongodb经常会变密码么?

苦逼少侠回复了问题 • 5 人关注 • 4 个回复 • 2864 次浏览 • 2015-10-11 22:06 • 来自相关话题

像灵雀云和时速云这些平台内部署的服务器镜像支持cron么

萧遥吟回复了问题 • 5 人关注 • 2 个回复 • 3509 次浏览 • 2015-09-15 09:49 • 来自相关话题

一键发布tomcat应用到灵雀云的Dockerfile怎么写啊

oilbeater 回复了问题 • 2 人关注 • 1 个回复 • 4455 次浏览 • 2015-07-10 09:57 • 来自相关话题

2019企业IT现状和趋势调研报告：70.7%的企业有云原生相关计划

灵雀云发表了文章 • 0 个评论 • 136 次浏览 • 2019-06-03 11:00 • 来自相关话题

被调研企业中，服务器规模在100-500台的比例为26.8%，500-1000台的企业占比22%，1000台服务器以上规模的14.6%。

IT系统自研还是外包

本次参与调研的企业以中大型企业为主，其中研发团队规模达到100人以上的比例高达44.3%，20-100人规模的占32.4%。

浅析 Kubernetes原生NetworkPolicy 网络策略，让更安全的容器运行环境唾手可得

灵雀云发表了文章 • 0 个评论 • 152 次浏览 • 2019-05-29 10:33 • 来自相关话题

k8s中的网络策略主要分为原生 NetworkPolicy 和第三方网络插件提供的网络策略。本文将主要分析原生Networkpolicy的网络策略。什么是网络策略 ...查看全部

Calico
Cilium
Kube-router
Romana
Weave Net

默认情况下 Pod 间及 Pod 与其他网络端点间的访问是没有限制的。

推荐观看Securing Cluster Networking with Network Policies - Ahmet Balkan, Google

一些常见的策略样例ahmetb/kubernetes-network-policy-recipes

使用 Jenkins + Ansible 实现 Spring Boot 自动化部署101

灵雀云发表了文章 • 0 个评论 • 233 次浏览 • 2019-05-22 10:43 • 来自相关话题

% tree -L 1

├── 1-cd-platform # 实验环境相关代码

├── 1-env-conf # 环境配置代码-实现配置独立

└── 1-springboot # Spring Boot 应用的代码及其部署代码

1-springboot 的目录结构如下：

% cd 1-springboot

% tree -L 1 

├── Jenkinsfile # 流水线代码

├── README.md

├── deploy # 部署代码

├── pom.xml 

└── src # 业务代码



docker.image('jenkins-docker-maven:3.6.1-jdk8')

.inside("--network 1-cd-platform_cd-in-practice -v $HOME/.m2:/root/.m2") {

    sh """

      mvn versions:set -DnewVersion=${APP_VERSION}

      mvn clean test package

      mvn deploy

    """

}





[list]

[*]hosts: "springboot"[/*]

[/list]  become: yes

  roles:

    - {"role": "ansible-role-java", "java_home": "{{JAVA_HOME}}"}

    - springboot



docker.image('williamyeh/ansible:centos7').inside("--network 1-cd-platform_cd-in-practice") {



  checkout([$class: 'GitSCM', branches: [[name: "master"]], doGenerateSubmoduleConfigurations: false,

            extensions: [[$class: 'RelativeTargetDirectory', relativeTargetDir: "env-conf"]], submoduleCfg: [],

            userRemoteConfigs: [[url: "https://github.com/cd-in-practice/1-env-conf.git"]]])



  sh "ls -al"



  sh """

    ansible-playbook --syntax-check deploy/playbook.yaml -i env-conf/dev

    ansible-playbook deploy/playbook.yaml -i env-conf/dev --extra-vars '{"app_version": "${APP_VERSION}"}'

  """

}



stage("build and upload"){

      // 如果不指定部署版本，则执行构建

      when {

        expression{ return params.SPECIFIC_APP_VERSION == "" }

      }

      // 构建并上传制品的逻辑

      steps{...}

}



machine.vm.provision "shell" do |s|

    s.inline = "echo '192.168.52.1 artifactory' >> /etc/hosts"

end

基于 Jenkins 的 DevOps 平台应该如何设计凭证管理

灵雀云发表了文章 • 0 个评论 • 213 次浏览 • 2019-05-20 11:06 • 来自相关话题



withCredentials([usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')]) {

    sh '''

      curl -u "$USERPASS" https://private.server/ > output

    '''

  }



git branch: 'master',

    credentialsId: '12345-1234-4696-af25-123455',

    url: 'ssh://git@bitbucket.org:company/repo.git'

深度解析Kubernetes核心原理之Scheduler

灵雀云发表了文章 • 0 个评论 • 231 次浏览 • 2019-05-17 10:56 • 来自相关话题

图 1. Pod处理流程

调度

Kubernetes Scheduler的任务是选择一个placement(位置)。一个placement是一个部分的，非内射的Pod集合到节点集合的分配。

图 3. Possible(可能), Feasible(可用)和Viable(可行)的调度

Kubernetes Scheduler是一个保证局部最优解的多步调度器，而不是一个保证全局最优解的单步调度器。

图 4. 多步 vs. 单步

Kubernetes Scheduler



BoundTo(Pod, Node, Snapshot)≝ 

  ∧ Pod ∈Snapshot

  ∧Pod.Kind = "Pod"

  ∧ Node∈ Snapshot

  ∧Node.Kind = "Node"

  ∧Pod.Spec.NodeName = Node.Name



Bound(Pod, Snapshot) ≝ 

  ∃ Node∈ Snapshot:

   BoundTo(Pod, Node, Snapshot)



Scheduler ≝

  LETUnbound ≝ {Pod \in Objects : Pod.Kind = "Pod" ∧ ~ Bound(Pod,Objects)} IN

    ∃ Pod∈ { Pod ∈ Unbound : ∀ Other ∈ Unbound : Other.Spec.Priority ≤ Pod.Spec.Priority}:

        CASE SchedulingEnabled(Pod) ⟶ Scheduling(Pod)

          [] PreemptionEnabled(Pod) ⟶ Preemption(Pod)

          [] OTHER ⟶ UNCHANGED(Objects)

Kubernetes Scheduler监控Kubernetes对象存储并且选择一个未绑定的最高优先级的Pod来执行调度流程或者抢占流程。

调度流程



SchedulingEnabled(Pod) ≝

  ∃ Node∈ {Node ∈ Objects : Node.Kind = "Node"}: 

   Feasibility(Pod, Node, Objects)



Scheduling(Pod) ≝

  LETFeasibile ≝ {Node ∈ Objects : n.Kind = "Node" ∧ Feasibility(Pod, n,Objects)} IN

    ∃Node ∈ Feasibile : 

      ∧ ∀Other ∈ Feasibile : Viability(Pod, Other, Objects) ≤ Viability(Pod, Node,Objects)

      ∧Objects' = {

       IF Pod = Object THEN 

         [Pod EXCEPT !["Spec"] = [Pod.Spec EXCEPT!["NodeName"] = Node.Name]] 

       ELSE 

         Object : Object ∈ Objects}



PreemptionEnabled(Pod) ≝

  ∃ Node∈ {Node \in Objects : Node.Kind = "Node"}:

    ∃Pods ∈ SUBSET(Jeopardy(Pod, Node, Objects)):

     Feasibility(Pod, Node, Objects \ Pods)



Preemption(Pod) ==

  LETPreemptable == {Node ∈ Objects : Node.Kind = "Node" ∧ ∃ Pods ∈SUBSET(Jeopardy(p, Node, Objects)): Feasibility(Pod, Node, Objects \ Pods)} IN

    ∃Node ∈ Preemptable:

      ∃Pods ∈ SUBSET(Jeopardy(Pod, Node, Objects)): 

        ∀OtherNode ∈ qualified: 

         ∀ OtherPods ∈ SUBSET(Jeopardy(Pod, OtherNode, Objects)): 

           ∧ Casualty(Pods) ≤ Casualty(OtherPods)

           ∧ Objects' = (Objects \ Pods)



Feasibility(Pod, Node,Snapshot) ==

 (Filter_1(Pod, Node, Snapshot) ∧ Filter_2(Pod, Node, Snapshot) ∧ ...)

图 1.1 可调度性和生命周期阶段



Filter(Pod, Node) ≝

  \* Onlyconsider Nodes that accept new Pods

  ∧Node.Spec.Unschedulable = False

  \* Onlyconsider Nodes that are ready to accept new Pods (Lifecycle Phase)

  ∧Node.Status.Phase = "Running"

1.2 资源需求和资源可用性

该过滤函数基于Pod的资源需求和Node的资源可用性来确定Node的可用。

图 1.2 资源需求和资源可用性



Resources(Pod, Node) ≝

  ∧ 1 ≤Node.Status.Allocatable["pods"]

  \* Usethe maximum resource requirements of init containers

  ∧ Max({i \in DOMAIN p.Spec.InitContainer :p.Spec.InitContainer[i].Resources.Required["cpu"] }) ≤Node.Status.Allocatable["cpu"]

  ∧ Max({i \in DOMAIN p.Spec.InitContainer :p.Spec.InitContainer[i].Resources.Required["mem"] }) ≤Node.Status.Allocatable["mem"]

  ∧ ...

  \* Usethe sum of resource requirements of main containers

  ∧ Sum({i \in DOMAIN p.Spec.Container :p.Spec.Container[i].Resources.Required["cpu"] }) ≤Node.Status.Allocatable["cpu"]

  ∧ Sum({i \in DOMAIN p.Spec.Container :p.Spec.Container[i].Resources.Required["mem"] }) ≤Node.Status.Allocatable["mem"]

  ∧ ...

1.3 Node Selector

该过滤函数基于Pod的node selector值和Node的label值来确定Node的可用。

图 1.3 Node Selector



Filter(Pod, Node) ==

  ∀ Label∈ DOMAIN(Pod.Spec.NodeSelector): 

      ∧Label ∈ DOMAIN(Node.Labels) 

      ∧Pod.Spec.NodeSelector[Label] = Node.Labels[Label]

1.4 Node Taints和Pod Tolerations

该过滤函数基于Pod的taints键值对和Node的tolerations键值对来确定Node的可用。

图 1.4 Node Taints和Pod Tolerations



Filter(Pod, Node) == 

    ∀Taint ∈ Node.Spec.Taints:

        ∃Toleration ∈ Pod.Spec.Tolerations: Match(Toleration, Taint)



Match(Toleration, Taint) ==

    ∧CASE Toleration.Operator = "Exists" 

          ⟶ Toleration.key = Taint.key 

       [] Toleration.Operator = "Equal" 

          ⟶ Toleration.key = Taint.key ∧ Toleration.value = Taint.value

       [] OTHER 

          ⟶ FALSE

    ∧Toleration.Effect = Taint.Effect

图 1.4 Node Taints和Pod Tolerations



Filter(Pod, Node) ≝

    \*Node, Affinity

    ∧ ∃NodeSelectorTerm ∈ Pod.Spec.Affinity.NodeAffinity.Required.NodeSelectorTerms : 

           Match_NS(NodeSelectorTerm, Node)

    \*Pod, Affinity

    ∧ ∀PodAffinityTerm ∈ Pod.Spec.Affinity.PodAffinity.Required : 

           P_Affinity(PodAffinityTerm, Node)

    \*Pod, Anit-Affinity

    ∧ ∀PodAffinityTerm ∈ Pod.Spec.Affinity.AntiPodAffinity.Required : 

         ¬ P_Affinity(PodAffinityTerm, Node)



\* Node, Affinity, Match Node Selector Term

Match_NS(NodeSelectorRequirement, Node) ≝

    CASENodeSelectorRequirement.Operator = "In" 

         ⟶   (NodeSelectorRequirement.Key ∈DOMAIN(Node.Labels) ∧ Node.Labels[NodeSelectorRequirement.Key] ∈NodeSelectorRequirement.Value)

      []NodeSelectorRequirement.Operator = "NotIn" 

         ⟶¬ (NodeSelectorRequirement.Key ∈ DOMAIN(Node.Labels) ∧Node.Labels[NodeSelectorRequirement.Key] ∈ NodeSelectorRequirement.Value)

      []NodeSelectorRequirement.Operator = "Exits" 

         ⟶   (NodeSelectorRequirement.Key ∈DOMAIN(Node.Labels))

      []NodeSelectorRequirement.Operator = "DoesNotExist" 

         ⟶¬ (NodeSelectorRequirement.Key ∈ DOMAIN(Node.Labels))

      []_NodeSelectorRequirement.Operator = "Gt" ∧ ∀ Value ∈NodeSelectorRequirement.Value: Value ∈ Int

         ⟶   (NodeSelectorRequirement.Key ∈DOMAIN(Node.Labels) ∧ Node.Labels[NodeSelectorRequirement.Key] ∈ Int ∧Node.Labels[NodeSelectorRequirement.Key] >Max(NodeSelectorRequirement.Value))

      []_NodeSelectorRequirement.Operator = "Lt" ∧ ∀ Value ∈NodeSelectorRequirement.Value: Value ∈ Int

         ⟶   (NodeSelectorRequirement.Key ∈DOMAIN(Node.Labels) ∧ Node.Labels[NodeSelectorRequirement.Key] ∈ Int ∧Node.Labels[NodeSelectorRequirement.Key] 
      []OTHER 

         ⟶FALSE



\* Pod, (Anti)Affinity, Match Pod Affinity Term

P_Affinity(PodAffinityTerm, Node) ==

    IFPodAffinityTerm.TopologyKey \in DOMAIN(Node.Labels) THEN

        ∃Other ∈ {Other ∈ Objects : Other.Kind = "Node" ∧PodAffinityTerm.TopologyKey ∈ DOMAIN(Other.Labels) ∧Other.Labels[PodAffinityTerm.TopologyKey] =Node.Labels[PodAffinityTerm.TopologyKey]}: 

           ∃ Pod ∈ {Pod ∈ objects : Pod.kind = "Pod" ∧ BoundTo(Pod, Node)∧ Pod.Namespace ∈ PodAffinityTerm.Namespaces}:

               Match_LS(PodAffinityTerm.LabelSelector, Pod.Labels)

    ELSE

       FALSE



\* Pod, (Anti)Affinity, Match Label Selector

Match_LS(LabelSelector, Labels) ≝

    ∧ ∀Key ∈ DOMAIN(LabelSelector) : Key ∈ DOMAIN(Labels) ∧ LabelSelector[Key] =Labels[Key]

    ∧ ∀LabelSelectorRequirement ∈ LabelSelector.MatchExpression:

         CASE LabelSelectorRequirement.Operator = "In"

              ⟶   (LabelSelectorRequirement.Key∈ DOMAIN(Labels) ∧ Labels[LabelSelectorRequirement.Key] ∈LabelSelectorRequirement.Values)

           [] _LabelSelectorRequirement.Operator = "NotIn"

              ⟶ ¬ (LabelSelectorRequirement.Key ∈ DOMAIN(Labels) ∧Labels[LabelSelectorRequirement.key] ∈ LabelSelectorRequirement.Values)

           [] _LabelSelectorRequirement.Operator = "Exists"

              ⟶   (LabelSelectorRequirement.Key∈ DOMAIN(Labels))

           [] _LabelSelectorRequirement.Operator = "DoesNotExist"

              ⟶ ¬ (LabelSelectorRequirement.Key ∈ DOMAIN(Labels))

可行性(Viability)



Viability(Pod, Node,Snapshot) ==

 Sum(<>)

图 1.4 Node Taints和Pod Tolerations



Rating(Pod, Node) ≝

 Sum(<<

   Sum(LAMBDA Term: Term.Weight, {NodeSelectorTerm ∈Pod.Spec.Affinity.NodeAffinity.Preferred.NodeSelectorTerms :Match_NS(NodeSelectorTerm, Node) }),

   Sum(LAMBDA Term: Term.Weight, {PodAffinityTerm ∈Pod.Spec.Affinity.PodAffinity.Preferred : P_Affinity(PodAffinityTerm, Node) }),

   Sum(LAMBDA Term: Term.Weight, {PodAffinityTerm ∈Pod.Spec.Affinity.AntiPodAffinity.Preferred : ~ P_Affinity(PodAffinityTerm,Node)})

 >>)

灵雀云Kube-OVN：基于OVN的开源Kubernetes网络实践

灵雀云发表了文章 • 0 个评论 • 452 次浏览 • 2019-05-09 14:34 • 来自相关话题

Kubernetes 中的渐进式交付：蓝绿部署和金丝雀部署

灵雀云发表了文章 • 0 个评论 • 364 次浏览 • 2019-05-07 15:27 • 来自相关话题



strategy:

  steps:

  - name: staging

    capacity:

      contender: 1

      incumbent: 100

    traffic:

      contender: 0

      incumbent: 100

  - name: 50/50

    capacity:

      contender: 50

      incumbent: 50

    traffic:

      contender: 50

      incumbent: 50

  - name: full on

    capacity:

      contender: 100

      incumbent: 0

    traffic:

      contender: 100

      incumbent: 0



apiVersion: networking.istio.io/v1alpha3

kind: Gateway

metadata:

 name: public-gateway

 namespace: istio-system

spec:

 selector:

   istio: ingressgateway

 servers:

 - port:

     number: 80

     name: http

     protocol: HTTP

   hosts:

   - "*"



apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

 name: croc-hunter-jenkinsx

 namespace: jx-production

spec:

 gateways:

 - public-gateway.istio-system.svc.cluster.local

 - mesh

 hosts:

 - croc-hunter.istio.example.org

 http:

 - route:

   - destination:

       host: croc-hunter-jenkinsx.jx-production.svc.cluster.local

       port:

         number: 80

     weight: 99

   - destination:

       host: croc-hunter-jenkinsx.jx-staging.svc.cluster.local

       port:

         number: 80

     weight: 1

使用 Jenkins + Ansible 实现自动化部署 Nginx

灵雀云发表了文章 • 0 个评论 • 429 次浏览 • 2019-04-29 11:00 • 来自相关话题



git clone https://github.com/zacker330/jenkins-ansible-nginx.git

cd jenkins-ansible-nginx

构建 Jenkins agent 的镜像需要自定义 Jenkins agent 镜像有两个原因：



docker build -f JenkinsSlaveAnsibleDockerfile -t jenkins-swarm-ansible .



docker-compose up -d

启动目标机器，用于部署 Nginx 在命令行中执行以下命令：



vagrant up

2、配置流水线配置 Jenkins 任务从远程仓库拉取 Jenkinsfile，如下图所示：

除此之外，不需要其它配置了，是不是很简单？

4. 手工触发一次自动化构建

点击“立即构建”：

最终执行日志如下：



% tree -L 2

├── JenkinsSlaveAnsibleDockerfile # Jenkins agent 镜像 Dockerfile

├── Jenkinsfile  # 流水线逻辑

├── README.md

├── Vagrantfile # Vagrant 虚拟机定义文件

├── docker-compose.yml # Jenkins 实现环境

├── env-conf # 所有应用配置

│   └── dev   # dev 环境的配置

├── deploy  # Ansible 部署脚本所在文件夹

│   ├── playbook.yaml

│   └── roles

└── swarm-client.sh # Jenkins swarm 插件的客户端

5.1流水线逻辑

Jenkinsfile 文件用于描述整条流水线的逻辑。代码如下：



pipeline{

  // 任务执行在具有 ansible 标签的 agent 上

  agent { label "ansible"}

  environment{

     // 设置 Ansible 不检查 HOST_KEY

    ANSIBLE_HOST_KEY_CHECKING = false

  }

  triggers {

     pollSCM('H/1 [i] [/i] [i] [/i]')

  }

  stages{

    stage("deploy nginx"){

      steps{

        sh "ansible-playbook -i env-conf/dev  deploy/playbook.yaml"

      }



[list]

[*]hosts: "nginx"[/*]

[/list]  become: true

  roles:

    # Nginx 的部署

    - ansible-role-nginx

    # 对防火墙的设置

    - ansible-role-firewall



% cd env-conf/

% tree

└── dev

    ├── group_vars

    │   └── nginx.yaml

    ├── host_vars

    │   └── 192.168.52.10

    └── hosts

hosts文件：Ansible 中通过“分组”来实现对主机的管理。hosts 文件内容如下：



[nginx]

192.168.52.10

nginx

关于 Jenkins master 共享 JENKINS_HOME 目录的实验

灵雀云发表了文章 • 1 个评论 • 323 次浏览 • 2019-04-24 14:45 • 来自相关话题

jenkins-b 的界面如下图所示：

而 jenkins-a 的界面如下图所示：

这时，将 jenkins-a 日志中的解锁密码（Unlock password）输入到 jenkins-b 的页面中，会得到报错信息：



ERROR: The password entered is incorrect, please check the file for the correct password



jenkins-b_1  | WARNING: A new build could not be created in job x

jenkins-b_1  | java.lang.IllegalStateException: JENKINS-23152: /var/jenkins_home/jobs/x/builds/2 already existed; will not overwrite with x #2

Gartner容器市场指南中国语境：容器成为新常态，本地厂商在选择中占据优势

灵雀云发表了文章 • 0 个评论 • 394 次浏览 • 2019-04-23 10:30 • 来自相关话题

更多...

云雀科技成立于2014年10月，是中国第一家基于容器技术、服务于开发者及企业的的云计算平台。云雀科技产品线以容器（Docker）这个新一代应用交付件为中心，全方位支持云端应用创建、编译、集成、部署、运行的每一个环节。

话题描述

最佳回复者

: 灵雀云
获得 0 次赞同, 0 次感谢

: darkheaven
获得 4 次赞同, 0 次感谢

: oilbeater
获得 1 次赞同, 0 次感谢

: sdvdxl
获得 1 次赞同, 0 次感谢

: heshuangcai
获得 4 次赞同, 0 次感谢

灵雀云

话题描述

相关话题

最佳回复者

69 人关注该话题