g****t
发帖数: 31659 | 1 以前thousands 级别机器的管理。据我所知没有统一的办法，或者各家不是走统一的办
法。而且知识和技术细节也都不是一般人可以接触到的。现在就别犹豫了。我个人的判
断是k8s看好。 |
d*******r
发帖数: 3299 | 2 你先捏着鼻子配置会儿k8s那一坨坨yaml再说
面向配置文件编程, 面向黑盒编程, 面向 stackoverflow 编程 @[email protected]
Infrastructure As messy cfgs |
g****t
发帖数: 31659 | 3 写写emacs/vim, 解决这些问题?
图灵完备的一大动力是自动化生成配置文件。
本来配置文件不是图灵完备的。加上模版和eval就成了正经的coding.
如果不熟悉emacs/vim. 可以写写MS word VBA自动产生yaml. Excel也行。
: 你先捏着鼻子配置会儿k8s那一坨坨yaml再说
: 面向配置文件编程, 面向黑盒编程, 面向 stackoverflow 编程 @[email protected]
: Infrastructure As messy cfgs
【在 d*******r 的大作中提到】
: 你先捏着鼻子配置会儿k8s那一坨坨yaml再说
: 面向配置文件编程, 面向黑盒编程, 面向 stackoverflow 编程 @[email protected]
: Infrastructure As messy cfgs
|
d*******r
发帖数: 3299 | 4 以下是我的个人观点:
面向配置文件配置 -- 没问题, 配置文件就是用来定义 high-level 的意愿的.
面向配置文件编程 -- 一般是这个系统或者工具设计有问题, 虽然这事儿在整个
industry 经常发生...
一旦有大量的配置文件，需要编程来动态生成的时候... 最好应该设计成 API 编程,
而不是捣鼓配置文件.
配置文件是个high-level & weak modeling tool, 编程语言(with function, API) 是
low-level & strong modeling tool.
所以一旦走上了面向配置文件编程的路线，设计的东西就会很 complex, fragile.
比如永远在更新，永远复杂的一逼的各种前端框架 -- 面向 HTML, CSS 配置文件编程.
还有传统 Java 里面那一坨坨的 XML cfgs, 也是这种毛病.
整个 industry 经常重复做错的一件事:
发明一个 high-level 的, 但是描述能力很弱的抽象工具,
然后因为这个工具 high-level, 捣鼓几下能直接看到效果,
就使劲忽悠大家用, 如果这个工具背景强, 有钱做 market,
这个祸害就扩散开了, 过几年再看... 又会有类似的新祸害出来, 号称可以拯救旧祸害
导致的各种问题...
于是, 整个 industry 就像时尚界一样, 可以这几年流行这个, 那几年流行那个...
真正 well design 的创新工具到底有多少?
【在 g****t 的大作中提到】
: 写写emacs/vim, 解决这些问题?
: 图灵完备的一大动力是自动化生成配置文件。
: 本来配置文件不是图灵完备的。加上模版和eval就成了正经的coding.
: 如果不熟悉emacs/vim. 可以写写MS word VBA自动产生yaml. Excel也行。
:
:
: 你先捏着鼻子配置会儿k8s那一坨坨yaml再说
:
: 面向配置文件编程, 面向黑盒编程, 面向 stackoverflow 编程 @[email protected]
:
: Infrastructure As messy cfgs
:
|
g****t
发帖数: 31659 | 5 写API成本高，耗时长。光定spec就要好几个senior不少时间。
等你做完，市场都变了。这个投入不划算。
市场的快速变化驱动python这样的糙快猛走到top1 语言的位置。
我怀疑现在时代已经变了。开发速度慢的语言的job positions会越来越少。
程.
【在 d*******r 的大作中提到】
: 以下是我的个人观点:
: 面向配置文件配置 -- 没问题, 配置文件就是用来定义 high-level 的意愿的.
: 面向配置文件编程 -- 一般是这个系统或者工具设计有问题, 虽然这事儿在整个
: industry 经常发生...
: 一旦有大量的配置文件，需要编程来动态生成的时候... 最好应该设计成 API 编程,
: 而不是捣鼓配置文件.
: 配置文件是个high-level & weak modeling tool, 编程语言(with function, API) 是
: low-level & strong modeling tool.
: 所以一旦走上了面向配置文件编程的路线，设计的东西就会很 complex, fragile.
: 比如永远在更新，永远复杂的一逼的各种前端框架 -- 面向 HTML, CSS 配置文件编程.
|
d*******r
发帖数: 3299 | 6 我觉得这个思路 写前端, 写跑一次就扔的数据处理，都行
infrastructure 也这么搞... 有点渗得慌
【在 g****t 的大作中提到】
: 写API成本高，耗时长。光定spec就要好几个senior不少时间。
: 等你做完，市场都变了。这个投入不划算。
: 市场的快速变化驱动python这样的糙快猛走到top1 语言的位置。
: 我怀疑现在时代已经变了。开发速度慢的语言的job positions会越来越少。
:
: 程.
|
g****t
发帖数: 31659 | 7 这个没啥吧？java下，我敲ff加上空格键，for loop就出来了。
核电站说不定也有老师傅是这么搞的。
copy paste自动化而已。
【在 d*******r 的大作中提到】
: 我觉得这个思路 写前端, 写跑一次就扔的数据处理，都行
: infrastructure 也这么搞... 有点渗得慌
|
d*******r
发帖数: 3299 | 8 我又不是指打字麻烦
【在 g****t 的大作中提到】
: 这个没啥吧？java下，我敲ff加上空格键，for loop就出来了。
: 核电站说不定也有老师傅是这么搞的。
: copy paste自动化而已。
|
g****t
发帖数: 31659 | 9 模板也可以轻松自制。
这些都可以轻松做到。各种复杂的格式都可以自动化填空。
例如latex。因为本身这类编辑器的函数的结果立即可见.
所以不需要太纠结程序强壮性，因为你能看见产生出来的结果。
你这样想。例如一个word文档，其中每个character的产生都可以用basic语言的函数控
制。
vim,emacs无数的3rd party脚本处理yaml，xhtml，etc
【在 d*******r 的大作中提到】
: 我又不是指打字麻烦
|
d*******r
发帖数: 3299 | 10 "所以不需要太纠结程序强壮性，因为你能看见产生出来的结果。"
这个不是 "开发一时爽, production 火葬场" 的节奏么?
guvest 呀, 这个topic上我不能同意你的观点啊 :D
话说 wdong 回国了? 我回来逛咋看不到他了.
【在 g****t 的大作中提到】
: 模板也可以轻松自制。
: 这些都可以轻松做到。各种复杂的格式都可以自动化填空。
: 例如latex。因为本身这类编辑器的函数的结果立即可见.
: 所以不需要太纠结程序强壮性，因为你能看见产生出来的结果。
: 你这样想。例如一个word文档，其中每个character的产生都可以用basic语言的函数控
: 制。
: vim,emacs无数的3rd party脚本处理yaml，xhtml，etc
|
|
|
g****t
发帖数: 31659 | 11 我说的是自动产生出来xml的脚本。你不需要考虑太多的options,适用性等等。本质就
是高级复制粘贴，用户就一个人。相当于一系列的repl.
和你说的开发的代码隔着一层呢。你没听明白吧。
Yaml再复杂也不比latex吧。所以自制脚本处理下，应该是可行的。
当然，要写个vim, emacs脚本供给大量的人用那就是另一回事了。
: "所以不需要太纠结程序强壮性，因为你能看见产生出来的结果。
【在 d*******r 的大作中提到】
: "所以不需要太纠结程序强壮性，因为你能看见产生出来的结果。"
: 这个不是 "开发一时爽, production 火葬场" 的节奏么?
: guvest 呀, 这个topic上我不能同意你的观点啊 :D
: 话说 wdong 回国了? 我回来逛咋看不到他了.
|
s******e
发帖数: 3 | 12 我举个实际例子说明：
我们有几十个springboot的应用，我弄了几个脚本，通过Jenkins使用，输入几个参数
，就自动创建Jenkins job，然后调用。被调用的Job会自动从git下载代码编译，打包
，上传到Image Registry，然后调用 k8s api部署，并配置服务。
脚本我大概用了几天时间开发调试完，python 加 bash 加一些模版。springboot源代
码一点没动。
模版都是使用现有的，或者先通过GUI做一个，然后导出，用shell做些替换即可。
【在 g****t 的大作中提到】
: 我说的是自动产生出来xml的脚本。你不需要考虑太多的options,适用性等等。本质就
: 是高级复制粘贴，用户就一个人。相当于一系列的repl.
: 和你说的开发的代码隔着一层呢。你没听明白吧。
: Yaml再复杂也不比latex吧。所以自制脚本处理下，应该是可行的。
: 当然，要写个vim, emacs脚本供给大量的人用那就是另一回事了。
:
:
: "所以不需要太纠结程序强壮性，因为你能看见产生出来的结果。
|
d*******r
发帖数: 3299 | 13 不用 K8S + container 这一套, 还不是一样自动化部署?
你看你的主要工作量是花几天写那些 python/bash 的部署脚本
【在 s******e 的大作中提到】
: 我举个实际例子说明：
: 我们有几十个springboot的应用，我弄了几个脚本，通过Jenkins使用，输入几个参数
: ，就自动创建Jenkins job，然后调用。被调用的Job会自动从git下载代码编译，打包
: ，上传到Image Registry，然后调用 k8s api部署，并配置服务。
: 脚本我大概用了几天时间开发调试完，python 加 bash 加一些模版。springboot源代
: 码一点没动。
: 模版都是使用现有的，或者先通过GUI做一个，然后导出，用shell做些替换即可。
|
s******e
发帖数: 3 | 14 是可以，之前用vm的时候，也是Jenkins做构建，弄了一些脚本做自动部署。区别如下：
以前要化大量时间创建维护升级运行环境，现在不用了。
以前扩容要做很多事，现在只要把数字改一下。
以前部署新版本，要么中断服务，要么自己写很多工具，现在只需要选择部署策略，就
有很多不间断的部署方式。
还有很多。我告诉大家自己的使用体会，容器技术，对大系统维护管理绝对是革命性的
。对快速软件使用测试也是非常有价值的。
【在 d*******r 的大作中提到】
: 不用 K8S + container 这一套, 还不是一样自动化部署?
: 你看你的主要工作量是花几天写那些 python/bash 的部署脚本
|
g****t
发帖数: 31659 | 15 你和我的觀點基本一致。k8s別猶豫了。我以前也找Jenkins 的人了解過。
: 是可以，之前用vm的时候，也是Jenkins做构建，弄了一些脚本做自动部署。区
别如下：
: 以前要化大量时间创建维护升级运行环境，现在不用了。
: 以前扩容要做很多事，现在只要把数字改一下。
: 以前部署新版本，要么中断服务，要么自己写很多工具，现在只需要选择部署策
略，就
: 有很多不间断的部署方式。
: 还有很多。我告诉大家自己的使用体会，容器技术，对大系统维护管理绝对是革
命性的
: 。对快速软件使用测试也是非常有价值的。
【在 s******e 的大作中提到】
: 是可以，之前用vm的时候，也是Jenkins做构建，弄了一些脚本做自动部署。区别如下：
: 以前要化大量时间创建维护升级运行环境，现在不用了。
: 以前扩容要做很多事，现在只要把数字改一下。
: 以前部署新版本，要么中断服务，要么自己写很多工具，现在只需要选择部署策略，就
: 有很多不间断的部署方式。
: 还有很多。我告诉大家自己的使用体会，容器技术，对大系统维护管理绝对是革命性的
: 。对快速软件使用测试也是非常有价值的。
|
d*******r
发帖数: 3299 | 16
下：
现在一样要维护你的 container build 脚本 (e.g. docker file)
因为 docker file 就是 glue 一堆 bash 而已, 不能保证 reproduce 你的环境.
参考版本以前的讨论: http://www.mitbbs.ca/article_t/Programming/31501247.html
你的 docker file 能不能 reproduce 的你环境, 决定于里面的 bash script 是否精
确追踪安装包版本.
所以你一样要维护你的升级运行环境, 除非你就是黑盒地依赖上次能跑通的 docker
image.
但是, 这样想起来渗得慌, 因为你依赖的是黑盒.
还有, docker image 以前跨越 OS (Mac, Win, Ubuntu) 是要可能出错的... 不知道现
在如何
有很多更简单的方法可以 horitzonal scale, 不一定要配置好 K8S, 然后改它配置文
件.
当然, K8S 自带 scheduler, 这一块是强项, 能玩的花头更多.
这个也跟 K8S 没有直接关系, 无非就是让旧service copy不关闭,
起新service copy, 换service discovery的地址, 关闭旧 service copy.
最后我想说, K8S 作为一个分布式系统, networking 设计不合格, 大坑不断.
简单说, 就是 不 合 格. 不知道 Google 的人能不能把这坨 shit fix 了, 反正他们
有钱耗.
【在 s******e 的大作中提到】
: 是可以，之前用vm的时候，也是Jenkins做构建，弄了一些脚本做自动部署。区别如下：
: 以前要化大量时间创建维护升级运行环境，现在不用了。
: 以前扩容要做很多事，现在只要把数字改一下。
: 以前部署新版本，要么中断服务，要么自己写很多工具，现在只需要选择部署策略，就
: 有很多不间断的部署方式。
: 还有很多。我告诉大家自己的使用体会，容器技术，对大系统维护管理绝对是革命性的
: 。对快速软件使用测试也是非常有价值的。
|
n******t
发帖数: 4406 | 17 很多年前dev就是ops，ops即使dev。網管都會寫程序，寫程序的都要管部署。
直到後來dev和ops分開，所以寫程序的人可能完全沒mount過機器，沒插過網線，
沒見過硬盤，也沒裝過OS。但是這幫人現在要去搞ops了！所以他們喜歡的東西就是只
要在開發環境下面能交差就OK。這樣才有了各種莫名其買哦的輪子，為了最後省幾分鐘
的事情搞出一堆crap，完全不顧部署的時候的情況。
和這樣的人說穩定，擴展，都是雞同鴨講。
【在 d*******r 的大作中提到】
:
: 下：
: 现在一样要维护你的 container build 脚本 (e.g. docker file)
: 因为 docker file 就是 glue 一堆 bash 而已, 不能保证 reproduce 你的环境.
: 参考版本以前的讨论: http://www.mitbbs.ca/article_t/Programming/31501247.html
: 你的 docker file 能不能 reproduce 的你环境, 决定于里面的 bash script 是否精
: 确追踪安装包版本.
: 所以你一样要维护你的升级运行环境, 除非你就是黑盒地依赖上次能跑通的 docker
: image.
: 但是, 这样想起来渗得慌, 因为你依赖的是黑盒.
|
g****t
发帖数: 31659 | 18 哈哈，是这个道理。本来古文就是白话文。宋朝以后分开了。然后胡适发动了白话文运
动，后来不懂古文的人要领导国家了。然后白话文最高峰的《金瓶梅》传开了，每个知
识分子
都努力学习。然后新中国成立了。毛主席给省委书记人手一套。然后顺着白话文，《金
瓶梅》里的段子，成为社会上没有其他价值观来源的人追求的人生目标。
: 很多年前dev就是ops，ops即使dev。網管都會寫程序，寫程序的都要管部
署。
: 直到後來dev和ops分開，所以寫程序的人可能完全沒mount過機器，沒插
過網線，
: 沒見過硬盤，也沒裝過OS。但是這幫人現在要去搞ops了！所以他們喜歡
的東西
就是只
: 要在開發環境下面能交差就OK。這樣才有了各種莫名其買哦的輪子，為了
最後省
幾分鐘
: 的事情搞出一堆crap，完全不顧部署的時候的情況。
: 和這樣的人說穩定，擴展，都是雞同鴨講。
【在 n******t 的大作中提到】
: 很多年前dev就是ops，ops即使dev。網管都會寫程序，寫程序的都要管部署。
: 直到後來dev和ops分開，所以寫程序的人可能完全沒mount過機器，沒插過網線，
: 沒見過硬盤，也沒裝過OS。但是這幫人現在要去搞ops了！所以他們喜歡的東西就是只
: 要在開發環境下面能交差就OK。這樣才有了各種莫名其買哦的輪子，為了最後省幾分鐘
: 的事情搞出一堆crap，完全不顧部署的時候的情況。
: 和這樣的人說穩定，擴展，都是雞同鴨講。
|
d*******r
发帖数: 3299 | 19 你又联系到金瓶梅, 哈哈哈
【在 g****t 的大作中提到】
: 哈哈，是这个道理。本来古文就是白话文。宋朝以后分开了。然后胡适发动了白话文运
: 动，后来不懂古文的人要领导国家了。然后白话文最高峰的《金瓶梅》传开了，每个知
: 识分子
: 都努力学习。然后新中国成立了。毛主席给省委书记人手一套。然后顺着白话文，《金
: 瓶梅》里的段子，成为社会上没有其他价值观来源的人追求的人生目标。
:
:
: 很多年前dev就是ops，ops即使dev。網管都會寫程序，寫程序的都要管部
: 署。
:
: 直到後來dev和ops分開，所以寫程序的人可能完全沒mount過機器，沒插
: 過網線，
|
T********i
发帖数: 2416 | 20 说的太对了。毛主席床头就摆了两本金瓶梅。
一本中文原著，一本德译本。
毛主席对照着学习马列原著，省得被翻译给骗了。。。
: 哈哈，是这个道理。本来古文就是白话文。宋朝以后分开了。然后胡适发动了白
话文运
: 动，后来不懂古文的人要领导国家了。然后白话文最高峰的《金瓶梅》传开了，
每个知
: 识分子
: 都努力学习。然后新中国成立了。毛主席给省委书记人手一套。然后顺着白话文
，《金
: 瓶梅》里的段子，成为社会上没有其他价值观来源的人追求的人生目标。
:
【在 g****t 的大作中提到】
: 哈哈，是这个道理。本来古文就是白话文。宋朝以后分开了。然后胡适发动了白话文运
: 动，后来不懂古文的人要领导国家了。然后白话文最高峰的《金瓶梅》传开了，每个知
: 识分子
: 都努力学习。然后新中国成立了。毛主席给省委书记人手一套。然后顺着白话文，《金
: 瓶梅》里的段子，成为社会上没有其他价值观来源的人追求的人生目标。
:
:
: 很多年前dev就是ops，ops即使dev。網管都會寫程序，寫程序的都要管部
: 署。
:
: 直到後來dev和ops分開，所以寫程序的人可能完全沒mount過機器，沒插
: 過網線，
|
|
|
g****t
发帖数: 31659 | 21 胡耀邦同志爱散步，当年他每天沿着中南海边一般要走一万步。1984年至1986年期间，
因中南海部分区域开放参观，他散步就改在毛主席丰泽园故居院内。我记得，耀邦同志
第一次与我交谈时问我：“你是做什么工作的？”我回答说：“我是
给晚年的毛主席做
图书服务工作的，就是毛主席晚年的图书服务员。”耀邦同志说：“那我问
你：主席晚
年是不是天天都看《金瓶梅》？”这是耀邦同志与我交谈时向我提的第一个问题
。我说
：“说真话，毛主席晚年没有看过《金瓶梅》。我们是从1966年5月开始为毛主席
做图
书服务工作的。毛主席每天看什么书我们都有登记，直到他老人家逝世，这10多年的时
间里，毛主席没有向我们要过《金瓶梅》，我们也没有发现他老人家看过《金瓶梅》，
但可以有把握地说，毛主席生前看过《金瓶梅》。”接着，我向耀邦同志汇报了
毛主席
先后三次对《金瓶梅》的评论。
——毛澤東晚年讀書記實，黨校出的
黨內人士說了。我們沒有發現他老人家看過《金瓶梅》。
哪壺不開提哪壺，耀邦同志這就屬於hci講的：沒文化！
: 说的太对了。毛主席床头就摆了两本金瓶梅。
: 一本中文原著，一本德译本。
: 毛主席对照着学习马列原著，省得被翻译给骗了。。。
: 话文运
: 每个知
: ，《金
【在 T********i 的大作中提到】
: 说的太对了。毛主席床头就摆了两本金瓶梅。
: 一本中文原著，一本德译本。
: 毛主席对照着学习马列原著，省得被翻译给骗了。。。
:
:
: 哈哈，是这个道理。本来古文就是白话文。宋朝以后分开了。然后胡适发动了白
: 话文运
:
: 动，后来不懂古文的人要领导国家了。然后白话文最高峰的《金瓶梅》传开了，
: 每个知
:
: 识分子
:
: 都努力学习。然后新中国成立了。毛主席给省委书记人手一套。然后顺着白话文
|
g****t
发帖数: 31659 | 22 文學作品就是軟件系統。
: 你又联系到金瓶梅, 哈哈哈
【在 d*******r 的大作中提到】
: 你又联系到金瓶梅, 哈哈哈
|
j*****w
发帖数: 1 | 23 但是没有可以运行文学作品的机器。
【在 g****t 的大作中提到】
: 文學作品就是軟件系統。
:
:
: 你又联系到金瓶梅, 哈哈哈
:
|
g****t
发帖数: 31659 | 24 人腦就是這樣的機器。你讀了書，就會用書裡面的詞語，邏輯，數據結構。
假如一個人沒讀過金瓶梅，但是自受教育以來學會的就只是金瓶梅這個書出入現實的辦
法。那他就是金瓶梅裡面的人。
白話文其實沒有金瓶梅以外的系統。金瓶梅這個作者是體制內的大知識分子。一人之力
完成這個巨著。絕對不是集體創作的二人傳類型的三國演義什麼的可以比較的。
: 但是没有可以运行文学作品的机器。
【在 j*****w 的大作中提到】
: 但是没有可以运行文学作品的机器。
|
j*****w
发帖数: 1 | 25 机器，这里特指硅基机器。
【在 g****t 的大作中提到】
: 人腦就是這樣的機器。你讀了書，就會用書裡面的詞語，邏輯，數據結構。
: 假如一個人沒讀過金瓶梅，但是自受教育以來學會的就只是金瓶梅這個書出入現實的辦
: 法。那他就是金瓶梅裡面的人。
: 白話文其實沒有金瓶梅以外的系統。金瓶梅這個作者是體制內的大知識分子。一人之力
: 完成這個巨著。絕對不是集體創作的二人傳類型的三國演義什麼的可以比較的。
:
:
: 但是没有可以运行文学作品的机器。
:
|
s******e
发帖数: 3 | 26 你用的是未来版Docker吧 :). 去年之前，docker只能运行在linux上，里边运行的也必
须是linux。Docker 对 win hyperv 的支持，好像还是 tech preview。你说的win 之
类的，都是通过virtualbox在玩，生产环境谁用？我做了很多docker image，你说的问
题我都没碰到。
我的主要工作还是写脚本，以前写上万行，shell不行，上perl；现在写几行，超过100
行就感觉心烦意乱，perl也忘光了，工作比以前轻松，出来的东西比以前强，这就是区
别。
【在 d*******r 的大作中提到】
: 你又联系到金瓶梅, 哈哈哈
|
d*******r
发帖数: 3299 | 27 很早就开始玩 Docker 了, 因为我要同时在 Mac, Win, Linux 上敲代码, 所以都折腾过
Win 上开始就是用 VirtualBox 跑的.
不过这个不重要，重要的是我大段说的这一段:
现在一样要维护你的 container build 脚本 (e.g. docker file)
因为 docker file 就是 glue 一堆 bash 而已, 不能保证 reproduce 你的环境.
参考版本以前的讨论: http://www.mitbbs.ca/article_t/Programming/31501247.html
你的 docker file 能不能 reproduce 的你环境, 决定于里面的 bash script 是否精
确追踪安装包版本. 所以你一样要维护你的升级运行环境, 除非你就是黑盒地依赖上次
能跑通的 docker image.
Docker 并不能消除你写维护脚本的工作量, 要求是一样的.
以前本版讨论得很详细了, Docker 最大的好处之一，
是 不写/不爱写/写不好 配置脚本的用户, 能直接下载 Docker image 当黑盒用.
100
【在 s******e 的大作中提到】
: 你用的是未来版Docker吧 :). 去年之前，docker只能运行在linux上，里边运行的也必
: 须是linux。Docker 对 win hyperv 的支持，好像还是 tech preview。你说的win 之
: 类的，都是通过virtualbox在玩，生产环境谁用？我做了很多docker image，你说的问
: 题我都没碰到。
: 我的主要工作还是写脚本，以前写上万行，shell不行，上perl；现在写几行，超过100
: 行就感觉心烦意乱，perl也忘光了，工作比以前轻松，出来的东西比以前强，这就是区
: 别。
|
