Mar 192021
 

这两个工具,都可以对镜像进行定制,有什么区别呢?DIB功能比较强大,灵活,模块化,通过一个一个Element,来实现镜像的定制。Virt-customize,可以让你不需要写代码,搞定基本你想要的定制。

调整镜像的大小,对于DIB来说,就一个参数,对于Virt来说,还是比较折腾的。下面的操作,写成一个脚本。应该都不难了。把镜像的名字改成变量。基本就没问题的。

这次还是基于CentOS官方镜像,进行整个过程的记录。

准备

设置Repo

cd /etc/yum.repos.d/
mkdir backup
mv *.repo ./backup
curl -O http://mirrors.aliyun.com/repo/Centos-7.repo
curl -O http://mirrors.aliyun.com/repo/epel-7.repo
yum clean all
yum list

下载镜像

mkdir cloud-images
cd cloud-images
curl -O https://mirrors.ustc.edu.cn/centos-cloud/centos/7/images/CentOS-7-x86_64-GenericCloud-2003.qcow2

安装DIB和Virt套件

yum install centos-release-openstack-train
yum install diskimage-builder
yum install libguestfs-tools-c

使用libguestfs前,需要运行

export LIBGUESTFS_BACKEND=direct

检查镜像

确认镜像下载的CentOS版本,这点其实挺重要。

virt-inspector -a CentOS-7-x86_64-GenericCloud-1905.qcow2 > c.txt

输出的内容很多,重定向到文本,打开文本,你就基本可以看到下面的信息。你就可以确定你的镜像的版本。

<?xml version="1.0"?>
<operatingsystems>
  <operatingsystem>
    <root>/dev/sda1</root>
    <name>linux</name>
    <arch>x86_64</arch>
    <distro>centos</distro>
    <product_name>CentOS Linux release 7.6.1810 (Core) </product_name>
    <major_version>7</major_version>
    <minor_version>6</minor_version>
    <package_format>rpm</package_format>
    <package_management>yum</package_management>
    <hostname>localhost.localdomain</hostname>
    <osinfo>centos7.0</osinfo>
    <mountpoints>
      <mountpoint dev="/dev/sda1">/</mountpoint>
    </mountpoints>
    <filesystems>
      <filesystem dev="/dev/sda1">
        <type>xfs</type>
        <uuid>60d67439-baf0-4c8b-94a3-3f10a362e8fe</uuid>
      </filesystem>

DIB

先用DIB,对镜像做一下标准对动作。

设置环境

export DIB_LOCAL_IMAGE="/root/cloud-images/CentOS-7-x86_64-GenericCloud-2003.qcow2"
export DIB_DISTRIBUTION_MIRROR="https://mirrors.ustc.edu.cn/centos"
export DIB_RELEASE=7
export DIB_CLOUD_INIT_ALLOW_SSH_PWAUTH="yes"

有一点你需要注意的,不管你下载的是那个CetnOS 7的镜像,DIB都会将他升级到最新的版本的CentOS,当前是CentOS 7.9。

如果你就只需要一个固定版本的镜像,那么你下载这个版本的镜像回来。加上下面的参数。另外镜像里面的base repo,你也是需要小心处理。需要在repo里指定版本,这样才能避免yum update 或 yum upgrade 升级系统。

export DIB_AVOID_PACKAGES_UPDATE=1

这样就可以开始构建镜像

DIB_CLOUD_INIT_DATASOURCES="ConfigDrive, OpenStack"  disk-image-create -a amd64 -o CentOS_Linux_release_7.8.2003.qcow2  -x --image-size 40 vm base centos disable-selinux cloud-init cloud-init-datasources dhcp-all-interfaces growroot

如果不是OpenStack平台的虚拟机使用,那么这个地方需要注意,例如zstack平台,要注意差异,growroot,这个功能,Zstack平台是不用的。growroot,是创建的时候,调整根分区的大小,Flavor,定义的磁盘大小。

DIB_CLOUD_INIT_DATASOURCES="ConfigDrive, Ec2"  disk-image-create -a amd64 -o CentOS_Linux_release_7.8.2003.qcow2  -x --image-size 40 vm base centos disable-selinux cloud-init cloud-init-datasources dhcp-all-interfaces

都启用EC2和OpenStack,会导致虚拟机启动速度慢。

