Gmail - [shlug] 如何管理ubuntu服务器

shlug] 如何管理ubuntu服务器

AR <aleiphoenix@gmail.com>

Tue, Sep 23, 2014 at 12:39 AM

Reply-To: shlug@googlegroups.com

To: "shlug@googlegroups.com" <shlug@googlegroups.com>

2014-09-22 19:05 GMT+08:00 机械唯物主义 : linjunhalida <linjunhalida@gmail.com>:

Hi Everyone,

最近思考维护线上服务器，几台ubuntu的机器，都是简单业务（rails），
现在在维护问题上面没有什么概念。比如：

- 安装一些工具，是用源里面的还是自己编译？编译是自己做一个ppa然后打包，还是直接源码安装？比如nginx。
- 日常软件更新应该怎么做？定期跑apt-get update && apt-get upgrade?
- 是否要升级大版本？
- 安全更新怎么监控？是看哪里的日报？还是后台跑一个自动安全更新？

谢谢。

PS: 最近一个月在看chef，好复杂的样子，最后还是觉得用chef solo比较简单。

TL;DR 版本，如果服务器规模不大，例如只有10台左右，甚至都是在云服务商那里的，那应该直接使用提供的基础设施就好。没特殊需求的话也是利用现有资源为宜。类似监控等都有现成服务可用，可以考虑一下。规模小自己投入时间精力来做，不会太划算。

既然有人问到了，某简单谈谈自己的经验，首先某还是主要开发，但和自己有关的部分都是自己运维的（可以算是职务便利吧）

下面是长篇废话，前阵子帮运维一起整理过一些规范，由于这块敝厂没几个人能讨论，所以仅是一家之言。

先介绍一下基本背景：

敝厂服务器还是传统的买机房机柜资源，除了硬件、网络这些货源，其他平时上架、巡检维护都是自己做。实体服务器数量大约300-400台左右（具体种类分布某不太清楚，APP大约200台，虚拟机的宿主机大约20台的样子）。

原来使用的是RHEL5 ，DB还在用RHEL6 （这个不敢出去说，其实都没付费，某都吐槽过不知道多少次了，一样用RH系，用CentOS不是挺好嘛）。现在APP基本上都上 Ubuntu Server LTS ，大部分 12.04 ，小部分最近上 14.04 。

Web类业务为主，技术栈是PHP5 ， Java 和 MySQL ， Memcached 为主。其他夹杂一些该有的，比如 Python 、 Ruby 应用， Redis 等。

1. 安装软件用源还是自己编译，还是打包

除非是使用云服务，他们都有提供这些基础设施。

某说的是类似我们这样相对有点尴尬，但有点规模的设施，比如上到几十台了，某觉得可以考虑自己搞 package 的 mirror 以及 repository （例如 apt 、 maven 、 PyPI 等，安装系统、上线版本都比较舒服）

同步官方镜像，例如 apt 。大前提，尽量使用官方源里现有提供的包。

私有包，自建 repo ，需要自己打包的一些原则：

* 官方源里有现成版本，但对应服务器版本不可用的，例如 12.04 使用 php5.5，直接拿官方的 debian 和源代码在对应服务器版本里重新打包。

* 官方源里有，但编译参数或功能不满足的，自己修改打包脚本或上 patch ，重新打包，比如 Nginx 。

* 自写的部分软件新打包（这类极少）

这里遇到的问题是我们运维整体对服务器发行版的熟悉程度比较... 所以 debian 打包的脚本基本需要某来审核的。当然这不是硬流程，有些时候是顾不上运维就直接打包上了。

2. 软件更新

这个一直没有规范，目前定的是没特殊需求的话，不进行 aptitude safe-upgrade 或 full-upgrade 的操作。如果有，一般是采取新给机器，或先在应用池里下线，升级维护完上线的操作。

我们对软件包主要关注的点都不在于系统的更新情况，而在于关注使用的软件是否能满足需求，但又不至于落后太多。

