Kubernetes中的容器编排和应用编排

众所周知,Kubernetes 是一个容器编排平台,它有非常丰富的原始的 API 来支持容器编排,但是对于用户来说更加关心的是一个应用的编排,包含多容器和服务的组合,管理它们之间的依赖关系,以及如何管理存储。 在这个领域,Kubernetes 用 Helm 的...
继续阅读 »

众所周知,Kubernetes 是一个容器编排平台,它有非常丰富的原始的 API 来支持容器编排,但是对于用户来说更加关心的是一个应用的编排,包含多容器和服务的组合,管理它们之间的依赖关系,以及如何管理存储。


在这个领域,Kubernetes 用 Helm 的来管理和打包应用,但是 Helm 并不是十全十美的,在使用过程中我们发现它并不能完全满足我们的需求,所以在 Helm 的基础上,我们自己研发了一套编排组件……


什么是编排

不知道大家有没仔细思考过编排到底是什么意思? 我查阅了 Wiki 百科,了解到我们常说的编排的英文单词为 “Orchestration”,它常被解释为:


  • 本意:为管弦乐中的配器法,主要是研究各种管弦乐器的运用和配合方法,通过各种乐器的不同音色,以便充分表现乐曲的内容和风格。
  • 计算机领域:引申为描述复杂计算机系统、中间件 (middleware) 和业务的自动化的安排、协调和管理。

有趣的是 “Orchestration” 的标准翻译应该为“编配”,而“编排”则是另外一个单词 “Choreography”,为了方便大家理解, 符合平时的习惯,我们还是使用编排 (Orchestration) 来描述下面的问题。至于“编配 (Orchestration)” 和 “编排(Choreography)” 之争,这里有一篇文章,有兴趣可以看一下 。http://www.infoq.com/cn/news/2008/09/Orchestration


Kubernetes 容器编排技术

当我们在说容器编排的时候,我们在说什么?


在传统的单体式架构的应用中,我们开发、测试、交付、部署等都是针对单个组件,我们很少听到编排这个概念。而在云的时代,微服务和容器大行其道,除了为我们显示出了它们在敏捷性,可移植性等方面的巨大优势以外,也为我们的交付和运维带来了新的挑战:我们将单体式的架构拆分成越来越多细小的服务,运行在各自的容器中,那么该如何解决它们之间的依赖管理,服务发现,资源管理,高可用等问题呢?


在容器环境中,编排通常涉及到三个方面:


  • 资源编排 - 负责资源的分配,如限制 namespace 的可用资源,scheduler 针对资源的不同调度策略;
  • 工作负载编排 - 负责在资源之间共享工作负载,如 Kubernetes 通过不同的 controller 将 Pod 调度到合适的 node 上,并且负责管理它们的生命周期;
  • 服务编排 - 负责服务发现和高可用等,如 Kubernetes 中可用通过 Service 来对内暴露服务,通过 Ingress 来对外暴露服务。

在 Kubernetes 中有 5 种经常会用到的控制器来帮助我们进行容器编排,分别是 Deployment, StatefulSet, DaemonSet, CronJob, Job


在这 5 种常见资源中,Deployment 经常被作为无状态实例控制器使用; StatefulSet 是一个有状态实例控制器; DaemonSet 可以指定在选定的 Node 上跑,每个Node 上会跑一个副本,它有一个特点是它的Pod的调度不经过调度器,在Pod 创建的时候就直接绑定NodeName;最后一个是定时任务,它是一个上级控制器,和 Deployment 有些类似,当一个定时任务触发的时候,它会去创建一个 Job,具体的任务实际上是由 Job 来负责执行的。他们之间的关系如下图:

一个简单的例子
我们来考虑这么一个简单的例子,一个需要使用到数据库的 API 服务在 Kubernetes 中应该如何表示:

客户端程序通过 Ingress 来访问到内部的 API Service, API Service 将流量导流到 API Server Deployment 管理的其中一个 Pod 中,这个 Server 还需要访问数据库服务,它通过 DB Service 来访问 DataBase StatefulSet 的有状态副本。由定时任务 CronJob 来定期备份数据库,通过 DaemonSet 的 Logging 来采集日志,Monitoring 来负责收集监控指标。

容器编排的困境

Kubernetes 为我们带来了什么?
通过上面的例子,我们发现 Kubernetes 已经为我们对大量常用的基础资源进行了抽象和封装,我们可以非常灵活地组合、使用这些资源来解决问题,同时它还提供了一系列自动化运维的机制:如 HPA, VPA, Rollback, Rolling Update 等帮助我们进行弹性伸缩和滚动更新,而且上述所有的功能都可以用 YAML 声明式进行部署。

困境
但是这些抽象还是在容器层面的,对于一个大型的应用而言,需要组合大量的 Kubernetes 原生资源,需要非常多的 Services, Deployments, StatefulSets 等,这里面用起来就会比较繁琐,而且其中服务之间的依赖关系需要用户自己解决,缺乏统一的依赖管理机制。

应用编排

什么是应用?
一个对外提供服务的应用,首先它需要一个能够与外部通讯的网络,其次还需要能运行这个服务的载体 (Pods),如果这个应用需要存储数据,这还需要配套的存储,所以我们可以认为:

应用单元 = 网络 + 服务载体 +存储

那么我们很容易地可以将 Kubernetes 的资源联系起来,然后将他们划分为 4 种类型的应用:

  • 无状态应用 = Services + Volumes + Deployment
  • 有状态应用 = Services + Volumes + StatefulSet
  • 守护型应用 = Services + Volumes + DaemonSet
  • 批处理应用 = Services + Volumes + CronJob/Job

我们来重新审视一下之前的例子:

应用层面的四个问题
通过前面的探索,我们可以引出应用层面的四个问题:

  • 应用包的定义
  • 应用依赖管理
  • 包存储
  • 运行时管理