好好看看这篇文章:https://mp.weixin.qq.com/s/hDe7djVI0ZufkrApoMpWjw

默认虚拟机是才有bios启动,如果你希望改成UEFI启动,那么你可以加入下面参数就可以。

block-device-efi 

应该很快,20分钟,就可以完成第一个镜像的构建。后续再做修改,时间就会短很多。把镜像的大小调整成40G。

# qemu-img info CentOS_Linux_release_7.8.2003.qcow2 
image: CentOS_Linux_release_7.8.2003.qcow2
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 619M
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

# virt-filesystems -a CentOS_Linux_release_7.8.2003.qcow2 --long --parts --blkdevs -h
Name       Type       MBR  Size  Parent
/dev/sda1  partition  83   40G   /dev/sda
/dev/sda   device     -    40G   -

virt-customize

后续使用这个工具来完成我们对镜像的定制。

# root 密码
#virt-customize -a CentOS_Linux_release_7.8.2003.qcow2 --root-password password:chenshake 

# 设置时区

virt-customize -a CentOS_Linux_release_7.8.2003.qcow2 --timezone "Asia/Shanghai" 

#安装工具

virt-customize -a CentOS_Linux_release_7.8.2003.qcow2 --install [net-tools,wget,vim,unzip,qemu-guest-agent] 

#启动服务
virt-customize -a CentOS_Linux_release_7.8.2003.qcow2 --run-command 'systemctl enable qemu-guest-agent' 


#SSH服务
virt-sysprep -a CentOS_Linux_release_7.8.2003.qcow2 --edit '/etc/ssh/sshd_config:s/GSS/#GSS/'
virt-sysprep -a CentOS_Linux_release_7.8.2003.qcow2 --edit '/etc/ssh/sshd_config:s/#UseDNS yes/UseDNS no/'


#查看修改
virt-cat -a CentOS_Linux_release_7.8.2003.qcow2 /etc/ssh/sshd_config 


#上传优化脚本和运行

virt-customize -a CentOS_Linux_release_7.8.2003.qcow2 --upload /root/centos.sh:/root/centos.sh 
virt-customize -a CentOS_Linux_release_7.8.2003.qcow2 -chmod 755:/root/centos.sh 
virt-customize -a CentOS_Linux_release_7.8.2003.qcow2 --run '/root/centos.sh'

安装Zstack的agent

virt-customize -a CentOS_Linux_release_7.8.2003.qcow2 --firstboot-command '/bin/bash -c "$(curl -s -S http://169.254.169.254/vm-tools.sh)"'

脚本,逐步完善,目前已经可以满足我使用

!/bin/bash

#yum seting
cd /etc/yum.repos.d/
mkdir backup
mv *.repo ./backup
curl -O http://mirrors.aliyun.com/repo/Centos-7.repo
curl -O http://mirrors.aliyun.com/repo/epel-7.repo
yum clean all
cd -
# only for centos 7.6
#sed -i 's/$releasever/7.6.1810/g' /etc/yum.repos.d/Centos-7.repo
#vim
echo 'alias vi=vim' >> /etc/profile

脚本如果需要指定版本的centos镜像,我们需要考虑在脚本加入一行。

sed -i 's/$releasever/7.6.1810/g' /etc/yum.repos.d/Centos-7.repo

查看修改结果

# virt-ls -a CentOS_Linux_release_7.6.1810.qcow2 /etc/yum.repos.d/
Centos-7.repo
backup
epel-7.repo

上传镜像

启用pyton的http server,简单很多。通过ip地址,就可以访问。

python -m SimpleHTTPServer 8080

参考文章

  • https://cloud.tencent.com/developer/article/1452066
  • https://www.cyberciti.biz/faq/check-running-services-in-rhel-redhat-fedora-centoslinux/
  • https://www.tecmint.com/list-all-running-services-under-systemd-in-linux/
  • https://docs.openstack.org/diskimage-builder/latest/elements/base/README.html
Sep 192018
 

七年之痒这个词,大家经常说,不过起源,估计就不是谁都清楚。这是梦露的一部影片的名字,后来大家发现无论是企业,家庭,甚至政府,都在第七年时间段上面临各种麻烦。

OpenStack存在的问题,其实已经不是痒,就挠一下。基本上是已经无药可救。

逐步没落

