使用nbd设备挂载镜像进行内容修改

Centos系列发行版默认没有编译nbd内核模块,需要手工编译后加载上才可以使用。在这一点上还是Debian/Ubuntu系列好用。

加载nbd模块方法:

1. 确认内核版本号,执行命令:uname -r
3.10.0-327.el7.x86_64
只支持上述内核版本,其他未验证

2. 拷贝nbd.ko到/lib/modules/3.10.0-327.el7.x86_64/kernel/drivers/block目录下,nbd.ko下载地址:nbd.ko.zip

3. 执行命令:depmod -a

4. 加载nbd模块:modprobe nbd

5. 确认nbd加载成功:ls /dev/nbd*可以看到nbd设备,lsmod|grep nbd可以看到内核模块

附1. 编译nbd模块方法:

参考https://www.ljjjustin.xyz/2016/12/07/compile-nbd-module-on-centos7文章中kernel-devel源码包下载链接已失效,kernel-devel源码包下载链接:wget ftp://ftp.icm.edu.pl/vol/rzm6/linux-slc/centos/7.1.1503/updates/Source/SPackages/kernel-3.10.0-327.el7.src.rpm

附2. 使用nbd设备挂载镜像分区方法:

 

2018-11-15更新

在Centos7.5上编译可能报错:
Makefile:901: "Cannot use CONFIG_STACK_VALIDATION, please install libelf-dev or elfutils-libelf-devel"
No rule to make target `tools/objtool/objtool'
可参考:https://blog.csdn.net/miaodichiyou/article/details/76050361

Neutron配额管理源码分析

本文基于Mitaka版本源码进行分析。

Neutron跟Nova的配额管理流程有一些不同,但设计思想都是类似的。

相关命令

相关配置项

默认配额是在neutron.conf中配置的,具体配置项如下,没有加入到配置项里面的,用default_quota配置项的值作为默认配额,需注意’track_quota_usage’的默认值为True。

其他配置项不用管,实际上neutron.conf中[quotas]段不需要进行配置,除非你想对network、subnet、port等资源设置不同的默认配额。

相关数据库表

quotas:保存租户各种资源(network、port等)配额限制信息

quotausages:保存租户各种资源的配额使用量信息

reservations:保存资源预留信息(预留过期时间),一般是操作过程中用到,操作结束后清理

resourcedeltas:同上,保存资源预留信息(预留资源量)

配额使用量查询

Mitaka版本没有提供,据说Pike版本提供了,http://www.cnblogs.com/sammyliu/p/7453548.html,但没有来及的分析源码。

也就是说没有API用来查询配额使用量,在做相关web或者对外API开发的时候就比较郁闷了,只能自己增加接口,直接查询quotausages表,或者直接在相关资源的表如ports中统计使用量。

配额管理流程

以network为例,其他资源管理流程基本完全相同。API请求转发流程可以参考:http://aspirer.wang/?p=690

资源注册

router中注册network的controller过程中会同步注册到配额管理模块,

–> neutron.api.v2.router.APIRouter:

–> neutron.quota.resource_registry.register_resource_by_name –> neutron.quota.resource_registry.ResourceRegistry#register_resource_by_name –> neutron.quota.resource_registry.ResourceRegistry#_create_resource_instance:

其中_tracked_resource_mappings属性的初始化流程是:

–> neutron.plugins.ml2.plugin.Ml2Plugin#__init__:

–> neutron.quota.resource_registry.tracked_resources:

–> neutron.quota.resource_registry.ResourceRegistry#set_tracked_resource:

数据库表内容变更回调注册

–> neutron.api.v2.router.APIRouter#__init__:

–> neutron.quota.resource_registry.register_resource_by_name –> neutron.quota.resource_registry.ResourceRegistry#register_resource_by_name –> neutron.quota.resource_registry.ResourceRegistry#register_resource –> neutron.quota.resource.TrackedResource#register_events:

–> neutron.quota.resource.TrackedResource#_db_event_handler:

 

创建

neutron.api.v2.base.Controller#create –> neutron.api.v2.base.Controller#_create:

–> neutron.db.quota.driver.DbQuotaDriver#make_reservation:

–> neutron.db.quota.api.create_reservation:

回到开始的地方–> neutron.api.v2.base.Controller#_create:创建network成功后,发送notify消息,并提交配额变更,

–> neutron.db.quota.driver.DbQuotaDriver#commit_reservation:

–> neutron.quota.resource_registry.set_resources_dirty:

–> neutron.quota.resource.TrackedResource#dirty&#mark_dirty:

从上面的代码可以看出,实际上提交变更只是清理了资源预留表记录,并修改quotausages表中相关resource和tenant记录的dirty字段,并没有修改in_use字段。

删除

neutron.api.v2.base.Controller#delete  –> neutron.api.v2.base.Controller#_delete:

这里也跟创建流程类似,没有修改in_use字段。

修改

update方法中也是调用set_resources_dirty方法,同删除流程。

查询

index方法调用到_items

–> neutron.api.v2.base.Controller#_items:

–> neutron.quota.resource_registry.resync_resource:

上面的res变量是一个neutron.quota.resource.TrackedResource对象,

–> neutron.quota.resource.TrackedResource#resync&_resync&_set_quota_usage:

–> neutron.db.quota.api.set_quota_usage:

也就是说真正修改quotausages表中in_use字段的操作是index,也就是列出网络等资源,对应的命令时neutron net-list或neutron xxx-list。

show方法没有涉及到quota操作。

OpenStack nova私有代码维护–一种外挂方案思路

修改OpenStack开源代码的套路

小bug或者简单功能

直接在launchpad上提bug或改进任务,之后提交代码关联到launchpad即可。

针对比较大的功能特性的正常套路:

1. 邮件或IRC提出需求,并与项目TL或相关核心开发人员讨论需求的合理性、必要性、普适性等问题
2. 初步确认后,提出正式blueprint,等待相关开发review
3. bp合入后,即可开始代码编写、提交等待review
4. 反复修改后,代码合入上游分支,开发完成

上述流程是完美状态,很多时候需求不等人,走完开源社区的这套流程,估计半年一年都过去了,甚至你的代码都很少有人关注,最终不了了之,没了下文。。。

私有代码产生背景

还有一些公司,保留私有代码的想法看起来挺有道理,是为了保持竞争力,把一些功能做好之后不贡献社区,自己的产品就比别人多了这个功能,这种情况不予置评,个人感觉是这些公司的领导太看得起自己的产品经理或者开发人员了。如果是因为这个理由,个人建议还是全部自研比较合适,不要采用开源了。

时间紧迫是一个比较常见的困难,另外常见的就是需求的普适性问题,具体到某个使用OpenStack的公司很多需求都是针对内部场景的(其实不止OpenStack,其他开源项目也有相同困境),或者针对某个外部客户的具体项目的,很难推到OpenStack社区。

乱改代码的问题非常多,除非你不打算继续跟进开源社区的新版本,否则后患无穷。

开源项目定制代码的可维护性是个普遍问题,目前我还没听说哪家公司有完美的解决方案,可能是我眼界不够宽吧。

有些需求场景是可以通过组合OpenStack已有功能来达到相同或类似目的,需求的差异性很大,能找到替代方案的毕竟是少数,而且很多时候产品经理或者领导层是不懂(或者不能忍受)OpenStack或者其他开源项目的设计思想的,就想按自己或者所在公司的意愿进行强行纠正,但又没有开源社区话语权(话语权通常掌握在少数超大公司手中,具体来说就是项目TL、core reviewer或者core developer),只能把这种需求强加给内部开发人员,因为大家(不光产品,开发自己或多或少都有)都有一种在我看来比较诡异的想法,你们OpenStack或其他开源项目的开发,如果只是简单的拿开源项目代码来用,公司给你们开这么些工资,你们连一行代码都不想写,公司又不指望你们给开源社区做贡献,那养你们有何用?开发的想法是,我只看代码有卵用?等哪天在这家公司干不下去了出去找工作,简历都没得写,必须得干点啥才行,于是乱改一通,美其名曰二次定制开发,实则给公司带来了很大的麻烦。当然公司的一些领导是不关心这种问题的,反正需求搞定了就行,产品有·亮点·就行,管他之后怎么玩,代码怎么维护,这些问题都是开发考虑的,搞的不好肯定是那帮开发没能力或者偷懒,不是我决策失误,我又不懂开发,之前改不改都是你们开发自己决定的,我只是提了个需求而已,又不知道你们乱改代码才能实现,现在搞成这个局面也不是我想要的啊!你们自己看着办吧,烂摊子你们开发自己收拾去,反正我还要继续提需求,你们还得按时保质保量的完成,至于改不改代码怎么改代码怎么维护怎么升级都是你们的事,反正我又不懂代码,出了问题别找我就行。

上述场景多见于中大型公司,小型公司没钱没人搞这些定制化开发,超大型公司要么有开源话语权,要么不跟开源玩,自己搞一套系统出来,想怎么改怎么改。

有些开发比较diao(或者定制开发搞多了就变diao了,毕竟踩的坑多了,知道深浅了),看到公司这么瞎折腾就跑路了,去超大公司搞私有项目或者去专门刷社区贡献的公司了,反正有实力,不受这种气(当然主要还是超大公司有钱赚,还能跟着里面的大牛学经验,增加见识扩展眼界)。开发拍拍屁股走人,留下的烂摊子还得有人收拾,有些公司估计也是为了变相撵人,走的人都是工资高(有没有实力不好说),养不起了,你自己走了正合适(这是我瞎猜的,不惮以最坏的打算来推测)。

大部分采用开源项目的公司,维护私有代码都是作茧自缚的下场(注意:这里单指长期跟进开源情况,维护独立分支不跟进上游不算),加法做到最后,发现加不下去了,或者加法变成了乘法,积累了几年的私有代码,每次升级要花几倍几十倍的人力去merge上游,但上游代码已经物是人非,99%的代码不能直接merge,工作量不亚于再次二次开发,甚至比重新开发还累(当初的需求、某些实现细节,当初提出需求的人、开发代码的人都可能已经走人了)想要还原当时的想法和功能,更是难上加难。

不过还好,很多公司的项目都具有时效性,今天改了,明天可能就不用了,丢了就丢了,只要当初的项目到手就行,公司本质还是赚钱。另外一些持久使用的,就比较麻烦,演变一定时间之后,就会考虑重构或自研,这也是一种应对方案,招人重写就好了,反正有钱任性,自研是解决开源项目私有代码问题的终极方案,可惜不是一般公司玩得起的。

nova外挂方案

言归正传,我们作为小公司,没时间没人力专门搞社区贡献,私有代码多多少少又都有一点,我们本身是极力避免的,一般的bug修好肯定推到社区,但一些项目定制化需求,不得不做,毕竟赚钱生存是第一要务。

比如nova中,我们开发了云主机在线升配功能,可以不停机增加CPU数量、内存大小、磁盘空间,方便用户做垂直扩容操作,由于在线扩容kvm还属于不十分稳定的操作,使用限制比较大,另外受制于物理机资源,不一定每台云主机都能执行,因此社区没有做这类功能,但我们的产品为了增加亮点功能,做了这个功能,就需要维护私有代码。

我们本来也是直接改nova代码的,涉及到两部分,一个是正常的升配功能操作,从api到compute,中间涉及到配额使用量检查、修改,云主机规格修改,调用libvirt接口进行升配操作等;另一部分是在创建云主机时,要在xml中预先配置好maxCPU、maxMemory,预留好CPU和内存插槽,并在镜像中配置好udev规则,在升配后可以自动online相关硬件设备。

其中操作部分可以考虑开发外挂程序来替代直接修改nova代码,但有很多细节问题需要考虑,这里主要是提供一种思路,具体到自己的代码是否具备可操作性,需要自行斟酌。配置maxCPU、maxMemory那部分,目前还没想到合适的外挂方案。

外挂方案描述:

首先写一个agent,跑在计算节点上负责跟libvirt打交道(其实也可以利用libvirt的tcp远程调用功能把agent和WSGI api服务放在一起),通过MQ(建议)或者直接监听端口提供WSGI服务(不建议),然后写一个WSGI服务跑在控制节点上负责提供api接口,通过MQ跟agent交互,参考nova那一套流程,agent直接访问nova库,在需要执行数据库操作时,不通过nova直接进行修改(其实也可以考虑通过MQ调用nova-conductor进行DB操作,但是不能确定nova-conductor有没有实现私有代码需要的数据库修改接口,如果有的话,是可以考虑的,没有的话就又涉及到增加私有代码问题了,所以还是直接操作数据库比较简单粗暴有效果)。

具体到在线升配功能,其他操作都无所谓,检查配额使用量、检查计算节点资源剩余量(并发资源占用问题也需要考虑,但本身在线升配就不能保证100%成功,所以也就暂时无视了),需要写入db的操作就是增加用户配额使用量,修改云主机规格,配额使用量可能不准,可以通过定期同步的配置来优化,利用nova的两个配置项,until_refresh和max_age。

这个外挂的想法很简单粗暴,目的也很直接,省的以后升级nova需要merge代码(如果数据库表结构改了,可能需要修改外挂执行的sql语句)。存在的漏洞也很多,最难处理的就是并发物理资源申请问题,在不修改nova代码的情况下,很难解决,修改了nova代码又违背了我们开发外挂的初衷,只能根据实际情况折中处理。

这里仅仅是提供一种思路,能不能用还得自己考虑确定。

私有云计费服务重构设计思路

需求

  • 计费时长(也叫计费账期)为1天,表示每天将用户资源费用入账一次(一般为每天凌晨统计前一天的费用),未到入账时长的暂不入账,等待下次账期或资源删除时入账
  • 使用时长不足一个账期的资源费用按实际使用时长计算(如账期为1天,云主机使用了半小时就删除了,按半小时计算费用)
  • 根据用户计费(user和project都要区分),费用情况包含总费用、单个资源费用、单个资源详单
  • 目前仅支持对云主机、云硬盘两种资源进行计费,并且支持用户对不同规格、类型的资源设置计费单价,按秒设置计费单价(单价按cpu个数、内存大小、磁盘类型和大小进行设置,用户设置单价时可以按小时设置,页面提示按秒计费的费用,后台转换为以秒为单位的单价用于计算实际费用)
  • 管理员可查询所有用户/租户账单,普通用户仅可查询当前用户/租户账单
  • 用户账期为1个月,每月初执行一次出账任务,当月账单属于未出账状态,之前的账单属于已出账状态,可按月/季度/半年/1年查询用户已出账月账单,并支持导出
  • 详单周期为1天,用户可按时间段(最短一天、最长一个月)查询费用详单,并支持导出

实现思路

基于当前已有的两个项目:yr-monitor-log和turtle,用户操作记录使用yr-monitor-log,计费服务整合到定时任务服务turtle中。

大致流程如下:

表结构概览

user_actions:与当前表结构保持一致,如有必要可做适当修改

bill_resource:

project
user
resource
date
start_time
end_time
resource_type
vcpu
mem
disk
flavor_type
租户或项目id 用户id 计费资源UUID:

云主机或云硬盘UUID

账期,一般为前一天日期:2017-10-27 云主机创建、修改规格、删除时间点,

或云硬盘创建、扩容、删除时间点,如没有创建操作则设置为前一天起始时间,如2017-10-27 00:00:00

同start_time,如果前一天没有删除操作,

则记录为前一天结束时间,如2017-10-27 23:59:59

计费资源类型:

云主机或云硬盘

vcpu规格 内存规格G 磁盘规格G 规格类型,比如容量型云硬盘,

或高性能cpu云主机,根据extra_specs确定

bill_overview:

project
user
month
cost
租户或项目id 用户id 月份:如2017-10 月度费用总和

注:上述表结构需要根据实际需要进行补充修改。

其他考虑

  • 主要是计费准确性相关问题,比如如果用户创建了云主机或云硬盘,创建操作被成功记录,之后删掉了,但删除记录丢失(MQ异常或yr-monitor-log、turtle、数据库服务异常等),怎么避免该云主机或云硬盘的费用一直累积?---需要考虑审计服务
  • 需要考虑费用记录保留时长,1年还是3年?还是更长?这个问题优先级不高,默认无限期保留吧,影响不大。
  • 如何支持特殊规格的单价设置?感觉应该是在yr-monitor-log从MQ接收到用户操作时,从消息payload中获取规格的详情(包含extra-specs或云硬盘类型),然后保存到user_actions表,之后计费服务直接存储备用,但不确定payload中是否有这些信息,如果没有,则需要yr-monitor-log从nova或者cinder数据库中根据资源uuid查询对应的规格再保存,具体细节需要再考虑
  • 服务异常导致前一天费用未入账,需要考虑如何解决(初步考虑了下,可以在审计服务中再次进行入账操作,并且将入账记录跟bill_resource表中的记录比较,如果还没有插入就补录一次,如果已经有了就忽略)
  • 计费服务所在节点异常,由其他节点接管计费服务(turtle已实现该功能),如果计费服务正在运行过程中节点发送故障,则接管后也无法继续完成前一天的入账,应该是会在第二天开始继续入账(其他节点会发现今天的入账任务执行时间点已经过去了),如果是在计费服务已经运行完之后才发生异常,则应该没有影响
  • 如果云主机或云硬盘前一天有一次扩容操作,则需要在bill_resource表中插入两个记录,start_time分别为前一天起始时间和扩容操作时间,end_time分别为扩容操作时间和前一天结束时间,有过N次修改规格或扩容操作,则需要插入N+1条记录
  • 如果前一天没操作记录的资源,如何入账到bill_resource?不管有没有记录,都先查询nova、cinder表,获取当前未删除资源的UUID,以此为依据遍历user_actions表,找到相关记录,进行相关入账工作,如果未找到记录,则认为当天正常存续,按规格没有变化入账一条记录(开始结束时间分别为前一天0点到23点最后一秒)
  • 还有很多细节需要仔细考虑

审计服务大概思路

在计费服务执行中新增一个费用审计任务,把所有已经创建但还没有标记为删除的云主机云硬盘资源,都跟nova或cinder库中记录比较一遍,如果发现已经删除了,则在user_actions插入一条资源删除的记录,云主机修改规格或云硬盘扩容操作的审计也是类似,插入bill_resource表之前从nova、cinder数据库中查询当前规格即可(主要用在user_actions表中当天没有操作记录场景下,有修改规格或扩容操作情况下,直接记录新规格即可)

审计服务可以设置到计费入账服务之后执行,比如入账1天一次,每天凌晨执行,审计每天一次,在中午执行,或者每天2次,上午下午各一次。审计服务也只审计前一天的入账记录。

审计服务还需要考虑审计月账单,也即每月初在出账完毕后,还需要审计bill_overview表,检查是否正常,可以设置在每月初在出账服务之后执行,可以多次审计。

RabbitMQ无法新建连接问题处理过程记录

症状描述

客户反馈无法云平台VNC控制台窗口一直处于loading状态,无法打开

定位过程

  1. 首先查看nova-api服务是否正常,nova list正常
  2. 查看nova service-list输出,所有服务在线
  3. 使用nova get-vnc-console获取云主机vnc链接,超时无法获取

初步找到控制台窗口无法打开的原因,继续分析问题,

  1. 查看云主机所在节点的nova-compute服务,一切正常
  2. 查看nova-compute日志,没有收到创建vnc链接请求(vnc控制台链接是在云主机所在计算节点生成的,因为要查询云主机qemu进程创建的vnc server端口号,创建完成后要把token和端口号对应关系保存到nova-consoleauth进程,nova-consoleauth进程会根据配置项决定把对应关系保存到进程内存还是memcache服务,之前处理过一次控制节点内存不足导致token保存失败的问题,这次也先查了下nova-consoleauth日志,没有发现类似情况)
  3. 查看nova-api节点日志,发现收到了请求但没有返回
  4. 打开nova-api和nova-compute的debug日志继续分析
  5. 发现nova-api一直在尝试连接到RabbitMQ,一直卡在connecting,没有connected日志

找到更进一步的问题原因,继续分析问题,

  1. 首先重启nova-api服务,试验下能否恢复,发现启动进程时可以连接到MQ,但获取vnc链接时问题仍然存在
  2. 通过rabbitmqctl命令行查看queue和exchange情况,也没发现异常,云主机节点的compute队列也有
  3. 重启MQ服务,试验能否恢复,重启后发现vnc链接获取命令恢复正常,页面打开控制台窗口正常

问题解决但没找到原因,于是继续观察,等了大概2分钟,再次尝试打开vnc控制台窗口,发现老问题还在,一直loading,继续分析问题,

  1. 查看MQ服务器日志,发现异常,

    发现问题根本原因,文件句柄数量超出限制,google搜索这个错误,发现了解决方法,https://my.oschina.net/moooofly/blog/678513
  2. 首先修改MQ节点物理机文件句柄数量配置(增加如下两行):
  3. ulimit -n也修改成65536
  4. 重启RabbitMQ,rabbitmqctl status命令查看限制,发现不生效:
  5. 按照搜索结果中的提示执行:rabbitmqctl stop,rabbitmq-server -detached,再次查看,发现句柄数限制已修改
  6. 尝试web打开vnc窗口,发现恢复正常,nova-api和nova-compute日志正常connected到MQ
  7. 等待几分钟仍然正常,问题解决
  8. 尝试修改安装部署脚本,发现先修改系统句柄数配置再安装MQ,仍然无法修改MQ句柄限制
  9. 继续google,查看到RabbitMQ官方文档,https://www.rabbitmq.com/install-rpm.html,有如下描述:

    据此修改后正常。

前女友居然喊我去她家……………………………………帮她重装系统

微信聊天记录

女:在吗?

男:在的,找我什么事?

女:没事儿就不能找你吗?

男:……

女:我笔记本电脑最近老死机,搞的我写了很久的方案都丢了,害我被领导骂,呜呜呜。。。

男:你用的啥系统?死机是什么症状?蓝屏还是卡死鼠标键盘没反应?

女:都有啊,有时候蓝屏有时候卡住什么都动不了,上次方案文档没保存就是卡死了只能重启,郁闷死了

男:这种时候就想到了我的好啊,所以你是想让我帮你修电脑?

女:也不是修电脑,就是重装下系统,我的电脑还是毕业前你帮我安装的XP系统呢,所以现在出问题了你也该负责解决

男:晕死!XP系统你还在用啊!我记得给你做过ghost镜像的,你还原下就好了吧?

女:是啊,我还原之后桌面上的很多文档资料什么的都找不到了,都藏哪里了你能帮我找出来吗?

男:找不到了,因为还原就会格式化系统盘,桌面的文档都删了,之前我跟你讲过的,不要把重要资料放到C盘或者桌面上

女:那就帮我重装系统吧,我想装win10,其他同事的电脑都是win10了,好像都没蓝屏死机过

男:装系统是可以,得准备工具去你那里才行,远程装不来

女:你上次不是说你们做的云平台很厉害,可以几秒钟就重装好系统的吗?你用云平台帮我重装一下呗?

男:额,看来我还得再给你科普下云计算平台

女:好啊好啊,上次还没听太懂

男:就按你现在遇到的问题来说吧,首先拿重装系统来说,如果是PC机或者数据中心的物理服务器,都是要从ISO光盘安装的,PC机可能还有ghost镜像这种做法,但物理服务器为了系统的稳定性和兼容性,不会这么做,从ISO安装就比较费时了,安装之后还需要调整很多配置,安装一些常用软件才能用,但云平台就不用这么复杂了,只需要你点一下“重装系统”按钮,然后选择一个你想要的镜像,等待几秒钟就完成了,非常方便

女:感觉好厉害,可惜不能用到我的笔记本电脑上。你们云平台怎么保证重装系统后资料不丢失的?

男:这个有两种方案,一种是像我跟你说的,不要把重要数据放到系统盘,否则重装系统后就会丢失,但在云平台里,可以通过定期备份功能来解决这个问题,至少可以保证恢复到前一天的数据(不管是因为硬盘故障还是重装系统),另一种方法是挂载云硬盘,把你的重要资料都存在那里,这样无论你怎么折腾都不会丢失,云硬盘默认都是有3个副本的(也就是一份资料保存到3个地方),坏一个没有任何影响,同时坏2个还可以找回来,极大提升了数据可靠性。

女:如果用云平台,我重装系统后,还要不要再安装一遍常用软件呢?装软件感觉很浪费时间呢

男:不想每次安装常用软件的话,可以用云平台的自定义镜像功能,你第一次装好系统和常用软件后,可以把这个系统做成一个自定义镜像,以后就可以用这个自定义镜像重装系统,或者新建云主机,这样的话常用软件都已经全部装好了,非常省心省力。

女:嗯,确实不错,什么时候能在电脑上用到这么强大的功能就好了

男:额,别胡思乱想了,我觉得你还是新买一台电脑比较实际,你那台旧笔记本电脑都用了快6年了,该退休了

女:那你帮我选一款呗

未完待续。。。

下一篇讲云主机规格和物理机硬件配置

写给儿子们<14>

人生的意义

之前在华为工作的时候,大概是2011年前后吧,由于那时候加班很多,经常搞问题单“攻关”修bug

所以爸爸时不时的就会不经意的思考人生的意义是什么?人究竟为了什么活着?怎么才能活的快乐?

那时候不知怎么的,就想到了一个“诡异”的结论,半调侃性质,人生=生人(人生就是生人,人生等于生人),然后饭后散步讲给身边的同事们听,大家都还觉得有一定的道理

毕竟千百年来,结婚生子都是非常自然而且是绝大部分人都期盼的一件人生大事,不孝有三无后为大,很多家庭甚至因为想要儿子而不停的生,更有甚者还有人因此闹离婚(你们妈妈就经常说,还好生了俩儿子,生活压力是大了点,但心理压力就没了,不用为生不出儿子发愁了,毕竟爷爷奶奶都是重男轻女的“老顽固”)

但人生=生人,毕竟只是一句玩笑,首先人活着必须得先考虑衣食住行财米油盐,才有闲心思考人生,单从爸爸还有心思思考人生来说,证明爸爸至少还不用为基本的生存条件发愁,也就是说爸爸还算活的可以,我们家还能过得下去

上次给你们写东西,提到爸爸想要多看点书,看一些软件技术之外的文学书,这也是因为书籍是精神食粮,当一个人不再为基本生存条件也就是物质食粮担忧的时候,精神食粮就显得愈发重要

毕竟我希望自己能快乐起来,这样我们全家才有可能都快乐起来,而你们在快乐的家庭环境下,才有可能养成乐观向上、简单快乐的人生观或者往低了说是生活观

人都是有贪欲的,物质上、精神上、生理上,没有人能彻底的看破红尘脱离世俗苦海,我是不相信有信仰的人(不管是佛、道、基督、真主还是其他)没有贪欲的,贪欲是一把双刃剑,关键看拥有他的人的态度,适可而止还是永无止境

拿爸爸自己来说,对金钱的贪欲让我努力学习、工作,提升自己的技术实力、人生阅历,不断思考找寻赚钱的门路,最终目的还是为了多赚钱,给咱们家带来舒适的生活环境和更好的生活条件,也给你们创造更好的人生基础

如果爸爸为了赚钱,拼命加班工作没空陪你们,或者是时不时的搏一把而赔的倾家荡产,甚至是走上赚快钱的邪路,那么我的人生就不会快乐,甚至会变得凄惨,而你们的人生在起步阶段就会遭受打击,以后的人生也会受到不好的影响

最近爸爸在看一部科幻小说《三体》,是爸爸的大学校友写的,这本书获得了被称为是科幻界诺贝尔文学家的雨果奖,不管这本书与奖项是否相符,但至少是爸爸喜欢的类型,书中人类遇到的三体危机(4个世纪之后才会被攻击),并不会对这一代人产生影响,但很多人就开始担心自己的子孙后代(N代以后自己根本不可能看得到)会绝种,我想要是我的话,肯定是会更加珍惜自己的一生,把每一天都当作世界末日来生活,把想做且能做的事情都试着做一下,不要给自己留下遗憾,而不是为虚无缥缈的未来担忧

另外爸爸还想了一个问题,绝大部分人活着都是平凡的一生,甚至可以说是平庸的一生,只有寥寥无几的一些人才能轰轰烈烈、名垂青史,但就算可以名垂青史又能如何?到头来还不是化作黄土亦或是灰飞烟灭,珍惜活着的时光,平凡没什么可怕,只要自己的一生是快乐的、有意义的、没有太多遗憾的,这就足够了。《平凡的世界》也是我最喜欢的书之一。

所以我之前经常担忧,程序员属于吃青春饭的行业,网上盛传35岁是个坎儿,40岁就是坑,掉坑里就被活埋了,没你的饭碗了,但现在想想,真的必须得一条道走到黑吗?不干程序员就不干好了,随便找份工作,快乐的活着就挺好,赚钱可以养家就行

另外还在想,你们的妈妈经常说一年到头都窝在家里,什么时候才能出去走走?爸爸现在决定了,明年开始(至少)每年要带你们和妈妈出去走走看看,不管到哪儿去都行,生活必须过的快乐,而满足妈妈和你们的梦想,也是快乐的一种,想做而且能做的事情就不要拖延,爸爸不是一个拖延症患者,下决心做的事情一定会尽力去做到

当然这种心态变化除了跟看书有关之外,也跟最近又买了一套房子有一定关系(但不太大,要定量的话10%左右吧),至少不用发愁买不起房子以后你们没地方住了,也算是解决了部分物质需求吧

如何向前女友解释你是做云计算的?

怎么跟前女友保持联系这个问题比较复杂,这里不做探讨,仅描述二人的对话内容:

女:听说你现在是程序员?你上学也不是学这个的啊?

男:你不知道吗?现在找不到工作的工科男都去做程序员了

女:不是说程序员待遇好门槛高的吗?你这么一说怎么感觉是个人都能做了?

男:(内心:一千点暴击伤害。。。)待遇好,但不表示门槛高,物以稀为贵,信息时代程序员缺口只会越来越大,所以程序员入门比较容易,但是做精做深比较难

女:为什么呢?

男:以前的程序员,什么都要自己动手做,都是各干各的,或者各公司干各公司的,互相不怎么交流,现在的程序员动不动开技术研讨会、写公众号文章分享新技术、甚至心情好了就把辛辛苦苦开发的软件开源掉,把自己的代码放到网上给人用,所以很多时候编程序变成了搭积木,只要你有点逻辑思维能力,再稍稍会点编程技术,就能做出来像模像样的软件。另外还有一个很重要的原因,现在云计算在程序员和IT公司中已经深入人心,云计算把软件开发需要的基础技能也都给弱化了,所以程序员干活更简单迅速了,简直变成了体力活,不是有个段子说程序员“钱多话少死的早”

女:哈哈,这个段子好冷。能问下你现在能拿多少吗?不方便的话可以不回答哦

男:养家糊口没问题吧。哎,不对啊,你为啥不问我什么是云计算?你没有按套路出牌啊。。。

女:哈哈,好吧,什么是云计算?听起来很高大上的样子

男:说到云计算,你算是问对人了,这可是我的老本行,云计算可不只是听起来高大上,他确实十分绝对非常高大上

女:这么高大上的技术我肯定听不懂,你也甭费劲给我解释了,咱还是聊点别的吧

男:别啊,我保证你绝对听得懂,我敢打赌,要是你听不懂的话活该我做一辈子单身狗(请按剧(tao)本(lu)走好吧。。。)

女:那看来我必须得洗(bu)耳(dong)恭(zhuang)听(dong)了

男:你还记得咱俩刚在一起那会儿去网吧包宿的那件事儿吗?凌晨3点多电脑还坏了那次

女:怎么不记得!说起来这事儿我就来气!你只顾着打游戏,我早早就睡了,电脑坏了你又半夜喊我换包间睡(活该你单身到现在!)

男:呃,不要在意这些细节,重点不在这里。(活该我做单身狗!)下面开始介绍啥是云计算,简单来说云计算平台就是个网吧管理系统,网吧有很多电脑,可以把电脑看作各大IT公司数据中心里面的服务器,实际上服务器就是性能比较好配置比较高的电脑,网管就是数据中心管理人员,我做的云计算平台就是网吧的管理系统(有计费、分配电脑、远程开关机等等功能),网吧电脑出问题了,就喊网管来修理,IT公司机房服务器出问题也一样找管理员修理。网吧新买了电脑得装系统、装软件、接网线电源,最后才能放到桌上给客户用,数据中心采购服务器也是一样的流程。

网吧电脑上桌之后,就可以通过网吧管理系统分配给客户了,只要客户交了钱,就能给他分电脑用,钱用完了强制下机,没用完提前下机下次来还可以继续用,云计算平台也是一样,按使用时间给钱,充值包月有优惠。(按时长计费

网吧里的一台电脑可以给很多客户用,这台有人用可以分另外一台空闲的给客户,一个客户下机了另一个可以继续用,云平台管的服务器也一样,服务器可以给很多人用,而不是固定分给一个人不管他来不来上机都给他留着别人不能用,那样的话网吧就亏死了。如果没有云平台,数据中心的服务器就是定死分配给一个用户的,他不用也只能空着浪费电,要不然就得搬迁到其他用户服务器所在的房间才能给别的用户用起来。

网吧另一个问题是一台电脑只能同时给一个客户用,俩人抢一台电脑肯定要打架了,因为鼠标、键盘、显示器就一套啊,俩人肯定不能一起用,当然情侣除外,要是网吧电脑配置很高,一个人来上机就是聊聊QQ、看看电影、玩玩欢乐斗地主,那电脑里的I7的CPU、8G内存、1000M光纤网速就太浪费了,要是能把这台电脑同时给几个人用,价格优惠点,买的电脑会少很多,电费也少很多,网吧肯定赚的更多,老板肯定很开心。网吧没这么做应该有很多其他因素,但云平台已经这么做了,一台服务器的CPU、内存、硬盘可以给多个客户用,服务器资源不浪费,用户节约成本,双赢的局面。(硬件资源池

网吧的电脑关机之后就把硬盘里的数据全部删掉了,还原成网管最开始上架电脑时的状态,这就是为了防止前一个人装的软件影响下一个人用电脑,云平台也是一样,一个用户不管做啥事儿,都不影响其他用户,云平台具体怎么做到这点的就不细说了。(资源隔离

网吧有个小问题,就是操作系统都是一个版本,比如XP或者win7,我还没见过一个网吧的电脑有好几个版本的,但云平台不一样,他可以支持好几种系统,用户喜欢哪个用哪个,用的不爽了可以随时换,用出问题了随时重装系统,并且重装系统特别快,比我给你重装系统快多了。(虚拟化

网吧空闲的电脑可以随时分配给客户,用完收回,云平台的服务器也是一样,只要有空闲的服务器就可以给给用户使用,而不用每次都买新服务器。(弹性

其实绝大部分网吧的电脑都是没有硬盘的,在网管那边统一管理很多很多硬盘,然后大家都可以用,然后每个电脑上看到的硬盘空间都是超级大的,成百上千T,云平台也差不多,他把每台服务器上的硬盘都用软件统一管理起来,然后再分配给用户用,用户要多少T就给多少T,不用担心这台服务器硬盘不够用了,另外一台的硬盘还剩余很多,具体怎么做到的也不细说了。(分布式存储

女:我大概明白了,云计算平台就是数据中心的网管系统,对吧?

男:哈哈,懂了吧,就这么简单(脱单有望啦)

女:原来就这么简单啊!那你工资肯定不会高吧?就一个网管系统哪个老板会给高工资?

男:(一万点暴击伤害。。。)呃,也不能这么说,云平台还是有一定的技术含量的,网管系统只是个比喻而已,肯定不能直接拿来用的。其实云计算还包含其他内容,我上面讲的只是基础设施平台,简单来说就是管理服务器的CPU、内存、硬盘、网络这些东西的,还有另外的云计算服务比如提供平台服务云、软件服务云,其中平台服务云就是程序员开发软件用到的“积木”,软件服务云就是网吧电脑里面安装好的游戏,用户打开软件或者浏览器输入账号密码就能用。我现在做的是第一种基础设施云,他是给程序员提供电脑的,程序员编好的软件得在电脑里跑起来才能用,属于很基础的运行环境所以叫基础设施云。

女:这回我真的彻底明白了,搞半天你就是科技市场卖电脑的!哦对了,还顺便卖网管软件。。。。

男:(一千万点暴击伤害。。。)呃呃呃呃呃呃。。。无力解释啦

待续。。。

本故事场景纯属虚构:程序猿怎么可能会有前女友???!!!

cloud-init代码调试方法

新做的centos7.4镜像的cloud-init安装好之后,修改密码失败,但是同样的配置文件在7.2上的是正常的,对比了一下版本,centos7.4上的是0.7.9,7.2上的是0.7.5,经过调试发现是0.7.9版本的cloud-init有bug导致的,发现问题之后通过降级到0.7.5版本解决。之前也加断点调试过几次,但没有记录下来,这里记录下调试方法,因为默认直接加pdb断点是没法调试的。

首先要知道如何手工运行cloud-init工具,可以命令行执行: cloud-init -h ,看到有多个命令供选择,但我们只需要执行 cloud-init init 命令和 cloud-init init --local 命令即可,这两个命令就是开机自启动服务中会执行的,差异就是 --local 仅读取本地数据源(如config drive数据源),不加这个参数,可能尝试读取EC2等网络数据源(http://169.254.169.254)。

执行的时候要注意,cloud-init很多操作都是默认仅第一次开机的时候执行的(once-per-instance),也就是说默认情况下,每个云主机仅在第一次创建后启动的时候执行一次初始化操作,后面无论你怎么重启都不会执行的(当然不是全部初始化操作都不执行,要看具体的配置,但绝大部分操作都是once-per-instance)。所以为了保证每次手工执行的时候,都执行所有初始化操作,可以手工删除cloud-init的缓存目录,cloud-init是根据缓存中的云主机id(instance-id,一般就是云主机uuid)和数据源中获取的id来对比,确认是否是新建云主机第一次启动的。该缓存目录一般位于(/var/lib/cloud),直接删除整个目录即可清空缓存,调试过程中每次执行cloud-init命令前都需要删除一次。

直接加pdb断点到源码里是无法调试的,因为cloud-init会重定向标准输入stdin,所以还要注释掉这行代码才行:

上面是cloud-init init命令需要注释掉代码的示例(基于0.7.9版本源码,0.7.5版本的入口在/usr/bin/cloud-init或者/bin/cloud-init,可使用 which cloud-init 命令查看具体路径,需要在这个文件里注释掉这行代码),如果你要调试其他命令如cloud-init modules还有其他地方需要注释:

之后在main_init方法的入口处加入断点(0.7.5的不加会进入不了调试模式,0.7.9的可以不加,为了保险,可以加上,然后执行c命令跳到你真正想调试的断点处即可),然后再在你想要的任何地方加断点即可调试。