如何在google cloud上搭建Choerodon

Choerodon猪齿鱼是一个开源企业服务平台,是基于Kubernetes的容器编排和管理能力,整合DevOps工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理,并提供IoT、支付、数据、智能洞察、企业应用市场等业务组件,来帮助企业聚焦于业务,加速数字化转型。 搭建choerodon比较麻烦,这里写一篇关于如何在google could提供的k8s集群上搭建choerodon。在基于google的官方集群基础上可以比较简单。 1.准备好k8s集群,可以在google cloud控制面板上创建一个集群或使用原有的集群 ![]() 2.准备存储: 点击导航菜单,下拉至文件存储创建文件存储(注意所属区域应该和集群一致) 创建完成后点击存储实例可以看到挂载地址,复制这个地址 3.在测试存储可用 准备好存储之后需要测试一下是否可用,并安装nfs-utils,复制挂载点 登录kubernetes控制台,部署linux 目前亲测一键安装脚本一键支持谷歌云,当然不能使用标准的storageClass而需要使用自己搭建的nfs-provisioner »

测试服务器性能

使用docker快速测试服务器性能 安装docker curl -sSL https://get.docker.io | sh 测试 docker run registry.saas.hand-china.com/paas/benchvm:latest 默认测试docker存储目录所在的卷,如果需要测试其他卷,请在其他卷所有的目录下创建一个文件夹,并绑定到容器中的/disktest/中。如: mkdir -p /u01/distest docker run -v /u01/distest:/disktest registry.saas.hand-china.com/paas/benchvm:latest 测试结果及描述 参考值指在阿里云ECS中测试,符合使k8s能够稳定运行的数据。 ==== test network and io TERM environment variable not set. 1:此处显示主机的基本信息 CPU model : Intel Core Processor (Broadwell, IBRS) Number of cores : 4 CPU frequency : 2099.998 MHz Total size of Disk : 164.1 GB (112.0 GB Used) Total amount of Mem : 15885 MB (7436 MB Used) Total amount of Swap : 16379 MB (2180 MB Used) System uptime : 33 days, 0 hour 47 min Load average : 8. »

好的程序员和不好的程序员

原文来自http://www.techug.com/post/good-programmer-and-bad-programmer.html 1. 有感于知乎上的一篇关于程序员的讨论。让我突然之间心有戚戚然的感觉。最近一段时间有点江郎才尽的感觉,写不了大的主题,就写点小东西吧。 我们从知乎上面引用的这段小故事开始: 魏文王问扁鹊家里三兄弟谁的医术最好。扁鹊回答说大哥最好,二哥次之,他自己最差。魏文王疑惑了,又问道,为什么扁鹊最有名呢?扁鹊回答说因为大哥治病的时候人没病就防止了,所以毫无名气。二哥呢,病刚起来的时候,就给治好了,大家以为只能治小病。而自己呢,能耐不够,非要到了病的很厉害了才能看出来,治起来的动静就大了。好在还不至于庸医能治好,结果大家看到每次治的都是顽疾,反而出名了。 这发生在几千年前的对话是不是靠谱我们不知道,但是拿这话来套程序员的生态圈,真就是一套一个准。 2. 微软某个大牛软件下面两个不同的组里各有一个大牛程序员,为了不失一般性,我们叫张三和李四吧。张三的特点颇有点大哥的风范,偶尔也充当一下二哥。写的程序严谨,测试也很严谨,几乎不犯错。组里其他同事有错的,也在出大事之前默默的修掉了。 李四的风格和扁鹊像,手脚麻利干活快,但是坑也很多。好在李四人聪明又手脚麻利,每次总是能够在自己或者组里其他人搞出惊天动地的大事来的时候,把坑迅速填好,救产品于危难。 名气来说,李四是整个产品部门从VP往下数出了名的可靠的火枪手,救火队员。领导信任不可或缺的左膀右臂。张三就默默无闻了。只有小组里面的人知道自己是高手。 说起结局来,李四很快就到了principal,张三么,一直默默无闻,很多年以后终于熬资历到了senior,然后在一次裁员中被裁掉了。 3. 事情到这里就有点意思了。几千年前的故事,几千年后还在上演。看官可能觉得这个是特例。其实也不然。这样的故事一直在上演。 说说另外一个顺利上市扩张的公司的故事。我们知道但凡是初创公司里的员工,都是能够迅速的开发出差不多能用的东西的工程师的天下。但是这个东西有个度,差不多能用的东西短平快带来的副作用其实很大。弄不好就得在未来某个时候全部重写。 这个公司的领导层就是这样一群码农自然而然的升上来的,崇尚的就是这种做事风格。但是因为公司大了,产品不能够再到处是bug了,可是公司的test coverage又是一塌糊涂。哪里都是坑。所以每次新版本的发行,都不停的延期延期又延期。 公司里我认识的有一个俄罗斯来的人,做事情严谨,写程序的test coverage很好,因为以前合作的关系,知道这个人的工作style,而且知道这个人是我见过的最为优秀的程序员之一。有次我偶遇聊起天来,这位一个劲的和我诉苦,苦不该去这个公司。因为公司里面所有的人崇尚的是救火队员,从未有人觉得好好写code,少出bug是重要的。 后来我又认识了一个罗马尼亚来的工程师,也是同一个公司。这位罗马尼亚老兄的程序我就不评价了,实在有点不堪入目。然而我看看linkedin,在此公司混的是风生水起。我再次和俄罗斯人见到的时候,俄罗斯人和我说,这个罗马尼亚人啊,就是个彻头彻尾的hacker。每次做事情,把当前的bug能修掉再说,code一塌糊涂,最后别人都得替他擦屎。但是领导们都很喜欢他啊,能迅速的修好东西让产品出去。 4. 这事情说道这里,其实可以概括下来两句话:曲突徒新亡恩泽,焦头烂额为上客。 一个程序员为了不出问题而做的努力,往往没有那些出了问题以后再打鸡血一样去努力解决的人获得的回报多。你说按照这个标准去判断,到底是哪里出错了呢? 从这一点来说,我们首先得要看看一个领导是怎么样去评价一个好或者不好的程序员的。在我的经历里面,并不是没有遇到过在意系统结构,对那些能够写出不错的程序,能够防范未然的程序员非常重视的领导。然而更多的领导其实最在乎的依然是如何能够迅速的把东西写完,迅速的发布出去。 基于后者的情况越来越普遍,尤其是在比如著名的亚马逊的很多产品组,领导有的是MBA或者产品经理出身的,其评价体系里面,并不会给扁鹊大哥那样的程序员太多发挥的空间。 我作为程序员的时候,是非常希望自己可以成为扁鹊大哥这样的牛逼的大神的。我环顾四周的时候,看到拯救公司的英雄们,各个都如同扁鹊,或者扁鹊++。这个问题我很困扰了,读到知乎上的文章,颇心有戚戚然。那么码农们,你们怎么选?经理们,你们怎么看? »

Author image VinkDong on #story,