我是2010年七月份,入职世纪互联云快线公司,开始搞云计算,公司是IDC,所以也就非常关注美国的IDC领头羊Rackspace,那时候在美国,Rackspace云计算是排名第二的,基本上是中国IDC的学习偶像。

非常巧合,我入职的时候,Rackspace和NASA推出OpenStack的项目。所以也就从哪个时候,一直跟着这个项目,一直走到2017年7月份,OpenStack的china Day,真的整整七年。见证了OpenStack整整7年,从零开始到巅峰,走向下坡路的过程。

现在已经离开OpenStack整整一年,回过头来看看,OpenStack到底有啥问题,遇到什么麻烦呢?屁股决定脑袋,我现在的屁股,应该也可以让我说的清楚一点。

经常有朋友问我未来OpenStack的发展趋势,我就用这张OpenStack邮件列表数量统计图来回答这个问题

邮件列表

图片来源:https://openstack.markmail.org/

现在邮件列表的活跃度,2016年到达巅峰,逐步在下降。基本上也是可以代表OpenStack的热度和发展状况的。这种下降的趋势,其实目前来看,还是很难逆转。

OpenStack社区真正干活,写代码的人,数量多少呢?估计已经不超过20人在全职干活。应该不到巅峰时刻的百分之十。

都不挣钱

其实我思考过,OpenStack存在的各种问题,不过归根结底,就是厂商根本就不挣钱。以前一个笑话,就是OpenStack最大的赢家是OpenStack基金会,每年入账1000万美金。

用开源软件来实现企业的盈利,这个无论是国外还是国内,都是非常有挑战性的问题。历史上,linux内核,就红帽实现的盈利。Hadoop的生态圈,至少有2家公司上市。那么对于OpenStack厂商来说,基本还是零。

国内的OpenStack市场,如果从2015年算起,经历了3年的发展和摸索,国内的OpenStack创业公司,基本都已经沦落为高级人力外包的公司。整个OpenStack的市场规模,也不足以支撑OpenStack创业公司的估值。这也导致从2016年,mirantis放弃Pure OpenStack厂商后,国内的厂商也都已经都布其后尘。

从现在看来,OpenStack创业公司上市套现的机会越来越少,也就导致OpenStack投资者也就没啥好日子。

很多朋友抱怨OpenStack很多不成熟的地方,不过说实话,就算把OpenStack做的完美,其实也是无法解决当前的困境,无法盈利。国内OpenStack厂商,最有想法,产品思维的两个厂商,是最先阵亡的,刻通和有云。

TC不作为

OpenStack基金会成立,专门有一个TC,技术委员会,负责OpenStack的技术方向,经过几年的发展,基本已经成为的养老院和老油条。

从2015搞的big tent,大帐篷项目,就是信心过于膨胀,项目从10个暴涨到50多个,不到1年的时间,问题就暴露出来。

谁都不能保证自己的决策不出错,但是出错,不做调整,就是作死。自从2016年Mirantis退出后,OpenStack大量项目出现没人玩的情况下,TC没做任何的事情。

一直到今天,OpenStack项目还是在不断增加,项目参与人手在不断减少。大量的僵尸项目,没人愿意站出来当丑人,直接把项目砍掉。

对比CNCF基金会,目前据说有500多个项目在排队等待孵化批准,批准进入孵化阶段门槛都是非常高,更别说毕业。

企业用户收益差

这点上,在我做容器,paas后,感受更加深刻。对于IaaS来说,他应该是可以给企业带来的效率的提升,资源的节省。不过这个如果和vmware比起来,就基本没啥优势。

国内的私有云市场,主要的客户群体是政府和国企。使用OpenStack的目的,并不是为了提高企业的竞争力,而是更多为了自主创新。

真正尝试使用OpenStack的企业,带来最大的好处,估计是技术人员的能力得到很大的提升。但是给企业的本身带来哪些改变呢?资源的节省,效率的提升,其实公司是没有感觉的。

企业目前使用资源的方式,还是资源创建者和使用者分开,无法真正实现自服务。运维负责创建虚拟机,开发者负责使用。

当用户无法在使用OpenStack中真正受益,那么放弃就是早晚的事情。

