阿里云有没有上 UBUNTU 18.04LTS 的时间表？

[realpg]

境外友商 5 月就上了，这边 11 月了还没动静

7 个月时间还不够开发监控系统啊

[tyzrj766]

阿里云腾讯云这种不错了，美团 京东这些要么没有要么压根不想上，Linux 里也就个 CentOS7 还行。

[mason961125]

自己系统内升级呗，反正升级了好几次都没问题。

[realpg]

@mason961125 #2
又不是几十台以下的小规模 爱怎么搞怎么搞

[ivmm]

阿里云已经出了啊

[realpg]

@ivmm #4
这不科学

[hash]

debian9 了解一下

[ysc3839]

不能自己安装吗？

[yujincheng08]

我反正自己升上去了

[xiaopc]

前几天用 do-release-upgrade 升级，结果 kernel panic 了...

[zocome]

想办法自己网络挂载安装吧，顺带还能把自带的那些监控给干了，我就是这么安装的 Debian9

[realpg]

@zocome #10
显然是为了集中部署统一管理需求的 多于 2000 台计算节点

[tulongtou]

自己升不一样么？大概花 10 几分钟就好了

[mason961125]

@xiaopc #9 所有配置文件全选新的，这样能成功。

[msg7086]

嗯？都 2000 台计算节点了，做不到自己去做模板机么……

[realpg]

@msg7086 #14
不全是阿里的啊
主要是外部版本号一致 就比较方便的分发和控制包版本，从同一个 apt 源弄出来的软件包都是同样的版本没有差异
有些弹性部署的节点当然是自动化的 但是你自动化创建完事再做可能一堆问题的跨版本升级就蛋疼了

[msg7086]

@realpg 我没看懂为什么这会影响外部版本号一致性。

我自己 VPS/云计算节点，很多都是进 Rescue 以后直接 Debootstrap 装系统，装完系统和软件包以后打一个 Snapshot，以后就全用那个 Snapshot 建新节点了。如果你们对版本那么关注的话，我觉得更应该走这条路线自己管理模板机了吧。

当然我没用过千万云，不知道他们有没有这功能……

跨服务商部署的话应该也是这么做比较方便，进 Rescue 然后 rsync 复制全盘再 Snapshot，还能避免各家厂商自己夹带私货。（比如 OVH 以前乱夹的内核和 rc.local 什么的……

[msg7086]

PS: 没 Rescue 功能的机器可以用 sysrq 把文件系统 ro 以后直接往硬盘里 dd 镜像，完了以后 sysrq 硬重启解决。在 AWS 的 Lightsail 上试过，用来修正 Debian AMI 里分区故意差了 1 扇区的毛病……

[realpg]

@msg7086 #16
你不了解我的需求 把整体架构实现目标从早晨解释到晚上意义也不大

简单说 系统维护部分的需求 就是要各种基本 apt 安装的应用层包的统一升级维护 版本一致性保持 应用层的还有应用层的系统自动化维护机制

现在采用的最省事的办法就是各家的自己直接带的系统（方便有时候的批量起按需实例从 api 直接创建和销毁 也方便傻瓜客户自己购买云服务器） 只要保持外部版本号一致，采用同一个 apt 源就能保证应用层软件的系统维护指令一致时的版本一致性

这些云服务，尤其是国内的，基础结构都有不少 hack，有运维团队单纯的自己想往里搞东西并不是很费劲，但是后续的维护就不可避免的可能出现莫名其妙的问题导致不省心

全部 ubuntu server 的基本服务器应用软件都是基于 apt 包管理安装，自定义的东西也是发布成内部源或者 ppa 源 这个结构是经过多年的结合实际摸索出来的套路 因为涉及很多客户自采半自维服务器 云服务账号 API 都没有，安装我们的引导软件接入平台统一管理 还有一些其他的更乱套的场景需要更细致的

[msg7086]

ermmm 感觉我们讨论完全不在一个位面上。
我从头到尾也都没提到 apt 啊，提的是系统安装……
系统装完以后当然走 apt 管理咯……

虽然大致是能理解你想做什么了。

[Remember]

@realpg 自己装的系统一样可以做一个 image 以后用这个 image 从 api 新建实例，不知道你在纠结什么