举例：

前阵子 openssl 的问题，我们是仅对和外网有接触的机器，例如 LB 等升级，并重启相关进程的，其他都没动。

我们的Web框架运行在 PHP5.3 ，但现在 5.6 都发布了，所以我们2个月前设立了一个目标是过年前完成全站 PHP5.5 的升级工作。运维这边的支持主要就是提供 PHP5.5 相关的运行环境。

3. 大版本升级

Web主要使用 Ubuntu Server LTS 12.04 与 14.04 这块不是太敏感，因为数量以及变动最大的池是APP，运行PHP与Java，除非是遇到硬件驱动那种人品问题。其他的不会太奢求最新或是版本不变动。

DB MySQL 那边较为特殊，运维工作全部交由 DBA 处理，运维只负责提供硬件、网络基础设施以及基础监控。没了解过如何评估升级的。

4. 安全更新

靠大众媒体吧，现在这消息传的飞快，一般情况下不太可能会漏。

当然，某不管运维这块，最近乌云上报了好几个问题，感觉玄。

5. 机器的安装、运维

我们最开始是用 puppet 的，但大家都知道这货早些时间比较老，用的还是 Ruby 1.8 （不知道现在新版本是否跟上节奏了？），并且敝厂运维有个值得吐槽的地方是研究或折腾某个东西一直到线上使用都是以人为单位的，个人分管一块“业务领域”。这事太玄了，导致缺了这人就玩不转。

所以后来在与架构师讨论比较了几个 provisioner 后，决定统一使用 ansible （包括开发部门也必须有懂运维的人来负责这块）。

就某对几个常见的 provisioner 看法是这样的，他们都有类似的地方，但有些细节（或者叫哲学？）不太一样

puppet 比较老牌，也久经大家使用，缺点是要布个很老的 agent ，还有就是那个 pp 写起来要查个文档不太容易。

chef 也得运行个 agent 。它把整个基础设施都考虑到了，比较全面，如果要自己折腾个 provision 的基础设施设计思路上是可以参考的。比较适合整个设施比较复杂的情景应用（好像哪里不对？）但是他的结果与模块太复杂， recipe 搞的太抽象都有点像 Java 了，上手不易。当初第一次用 vagrant 玩 chef 折腾了 1 天。但下面 ansible 基本上 15 分钟就可以上手玩了。

ansible 简单易上手，Python2.x 的，能想到的基本安装配置类的功能都有了。支持推拉两种模式，客户端机器不需要 agent ，只要有最低 Python 2.4 环境就可以运行（某些特殊的人品问题除外）。缺点是设施还不够全面，但那可能就是其他解决方案了。

另外， puppet 与 chef 的 recipe 不知道有无分发机制？某印象里是没的，谁玩的比较深入可以介绍一下。 ansible 的 role 有，meta 信息可以加依赖但服务端（目前）还未开源，叫 ansible galaxy 。我们目前是自己写了个 Rolefile ，然后整了一个工具脚本从代码仓库获取依赖（服务器管理脚本也类似写代码了，一走上 git 就舒畅啦）。

6 配置管理

这块比较乱，我们自己都还没理清楚，现在每块都有各自的管辖。比如应用程序对 MySQL 的访问配置是独立的。/etc 下系统软件的配置则多半在安装系统时就固定（但我们都知道这不太现实，现在的解决方案是把这类配置都和 ansible 脚本放一起，修改时重新跑一下脚本）。其他的每个团队都有各自的做法。这块基本还没整，所以某没多少可以谈的。

--
Silence is golden.

--
-- You received this message because you are subscribed to the Google Groups Shanghai Linux User Group group. To post to this group, send email to shlug@googlegroups.com. To unsubscribe from this group, send email to shlug+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/shlug?hl=zh-CN
---
您收到此邮件是因为您订阅了Google网上论坛中的“Shanghai Linux User Group”论坛。

自怼圈/年度番新