其实我当初走PaaS的时候,对PaaS能给企业带来什么好处,还是有疑问的。不过经过不到半年的使用,就能真正感受到Docker,PaaS平台给企业带来的好处,效率的提升,资源的节省,真的一个数量级别的提升。

K8S and PaaS

容器,Docker对OpenStack来说,其实还不能构成威胁。但是K8S,和PaaS的成熟,确实让OpenStack看不到未来。

很多用户受到IaaS,PaaS,SaaS三层架构的影响,认为PaaS就应该跑在IaaS上面,当年一位朋友,还专门去找新浪的SAE部门的老大,确认新浪的PaaS是跑在IaaS上,还是物理机器上。

其实根本不用纠结这个问题,PaaS和IaaS其实是一个松耦合的,PaaS完全可以直接跑在物理机器上。

我经常问容器厂商一个问题,到目前为止,哪些应用是无法跑在容器上的。必须要跑在VM上呢?其实真的没有,或者真的很少,很少。

Snap4

未来的企业数据中心,很可能是PaaS,K8S的天下。

OpenStack其实就算不犯任何的错误,在k8s出现后,其实都很难改变他的下坡路的趋势,无非是让下降平滑一点而已。

技术不是问题

最近好几篇文章,讨论OpenStack,说OpenStack技术复杂,有哪些短板。其实我 是看着OpenStack过来的。我可以说,目前阶段的OpenStack,技术上,还是过得去的。

几大核心项目,提供计算,存储,网络的功能,还是很稳定的。借助OpenStack容器化部署工具,kolla,不仅仅把OpenStack部署好,日志EFK都会部署的很好,目前kolla的社区普罗米修斯已经基本整合好了,再打磨一个版本,应该就用了。

长期用户纠结所谓升级的问题,也顺利解决,甚至可以实现某个组件的降级,例如neutron,你可以上以前版本,因为sdn兼容的原因。

我曾经很霸气回答友商提问,你的OpenStack和我的有啥区别问题。我说我给用户提供的OpenStack,让用户自己可以升级。

kolla即使做的那么优秀,我整整参与了2年,也无法挽救OpenStack的衰退。

Sep 102018
 

公有云的公司讨论的两大热门话题,我想第一是计费,第二应该就是应用商店。IaaS厂商都在想办法做一个应用商店,很可惜,基本都失败了。

当年我曾经也是一个产品经理,调研过各大厂商的应用商店。这里我就做一个总结

虚拟机年代

镜像

把应用放到镜像里,这是最容易想到的应用商店,虚拟机启动后,做的配置,技术上还是可以实现。AWS在2010年的时候,应该就是差不多这种情况。

AWS上有大量的应用的镜像,你启动后,就可以使用,看起来是很方便。不过其实也就是自己使用,很难满足复杂的场景,基本都是 all in one。而且软件的版本,是一个噩梦,一个版本一个镜像,真的受不了。

脚本

很多人自然就想到,base的镜像都是一样,在虚拟机启动的时候,运行相关的脚本,来部署相关的软件。cloud-init,基本就是这个用途。

在国外的网络速度的情况,基本不是问题。不过在国内,基本就没戏了。而且这种方式,还是单机版本,复杂点,就基本没办法。

开发模式

有专门针对开发者的应用商店,因为开发者,有不同版本的需求,就简单lamp为例,php版本,mysql的版本,apache的版本,排列组合太多了,如何解决这个问题呢?

把软件都放到虚拟机里,用户选择需要什么版本,就启动相应的组件。这方面,bitnami做的应该是最好的。这家公司,从2011年开始到现在,做了8年,也在不断改进。

Agent模式

为了应用商店能投入生产,能部署复杂的应用,支持灵活的定义,web和数据库,可以合并部署,也可以分开部署。那么就有人想到使用agent来实现。

rightscale,国外著名的云管厂商,就是通过植入一个agent,来对虚拟机进行应用的部署,类似配置管理工具,这样就非常灵活,基本可以实现软件的全生命周期的管理。

通过agent,你可以实现对应用进行监控。那么对于IaaS来说,如果所谓弹性扩展,只考虑cpu,内存,那么是很胡扯的。

Sep 102018
 

我也算是折腾了一年的OpenShift,OpenShift,就是Kubernetes的一个发行版,我的感觉,其实他们相似的地方还是很多,对我的改变并没有想象那么大。

下面总结一下他们的相同的地方

看不到对手

