MySQL的三种复制模式

MySQL支持的三种复制模式分别为: asynchronous 异步复制fully synchronous 全同步复制semi synchronous 半同步复制异步复制 (asynchronous replication)原理:在异步复制中,master写数...
继续阅读 »

MySQL支持的三种复制模式分别为:


  1. asynchronous 异步复制
  2. fully synchronous 全同步复制
  3. semi synchronous 半同步复制

异步复制 (asynchronous replication)

原理:在异步复制中,master写数据到binlog且sync,slave request binlog后写入relay-log并flush disk
优点:复制的性能最好
缺点: master挂掉后,slave可能会丢失事务
代表:MySQL原生的复制

全同步复制 (fully synchronous replication)

原理:在全同步复制中,master写数据到binlog且sync,所有slave request binlog后写入relay-log并flush disk,并且回放完日志且commit
优点:数据不会丢失
缺点:会阻塞master session,性能太差,非常依赖网络
代表:MySQL Cluster

半同步复制 (semi synchronous replication)

1. 普通的半同步复制

原理: 在半同步复制中,master写数据到binlog且sync,且commit,然后一直等待ACK。当至少一个slave request bilog后写入到relay-log并flush disk,就返回ack(不需要回放完日志)
优点:会有数据丢失风险(低)
缺点:会阻塞master session,性能差,非常依赖网络,
代表:after commit, 原生的半同步



重点:由于master是在三段提交的最后commit阶段完成后才等待,所以master的其他session是可以看到这个提交事务的,所以这时候master上的数据和slave不一致,master crash后,slave数据丢失



2. 增强版的半同步复制(lossless replication)

原理: 在半同步复制中,master写数据到binlog且sync,然后一直等待ACK. 当至少一个slave request bilog后写入到relay-log并flush disk,就返回ack(不需要回放完日志)
优点:数据零丢失(前提是让其一直是lossless replication),性能好
缺点:会阻塞master session,非常依赖网络
代表:after sync, 原生的半同步



重点:由于master是在三段提交的第二阶段sync binlog完成后才等待, 所以master的其他session是看不见这个提交事务的,所以这时候master上的数据和slave一致,master crash后,slave没有丢失数据



重要参数:
































参数 评论 默认值 推荐值 是否动态
rpl_semi_sync_master_wait_for_slave_count 至少有N个slave接收到日志 1 1 dynamic
rpl_semi_sync_master_wait_point 等待的point AFTER_SYNC AFTER_SYNC dynamic
rpl_semi_sync_master_timeout 切换复制的timeout 1000(10s) 1000 (1s) dynamic
rpl_semi_sync_master_enabled 是否开启半同步 OFF ON dynamic
rpl_semi_sync_slave_enabled 是否开启半同步 OFF ON dynamic

如何开启lossless replication:


########semi sync replication settings########
plugin_dir=/usr/local/mysql/lib/plugin
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
loose_rpl_semi_sync_master_enabled = 1
loose_rpl_semi_sync_slave_enabled = 1
loose_rpl_semi_sync_master_timeout = 1000

实践是检验真理的唯一标准

如何检验上述after_syncafter_commit, 如何检验上述原理的正确性。


InnoDB commit: 三阶段提交过程
A阶段: wite prepare log 写入Xid
B阶段: write binlog
C阶段: write commit log

测试点:master上当一个事务Waiting for semi-sync ACK from slave的时候,后来的事务是在A,B,C哪个阶段卡住呢?


0,RC模式

1. semi-sync C阶段等待

假设设置time-out=100000s,当事务一提交了一个大事务,在write commit log(C阶段)时候等待,
那么第二个事务在敲commit命令的时候,是卡在哪个阶段呢?是卡在 wite prepare log(A阶段)?还是write binlog(B阶段)?还是write commit log(C阶段)

测试:semi-sync vs loss-less semi-sync

【semi-sync】 C阶段等待
0, 开启事务1,然后在slave上执行stop slave,制造timeout的情况,让其阻塞。(Waiting for semi-sync ACK from slave)
1,在开启一个事务2,事务2插入一条特殊记录(XXXXX)。 (Waiting for semi-sync ACK from slave)
2,在开启一个事务3。
2.1,测试案例:这个时候,kill -9 mysqld,造成人为的mysql crash
3,假设卡在A阶段,那么事务3,肯定是看不到事务1,2写入的记录(XXXXX),且重启mysql后,事务2不会提交。
4,假设卡在C阶段,那么事务3,肯定是可以看见事务1,2写入的记录(XXXXX)。