在社区中,这四个方面的问题分别由三个组件或者项目来解决:


  • Helm Charts: 定义了应用包的结构以及依赖关系;
  • Helm Registry: 解决了包存储;
  • HelmTiller: 负责将包运行在 Kubernetes 集群中。

Helm Charts
Charts 在本质上是一个 tar 包,包含了一些 yaml 的 template 以及解析 template 需要的 values, 如下图:templates 是 Golang 的 template 模板,values.yaml 里面包含了这个 Charts 需要的值。

Helm Registry
用来负责存储和管理用户的 Charts, 并提供简单的版本管理,与容器领域的镜像仓库类似这个项目是开源的。( https://github.com/caicloud/helm-registry)


Tiller


  • 负责将 Chart 部署到指定的集群当中,并管理生成的 Release (应用);
  • 支持对 Release 的更新,删除,回滚操作;
  • 支持对 Release 的资源进行增量更新;
  • Release 的状态管理;
  • Kubernetes下属子项目(https://github.com/kubernetes/helm) 。


Tiller 的缺陷


  1. 没有内建的认知授权机制,Tiller 跑在 kube-system 分区下,拥有整个集群的权限;
  2. Tiller 将 Release 安装到 Kubernetes 集群中后并不会继续追踪他们的状态;
  3. Helm+Tiller的架构并不符合 Kubernetes 的设计模式,这就导致它的拓展性比较差;
  4. Tiller 创建的 Release 是全局的并不是在某一个分区下,这就导致多用户/租户下,不能进行隔离;
  5. Tiller 的回滚机制是基于更新的,每次回滚会使版本号增加,这不符合用户的直觉。

Release Controller

为了解决上述的问题,我们基于 Kubernetes 的 Custom Resource Definition 设计并实现了我们自己的运行时管理系统 – Release Controller, 为此我们设计了两个新的 CRD – Release 和 Release History。


Release 创建
当 Release CRD 被创建出来,controller 为它创建一个新的 Release History, 然后将 Release 中的 Chart 和 Configuration 解析成 Kubernetes 的资源,然后将这些资源在集群中创建出来,同时会监听这些资源的变化,将它们的状态反映在 Release CRD 的 status 中。

Release 更新
当用户更新 Release 的时候,controller 计算出更新后的资源与集群中现有资源的 diff, 然后删除一部分,更新一部分,创建一部分,来使得集群中的资源与 Release 描述的一致,同时为旧的 Release 创建一份 Release History。

Release 回滚和删除
用户希望回滚到某一个版本的 Release, controller 从 Release History 中找到对应的版本,然后将 Release 的 Spec 覆盖,同时去更新集群中对应的资源。当 Release 被删除后,controller 将它关联的 Release History 删除,同时将集群中的其他资源一并删除。

架构图

这样的设计有什么好处?


  • 隔离性:资源使用 Namespace 隔离,适应多用户/租户;
  • 可读性:Release Controller 会追踪每个 Release 的子资源的状态;
  • 版本控制:你可以很容易地会退到某一个版本;
  • 拓展性:整个架构是遵循 Kubernetes 的 controller pattern,具有良好的可扩展性,可以在上面进行二次开发;
  • 安全性:因为所有的操作都是基于 Kubernetes 的 Resource,可以充分利用 Kubernetes 内建的认证鉴权模块,如 ABAC, RBAC 。

总而言之,编排不仅仅是一门技术也是一门艺术!谢谢!
分享阅读原文链接:https://mp.weixin.qq.com/s/zHlS2cQEHzRea_bqKpNA9A

收起阅读 »

漏洞风险评估CVSS介绍

什么是CVSS通用弱点评价体系(CVSS)是由NIAC开发、FIRST维护的一个开放并且能够被产品厂商免费采用的标准。利用该标准,可以对弱点进行评分,进而帮助我们判断修复不同弱点的优先等级。 CVSS(Common Vulnerability Scoring ...
继续阅读 »

什么是CVSS

通用弱点评价体系(CVSS)是由NIAC开发、FIRST维护的一个开放并且能够被产品厂商免费采用的标准。利用该标准,可以对弱点进行评分,进而帮助我们判断修复不同弱点的优先等级。


CVSS(Common Vulnerability Scoring System),即”通用漏洞评分系统”,是一个”行业公开标准,其被设计用来评测漏洞的严重程度,并帮助确定所需反应的紧急度和重要度”。


它的主要目的是帮助人们建立衡量漏洞严重程度的标准,使得人们可以比较漏洞的严重程度,从而确定处理它们的优先级。CVSS得分基于一系列维度上的测量结果,这些测量维度被称为量度(Metrics)。漏洞的最终得分最大为10,最小为0。


得分7~10的漏洞通常被认为比较严重,得分在4~6.9之间的是中级漏洞,0~3.9的则是低级漏洞。


CVSS系统包括三种类型的分数:基本分数、暂时分和环境分。


基本得分临时得分通常由安全产品卖主、供应商给出,因为他们能够更加清楚的了解漏洞的详细信息;


环境得分通常由用户给出,因为他们能够在自己的使用环境下更好的评价该漏洞存在的潜在影响。


所以应该是基于漏洞库的扫描, 需要预先知道该漏洞的威胁值?


就是说漏洞应该预先有脆弱性等级,系统的安全性评估是综合各个漏洞来进行的?


CVSS 2.0 计算方法: 通用漏洞评估方法CVSS 3.0 计算公式及说明 - caya - 博客园 (cnblogs.com)


一些指标具有不确定性和复杂性,会导致完全的定量分析困难。3个客观性指标和11个主观性指标。下一步:指标量化(客观性指标量化和主观性指标量化)。


CVSS评分计算方法

A. 基本评价(Base Metric)

基本评价指的是该漏洞本身固有的一些特点及这些特点可能造成的影响的评价分值


































序号 要素 可选值 评分
1 攻击途径 (AccessVector) 本地/远程 0.7/1.0
2 攻击复杂度(AccessComplexity) 高/中/低 0.6/0.8/1.0
3 认证(Authentication) 需要/不需要 0.6/1.0
4 机密性(Conflmpact) 不受影响/部分/完全 0/0.7/1
5 完整性(integlmpact) 不受影响/部分/完全 0/0.7/1
6 可用性(Availlmpact) 不受影响/部分/完全 0/0.7/1
7 权值倾向 平均/机密性/完整性/可用性 各0.333/权值倾向要素0.5另两个0.25

基础评价 = 四舍五入(10 * 攻击途径 攻击复杂度 认证 ((机密性 机密性权重) + (完整性 完整性权重) + (可用性 可用性权重)))


B.生命周期评价(Temporal Metric)

是针对最新类型漏洞(如: 0day漏洞)设置的评分项,因此SQL注入漏洞不用考虑


因此这里也列举出三个与时间紧密关联的要素如下:


















序号 要素 可选值 评分
1 可利用性 未证明/概念证明/功能性/完全代码 0.85/0.9/0.95/1.0
2 修复措施 官方补丁/临时补丁/临时解决方案/无 0.87/0.90/0.95/1.0
3 确认程度 不确认/未经确认/已确认 0.9/0.95/1.0

生命周期评价 =四舍五入(基础评价 可利用性 修复措施 * 未经确认)


C.环境评价(Environmental Metric)

每个漏洞会造成的影响大小都与用户自身的实际环境密不可分,因此可选项中也包括了环境评价,这可以由用户自评。(用户扫描配置时填写)














序号 要素 可选值 评分
1 危害影响程度 无/低/中/高 0/0.1/0.3/0.5
2 目标分布范围 无/低/中/高(0/1-15%/16-49%/50-100%) 0/0.25/0.75/1.0

环境评价 = 四舍五入<(生命周期评价 + [(10 -生命周期评价) *危害影响程度]) *目标分布范围>


评分与危险等级













序号 评分 危险等级
1 [0,4]
2 [4,7]
3 [7,10]
收起阅读 »

使用kubekey部署kubernetes集群

kubekey简介kubeykey是KubeSphere基于Go 语言开发的kubernetes集群部署工具,使用 KubeKey,您可以轻松、高效、灵活地单独或整体安装 Kubernetes 和 KubeSphere。 KubeKey可以用于以下三种安装场景...
继续阅读 »

kubekey简介

kubeykey是KubeSphere基于Go 语言开发的kubernetes集群部署工具,使用 KubeKey,您可以轻松、高效、灵活地单独或整体安装 Kubernetes 和 KubeSphere。


KubeKey可以用于以下三种安装场景:


  • 仅安装 Kubernetes集群
  • 使用一个命令安装 Kubernetes 和 KubeSphere
  • 已有Kubernetes集群,使用ks-installer 在其上部署 KubeSphere

项目地址:https://github.com/kubesphere/kubekey 开源公司:青云


kubekey安装

下载kk二进制部署命令,您可以在任意节点下载该工具,比如准备一个部署节点,或者复用集群中已有节点:


wget https://github.com/kubesphere/kubekey/releases/download/v1.2.0-alpha.2/kubekey-v1.2.0-alpha.2-linux-amd64.tar.gz
tar -zxvf kubekey-v1.2.0-alpha.2-linux-amd64.tar.gz
mv kk /usr/local/bin/

脚本下载安装:


export KKZONE=cn
curl -sfL | VERSION=v1.1.0 sh -
mv kk /usr/local/bin/

查看版本:


kk version

在所有节点上安装相关依赖


yum install -y socat conntrack ebtables ipset

所有节点关闭selinux和firewalld


setenforce 0 && sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config
systemctl disable --now firewalld

所有节点时间同步


yum install -y chrony
systemctl enable --now chronyd
timedatectl set-timezone Asia/Shanghai

节点无需配置主机名,kubekey会自动纠正主机名。


部署单节点集群

部署单节点kubernetes


kk create cluster

同时部署kubernetes和kubesphere,可指定kubernetes版本或kubesphere版本


kk create cluster --with-kubernetes v1.20.4 --with-kubesphere v3.1.0

当指定安装KubeSphere时,要求集群中有可用的持久化存储。默认使用localVolume,如果需要使用其他持久化存储,请参阅addons配置。


部署多节点集群

准备6个节点,部署高可用kubernetes集群,kubekey的高可用实现目前是基于haproxy的本地负载均衡模式。


创建示例配置文件:


kk create config

根据您的环境修改配置文件config-sample.yaml,以下示例以部署3个master节点和3个node节点为例(不执行kubesphere部署,仅搭建kubernetes集群):


cat > config-sample.yaml <

使用配置文件创建集群

export KKZONE=cn
kk create cluster -f config-sample.yaml | tee kk.log

创建完成后查看节点状态

[root@kube-master1 ~]# kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
kube-master1 Ready control-plane,master 4m58s v1.20.6 192.168.93.60 CentOS Linux 7 (Core) 3.10.0-1127.el7.x86_64
kube-master2 Ready control-plane,master 3m58s v1.20.6 192.168.93.61 CentOS Linux 7 (Core) 3.10.0-1127.el7.x86_64
kube-master3 Ready control-plane,master 3m58s v1.20.6 192.168.93.62 CentOS Linux 7 (Core) 3.10.0-1127.el7.x86_64
kube-node1 Ready worker 4m13s v1.20.6 192.168.93.63 CentOS Linux 7 (Core) 3.10.0-1127.el7.x86_64
kube-node2 Ready worker 3m59s v1.20.6 192.168.93.64 CentOS Linux 7 (Core) 3.10.0-1127.el7.x86_64
kube-node3 Ready worker 3m59s v1.20.6 192.168.93.65 CentOS Linux 7 (Core) 3.10.0-1127.el7.x86_64

查看所有pod状态

[root@kube-master1 ~]# kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-kube-controllers-8545b68dd4-rbshc 1/1 Running 2 3m48s
kube-system calico-node-5k7b5 1/1 Running 1 3m48s
kube-system calico-node-6cv8z 1/1 Running 1 3m48s
kube-system calico-node-8rbjs 1/1 Running 0 3m48s
kube-system calico-node-d6wkc 1/1 Running 0 3m48s
kube-system calico-node-q8qp8 1/1 Running 0 3m48s
kube-system calico-node-rvqpj 1/1 Running 0 3m48s
kube-system coredns-7f87749d6c-66wqb 1/1 Running 0 4m58s
kube-system coredns-7f87749d6c-htqww 1/1 Running 0 4m58s
kube-system haproxy-kube-node1 1/1 Running 0 4m3s
kube-system haproxy-kube-node2 1/1 Running 0 4m3s
kube-system haproxy-kube-node3 1/1 Running 0 2m47s
kube-system kube-apiserver-kube-master1 1/1 Running 0 5m13s
kube-system kube-apiserver-kube-master2 1/1 Running 0 4m10s
kube-system kube-apiserver-kube-master3 1/1 Running 0 4m16s
kube-system kube-controller-manager-kube-master1 1/1 Running 0 5m13s
kube-system kube-controller-manager-kube-master2 1/1 Running 0 4m10s
kube-system kube-controller-manager-kube-master3 1/1 Running 0 4m16s
kube-system kube-proxy-2t5l6 1/1 Running 0 3m55s
kube-system kube-proxy-b8q6g 1/1 Running 0 3m56s
kube-system kube-proxy-dsz5g 1/1 Running 0 3m55s
kube-system kube-proxy-g2gxz 1/1 Running 0 3m55s
kube-system kube-proxy-p6gb7 1/1 Running 0 3m57s
kube-system kube-proxy-q44jp 1/1 Running 0 3m56s
kube-system kube-scheduler-kube-master1 1/1 Running 0 5m13s
kube-system kube-scheduler-kube-master2 1/1 Running 0 4m10s
kube-system kube-scheduler-kube-master3 1/1 Running 0 4m16s
kube-system nodelocaldns-l958t 1/1 Running 0 4m19s
kube-system nodelocaldns-n7vkn 1/1 Running 0 4m18s
kube-system nodelocaldns-q6wjc 1/1 Running 0 4m33s
kube-system nodelocaldns-sfmcc 1/1 Running 0 4m58s
kube-system nodelocaldns-tvdbh 1/1 Running 0 4m18s
kube-system nodelocaldns-vg5t7 1/1 Running 0 4m19s

kubekey集群维护

添加节点

kk add nodes -f config-sample.yaml

删除节点

kk delete node  -f config-sample.yaml

删除集群

kk delete cluster
kk delete cluster [-f config-sample.yaml]

集群升级

kk upgrade [--with-kubernetes version] [--with-kubesphere version]
kk upgrade [--with-kubernetes version] [--with-kubesphere version] [(-f | --file) path]
收起阅读 »

什么是PDCA模型和SMART原则

什么是 PDCA 模型?PDCA 循环是提高工作质量的理论方法,广泛应用在企业管理和个人工作中。P-D-C-A 这四个字母,分别代表:Plan(计划),Do(行动),Check(检查),Act(处理)。美国的质量管理大师戴明认为,高质量,不是来自基于结果的产品...
继续阅读 »

什么是 PDCA 模型?

PDCA 循环是提高工作质量的理论方法,广泛应用在企业管理和个人工作中。P-D-C-A 这四个字母,分别代表:Plan(计划),Do(行动),Check(检查),Act(处理)。美国的质量管理大师戴明认为,高质量,不是来自基于结果的产品检验,而是来自于基于过程的不断改善。


PDCA循环的四个过程


第一,Plan(计划)
一个 PDCA 循环式的「计划」,一定要有「Who do what by when」,也就是:「谁在什么时间之前做什么」,发给大家,而不是口头布置。

第二,Do(行动)


行动,是最占用时间,也是最重要的部分。因为有了计划,以及基于计划分解的,分配到每个人任务栏里的,有时间限制的具体任务,执行就变得责任明确、优先级清晰。


第三,Check(检查)
每一件交代出去的任务,就像一个扔出去的回行镖,最终必须回到你的手上。这是 PDCA 的关键。

第四,Act(处理)
处理不是行动,而是总结成功经验,制定相应标准,或者把未解决或新出现的问题转入下一个 PDCA 循环。

什么是 SMART 原则?

SMART原则是一套制定目标的原则。S-M-A-R-T这5个字母,代表Specific(具体的),Measurable(可衡量的),Attainable(可实现的),Relevant(相关的),和Time-Based(有时间限制的)。


它的本质,是砍掉模棱两可,砍掉标准争议,砍掉不切实际,砍掉无关目标,砍掉无限拖延,让目标从“一千个人心中的一千个哈姆雷特”,变成同一个。


五个字母的含义


第一,Specific(具体的)
绩效考核要切中特定的工作指标,不能笼统。

第二,Measurable(可衡量的)
绩效指标是数量化或者行为化的,验证这些绩效指标的数据或者信息是可以获得的。

第三,Attainable(可实现的)
绩效指标在付出努力的情况下可以实现,避免设立过高或过低的目标。

第四,Relevant(相关性的)
绩效指标是与工作的其它目标是相关联的;绩效指标是与本职工作相关联的。

第五,Time-bound(有时间限制的)
注重完成绩效指标的特定期限。

收起阅读 »

Python的发展趋势

一、Python发展历史Python是一种计算机程序设计语言。你可能在之前听说过很多编程语言,比如难学的C语言(语法和实现难度),非常流行的JAVA语言(尤其是现在分布式存储和服务),非常有争议的PHP(常见 WordPress 大多网站),前端HTML、Ja...
继续阅读 »

一、Python发展历史

Python是一种计算机程序设计语言。你可能在之前听说过很多编程语言,比如难学的C语言(语法和实现难度),非常流行的JAVA语言(尤其是现在分布式存储和服务),非常有争议的PHP(常见 WordPress 大多网站),前端HTML、JavaScripts、Node.JS、还有最近随着容器风行的Golang等等。那Python是What?


  • 1989年,Python的创始人为吉多·范罗苏姆(Guido van Rossum)。1989年的圣诞节期间,吉多·范罗苏姆为了在阿姆斯特丹打发时间,决心开发一个新的脚本解释程序,作为ABC语言的一种继承。
  • 1991年,第一个Python编译器诞生。它是用C语言实现的,并能够调用C语言的库文件。从一出生,Python已经具有了:类,函数,异常处理,包含表和词典在内的核心数据类型,以及模块为基础的拓展系统。
  • 1992年,Python之父发布了Python的web框架Zope1.
  • Python 1.0 - January 1994 增加了 lambda, map, filter and reduce.
  • Python 2.0 - October 16, 2000,加入了内存回收机制,构成了现在Python语言框架的基础
  • Python 2.4 - November 30, 2004, 同年目前最流行的WEB框架Django 诞生
  • Python 2.5 - September 19, 2006
  • Python 2.6 - October 1, 2008
  • Python 2.7 - July 3, 2010
  • In November 2014, it was announced that Python 2.7 would be supported until 2020, and reaffirmed that there would be no 2.8 release as users were expected to move to Python 3.4+ as soon as possible
  • Python 3.0 - December 3, 2008
  • Python 3.1 - June 27, 2009
  • Python 3.2 - February 20, 2011
  • Python 3.3 - September 29, 2012
  • Python 3.4 - March 16, 2014
  • Python 3.5 - September 13, 2015

最新参考:https://www.python.org/downloads/release


二、Python的前景

最新的TIOBE( https://www.tiobe.com/tiobe-index/ )排行榜,Python赶超JAVA占据第二名了, Python崇尚优美、清晰、简单,是一个优秀并广泛使用的语言。

我们看看17年Python的排名:


由上图17年预测可见,Python整体呈上升趋势,反映出Python应用越来越广泛并且也逐渐得到大家的认知和认可,影响度也越来越大,在国内Python开发招聘的岗位也越来越多,我们来看看2017年100offer统计情况:

从上图我们可以看出Python的人均面邀数为6,整体年薪在34w左右,在职位招聘排行榜前十名,应该还算不错的表现哦。


三、Python的应用领域

Python可以应用于众多领域,如:数据分析、组件集成、网络服务、图像处理、数值计算和科学计算等众多领域。


目前业内几乎所有大中型互联网企业都在使用Python,如:Youtube、Dropbox、BT、Quora(中国知乎)、豆瓣、知乎、Google、Yahoo!、Facebook、NASA、阿里、百度、腾讯、汽车之家、美团等。


目前Python主要的应用领域

  • 云计算: 在云计算领域Python可谓有一席之地, 典型应用OpenStack这个大体量的开源云计算产品就是居于Python开发的。


  • WEB开发: 已有众多大型网站均为Python开发,Youtube, Dropbox, 豆瓣, 知乎等…., Python也有许多Web开发框架,典型WEB框架有Django、Pylons,还有Tornado、Bottle、Flask等。


  • 系统运维: 从国内的趋势来看,掌握一门编程语言已经成为了必然的结果,Python在国内已经成为了首选,不管是做自动化运维还是业务运维现在Python在运维领域已经应用极广。


  • 金融:量化交易,金融分析,在金融工程领域,Python不但在用,且用的最多,而且重要性逐年提高。原因:作为动态语言的Python,语言结构清晰简单,库丰富,成熟稳定,科学计算和统计分析都很牛逼,生产效率远远高于c,c++,java,尤其擅长策略回测


  • 图形GUI: PyQT, WxPython, TkInter, PySide等在图形用户接口领域都有广泛被应用。


哪些公司在用Python

  • 谷歌:Google App Engine 、code.google.com 、Google earth 、谷歌爬虫、Google广告等项目都在大量使用Python开发。


  • CIA: 美国中情局网站就是用Python开发的。


  • NASA: 美国航天局(NASA)大量使用Python进行数据分析和运算。


  • YouTube:世界上最大的视频网站YouTube就是用Python开发的。


  • Dropbox:美国最大的在线云存储网站,全部用Python实现,每天网站处理10亿个文件的上传和下载。


  • Instagram:美国最大的图片分享社交网站,每天超过3千万张照片被分享,全部用python开发。


  • Facebook:大量的基础库均通过Python实现的


  • Redhat: 世界上最流行的Linux发行版本中的yum包管理工具就是用python开发的


  • 豆瓣: 公司几乎所有的业务均是通过Python开发完成的。


  • 知乎: 国内最大的问答社区,通过Python开发(国外Quora)


  • 春雨医生:国内知名的在线医疗网站是用Python开发的


除上面之外,还有搜狐、金山、腾讯、盛大、网易、百度、阿里、淘宝 、土豆、新浪、果壳等公司都在使用Python完成各种各样的任务, 互联网公司广泛使用Python来做的事一般有:自动化运维、自动化测试、大数据分析、爬虫、Web 等


为什么是Python而不是其他语言呢?

C 和 Python、Java、C#等

C语言: 代码编译得到 机器码 ,机器码在处理器上直接执行,每一条指令控制CPU工作


其他语言: 代码编译得到 字节码 ,虚拟机执行字节码并转换成机器码再后在处理器上执行


Python和C Python这门语言是由C开发而来 

对于使用:Python的类库齐全并且使用简洁,如果要实现同样的功能,Python 10行代码可以解决,C可能就需要100行甚至更多.
对于速度:Python的运行速度相较与C,绝逼是慢了


Python 和 Java、C#等

对于使用:Linux原装Python,其他语言没有;以上几门语言都有非常丰富的类库支持


对于速度:Python在速度上可能稍显逊色


Python和PHP相比

Python提供了丰富的数据结构,非常容易和c集成。相比较而言,php集中专注在web上。 php大多只提供了系统api的简单封装,但是python标准包却直接提供了很多实用的工具。python的适用性更为广泛,php在web更加专业,php的简单数据类型,完全是为web量身定做。


所以,Python和其他语言没有什么本质区别,其他区别在于:擅长某领域、人才丰富、先入为主。语言是死的,每个语言的诞生都有它的道理,所以选择你喜欢的,开心的玩起来。

收起阅读 »

yum和apt-get命令对比

说明 Redhat系 Debian系 更新缓存 yum makecache apt-get update 更新包 yum update apt-get upgrade 检索包 yum search apt-cache search 检索包内文件 yum pro...
继续阅读 »






















































说明 Redhat Debian
更新缓存 yum makecache apt-get update
更新包 yum update apt-get upgrade
检索包 yum search apt-cache search
检索包内文件 yum provides apt-file search
安装指定的包 yum install apt-get install
删除指定的包 yum remove apt-get remove
显示指定包的信息 yum info apt-cache show
显示包所在组的一览 yum grouplist -
显示指定包所在组的信息 yum groupinfo -
安装指定的包组 yum groupinstall -
删除指定的包组 yum groupremove -
参考库的设定文件 /etc/yum.repos.d/* /etc/apt/sources.list
安装完的包的列表 rpm -qa dpkg-query -l
显示安装完的指定包的信息 rpm -qi apt-cache show
安装完的指定包内的文件列表 rpm -ql dpkg-query -L
安装完的包的信赖包的列表 rpm -qR apt-cache depends
安装完的文件信赖的包 rpm -qf dpkg -S
收起阅读 »

什么是CICD

传统的应用发布模式如果你经历体验过传统的应用发布,你可能就会觉得CICD有足够吸引你的地方,反之亦然。一般一个研发体系中都会存在多个角色:开发、测试、运维。当时我们的应用发布模式可以能是这样的: 开发团队在开发环境中完成软件开发,单元测试,测试通过,提交到代码...
继续阅读 »

传统的应用发布模式


如果你经历体验过传统的应用发布,你可能就会觉得CICD有足够吸引你的地方,反之亦然。一般一个研发体系中都会存在多个角色:开发、测试、运维。当时我们的应用发布模式可以能是这样的:

  • 开发团队在开发环境中完成软件开发,单元测试,测试通过,提交到代码版本管理库;
  • 开发同学通知运维同学项目可以发布了,然后运维同学下载代码进行打包和构建,生成应用制品;
  • 运维同学使用部署脚本将生成的制品部署到测试环境,并提示测试同学可以进行产品的测试;
  • 测试同学开始进行手动、自动化测试,测试完成后提醒运维同学可以进行预生产环境部署;
  • 运维同学开始进行预生产环境部署,然后测试同学进行测试,测试完成后,开始部署生产环境。

当然我描述的可能只是其中的一部分,手动操作很多、出现的问题很多。上面看似很流畅的过程,其实每次构建或发布都可能会出现问题。未对每次提交验证、构建环境不一致:开发人员本地测试成功后提交代码,运维同学下载代码进行编译却出现了错误。


存在的问题:


  1. 错误发现不及时: 很多错误在项目的早期可能就存在,到最后集成的时候才发现问题;
  2. 人工低级错误发生: 产品和服务交付中的关键活动全都需要手动操作;
  3. 团队工作效率低: 需要等待他人的工作完成后才能进行自己的工作;
  4. 开发运维对立: 开发人员想要快速更新,运维人员追求稳定,各自的针对的方向不同。

经过上述问题我们需要作出改变,如何改变?


什么是CICD


软件开发的连续方法基于自动执行脚本,以最大程度地减少在开发应用程序时引入错误的机会。从开发新代码到部署新代码,他们几乎不需要人工干预,甚至根本不需要干预。

它涉及到在每次小的迭代中就不断地构建,测试和部署代码更改,从而减少了基于错误或失败的先前版本开发新代码的机会。


此方法有三种主要方法,每种方法都将根据最适合您的策略的方式进行应用。


持续集成 CI(Continuous Integration)


在传统软件开发过程中,集成通常发生在每个人都完成了各自的工作之后。在项目尾声阶段,通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式,让构建、测试和集成代码更经常反复地发生。

开发人员通常使用一种叫做CI Server的工具来做构建和集成。持续集成要求史蒂夫和安妮能够自测代码。分别测试各自代码来保证它能够正常工作,这些测试通常被称为单元测试(Unit tests)。


代码集成以后,当所有的单元测试通过,史蒂夫和安妮就得到了一个绿色构建(Green Build)。这表明他们已经成功地集成在一起,代码正按照测试预期地在工作。然而,尽管集成代码能够成功地一起工作了,它仍未为生产做好准备,因为它没有在类似生产的环境中测试和工作。


CI是需要对开发人员每次的代码提交进行构建测试验证。确定每次提交的代码都是可以正常编译测试通过的。在没有持续集成服务器的时候,我们可以写一个程序来监听版本控制系统的状态,当出现了push动作则触发相应的脚本运行编译构建等步骤。现在有了专业的持续集成服务器后,我们借助持续集成服务器来实现版本控制系统中代码提交触发构建测试等验证步骤。


持续合并开发人员正在开发编写的所有代码的一种做法。通常一天内进行多次合并和提交代码,从存储库或生产环境中进行构建和自动化测试,以确保没有集成问题并及早发现任何问题。


开发人员提交代码的时候一般先在本地测试验证,只要开发人员提交代码到版本控制系统就会触发一条提交流水线,对本次提交进行验证。


持续交付 CD (Continuous Delivery)


Continuous Delivery (CD) 持续交付是持续集成的延伸,将集成后的代码部署到类生产环境,确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题,可以继续手工部署到生产环境中。

持续交付CD:是基于持续集成的基础上,将集成后的代码自动化的发布到各个环境中测试(DEV TEST UAT STAG),确定可以发布生产版本。这里我们可以借用制品库实现制品的管理,根据环境类型创建对应的制品库。一次构建,到处运行


  • 开发环境发布:我们可以将开发环境产出的制品部署进行测试,没有问题后上传到测试环境的制品库中。
  • 测试环境发布:此时通知测试人员可以进行测试环境发布测试,获取测试环境制品库中的制品,发布到测试环境验证。验证通过将制品上传到预生产环境制品库。
  • 预生产环境发布:获取预生产环境制品,进行部署测试。测试成功后可以将制品上传到生产库中。
  • 手动部署生产环境。

持续交付是超越持续集成的一步。不仅会在推送到代码库的每次代码更改时都进行构建和测试,而且,作为附加步骤,即使部署是手动触发的,它也可以连续部署。此方法可确保自动检查代码,但需要人工干预才能从策略上手动触发更改的部署。


持续部署 CD(Continuous Deploy)


如果真的想获得持续交付的好处,应该尽早部署到生产环境,以确保可以小批次发布,在发生问题时可以轻松排除故障。于是有了持续部署。

通常可以通过将更改自动推送到发布系统来随时将软件发布到生产环境中。持续部署 会更进一步,并自动将更改推送到生产中。类似于持续交付,持续部署也是超越持续集成的进一步。不同之处在于,您无需将其手动部署,而是将其设置为自动部署。部署您的应用程序完全不需要人工干预。


持续部署CD:是基于持续交付的基础上,将在各个环境经过测试的应用自动化部署到生产环境。其实各个环境的发布过程都是一样的。应用发布到生产环境后,我们需要对应用进行健康检查、添加应用的监控项、 应用日志管理。


我们通常将这个在不同环境发布和测试的过程叫做部署流水线, 持续部署是在持续交付的基础上,把部署到生产环境的过程自动化。


参考:



https://blog.csdn.net/weixin_40046357/article/details/107478696


http://www.idevops.site/gitlabci/chapter01/01/


https://www.jianshu.com/p/654505d42180


收起阅读 »

最全医疗细分赛道龙头

今天周末,股大夫一直满仓,最近账户增值不错,我敢于满仓持股不动主要得益于我对医疗的三大逻辑思考:人口老龄化,这个话题前面我已经表格说明过,最近七普人口调查数据大家应该也看了。国产替代,我之前也专题研说过,未来国产替代将是大势所趋,无法阻挡的历史洪流。刚需,医疗...
继续阅读 »
今天周末,股大夫一直满仓,最近账户增值不错,我敢于满仓持股不动主要得益于我对医疗的三大逻辑思考:人口老龄化,这个话题前面我已经表格说明过,最近七普人口调查数据大家应该也看了。国产替代,我之前也专题研说过,未来国产替代将是大势所趋,无法阻挡的历史洪流。刚需,医疗作为一种特殊的消费品,中国人口数量仍然世界第一,居民人均可支配收入不断提高,这也是很自然的大趋势客观存在,无法改变。

今天花时间总结下医疗各赛道龙头公司,每个公司的产品都是自己独特的护城河,或者有的公司有自己的祖传秘方,我们投资的目标就是找寻市场最牛的,最有需求的公司,今天我列举出来,每个人的理解不同,估计还不是很全面。

恒瑞医药:肿瘤创新药龙头,医药总龙头

爱尔眼科:眼科医疗服务龙头

迈瑞医疗:医疗器械总龙头

药明康德:医药CXO龙头

长春高新:生长激素龙头


片仔癀:中药龙头

美年健康:体检医疗服务龙头

云南白药:传统中医药龙头

复星医药:创新药龙头老二,医药综合龙头

乐普医疗:心脏支架系统龙头


新和成:维生素龙头

华兰生物:血液制品龙头

智飞生物:疫苗代理销售龙头

人福医药:麻醉药龙头

科伦药业:大输液龙头


康泰生物:乙肝、肺炎疫苗龙头

我武生物:脱敏药龙头

鱼跃医疗:家用医疗器械龙头

健帆生物:血液灌流器械龙头

健友股份:肝素原料药龙头


华大基因:基因检测龙头

汤臣倍健:保健品龙头

欧普康视:角膜塑形镜龙头

三诺生物:血糖监测仪龙头

安图生物:化学发光试剂龙头


南微医学:微创手术器械龙头

大博医疗:骨科龙头

透景生命:体外试剂诊断龙头

通化东宝:糖尿病药龙头之一

甘李药业:糖尿病药龙头之一


山大华特:新生儿补充剂龙头

司太立:    造影剂龙头

戴维医疗:新生儿医疗器械龙头

沃森生物:肺炎疫苗和HPV疫苗龙头

凯利泰:椎体成形微创介入手术、骨科植入、骨科手术器械龙头。


三友医疗:脊椎类植入耗材、创伤类植入耗材龙头。

楚天科技:医药装备龙头。

华海药业:特色原料药龙头。全球最大的普利类和沙坦类药物提供商。

康美药业:国内中药饮品龙头。

卫宁健康:医疗信息龙头。


英科医疗:专精医用手套世界级龙头。

康龙化成:国内第二、全球第三的临床前CRO企业,次于药明康德。

昭衍新药:临床前CRO安全性评价龙头。

凯莱英:小分子化学制药CDMO龙头

药石科技:药物分子砌块领域CRO龙头


泰格医药:专注定位CRO这个细分市场并成为临床CRO行业龙头

通策医疗:国内口腔医疗龙头,从医生+口碑两个方面加深自己的护城河。

国瓷材料:全资子公司爱尔创在国内高端陶瓷牙用纳米氧化锆市占率第一。

爱美客:注射用玻尿酸龙头,聚焦于医美终端产品。公司研发能力很强,多款产品属于国内首款。

华熙生物:玻尿酸原料龙头,是世界最大的透明质酸生产及销售企业。全产业链布局,在医美和化妆品赛道持续发力。


金域医学:国内第三方医学检验龙头企业,行业核心在于数据积累,数据库越大,检验效率、准确率越高。

万孚生物:即时检测龙头,在POCT领域惟精惟一。

艾德生物:聚焦肿瘤检测。

大参林:国内连锁药店的龙头之一,四大药房中毛利率净利润率排名第一,盈利能力较强,稳扎稳打型。

益丰药房:国内连锁药店的龙头之一。


医疗行业是非常复杂的行业,很多公司都具备自己独特的立身之本,很多小公司靠一两个产品都能稳定于市场之中长期活下去,跟随医疗的上面三大逻辑不断壮大。各位朋友,今天的文章,建议大家收藏,有个大体了解就好。

分享阅读原文: https://henduan.com/Flkgz 

收起阅读 »

敏捷为什么要使用Scrum而不是瀑布?

Scrum方法需要改变传统方法的思维方式。中心焦点已经从瀑布方法的范围转变为在Scrum中实现最大的商业价值。 在瀑布中,改变成本和进度以确保达到预期的范围,在Scrum中,可以改变质量和约束以实现获得最大商业价值的主要目标。瀑布模型适用于有序和可预测的项目,...
继续阅读 »

Scrum方法需要改变传统方法的思维方式。中心焦点已经从瀑布方法的范围转变为在Scrum中实现最大的商业价值。


在瀑布中,改变成本和进度以确保达到预期的范围,在Scrum中,可以改变质量和约束以实现获得最大商业价值的主要目标。

瀑布模型适用于有序和可预测的项目,其中所有要求都明确定义并且可以准确估计,并且在大多数行业中,此类项目正在减少。客户需求的变化导致企业适应和改变其交付方式的压力增大。

Scrum方法在当前市场中更为成功,其特点是不可预测性和波动性。Scrum方法基于inspect-adapt循环,而不是Waterfall方法的命令和控制结构。


Scrum项目以迭代方式完成,其中首先完成具有最高业务价值的功能。各个跨职能团队在Sprint中并行工作,以便在每个Sprint结束时提供潜在的可交付解决方案。


因为每次迭代都会产生可交付的解决方案(这是整个产品的一部分),所以团队必须实现可衡量的目标。这可确保团队正在进行,项目将按时完成。传统方法没有提供这种及时的检查,因此导致团队可能会下班并最终完成大量工作。


当客户定期与团队互动时,定期审查完成的工作; 因此,可以确保进度符合客户的要求。然而,在瀑布中没有这样的交互,因为工作是在筒仓中进行的,并且在项目结束之前没有可用的功能。


在复杂的项目中,客户不清楚他们在最终产品中需要什么,并且功能需求不断变化,迭代模型可以更灵活地确保在项目完成之前可以包含这些更改。


但是,当完成具有明确定义的功能的简单项目,并且当团队具有完成此类项目的先前经验(因此,估计将是准确的)时,瀑布方法可以是成功的。


敏捷 Vs 瀑布

下面是一个表格,可以更好地了解Scrum和瀑布的差异。

敏捷还是瀑布?

Standish Group的最新报告涵盖了他们在2013年至2017年期间研究的项目。在这段时间内,敏捷和瀑布的成功,挑战和失败的整体突破如下所示,敏捷项目成功的可能性大约是后者的2倍,失败的可能性降低1/3

来源:vitalitychicago.com - 比较瀑布和敏捷项目成功率


分享阅读: https://henduan.com/Aynya

收起阅读 »

cmake编译程序设置动态链接库加载路径

编译运行的程序需要链接到程序所在路径下的某些个动态库,为方便移植,必须设置链接库的相对路径,比如./lib等等。默认在Linux系统下动态库的搜寻路径如下: 使用选项-Wl,-rpath在编译时指定;通过配置LD_LIBRARY_PATH来指定;在/lib和/...
继续阅读 »

编译运行的程序需要链接到程序所在路径下的某些个动态库,为方便移植,必须设置链接库的相对路径,比如./lib等等。默认在Linux系统下动态库的搜寻路径如下:


  1. 使用选项-Wl,-rpath在编译时指定;
  2. 通过配置LD_LIBRARY_PATH来指定;
  3. /lib/usr/lib中查找;

其中第一个在gcc编译选项中添加:-Wl,rpath=xxx会将rpath路径写入到程序中保存起来。


为了方便移植运行一些编译安装的应用程序,在编译的时候需要设置链接库读取的相对路径目录, 比如../lib 或者./lib


默认在Linux系统下动态库的搜寻路径如下:


  1. 使用选项-Wl,-rpath在编译时指定rpath;
  2. 通过配置LD_LIBRARY_PATH来指定,运行加载;
  3. /lib/usr/lib等系统默认动态库路径中查找。

其中第一个在gcc编译选项中添加:-Wl,rpath=xxx会将rpath路径写入到程序中保存起来。
以下两种方式都可以用来配置rpath路径。

1、使用gcc编译选项:


add_definitions(-std=c++11)
SET(CMAKE_CXX_FLAGS_DEBUG "$ENV{CXXFLAGS} -O0 -Wall -g -ggdb -Wl,-rpath=./:./lib") #-Wl,-rpath=./
SET(CMAKE_CXX_FLAGS_RELEASE "$ENV{CXXFLAGS} -O3 -Wl,-rpath=./:./lib") #-Wall

2、使用cmake配置


set(CMAKE_SKIP_BUILD_RPATH FALSE)
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(CMAKE_INSTALL_RPATH "./lib")

或者


SET(CMAKE_SKIP_BUILD_RPATH FALSE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib:$ORIGIN/lib")
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

其中RPATH可以使用"./lib""./"配置,有可以使用"$ORIGIN/lib""\${ORIGIN}/lib",这里必须加上\符号,否则无法识别。


还可以同时定义多个RPATH,比如:"$ORIGIN:$ORIGIN/lib",中间使用:分割。


参考:https://blog.csdn.net/wh8_2011/article/details/79519293
CMAKE和RPATH:https://blog.csdn.net/zhangzq86/article/details/80718559
CMAKE中RPATH的用法:https://blog.csdn.net/z296671124/article/details/86699720
Linux C编程使用相对路径加载动态库: https://blog.csdn.net/dreamcs/article/details/52138229

收起阅读 »