无论是OpenStack还是kubernetes,都是在重围中杀出来,一骑绝尘,根本看不到对手。

OpenStack干掉CloudStack,Eucalyptus,OpenNebula。

Kubernetes,干掉swam ,messos

都是压倒性的优势胜出。

区别就在于,OpenStack胜出以后,就迷失了方向,往自己不擅长的边缘计算,最终只能是一条不归路。

K8s胜出后,社区的想法还是很多,还保持1年4个版本的迭代。

一个是python最大的开源项目,一个是Go语言最大的开源项目。

基金会管理

OpenStack专门成立基金会管理,不过基金会不涉及技术方向,技术方向有专门的TC,技术委员会管理,当big tent,大帐篷策略后,TC的用途也就不大,而且TC混日子的人也多了。

OpenStack官方目前有60多个项目,其实大部分都是僵尸项目,停留在实验室阶段,根本就没生产使用案例。真的能用的项目,应该不超过15个。

k8s,其实也归属CNCF基金会。吸取OpenStack基金会的教训。对项目是加入,孵化,毕业,有了严格的流程。这个可以很好避免。

OpenStack技术设计的时候,很纠结规模优先还是功能优先。公有云为主,还是私有云为主。这个也导致一直无法明确。

我的理解,K8s的功能,逐步的玩企业级发展。无论是用k8s支持有状态的应用,还是让k8s管理vm,方向都非常明确。

架构

看完OpenStack的架构演变过程,再看k8s,感觉相似的地方很多的。

  • Nova==CRI-O
  • cinder=CSI
  • Neutron=CNI

计算,存储,网络,都搞一个,无论是OpenStack,还是k8s,基本都是一样的玩法,让厂商都能参与进来。

目前k8s上没有统一的身份认证,就没有keystone,k8s上,没提供镜像仓库,就没有glance。

事实上也是有一堆的应用,对于OpenStack组件

  • keystone+ldap=keycloak+ldap
  • glance=Quay or harbor

部署

大家都感觉OpenStack很复杂,如果和k8s比起来,其实算是简单的。k8s的部署,单单是一个双向的证书,都能让你折腾一个半天。

但是用户一般感觉k8s比较简单,一个原因,就是k8s自己做的部署管理工具比较成熟。目前红帽的OpenShift,已经采用全容器化的部署方案部署OpenShift,并且容器的管理,也是在Openshift上,真的比较完善。升级的问题,也就变得很简单。

OpenStack目前部署方案的方向也是容器化部署,不过还无法实现用k8s来管理,只能通过ansible来管理。

对我来说,

  • kolla-ansible 部署OpenStack
  • openshift-ansible 部署OpenShift

都是通过ansible来实现。

Feb 222018
 

春节前结果就出来了,上班第一天,整理一下。

会说中文。那么一共是12个项目,11位PTL。zhurong一个人担任两个项目Murano和Solum项目的PTL。

61个项目里,有一部分的基础项目,是属于OpenStack管理的项目,例如 Infrastructure,RefStack,和用户没太多直接关系。真正和用户有关的项目应该就30个左右。