经过测试:
1,是卡在C阶段,也就是说事务3是可以看见事务1,事务2的。
2,MySQL crash重启后,事务1,事务2的dml都已经提交成功,说明不是卡在A阶段

【loss-less semi-sync】B阶段等待

0, 开启事务1,然后在slave上执行stop slave,制造timeout的情况,让其阻塞。(Waiting for semi-sync ACK from slave)
1,在开启一个事务2,事务2插入一条特殊记录(XXXXX)。(Waiting for semi-sync ACK from slave)
2,在开启一个事务3
3,假设卡在A阶段,那么事务3,肯定是看不到事务1,2写入的记录(XXXXX),且重启mysql后,事务2不会提交。。
4,假设卡在B阶段,那么事务3,肯定是可以看见事务1,2写入的记录(XXXXX),且重启mysql后,事务1,2都会提交。。
5, 假设卡在C阶段,那么事务3,肯定是可以看见事务3写入的记录(XXXXX)。

经过测试:
1,是卡在B阶段,也就是说事务3,既看不见事务1的提交内容,也看不见事务2的提交内容,且重启mysql后,事务1,2都已经提交。。
2,MySQL crash重启后,事务1,事务2的dml都已经提交成功,说明不是卡在A阶段。

性能
semi-sync vs lossless semi-sync 的性能对比


根据以上的测试,可以得知,lossless只卡在B阶段,普通的semi-sync是卡在C阶段。
lossless的性能远远好于普通的semi-sync,即(after_sync 优于 after_commit)
因为lossless 卡在B阶段的时候可以堆积事务,可以在C阶段进行group commit。
普通的semi-sync,卡在C阶段,事务都已经commit了,并没有堆积的过程。


CAP理论:



一致性【C】
可用性【A】
分区容忍性【P】
理论:CAP 三者不可兼得,必须要牺牲一个


分区,是一定存在的,不是你想不要就不要的。所以,这里只剩下两种组合


CP 牺牲可用性



这种做法,就是保留强一致性,牺牲可用性
案例:可以将rpl_semi_sync_master_timeout设置成一个无限大的值,比如:100天,那么master和slave就强一致了,但是可用性就大打折扣


AP 牺牲一致性



这种做法,就是保留高可用性,牺牲一致性
案例:比如原生的异步复制就是这样咯。可以快速做到切换,但是一致性就没有保障


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

收起阅读 »

安可产业名录和国产化替代

关于国家信息化安全可靠工程随着信息安全问题日益突出,信息安全已上升至国家战略,自主可控,国产化替代已成为历史趋势。2019年开始我国信息、网安领域企业逐渐发力“安全可靠工程”,安全可靠工程战略意义在于证明我国具有安全可靠关键系统、关键应用及关键软硬件产品的研发...
继续阅读 »

关于国家信息化安全可靠工程

随着信息安全问题日益突出,信息安全已上升至国家战略,自主可控,国产化替代已成为历史趋势。2019年开始我国信息、网安领域企业逐渐发力“安全可靠工程”,安全可靠工程战略意义在于证明我国具有安全可靠关键系统、关键应用及关键软硬件产品的研发集成能力,能够初步实现对国外信息技术产品的全方位替代,在新的历史起点上构建起网络安全的“铜墙铁壁”。在党政办公及国家重要信息系统推进国产化替代,实现安全可靠、自主可控,保障国家信息安全的工作已全面展开。

安可名录

安全可靠技术和产业联盟主要成员单位包括联盟理事和联盟会员两大类。
其中联盟理事(19家)又分为:集成厂商(10家)、测试厂商(4家)、互联网厂商(3家)和高等院校(2家)四大类。

集成厂商(10家)包括:
华宇软件、神州航天软件、东华软件、东软集团、航天信息、浪潮软件集团、神州信息、太极股份、同方股份、中国软件

测试机构(4家)包括:
国家工业信息安全发展研究中心、中国电子技术标准化研究院、工业和信息化部电子第五研究所、中国电子信息产业发展研究院

互联网厂商(3家)包括:
阿里云、金山软件、华为技术

高等院校(2家)包括:
北京航空航天大学、北京理工大学

联盟会员则包含:芯片厂商(7家)、集成厂商(12家)、整机厂商(8家)、操作系统厂商(9家)、数据库厂商(6家)、中间件厂商(3家)、流版签厂商(7家)、外设固件厂商(3家)、安全厂商(6家)、网络厂商(3家)、互联网厂商(2家)、存储厂商(5家)和应用软件厂商(2家)共十二大类。


芯片厂商(7家)包括:
上海兆芯(X86)、东土军悦(交换机芯片、东土科技)、国科微(安防、存储、物联网芯片)、盛科网络(交换机芯片、中国电子、振华科技)、天津飞腾(ARM、中国长城、振华科技)、上海高性能集成电路设计中心(Alpha、申威)、龙芯中科(MIPS)

集成厂商(12家)包括:
百得科技、华胜天成、中软信息(中国软件)、广东省信息工程公司、中科软、南威软件、太极信息(太极股份)、烽火信息(烽火通信)、万达信息、中软系统(中国软件)、中科九洲、长城软件(中国软件)

整机厂商(8家)包括:
上海仪电智通、联想长风、华胜天成、长城科技(中国长城)、宝德网络、曙光信息(中科曙光)、百信信息、北京计算机技术及应用研究所(航天二院706所)

操作系统厂商(9家)包括:
中科方德(兆芯)、一铭软件、湖南麒麟信安(中国软件)、天津麒麟(中国软件)、思普投资(X86)、深之度、普华基础软件(中国电科)、航天国盛(航天科技)、中标软件(中国软件)

数据库厂商(6家)包括:
武汉达梦(中国软件)、神舟通用(航天科技)、人大金仓(太极股份)、南大通用、恒辉信达、瀚高基础软件

中间件厂商(3家)包括:
金蝶天燕中间件、东方通、中创软件

流版签厂商(7家)包括:
金格科技(电子签章)、方正国际软件(电子文档)、书生电子(启明星辰、安全文档)、数科网维(版式OFD)、航天福昕(文档OFD)、安证通(电子签章)、永中软件(office,办公软件)

外设固件厂商(3家)包括:
立思辰(文件管理)、中电科技(中国电子、BIOS等)、光电通信(传真机)

安全厂商(6家)包括:
星网锐捷(通信、安全)、中孚信息(安全保密)、安宁创新(邮件、消息)、中安网脉(密码、存储)、海泰方圆(密码、安全)、卫士通(密码、芯片、系统)

网络厂商(3家)包括:
紫光集团(从芯到云)、迈普通信(中国电子、网络设备)、仰联信通(交换机)

互联网厂商(2家)包括:
拓尔思、恒生电子

存储厂商(5家)包括:
滕凌科技(存储)、亚细亚智业(存储灾备)、同有科技(存储)、鲸鲨软件(存储)、鼎甲科技(中国电子、灾备)

应用软件厂商(2家)包括:
慧点科技(太极股份、管理软件)、华电园技术(办公自动化)

国产化软硬件资源

应用软件
监控国产数据库:达梦数据库、南大通用、人大金仓、神舟通用;

大数据产业下,对金融、电信、航空、制造等行业影响非常明显,其中国产数据库的作用被不断提升,担负起捍卫国家信息安全和技术的重任。
监控国产中间件:东方通、中创、金碟等中间件;

中间件一直是基础软硬件发展中不可缺少的一环,占居重要的地位。2018年以来本土中间件加快进入电信、金融、政府等行业,由东方通作为开拓者和领导者,中创、宝兰德等追其后。


操作系统
监控中标麒麟、银河麒麟、深度科技、红旗、中兴新支点等操作系统;

在持续的贸易战背景下,由于我们受到了外国的管控,操作系统等核心技术一度面临被限制使用的局面,于是国产操作系统被推到了风口浪尖。


硬件资源
监控国产服务器:华为、曙光、H3C、联想、浪潮;
国产服务器发展已将近二十载,二十载潮起潮落,国产服务器已涌现出联想、曙光、浪潮、华为等一批民族品牌。现在国产服务器已抢占更多服务器市场份额。

监控国产存储设备:华为、曙光、H3C、同有、浪潮;


网络资源
监控国产网络设备:华为、H3C、仰联、TP-LINK、ZTE中兴、锐捷等;

监控国产安全设备:天融信、启明星辰、绿盟、网康、趋势科技、山石网科等;
中国最核心的网络安全设备大部分依赖于进口,不具有强大的防御与反击能力,安全问题依然严峻。单靠技术无法抑制网络安全事件增长。核心网络设备国产化是解决这一问题最好的办法。



应用环境
兼容国产数据库:达梦数据库、南大通用、人大金仓、神舟通用;

兼容国产中间件:东方通、中创、金碟等中间件;


硬件环境


兼容国产服务器:华为、曙光、H3C、联想、浪潮;
兼容国产 CPU:龙芯、飞腾、海思、鲲鹏、展讯通信;

系统环境
兼容国产操作系统:中标麒麟、银河麒麟、深度科技、红旗、中兴新支点;

收起阅读 »

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 

收起阅读 »