1     * Barbican                             Ade Lee
2     * Blazar                                 Masahito Muroi                               
4     * Cinder                                 Jay Bryant                                 
5     * Cloudkitty                           Christophe Sauthier                        
6     * Congress                             Eric Kao
7     * Cyborg                                Zhipeng Huang                            
8     * Designate                            Graham Hayes                               
10     * Dragonflow                          Omer Anson                                 
11     * Ec2 Api                                Andrey Pavlov                              
12     * Freezer                                 Saad Zaher                                 
13     * Glance                                 Erno Kuvaja                             
14     * Heat                                     Rico Lin                                   
15     * Horizon                                Ivan Kolodyazhny                                 
16     * I18n                                     Frank Kloeker                              
17     * Infrastructure                      Clark Boylan                               
18     * Ironic                                    Julia Kreger                             
19     * Karbor                                  Ying Chen                          
20     * Keystone                              Lance Bragstad                             
21     * Kolla                                     Jeffery Zhang                         
22     * Kuryr                                    Daniel Mellado    
23     * Loci                                      Sam Yaple 
24     * Magnum                               Spyros Trigazis                            
25     * Manila                                   Tom Barron        
26     * Masakari                               Sampath Priyankara                 
27     * Mistral                                   Dougal Matthews                                
28     * Monasca                               Witold Bedyk                               
29     * Murano                                 Rong Zhu                          
30     * Neutron                                Miguel Lavelle                               
31     * Nova                                     Melanie Witt                             
32     * Octavia                                 Michael Johnson                            
33     * OpenStackAnsible               Jean-Philippe Evrard                       
34     * OpenStackClient                 Dean Troyer
35     * OpenStackSDK                     Monty Taylor                                
36     * OpenStack Charms              James Page                                 
37     * OpenStack Helm                  Matt McEuen
38     * Oslo                                      Ben Nemec                                      
39     * Packaging Rpm                    Javier Peña                      
40     * Puppet OpenStack               Mohammed Naser                             
41     * Quality Assurance                Ghanshyam Mann                            
42     * Rally                                      Andrey Kurilin                             
43     * RefStack                                Chris Hoge                                 
44     * Release Management            Sean McGinnis                              
45     * Requirements                        Matthew Thode                              
46     * Sahara                               Telles Mota Vidal Nobrega                  
47     * Searchlight                            Steve McLellan                             
48     * Senlin                                    XueFeng Liu                                
49     * Solum                                     Rong Zhu                                        
50     * Storlets                                  Kota Tsuyuzaki                             
51     * Swift                                       John Dickinson                             
52     * Tacker                                     Yong Sheng Gong                            
53     * Telemetry                               Julien Danjou                               
54     * Tricircle                                  Zhiyuan Cai                                
55     * Tripleo                                    Alex Schultz                               
56     * Trove                                      Zhao Chao                               
57     * Vitrage                                  Ifat Afek                                  
58     * Watcher                                 Alexander Chadin                           
59     * Winstackers                           Claudiu Belu                               
60     * Zaqar                                     Wang Hao                               
61     * Zun                                        Feng Shengqin                                

Feb 082018
 

从2010年到现在,OpenStack差不多走过了8年的历程。2017年,对OpenStack来说,其实算是令人难忘。

OpenStack作为全球最大的Python的开源项目,他所取得的成就,其实是任何一个开源项目都是不容易超越。不过任何一个开源的项目,都会有他的生命周期,上升的过程和走下坡路,OpenStack也是不会例外。

在K8S如日中天的时候,其实OpenStack未来可以讲的故事,空间越来越小。OpenStack走下坡路的过程,其实某种意义,也表明他的成熟,可以让大家像linux一样,使用OpenStack。

有一次和朋友聊天,说OpenStack厂商最近几年干啥?除了改改UI,好像真的啥也不干。

回顾

巅峰之作

如果说OpenStack的发展看中国,那么如果2年前,这肯定当笑话。不过到了2017年,真的不得不承认,OpenStack现在比美国还要热门。

2017年7月份,在北京举办OpenStack China day,我想这个应该是OpenStack在国内的最高峰的时刻。我听到我最爱听的评价就是:China Day上的现场Demo,超过OpenStack的峰会。这个时候,其实可以告诉大家,当时China Day上演示OpenStack升级和OpenStack故障的恢复,都是基于Kolla,和我的想法。

这也算是我的OpenStack的最后告别之作,有点悲壮,不过还是不得不承认,OpenStack已经在走下坡路。我是知道大会的实际参会人数的。

大帐篷模式

其实到了2017年,基金会也开始反思当初的所谓Big Tent模式。这个改变,给OpenStack带来什么?

对我来说,OpenStack项目从10多个,直接扩大30多个。不过最后真正活下来的项目,其实真的没几个。如果从我的角度,目前看到,经过3年的发展,真正能投入生产的,就只有kolla的这个OpenStack部署工具。

真正对OpenStack产生威胁的不是Docker,而是K8s。

目前OpenStack基金会,引入kata容器,不过也很难逃脱挂掉的命运。在红帽收购了CoreOS后,其实就真的没啥机会。

信心不足

自从2016年,Mirantis算是部分退出OpenStack,转向K8s。其实背景就是OpenStack无法支撑公司的估值和成长。这种影响,也直接影响到国内的OpenStack厂商。已经逐步没有所谓的pure OpenStack厂商。

基本上所有的OpenStack厂商,都要和用户交流K8s,不然就真的没法出门。OpenStack的基金会,也在考虑如何转型,包括搞出一个kata,改名 Open Infra。

如果从我角度,OpenStack其实有很多不足,计费,监控都远远没达到生产的需求。形同摆设。不过大家都没法顾及。

让OpenStack厂商去折腾K8s,搞所谓的Kata,基本都是死翘翘。

目前单纯的OpenStack,已经无法解决OpenStack创业公司的估值问题,都在寻找出路。

无法颠覆

当我们把OpenStack定义成公有云和私有云,就会发现他在公有云上无法和AWS PK,在私有云上,无法威胁到vmware。这基本就是老二打不过老大,把吃饭的家伙开源出来的故事。

OpenStack对开源产生了很大的贡献,至少大幅提高了Python程序员的地位。培养了大量的开源的人才。

不过在商业上,技术上,和Docker比起来,所带来的变化,真的不是颠覆性的。

市场乱象

国内的OpenStack 2B市场,基本都是靠销售和市场,年底,Gartner出来辟谣,没有搞过所谓的OpenStack厂商评选。

最近两年,国内的OpenStack公司,基本上都已经没在技术上有啥投入,也就导致非常没有追求。都在搞市场。忽悠用户。

两热一冷

随着大家对OpenStack熟悉,也就熟悉OpenStack的游戏规则。OpenStack社区是很民主。

  1. 独立董事
  2. TC,技术委员会成员
  3. PTL,项目负责人

PTL目前半年选一次,独立董事和TC都是一年选一次。其实无论国内还是国外,大家都比较积极参加独立董事和TC的选举。PTL最近两年,经常出现冷场,很多项目没人想当PTL。

简单点说,干活的,要承担责任的,没人想做。开开会议,指导江山的,大家都比较喜欢。

展望

其实如果展望2018年,国内的OpenStack发展,其实没那么悲观。因为OpenStack没有对手,尤其在国内的国产化的环境下,OpenStack也是唯一的选择,让各方比较容易达成共识。

China infra Day

OpenStack基金会会不会改名,这都是可能的。这是将要在2018年6月份在北京举办的大会,这也注定是一个风向标。

一个美国主导的开源项目,最后在中国繁荣发展,这个本来是我们最开始希望看到的,不过真正到来的时候,我们又感觉我们是否是冤大头,人,就是那么矛盾。

竞争对手

基金会,应该还是会搞出不少的项目,不过这些项目离生产还是很远。目前我也真没看出那个项目,会给用户带来眼前一亮的感觉。

留给OpenStack基金会的时间不多了。

CNCF基金会,其实类似OpenStack基金会,未来会是Openstack基金会的竞争对手。压力真的很大。如果OpenStack的白金会员出现空缺,那么就真的是一件很危险的事情。这也是大概率发生的事情。

其实你看一下就知道,这两个基金会成员高度重合。

Kolla

如果我写OpenStack文章,不涉及Kolla,是不太可能的事情。2018年,kolla-ansible,还是可以笑傲江湖,无人能匹敌。红帽都要使用kolla的镜像,来部署红帽的OpenStack。

对我有实际意义的事情,就是kolla-Kubernetes。因为OpenStack是足够复杂,如果OpenStack可以跑在Kubernetes上,那么其他的所谓有状态的应用,都可以放到Kubernetes上,那么对传统企业来说,Kubernetes就真的能体现出他的价值。

企业内部99%的应用都是有状态的,Kubernetes能不能支撑这些应用,其实就要靠kolla-Kubernetes证明。

华为

目前OpenStack国际上就是红帽,国内就靠华为来扛,哪个离场,都马上会制造很大的悲剧。当年Mirantis宣布部分退出OpenStack,导致很多OpenStack项目的PTL都失去工作,更别说Core。

华为在国内推OpenStack的公有云,这是一件十分凶险的事情,经常有朋友说我老黑华为。如果我夸华为,华为公有云就可以做好,我肯定无条件支持华为。

华为目前是投入2000人在OpenStack公有云业务上,什么概念,2000人一年的工资是多少?如果平均是50万,1年工资就10亿。

华为有钱,可以长期投入,我没疑问。不过如何应对未来的技术的变化,很可能出现的Kubernetes管理资源,而不是IaaS来管理资源呢?

我也只能祝华为好运,因为OpenStack真的靠你了。