不仅是 Linux 运维最佳实践
我们面对的是一个不断变化的世界，业务需求在变，技术架构在变，开源工具与商业系统异构部署，新工具和技术概念层出不穷，唯有一套科学的技术方法论才能应对这些变化。很多时候，我们在面对新的问题时，会束手无措。因此，在 OSC 第 132 期高手问答中，我们策划了“Linux 运维最佳实践”的主题，并邀请了@xufengnju（胥峰）作为高手嘉宾。
@xufengnju（胥峰），资深运维专家，有 10 年运维经验，在业界颇具威望和影响力。也是盛大游戏高级研究员，2006 年毕业于南京大学，2011 年加入盛大游戏，工作至今，曾参与盛大游戏多款大型端游和手游的上线运维，主导运维自动化平台的功能设计和实施。拥有工信部认证高级信息系统项目管理师资格。
自动化运维在近几年一直都是很火热的话题，技术也一直在进步，因此对于技术人员来说，最重要的思维上、思想上的适应与转变。毕竟技术不是运维的终极追求，思想才是运维人员应该毕生修炼的目标！本次高手问答的高手嘉宾对运维服务体系有着深度的思考，因此问答中产生的内容也是十分有质量。
本文从多个角度整理了与运维相关的内容，包括工具的选择、运维中遇到的问题、自动化运维相关等等。
Q&A
1. 对服务器安全和监控，可以推荐一些开源工具吗？监控好像也就 nagios, cacti, zabbix，还有其他可以推荐的吗？安全方面如何监控？
2. Linux 运维中，服务器版本都用什么版本？CentOS 5 还是 CentOS 6、Ubuntu？为什么选择这个版本？有做哪些测试？
3. 对于使用缓存有什么推荐吗？一般就 Redis, Codis。还有那些比较好用的开源软件？
4. 做自动化发布，除了 Jenkins 持续集成工具，还有那些好用的工具呢？
5. 问个 MySQL 问题，三个版本（MySQL（官方版本）、Percona Server 、MariaDB）您建议使用哪个版本，原因是？
6. 服务器日志收集和分析有什么好工具推荐吗？ELK 貌似有点复杂，不太会用，有其他的推荐么？
7. 书里有开源出一些工具和脚本吗，哪里可以下载到？
8. 请问你们现在运维都是基于 Ansible 吗？我们之前都是用 chef puppt 来管理。最近感觉 Ansible 很火，还没实践用过，请问这个用起来差别大吗？
负载均衡器本身的连接数、PPS 数据以及延迟如何进行计算和统计？
2. 对于涉及多个平台（Unix, Linux, Windows）的统一管理（认证，配置，服务）有什么好的解决方案或者思路么？
3. 如何监控服务，业务运行状态监控你是怎么做的？
4. 你们是如何批量管理各个业务模块的机器系统及配置的。我们目录使用 Ansible 使用批量命令和脚本，业务上使用上线平台 SVN 管理业务程序及配置。是否开发了 CMDB 平台？
5. 请问有使用过流量镜像吗？就是把线上的流量镜像一份，引到测试环境，用真实的用户数据测试，想了解下从 0 开始实施的过程。
6. CentOS 6 要如何做系统和网络优化？/etc/sysctl.conf 中的这个参数
7. 如果有 100 多台服务器，大部分都是在提供业务的服务器，如何升级呢？除了停机维护，现在有什么比较好的解决方案吗？
8. LVS 和 HAPROXY 分别能支持多少类似 FARM 的概念？
9. 系统是 CentOS release 6.5 (Final)， 系统没有自动回收内存，16G，我自己写了个 Shell 脚本，每次执行判断小于 1G 的时候回收内存
10. 请问如果是有很多 ECS/VPS，系统一般是 CentOS。目前很多堡垒机也有类似的 SSH 同步密钥下发命令等功能，但是如果还有 Win的堡垒机支持很少。有别的开源工具或者办法来混合管理所有的 Linux, Windows 机器吗？
1. 可以说下什么是自动化运维，如何才算服务器做了自动化运维？包括哪些？自动化发布，有问题可以回滚？
2. 想请问一下自动化运维怎么做的？需要从那些方面考虑？我所考虑到的有实施运维，日常巡检维护，以及故障自动化处理，和提醒。除了这些请问还要注意那些方面？另外，随着 IT 技术的日新月异，涌现了很多新的应用，请问该如果有一个基本的路子来做运维，或者规律，流程来达到运维需求？例如现在比较火的OpenStack Docker 大数据。这些技术实现功能只是很小的一步，更多的是上线后的运维。更多是想要一种思路，能列举大家遇到过的问题，以及问题如何处理？
3. 实现运维自动化，最主要就是配置管理、状态管理和变更管理，其中配置管理要如何来做，有什么好的方法分享下吗？
4. 请问你主导运维自动化平台的功能设计和实施，是通过 Python 开发管理工具吗？另外，你们是重新开发，还是根据 Saltstack 之类的进行二次开发。
2. Web 安全监控有开源解决方案吗，能否做到在接入层就把一些可能的漏洞拦掉？Suricata？
2. Docker 化对运维影响深远吗？
3. 为何国内没有一家成熟的 Docker 方案公布细节呢？
2. 作为运维人员，Python 这样的脚本在进行系统管理和监控的时候相比 Shell 有怎样的优势呢？
3. CentOS 比起 Ubuntu 来说有啥优势？为什么服务器大多用 CentOS？
4. 想问下只有一台服务器，有多个应用，是用 LVS 做负载好还是 Nginx？差别大吗？
2. 备份是怎么做的？上百 T 的图片、附件有什么高雅的备份方案？
2. 作为工作 4 年多的测试工作者，在运维方面也是有一定的涉猎，在公司维护自己的测试环境，有时候也需要一定运维功底，从 Windows Server 到 Linux，学习很多，也总结了很多。上家公司着手 Docker 部署的时候刚好离开公司了。真是有点遗憾，后续工作也没时间去实践，目前使用的是 ng 负载，采用 Tomcat 部署方案，工作实在比较忙，很想在运维方面也有一定的提升！不知道从何入手好，求大神指教。
3. 运维技术挺杂的，如何看待这种杂？给人感觉好像什么都会点，对于工作 5-6 年的运维来说，有什么好的学习建议？
有关 Linux 运维最佳实践的问答内容至此结束，各位读者可以转到原帖浏览更多内容。
原文：运维技术干货 — 不仅是 Linux 运维最佳实践 。 收起阅读 »
@xufengnju（胥峰），资深运维专家，有 10 年运维经验，在业界颇具威望和影响力。也是盛大游戏高级研究员，2006 年毕业于南京大学，2011 年加入盛大游戏，工作至今，曾参与盛大游戏多款大型端游和手游的上线运维，主导运维自动化平台的功能设计和实施。拥有工信部认证高级信息系统项目管理师资格。
自动化运维在近几年一直都是很火热的话题，技术也一直在进步，因此对于技术人员来说，最重要的思维上、思想上的适应与转变。毕竟技术不是运维的终极追求，思想才是运维人员应该毕生修炼的目标！本次高手问答的高手嘉宾对运维服务体系有着深度的思考，因此问答中产生的内容也是十分有质量。
本文从多个角度整理了与运维相关的内容，包括工具的选择、运维中遇到的问题、自动化运维相关等等。
Q&A
一、工欲善其事必先利其器，如何选择工具？
1. 对服务器安全和监控，可以推荐一些开源工具吗？监控好像也就 nagios, cacti, zabbix，还有其他可以推荐的吗？安全方面如何监控？
监控工具各有侧重点，zabbix 同时支持 snmp 和自己的 agent，也支持自定义模板，在大部分场景下都是不错的选择。
另外，不要把 zabbix 视为只能监控服务器信息，通过自定义模板，也可以监控业务层面的指标。安全监控分为主动检测，如 Tenable Nessus，以及 IDS、IPS。
2. Linux 运维中，服务器版本都用什么版本？CentOS 5 还是 CentOS 6、Ubuntu？为什么选择这个版本？有做哪些测试？
目前我们以 CentOS6.X 为主。不同 Linux 分支各有特点，比如 Ubuntu 新版本发布较快，如果追求内核版本升级速度的话，可以考虑。CentOS 一直是我们的主要 Linux 发行版，主要是考虑到它的稳定性以及熟悉程度最高。
3. 对于使用缓存有什么推荐吗？一般就 Redis, Codis。还有那些比较好用的开源软件？
对于类似 session-id 这样的可以非持久存储的数据，可以考虑 memcached，使用一致性哈希算法分布式存储。
4. 做自动化发布，除了 Jenkins 持续集成工具，还有那些好用的工具呢？
目前我所知道的，一般都是 Hudson 或者 Jenkins，后者是前者分支出来的。这些工具都有丰富的插件，灵活使用这些插件是关键所在。
5. 问个 MySQL 问题，三个版本（MySQL（官方版本）、Percona Server 、MariaDB）您建议使用哪个版本，原因是？
我们团队一般使用的是官方版本。主要是考虑到支持和生态。
6. 服务器日志收集和分析有什么好工具推荐吗？ELK 貌似有点复杂，不太会用，有其他的推荐么？
ELK 确实是目前使用比较广泛的日志收集和分析的工具。虽然有些学习成本，但还是值得去研究和尝试的。
7. 书里有开源出一些工具和脚本吗，哪里可以下载到？
书上的脚本我正在整理，其中一部分通过 git 可以下载 https://github.com/xufengnju/books.git
8. 请问你们现在运维都是基于 Ansible 吗？我们之前都是用 chef puppt 来管理。最近感觉 Ansible 很火，还没实践用过，请问这个用起来差别大吗？
各种不同的批量管理工具各具特点，根据自己的熟悉程度和实际业务需要选择一个完全掌握即可
目前 IaaS 平台是自研的，基于 KVM
二、绝知此事要躬行，运维中遇到问题？1. LVS 和 HAPROXY 后端服务器规模可以到什么程度，比如有多少个应用，多少台后端服务器？
这个取决于应用的类型，在实际的业务场景下，需要关注 LVS 等负载均衡器本身的连接数、PPS 数据以及延迟。如果后端吞吐量比较大，可以考虑 LVS 的 DR 模式。一般情况下，负载均衡器不太会成为瓶颈。
负载均衡器本身的连接数、PPS 数据以及延迟如何进行计算和统计？
通过开源的 Zabbix 模板或者自定义模板，这些都不难实现。有没有相关的命令集进行统计，或者详细的统计实例？
针对 HAProxy 建议参考咱们书中 P76 页最佳实践 29 HAProxy 监控的内容。Zabbix 模板技术，建议参考下咱们书中第 12 章的内容。可以使用的命令包括 ipvsadm，netstat 等。
2. 对于涉及多个平台（Unix, Linux, Windows）的统一管理（认证，配置，服务）有什么好的解决方案或者思路么？
先说下认证这一块吧。Unix、Linux 都支持 OpenLDAP 认证，可以考虑，这个和 Windows 下的 AD 是兼容的。配置和服务可以考虑下开源的通用产品，比如 Ansible 或者 Salt。目前我们用的自研系统，思路和 Ansible 类似。
3. 如何监控服务，业务运行状态监控你是怎么做的？
我们的监控系统是自研的，对游戏来说，很重要的一个业务指标是在线人数，它是通过监控系统周期性轮询游戏服务器来进行收集和绘制图表的。
4. 你们是如何批量管理各个业务模块的机器系统及配置的。我们目录使用 Ansible 使用批量命令和脚本，业务上使用上线平台 SVN 管理业务程序及配置。是否开发了 CMDB 平台？
我们批量管理服务器的方式是 ssh，思路和 Ansible 类似。CMDB 提供基础数据的管理，是自研的。
5. 请问有使用过流量镜像吗？就是把线上的流量镜像一份，引到测试环境，用真实的用户数据测试，想了解下从 0 开始实施的过程。
关于流量镜像的原理，可以参考《Linux 运维最佳实践》第 15 章中网卡混杂模式和 RawSocket 技术。看了这一部分后，你应该可以自己写一套。我没有亲自实践过，你可以自己关注下 tcpcopy 这个项目。
6. CentOS 6 要如何做系统和网络优化？/etc/sysctl.conf 中的这个参数
net.ipv4.tcp_max_tw_buckets = 6000要如何设置，是越多越好吗？设置成 16000？
net.ipv4.tcp_max_tw_buckets = 16000
对于系统优化来说，要有针对性。tcp_max_tw_buckets 针对的是 time wait bucket，如系统中 timewait 状态较多，可以考虑 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle 这 2 个值调整。另外，如果使用长连接对于减少该状态的连接数有效。
7. 如果有 100 多台服务器，大部分都是在提供业务的服务器，如何升级呢？除了停机维护，现在有什么比较好的解决方案吗？
如果本身业务切分比较好，例如采用无状态的微服务等架构，可以通过前端负载均衡器进行灰度升级。如果应用做的不好，只有单台的这种，或者集中数据库，就比较麻烦了。
8. LVS 和 HAPROXY 分别能支持多少类似 FARM 的概念？
你说的 FARM 应该是某硬件负载均衡设备的专有名词，应该是负载均衡组的概念。在 LVS 和 HAProxy 里面，负载均衡组的数量上没有硬限制，但实践中一般不会配置太多，因为这涉及到维护成本以及 HA 环境下主备切换时的开销。
9. 系统是 CentOS release 6.5 (Final)， 系统没有自动回收内存，16G，我自己写了个 Shell 脚本，每次执行判断小于 1G 的时候回收内存
可以关注下 sysctl 中 swap 以及 swappiness 的一些配置
10. 请问如果是有很多 ECS/VPS，系统一般是 CentOS。目前很多堡垒机也有类似的 SSH 同步密钥下发命令等功能，但是如果还有 Win的堡垒机支持很少。有别的开源工具或者办法来混合管理所有的 Linux, Windows 机器吗？
在我的这个演讲里面讲到了异构系统的批量管理方法，你可以参考下。
http://www.build.net/greatops/453250.html 。另外，你可以参考下 Ansible 或者 salt。
三、自动化运维相关，工程师思维？
1. 可以说下什么是自动化运维，如何才算服务器做了自动化运维？包括哪些？自动化发布，有问题可以回滚？
运维自动化是一个仁者见仁智者见智的概念。我的理解是，运维自动化要打通从代码开发完到正式上线的所有环节，包括版本构建、打通自动测试、自动化上线以及自动化监控。
在这个大命题下，可以根据自己工作环境和自动化水平的不同，选择一两个痛点开始进行自动化实践。最后形成完整体系。
2. 想请问一下自动化运维怎么做的？需要从那些方面考虑？我所考虑到的有实施运维，日常巡检维护，以及故障自动化处理，和提醒。除了这些请问还要注意那些方面？另外，随着 IT 技术的日新月异，涌现了很多新的应用，请问该如果有一个基本的路子来做运维，或者规律，流程来达到运维需求？例如现在比较火的OpenStack Docker 大数据。这些技术实现功能只是很小的一步，更多的是上线后的运维。更多是想要一种思路，能列举大家遇到过的问题，以及问题如何处理？
你的问题很好，但这个话题比较大。我先说下我的理解吧。传统的运维服务流程 ITIL 还有一定的价值，但需要结合一些 DevOps 思想来进行适当的改造，融合两者的长处。从拥抱变化开始，以一种开放的态度来进行运维。但不变的一点是，以为业务创造价值为最终目标，这就是运维的目标。
3. 实现运维自动化，最主要就是配置管理、状态管理和变更管理，其中配置管理要如何来做，有什么好的方法分享下吗？
对配置管理，我认为应该分为“基础架构资源配置管理”和“软件/应用配置管理”。
前者是一般意义上的 CMDB 的范畴，这个可以根据自己业务特点在开源 CMDB 方案的基础上做一定的适配；
对于后者，一方面是系统（例如版本控制系统的结合），一方面是流程（例如和变更管理挂钩）。在我们的实践中，这 2 个方面都有涉及。
4. 请问你主导运维自动化平台的功能设计和实施，是通过 Python 开发管理工具吗？另外，你们是重新开发，还是根据 Saltstack 之类的进行二次开发。
底层使用 SSH 协议建立服务器管理通道，上层使用 PHP 开发管理界面以及封装一些常用操作，比如密码修改、脚本下发和执行等。完全自主开发。
四、做好安全措施很重要，安全相关的问题1. 运维离不开安全，服务器的安全也很重要，书中有讲运维安全这块吗，如何把控安全这块？
书中有安全主题。安全是一个庞大的体系，书中主要讲了保障 Linux 系统安全的一些措施。其他安全主题，比如社会工程和入侵检测，可能需要看更专业的书。你可以先看看咱们《Linux 运维最佳实践》是否能满足你的基本安全需求。谢谢支持。
2. Web 安全监控有开源解决方案吗，能否做到在接入层就把一些可能的漏洞拦掉？Suricata？
Suricata 没有研究和实践过。《Linux 运维最佳实践》中第 11 章 Web 服务器安全部分提到了几个工具，你可以参考下。但 ModSecurity 规则在上线前要进行严格详细测试，不要出现误判。另外，建议对生产环境进行定期的安全扫描，例如使用 Tenable Nessus 工具等。安全专家的人工渗透测试也是必须的。
五、Docker 很火热，在运维中结合使用？1. 在网易游戏运维中是否用到了最近很火的 Docker 技术以及应用在哪，存在什么问题，如何解决？
目前我们在调研 Docker 技术，只有少量游戏测试使用。需要根据不同的业务模型选择对应的网络模型和存储方案。Docker 技术会改变传统的运维方式，要考虑和原有运维系统整合以及运维习惯的调整所带来的挑战。另外，我不是网易公司的，我目前在盛大游戏工作。
2. Docker 化对运维影响深远吗？
Docker 化对运维有影响，它带来的影响包括：持续交付、微服务以及 DevOps 理念的冲击。作为运维，我们要拥抱这个变化，通过不断学习和实践来迎接这些挑战。
3. 为何国内没有一家成熟的 Docker 方案公布细节呢？
Docker 还是一个新生事物，各家使用的场景和模式有所不同，而且会有一些二次开发的管理系统和调度系统。
六、不是所有对比都会产生伤害，工程师想的只是最优方案1. 游戏服务器运维和网站服务器运维以及 APP 服务器运维，有哪些不同点和相同点？
这个问题很有代表性。不同点是，网站和 APP 运维接触的通用开源软件比较多，游戏运维接触的大部分都是自研的程序。
共同点是，都需要掌握操作系统知识、软件硬件以及网络知识，还有排查问题的思路和容量规划等。两者都需要引入运维自动化的思维和体系。《Linux 运维最佳实践》最后 2 章描述了游戏运维的相关体系和技术。
2. 作为运维人员，Python 这样的脚本在进行系统管理和监控的时候相比 Shell 有怎样的优势呢？
作为高级编程语言，Python 有非常丰富的库，包括核心库和第三方库，很多时候不需要自己造轮子；
相比 Shell，它有更好的控制力、重试机制，比如对 Socket 设置超时等等。
3. CentOS 比起 Ubuntu 来说有啥优势？为什么服务器大多用 CentOS？
不同 Linux 分支各有特点，比如 Ubuntu 新版本发布较快，如果追求内核版本升级速度的话，可以考虑。CentOS 一直是我们的主要 Linux 发行版，稳定性以及熟悉程度最高。
选择某个发行版时，要考虑它的生态，比如上下游的支持，还有一点，就是运维人员招聘的方便程度，国内熟悉 CentOS 的稍多一些。
4. 想问下只有一台服务器，有多个应用，是用 LVS 做负载好还是 Nginx？差别大吗？
你说的后端应用是基于 HTTP 或者 HTTPS 的吗？如果是的话，并且吞吐量不大的情况下，使用 Nginx 即可；如果非 HTTP 或者 HTTPS 的 TCP 应用，建议使用 LVS；如果 HTTP 或者 HTTPS 吞吐量特别大的情况下，使用 LVS DR 模式。
七、You Need Backup，与备份相关的一些问题1. 1000 台机器规模，备份系统应该要做到什么程度？
1000 台服务器，要区分业务类型，如果类型单一，备份就比较好做。如果类型多，那么要考虑的地方包括：数据库更新的频率（全备+增量备份？还是只使用全备）、数据备份的大小、数据集中归档的要求。
2. 备份是怎么做的？上百 T 的图片、附件有什么高雅的备份方案？
在线备份这一块，可以考虑使用 erasure coding 算法，在增加一定可靠性的能力下，不至于导致备份存储的成本过高。同时要考虑离线备份，比如磁带。
八、路漫漫其修远兮，运维工程师的职业生涯1. 你觉得在未来，运维的核心会是什么，自动化，预判或是其他？
我觉得，未来的运维应该是智能化的。把现在需要人做的容量规划、扩缩容、排障全部实现智能化。运维的任务就是编程，把自己的能力灌输到机器上。当然，理想很丰满，现实很骨感。这需要我们的不懈努力。
2. 作为工作 4 年多的测试工作者，在运维方面也是有一定的涉猎，在公司维护自己的测试环境，有时候也需要一定运维功底，从 Windows Server 到 Linux，学习很多，也总结了很多。上家公司着手 Docker 部署的时候刚好离开公司了。真是有点遗憾，后续工作也没时间去实践，目前使用的是 ng 负载，采用 Tomcat 部署方案，工作实在比较忙，很想在运维方面也有一定的提升！不知道从何入手好，求大神指教。
从你的描述来看，目前是兼职运维。我建议是否可以考虑，在搭建环境之外，多多研究下其中的原理，同时用自动化脚本维护这些环境呢。相信你也有一些编程经验，这些对于你后续实践运维也是有帮助的。另外，就是可以多看看别人总结的运维案例，少走一些弯路。
3. 运维技术挺杂的，如何看待这种杂？给人感觉好像什么都会点，对于工作 5-6 年的运维来说，有什么好的学习建议？
4. 由于运维系统有全面的数据收集、自动处理、报警和自动恢复的机制，我们这里将运维和 BI 结合在一起。扩展运维工具和架构，将已成熟的 BI 接入运维体系，解放业务专员的工作，常规的业务分析、报表、数据监控都可依赖这套运维系统。在我们这里，运维从一层平台逐渐变成一种框架，有需要的场景都可以套用。技术一直在变，但最重要的不是技术，而是用技术提供服务的思想。 除了和 BI 结合，运维思维还可以和哪些相关业务场景结合，可以在新的方向上产生价值呢？
如你所说，运维技术要求范围确实蛮广的。我觉得，对于工作了一定时间的运维同学来说，可以考虑的方向有以下几个：
- DevOps 实践（加强自己的编程能力，系统学习一门高级编程语言，运维自动化）
- 对自己的技术薄弱点重点学习，比如系统学习网络知识
- 看一些比较好的运维技术书籍，学习别人的干货
5. Devops 对运维有那些改变，能简单说下嘛？我很赞同你的想法和实践，“用技术提供服务的思想”。我个人认为，运维的终极目标可能是“没有运维工程师的”自运维，或者叫智能运维，是 AI 在运维领域的深度融合和实践。容量规划算法的不断优化、基于公有云的资源自动调度都应该是智能化的。当然，实现这个目标还有很长的路要走。
6. 现在哪个版本的 Linux 使用最广泛，还有 Linux 运维，我们需要学习一些语言吗，比如 Python 之类，这样才能算是一个真正的好运维？Devops 从概念提出到现在已经有一段比较长的时间了，总体来说，我认为它带来的变化是：持续交付能力需要打通研发、测试和部署运维的整个链路，它对运维自动化的能力要求更高了。我们必须通过掌握一些运维自动化框架加上一定的编程能力才能根据业务场景来应对这种变化。另外，对运维来说，就是要拥抱变化，以开放的态度进行协作。
7. 请问您写书，是怎么坚持写下来的？是把平时工作重点的问题，记录下来，每天写一点，再总结吗？写书有什么工具软件吗，还是只是用 Word 来写？能分享下写运维书籍的方法吗？不要犹豫了，立即开始学习编程吧，不管 Perl 还是 Python，熟悉哪一种都行。在这里，我不对比 Perl 和 Python 的优缺点。坚持用自己的代码（加上别人的框架和库）来解决重复的运维问题，你会成长的更快。CentOS 用的比较多。《Linux 运维最佳实践》第 18 章是使用 Perl 进行系统自动化编程的内容，你可以先看看。如果感兴趣的话，立即开始吧。
这个问题非常好，也是我想分享的。写书的素材依赖于平时的积累，建议大家平时多写写标准的文档，word 格式可以参考咱们这本书的编排。比较重要的 3 点是：
- visio 图要保留下来，不能只存图片，因为可能还要调整排版
- 有些故障现场，尽量记录详细，现象和分析过程、辅助的日志和抓包文件等，建议都保留下来
- 脚本按照分类保存下来，以便查找
有关 Linux 运维最佳实践的问答内容至此结束，各位读者可以转到原帖浏览更多内容。
原文：运维技术干货 — 不仅是 Linux 运维最佳实践 。 收起阅读 »
基于CMDB与SALTSTACK的运维自动化之路
作者介绍
张延礼，现苏州蜗牛高级运维经理，就职于腾讯多年，熟悉基础架构运维及业务运维，在运维技术实施、流程及标准化体系建设、运维自动化架构设计及实现，运维支撑体系规划和执行团队管理等方面具有丰富经验。
正文
本文基于蜗牛从零开始建设运维自动化的一些实践，总结自动化建设过程中涉及的体系规划、实施路线、产品设计及架构设计等方面的经验。
一、自动化体系规划
1、自动化要解决什么问题
运维层面的工作可以归结为如下三大块
服务管理层面主要是从运维总体支撑的角度来管理运维质量、规范、成本等等，处在运维工作的最高层；技术决策主要是为实现管理目标去制定总体方案，实施路径；技术执行则是落地的最后一环，这一环工作往往呈现零散、杂乱、重复、频繁变更的特点，承接的需求量最多，但价值体现却是较低的一环。
当前运维自动化的首要目标还是在解决”技术执行”这一层面的问题：将大量重复低价值含量的人力实施变成自动化执行，最大化地降低人力依赖，提升运维效率及业务支撑能力。
2、自动化建设思路
对于如何建设自动化运维，个人认为首要的是要有建设思路与方法论，以下供参考：
3、自动化建设总体框架
自动化的建设水平在行业内差异化还是明显的，如果处于运维自动化起步的阶段，建议是组建运维开发团队，从整体规划，基于ESB思想，分层建设，让支撑平台从业务逻辑中解耦。比如就业务运维而言，整个操作工作面无非就是对业务运营环境的各种操作、配置，以及对业务应用程序的管理，简单来说就是OS层和应用层。
要做自动化实施首先得有准确对称的数据，然后需要一个统一的管控平台，能并发的控制和操作远程大量主机，这解决了OS层面的操作问题，但需要管理应用层面的东西还需要与应用的研发人员规范相关接口，这对于开源组件应用而言一般不会有什么问题。因此如果是从零开始做自动化，个人认为CMDB、管控平台、业务进程管理工具这三部分是地基。在此基础之上，可以针对运维各类场景和业务逻辑去做相应的垂直功能系统，再上一层，可以使用流程引擎之类的组件来实现业务运维流程的纵向整合，最终实现运维各类业务流程的纯线上自动化。
二、自动化实施路线
业务发展往往带来运维块面的应用形态、运营环境、、部署结构、基础架构规模及组织流程等多样化、复杂化；如无统一的标准及规范，运维支撑工作将异常混乱，自动化也难以实施。因此自动化有一个基础:标准化，标准化是将一切杂乱无章、千头万绪的运维工作变得有序及可控，流程规范与执行标准的落地是自动化的一大基石。结合我司实际运维现状及需求，基于以上自动化体系建设思路，前期规划的建设线路如下
1、信息的标准化管理：CMDB
在运维工作中，信息的管理往往是难点，运维侧涉及的信息太多，且也与其他职能部门多点关联，信息流转于整个流程的多个职能部门、多个环节
中小型企业中，手工线下记录的方式居多，线上线下信息一致性保持、内部外部信息传递、共享、同步等均存在较大问题，经常出现:
- 线下表格有，实际位置找不到，或信息不对称
- 不清楚设备状态，不清楚哪个业务在使用
- 一个部门做了变更，其他部门不知情
- 变更一条上联链路，无法及时判断影响范围及程度
- CI及属性需要贴合实际环境，同时考虑长期的运维规划
- 管理的不仅是CI及其属性，还有CI之间的关系，状态流转机制等等
- 充分考虑扩展性及灵活性，如引入自定义属性来满足未来或暂时不可预见的需求
- 良好的scale-up/scale-out，灵活扩展，支持复杂网络结构
- 轻量级、高效的后端通信机制，成千上万的管理规模
- 跨平台，支持windows、unix-like多平台，无需重复开发
- 全网统一的一套基于web的用户界面，将所有操作逻辑通过web层来调用salt-api，web前端提供与直接登录机器操作一样的灵活性和自由度，运维人员在web上完成所有操作。
- 对运维操作进行建模，将其分解为几大原子操作类型，一切复杂的序列化操作逻辑可通过原子的自由组合来实现，给用户提供自由灵活的操作方式
- 基于以上逻辑，再给salt加一层应用接口，便于后续其他系统平台可直接调用或整合UJOBS以建设更高层次的平台。
后端salt的逻辑这里不赘述，由于实际网络环境的特殊性，我们采用了二层架构，即master-syndic-minion,公网与内网相结合的方式最大限度提升系统性能。
权限控制、执行对象等等与CMDB打通，可以非常灵活的适应各类业务，各种场景。
如运维人员可以在界面定义好一个版本发布作业：xx业务发布，分解整个发布流程中到每一步骤，并写脚本或调用外部接口来实现具体的操作，最终线上操作只需在页面点击开始执行就可：
当然用户自定义作业可以复用，通过传参的方式实现实例化，避免必要每次发布都建作业。
3、建设过程中的问题总结
做好产品设计及架构设计
充分解析运维内部需求，各具体平台或产品业务区分明确，产品定位一定要清晰，不要想着让微波炉具备电冰箱的功能，自动化整个体系不是一个产品能解决所有问题，需要自顶向下分层设计，产品之间相互解耦且又对外提供接口，能方便的整合与被整合。
组建运维内部开发团队
运维自动化的建设，最好是组建运维内部团队来进行开发，直接丢给业务研发部门往往做出来的东西不是运维侧想要的，因其不易理解运维侧的需求场景、痛点，操作方式等等；如实在没有运维开发团队，那就找个深度理解运维场景的PM去跟开发团队吧。
推动业务开发侧的标准化
其实产品开发团队的研发管理水平及标准化程度直接决定了运维人员爽与不爽，绝大多数研发人员往往只考虑产品功能实现，而很少关注可维护性设计，导致业务给运维人员带来很大的无价值工作量，更有甚者直接是将运维人员当成代码逻辑的一部分。让运维人员参与产品研发的可维护性设计是很多必要的，运维侧需形成可维护性标准规范，推动业务开发遵循将非常利于运维自动化的建设。
文章来源：微信订阅号"运维帮"
地址：http://dwz.cn/6c2Yqz
收起阅读 »
利用ITIL建立高效能IT服务
急需转型的企业IT服务
在企业里，IT部门一般是作为服务部门而存在，大部分企业IT部门是以提供基础架构服务和通用IT服务为主，如何提高系统的可用性和提升响应速度就变成IT服务管理内容的核心。
目前，国内企业的IT管理经历了系统管理、网络管理之后，现在正逐渐向IT服务管理阶段过渡。但许多企业IT服务远没有实现主动式管理，依然停留在服务支持管理的层面上。
目前，IT已成为许多业务流程中必不可少的部分，IT服务地位的提升意味着IT要承担更大的责任。一方面，IT必须满足业务流程不断变化的需求;另一方面，IT服务的相关成本也要随之不断降低。但是我们看见，IT在这两个方面都没有做出令人满意的答案。
IT服务管理的根本目标有三个：
如果简单说明，IT服务管理可概括为"二次转换"，第一次是"梳理"，第二次是"打包"。
首先，将纵向的各种IT技术管理工作(传统IT管理的重点)，如服务器管理、网络管理和系统软件管理等进行“梳理”，形成典型的流程，这是第一次转换。这主要是供IT部门内部使用，用户对此并不感兴趣。但是，仅是这些流程还不能保证服务质量或客户满意，还需将流程按需”打包“成特定的IT服务，提供给用户，这是第二次转换。
简单来说，第一次转换是将IT技术管理转化为IT流程管理，第二次转换是将IT流程管理转化为IT服务管理。
从用户的角度来说， IT只是提高运营业务效率的一种工具，用户不需要对IT有太多的了解，用户需要的是IT所实现的功能。用户和IT部门之间的交流，使用的是”商业语言“而不是”技术语言“，IT部门需要向用户提供的是 IT服务。
为了能够灵活、及时和有效地提供IT服务，并保证服务质量、理化计算有关成本，IT服务就必须事先对服务进行一定程度上的分类和打包。
ITIL的全名是IT基础设施库，简单的说，就是一套针对各行业的IT服务管理标准库。 ITIL结合流程、人员和技术三要素，为企业的IT构建一套从计划、研发、实施到运行维护的最佳实践方案。
一套协同流程是ITIL框架的核心，它通过服务级别协议(SLA)来保证IT服务的质量。它融合了系统管理、网络管理、系统开发管理等管理活动，以及关于变更管理、资产管理、问题管理等许多流程的理论和实践。
ITIL提供的是一种流程处理的IT服务管理方案，它通过工作单形成IT服务流程闭环，以确保整个IT服务过程有据可查。同时，ITIL还制定了明确的服务流程规范，员工需要严格按照流程进行操作。ITIL不断高效地解决IT服务问题，提高IT部门服务效率，以此使用户感到满意，从而达到优质的服务。ITIL是一个很好的手段， 它简化了IT服务管理，变得优质与高效。
建立高效能IT服务告别危机时代
IT服务的质量目标是各方对IT服务管理的期望，它是业务部门和IT部门双方根据业务目标制定的。一个好的IT服务目标要有这几个方面的作用：明确持续服务管理，改进活动的方向;促使有关人员朝正确方向采取行动;协调不同人员的多个行动;简要有力地说明高层管理者的意图。
评估企业目前的IT服务管理现状和成熟度级别是核心步骤之一。ITIL自我评估手册提供了一个全面的评估方法。因为，用户的需求和IT服务现状是决定所提供IT服务的基础，而服务流程、职能、技能、企业结构和文化等则是根据用户需求和所提供的服务类型决定的。
分析和评价的现状要从这几个方面考虑：IT部门是否理解业务战略和方向、业务面临的问题;IT部门是否理解技术对业务的作用;IT部门和业务部门对当前IT服务成熟度和IT服务质量的看法是否一致;IT部门是否清楚了解利益相关者的需求; IT部门是否清楚了解不改进IT服务质量的后果等。
管理方案包括两个方面，一是选用何种服务管理工具，二是进行教育、培训、文化变革。经验表明，成功的IT服务管理实施，更多的是要依靠后者。
这一阶段的IT服务工作包括以下几点：
文件和制度制定：主要有IT制度文件准备、编制用户手册、工作记录手册及IT管理人员工作指南等。
员工培训工作：对与IT系统相关的每位员工都要进行适当的培训，一方面是对IT人员要加强业务知识技能的培训，理解业务原理及本质
对业务人员要加强IT知识技能的培训，通过培训可以使IT业务人员都能理解IT服务管理各流程的基本原则。
关键成功因素和绩效指标决定IT服务考核标准
检查IT服务效果是保障IT服务高质量的关键过程之一。这需要事先明确定义一系列可测量的目标和指标，然后在每个时期内进行评审，检查IT服务目标是否达到，服务质量是否得到提高。否则，就需要提出和采取补救和改进措施来实现预期目标。
因此，可以先为每个IT服务确定和定义一些关键成功因素(CSF)和关键绩效指标 (KPI)。关键成功因素是使每个IT服务达到高质量所需达到的最低要素，关键绩效指标是测量每个关键成功因素是否实现的具体数量指标。关键成功因素和关键绩效指标建立了每个IT服务的绩效考核基准。
俗语说：创业难，守业更难。逆水行舟，不进则退。先前的IT服务活动已经达到目标，继而就要巩固取得的成果并采取进一步的改进行动。我们必须明白一个道理，提高IT服务质量是一个永无止境的持续过程。
摩卡业务服务管理(Mocha BSM)能够监控基础设施和应用，也能够将复杂的IT设施转化为简单的业务视图，它帮助我们从IT服务的角度出发，保障IT部门提供稳定可靠的服务。
阅读分享：http://www.sootoo.com/content/47944.shtml 收起阅读 »
在企业里，IT部门一般是作为服务部门而存在，大部分企业IT部门是以提供基础架构服务和通用IT服务为主，如何提高系统的可用性和提升响应速度就变成IT服务管理内容的核心。
目前，国内企业的IT管理经历了系统管理、网络管理之后，现在正逐渐向IT服务管理阶段过渡。但许多企业IT服务远没有实现主动式管理，依然停留在服务支持管理的层面上。
IT服务管理的必要理念
目前，IT已成为许多业务流程中必不可少的部分，IT服务地位的提升意味着IT要承担更大的责任。一方面，IT必须满足业务流程不断变化的需求;另一方面，IT服务的相关成本也要随之不断降低。但是我们看见，IT在这两个方面都没有做出令人满意的答案。
IT服务管理的根本目标
IT服务管理的根本目标有三个：
- 第一，以用户为中心提供IT服务
- 第二，提供高质量、低成本的服务
- 第三，提供可量化计价的服务。
如果简单说明，IT服务管理可概括为"二次转换"，第一次是"梳理"，第二次是"打包"。
首先，将纵向的各种IT技术管理工作(传统IT管理的重点)，如服务器管理、网络管理和系统软件管理等进行“梳理”，形成典型的流程，这是第一次转换。这主要是供IT部门内部使用，用户对此并不感兴趣。但是，仅是这些流程还不能保证服务质量或客户满意，还需将流程按需”打包“成特定的IT服务，提供给用户，这是第二次转换。
简单来说，第一次转换是将IT技术管理转化为IT流程管理，第二次转换是将IT流程管理转化为IT服务管理。
从用户的角度来说， IT只是提高运营业务效率的一种工具，用户不需要对IT有太多的了解，用户需要的是IT所实现的功能。用户和IT部门之间的交流，使用的是”商业语言“而不是”技术语言“，IT部门需要向用户提供的是 IT服务。
为了能够灵活、及时和有效地提供IT服务，并保证服务质量、理化计算有关成本，IT服务就必须事先对服务进行一定程度上的分类和打包。
ITIL高效解决IT服务问题
ITIL的全名是IT基础设施库，简单的说，就是一套针对各行业的IT服务管理标准库。 ITIL结合流程、人员和技术三要素，为企业的IT构建一套从计划、研发、实施到运行维护的最佳实践方案。
一套协同流程是ITIL框架的核心，它通过服务级别协议(SLA)来保证IT服务的质量。它融合了系统管理、网络管理、系统开发管理等管理活动，以及关于变更管理、资产管理、问题管理等许多流程的理论和实践。
ITIL提供的是一种流程处理的IT服务管理方案，它通过工作单形成IT服务流程闭环，以确保整个IT服务过程有据可查。同时，ITIL还制定了明确的服务流程规范，员工需要严格按照流程进行操作。ITIL不断高效地解决IT服务问题，提高IT部门服务效率，以此使用户感到满意，从而达到优质的服务。ITIL是一个很好的手段， 它简化了IT服务管理，变得优质与高效。
建立高效能IT服务告别危机时代
清晰IT服务质量SLA目标
IT服务的质量目标是各方对IT服务管理的期望，它是业务部门和IT部门双方根据业务目标制定的。一个好的IT服务目标要有这几个方面的作用：明确持续服务管理，改进活动的方向;促使有关人员朝正确方向采取行动;协调不同人员的多个行动;简要有力地说明高层管理者的意图。
分析IT服务管理的现状
评估企业目前的IT服务管理现状和成熟度级别是核心步骤之一。ITIL自我评估手册提供了一个全面的评估方法。因为，用户的需求和IT服务现状是决定所提供IT服务的基础，而服务流程、职能、技能、企业结构和文化等则是根据用户需求和所提供的服务类型决定的。
分析和评价的现状要从这几个方面考虑：IT部门是否理解业务战略和方向、业务面临的问题;IT部门是否理解技术对业务的作用;IT部门和业务部门对当前IT服务成熟度和IT服务质量的看法是否一致;IT部门是否清楚了解利益相关者的需求; IT部门是否清楚了解不改进IT服务质量的后果等。
制定高效的IT服务管理方案
管理方案包括两个方面，一是选用何种服务管理工具，二是进行教育、培训、文化变革。经验表明，成功的IT服务管理实施，更多的是要依靠后者。
这一阶段的IT服务工作包括以下几点：
文件和制度制定：主要有IT制度文件准备、编制用户手册、工作记录手册及IT管理人员工作指南等。
员工培训工作：对与IT系统相关的每位员工都要进行适当的培训，一方面是对IT人员要加强业务知识技能的培训，理解业务原理及本质
对业务人员要加强IT知识技能的培训，通过培训可以使IT业务人员都能理解IT服务管理各流程的基本原则。
关键成功因素和绩效指标决定IT服务考核标准
检查IT服务效果是保障IT服务高质量的关键过程之一。这需要事先明确定义一系列可测量的目标和指标，然后在每个时期内进行评审，检查IT服务目标是否达到，服务质量是否得到提高。否则，就需要提出和采取补救和改进措施来实现预期目标。
因此，可以先为每个IT服务确定和定义一些关键成功因素(CSF)和关键绩效指标 (KPI)。关键成功因素是使每个IT服务达到高质量所需达到的最低要素，关键绩效指标是测量每个关键成功因素是否实现的具体数量指标。关键成功因素和关键绩效指标建立了每个IT服务的绩效考核基准。
总结
俗语说：创业难，守业更难。逆水行舟，不进则退。先前的IT服务活动已经达到目标，继而就要巩固取得的成果并采取进一步的改进行动。我们必须明白一个道理，提高IT服务质量是一个永无止境的持续过程。
摩卡业务服务管理(Mocha BSM)能够监控基础设施和应用，也能够将复杂的IT设施转化为简单的业务视图，它帮助我们从IT服务的角度出发，保障IT部门提供稳定可靠的服务。
阅读分享：http://www.sootoo.com/content/47944.shtml 收起阅读 »
Centos7下使用Yum安装Zabbix2.4
一、Zabbix简介
zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。
二、Zabbix安装
本文档在同一台机器上安装了zabbix-server 和zabbix-agent 自己监控自己。
1、配置LAMP
这个可以参考之前的文章：http://openskill.cn/article/578
2、配置Yum源
Zabbix在CentOS基本源里不可获得，因此必须配置EPEL 和Zabbix 官方repository
安装EPEL repository
yum install epel-release配置ZabbixZone package repository and GPG key
rpm --import http://repo.zabbix.com/RPM-GPG-KEY-ZABBIX3、安装Zabbix server and agent（agent是可选的）
rpm -Uv http://repo.zabbix.com/zabbix/2.4/rhel/7/x86_64/zabbix-release-2.4-1.el7.noarch.rpm
安装Zabbix server and agent:（配置自己监控自己，所以安装了zabbix-agent）
yum install zabbix-server-mysql zabbix-web-mysql zabbix-agent zabbix-java-gateway编辑 file /etc/httpd/conf.d/zabbix:
vi /etc/httpd/conf.d/zabbix.conf更新时区:
php_value date.timezone Asia/Shanghai重启httpd
systemctl restart httpd
4、创建MySQL 数据库和用户
登录MariaDB:
mysql –u root –p创建一个数据库‘zabbixdb’和数据库用户‘zabbix’
MariaDB [(none)]> create database zabbix character set utf8;
MariaDB [(none)]> grant all privileges on zabbix.* to 'zabbix'@'localhost' identified by 'zabbix';
MariaDB [(none)]> flush privileges;
5、数据库导入zabbix template
使用数据库用户zabbix登录数据库
mysql –uzabbix –p切换到zabbix数据库
use zabbix导入模板数据
MariaDB [zabbix]> source /usr/share/doc/zabbix-server-mysql-2.4.7/create/schema.sql
MariaDB [zabbix]> source /usr/share/doc/zabbix-server-mysql-2.4.7/create/images.sql
MariaDB [zabbix]> source /usr/share/doc/zabbix-server-mysql-2.4.7/create/data.sql
6、配置Zabbix server
编辑文件/etc/zabbix/zabbix_server.conf
vi /etc/zabbix/zabbix_server.conf配置下面的三个参数
[...]
DBName=zabbix
[...]
DBUser=zabbix
[...]
DBPassword=zabbix
[...]
7、配置zabbix-agent
vi /etc/zabbix/zabbix_agentd.conf配置zabbix server 的ip
[...]
## Line 85 - Specify Zabbix server ##
Server=127.0.0.1
[...]
## Line 126 - Specify Zabbix server ##
ServerActive=127.0.0.1
[...]
## Line 137 - Specify Zabbix server Hostname or IP address ##
Hostname=127.0.0.1
[...]
8、修改PHP 设置
修改php.ini为zabbix 建议的设置
编辑文件 php.ini
vi /etc/php.ini设置下面的参数
max_execution_time = 600
max_input_time = 600
memory_limit = 256
Mpost_max_size = 32M
upload_max_filesize = 16M
date.timezone = Asia/Shanghai
9、修改Firewall 和SELinux 设置
开放zabbix端口10050 and 10051.
firewall-cmd --permanent --add-port=10050/tcp重启firewall
firewall-cmd --permanent --add-port=10051/tcp
systemctl restart firewalld如果使用 SELinux, 运行以下命令使 Apache 可以和 Zabbix通信
setsebool -P httpd_can_connect_zabbix=1
10、允许Zabbix web console 对特定IP段可用 (可选)
编辑文件 /etc/httpd/conf.d/zabbix.conf
vi /etc/httpd/conf.d/zabbix.conf添加允许访问 zabbix web interface的ip段. 如果设置 ‘Allow from All’, 这可以允许全部可以访问
#启动zabbix-server 和zabbix-agent。重启httpd,，并设置zabbix-server和zabbix-agent开机自动启动
# Zabbix monitoring system php web frontend
#
Alias /zabbix /usr/share/zabbix
Options FollowSymLinks
AllowOverride None
Require all granted
php_value max_execution_time 300
php_value memory_limit 128M
php_value post_max_size 16M
php_value upload_max_filesize 2M
php_value max_input_time 300
php_value date.timezone Asia/Shanghai
Require all denied
Require all denied
systemctl start zabbix-server
systemctl start zabbix-agent
systemctl restart httpd
systemctl restart mariadb
systemctl enable zabbix-server
systemctl enable zabbix-agent ---- (可选)
11、通过控制台配置Zabbix
浏览器访问http://ip-address/zabbix
数据zabbix数据库名、数据库用户和密码，并测试
输入Server name(可选)
预安装summary
点击完成，完成安装
安装完成后，重定向到zabbix控制台登录页面. 输入用户名和密码，默认的用户名和密码为admin/zabbix.
管理仪表盘页面如下
英文原文地址：http://www.unixmen.com/how-to-install-zabbix-server-on-centos-7/ 收起阅读 »
Centos7下配置LAMP过程记录
LAMP指的Linux（操作系统）、Apache HTTP 服务器，MySQL（有时也指MariaDB，数据库软件）和PHP（有时也是指Perl或Python）的第一个字母，一般用来建立web应用平台。所有组成产品均是开源软件，是国际上成熟的架构框架，很多流行的商业应用都是采取这个架构，和Java/J2EE架构相比，LAMP具有Web资源丰富、轻量、快速开发等特点，微软的.NET架构相比，LAMP具有通用、跨平台、高性能、低价格的 优势，因此LAMP无论是性能、质量还是价格都是企业搭建网站的首选平台。
下面讨论如何在RHEL/CentOS/Scientific Linux 7上搭建LAMP环境.
Apache HTTP Server（简称Apache）是Apache软件基金会的一个开放源码的网页服务器，可以在大多数计算机操作系统中运行，由于其多平台和安全性被广泛使用，是最流行的Web服务器端软件之一。它快速、可靠并且可通过简单的API扩展，将Perl/Python等解释器编译到服务器中。
在终端以root权限运行以下命令:
浏览器访问 http://localhost/ or http://server-ip-address/
MariaDB数据库管理系统是MySQL的一个分支，主要由开源社区在维护，采用GPL授权许可 MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能轻松成为MySQL的代替品。 MariaDB由MySQL的创始人Michael Widenius（英语：Michael Widenius）主导开发，他早前曾以10亿美元的价格，将自己创建的公司MySQL AB卖给了SUN，此后，随着SUN被甲骨文收购，MySQL的所有权也落入Oracle的手中。MariaDB名称来自Michael Widenius的女儿Maria的名字。
安装MariaDB：
默认情况下，root密码为空。为防止未授权的访问，我们设置root密码
PHP（外文名:PHP: Hypertext Preprocessor，中文名：“超文本预处理器”）是一种通用开源脚本语言，主要适用于Web开发领域。
使用以下的命令安装php
在Apache文档根目录创建“testphp.php”
也可以使用如下命令安装所有php modules，重启httpd服务，查看http://server-ip-address/testphp.php ，可以看到所有安装的modules
phpMyAdmin 是一个以PHP为基础，以Web-Base方式架构在网站主机上的MySQL的数据库管理工具，让管理者可用Web接口管理MySQL数据库。由于phpMyAdmin跟其他PHP程式一样在网页服务器上执行，您可以在任何地方使用这些程式产生的HTML页面，也就是于远端管理MySQL数据库，方便的建立、修改、删除数据库及资料表。也可借由phpMyAdmin建立常用的php语法，方便编写网页时所需要的sql语法正确性。
添加 EPEL repository 参照（Install EPEL Repository on RHEL/CentOS/Scientific Linux 7）
默认，phpMyAdmin只能由本机访问。为了能够远程访问，编辑phpmyadmin.conf file: ，注释掉或删除如下内容
# Apache 2.4
Require ip 127.0.0.1
Require ip ::1
# Apache 2.2
Order Deny,Allow
Deny from All
Allow from 127.0.0.1
Allow from ::1
添加
重启the Apache service:
输入MySQL username and password，将重定向到PhpMyAdmin main web interface.
现在你可以通过phpMyAdmin web interface 管理你的MariaDB数据库了。 收起阅读 »
下面讨论如何在RHEL/CentOS/Scientific Linux 7上搭建LAMP环境.
一、Install Apache
Apache HTTP Server（简称Apache）是Apache软件基金会的一个开放源码的网页服务器，可以在大多数计算机操作系统中运行，由于其多平台和安全性被广泛使用，是最流行的Web服务器端软件之一。它快速、可靠并且可通过简单的API扩展，将Perl/Python等解释器编译到服务器中。
在终端以root权限运行以下命令:
yum install httpd -y启动Apache
systemctl start httpd设置开机启动
systemctl enable httpdfirewall设置允许远程登录:
firewall-cmd --permanent --add-service=http测试Apache
systemctl restart firewalld
浏览器访问 http://localhost/ or http://server-ip-address/
二、Install MariaDB
MariaDB数据库管理系统是MySQL的一个分支，主要由开源社区在维护，采用GPL授权许可 MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能轻松成为MySQL的代替品。 MariaDB由MySQL的创始人Michael Widenius（英语：Michael Widenius）主导开发，他早前曾以10亿美元的价格，将自己创建的公司MySQL AB卖给了SUN，此后，随着SUN被甲骨文收购，MySQL的所有权也落入Oracle的手中。MariaDB名称来自Michael Widenius的女儿Maria的名字。
安装MariaDB：
yum install mariadb-server mariadb -y启动MariaDB
systemctl start mariadb设置开机启动
systemctl enable mariadb设置root密码
默认情况下，root密码为空。为防止未授权的访问，我们设置root密码
mysql_secure_installation
三、Install PHP
PHP（外文名:PHP: Hypertext Preprocessor，中文名：“超文本预处理器”）是一种通用开源脚本语言，主要适用于Web开发领域。
使用以下的命令安装php
yum install php php-mysql php-gd php-pear -y测试PHP:
在Apache文档根目录创建“testphp.php”
vi /var/www/html/testphp.php编辑内容如下
phpinfo();重启 httpd 服务:
?>
systemctl restart httpd浏览器访问 http://server-ip-address/testphp.php. 将会显示php的版本信息.
也可以使用如下命令安装所有php modules，重启httpd服务，查看http://server-ip-address/testphp.php ，可以看到所有安装的modules
yum install php* -y
四、Install phpMyAdmin (可选)
phpMyAdmin 是一个以PHP为基础，以Web-Base方式架构在网站主机上的MySQL的数据库管理工具，让管理者可用Web接口管理MySQL数据库。由于phpMyAdmin跟其他PHP程式一样在网页服务器上执行，您可以在任何地方使用这些程式产生的HTML页面，也就是于远端管理MySQL数据库，方便的建立、修改、删除数据库及资料表。也可借由phpMyAdmin建立常用的php语法，方便编写网页时所需要的sql语法正确性。
添加 EPEL repository 参照（Install EPEL Repository on RHEL/CentOS/Scientific Linux 7）
yum install epel-release安装 phpMyAdmin:
yum install phpmyadmin -y配置phpMyAdmin
默认，phpMyAdmin只能由本机访问。为了能够远程访问，编辑phpmyadmin.conf file:
vi /etc/httpd/conf.d/phpMyAdmin.conf查找/
AddDefaultCharset UTF-8
# Apache 2.4
Require ip 127.0.0.1
Require ip ::1
# Apache 2.2
Order Deny,Allow
Deny from All
Allow from 127.0.0.1
Allow from ::1
# Apache 2.4
Require ip 127.0.0.1
Require ip ::1
# Apache 2.2
Order Deny,Allow
Deny from All
Allow from 127.0.0.1
Allow from ::1
添加
编辑“config.inc.php” 改变phpMyAdmin的authentication，修改“cookie” 为 “http”
Options none
AllowOverride Limit
Require all granted
vi /etc/phpMyAdmin/config.inc.phpChange ‘cookie’ to ‘http’.
重启the Apache service:
systemctl restart httpd访问 phpmyadmin 的控制台 http://server-ip-address/phpmyadmin/
输入MySQL username and password，将重定向到PhpMyAdmin main web interface.
现在你可以通过phpMyAdmin web interface 管理你的MariaDB数据库了。 收起阅读 »
Centos6下安装PHP7和Nginx
一、安装PHP
PHP源码包下载地址：
# wget http://cn2.php.net/distributions/php-5.6.22.tar.bz2
# wget http://cn2.php.net/distributions/php-7.0.7.tar.bz2
更新yum源
这里将Centos的yum源更换为国内的阿里云源。yum安装正常的可以跳过本步骤, 阿里云Linux安装镜像源地址: http://mirrors.aliyun.com/
1、备份你的原镜像文件，以免出错后可以恢复：
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup
2、下载新的CentOS-Base.repo 到/etc/yum.repos.d/
# CentOS 5
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-5.repo
# CentOS 6
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-6.repo
# CentOS 7
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
3、生成缓存
yum clean all
yum makecache
安装依赖
yum install -y gcc gcc-c++ make cmake bison autoconf wget lrzsz需要编译libmcrypt、mhash、mcrypt库
yum install -y libtool libtool-ltdl-devel
yum install -y freetype-devel libjpeg.x86_64 libjpeg-devel libpng-devel gd-devel
yum install -y python-devel patch sudo
yum install -y openssl* openssl openssl-devel ncurses-devel
yum install -y bzip* bzip2 unzip zlib-devel
yum install -y libevent*
yum install -y libxml* libxml2-devel
yum install -y libcurl* curl-devel
yum install -y readline-devel
tar zxvf /libmcrypt-2.5.8.tar.gz \
&& cd /libmcrypt-2.5.8 && ./configure && make && make install && cd - / && rm -rf /libmcrypt* \
&& tar zxvf /mhash-0.9.9.9.tar.gz && cd mhash-0.9.9.9 && ./configure && make && make install && cd - / && rm -rf /mhash* \
&& tar zxvf /mcrypt-2.6.8.tar.gz && cd mcrypt-2.6.8 && LD_LIBRARY_PATH=/usr/local/lib ./configure && make && make install && cd - / && rm -rf /mcrypt*
开始安装
使用./configure --help查看编译支持的选项。如果写了不支持的选项，如php7里不支持--with-mysql=mysqlnd会提示：
configure: WARNING: unrecognized options: --with-mysql
wget http://cn2.php.net/distributions/php-7.0.7.tar.bz2可选项：
tar jxvf php-7.0.7.tar.bz2
cd php-7.0.7
$ ./configure --prefix=/usr/local/php --with-config-file-scan-dir=/usr/local/php/etc/ --enable-inline-optimization --enable-opcache --enable-session --enable-fpm --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-pdo-sqlite --with-sqlite3 --with-gettext --enable-mbregex --enable-mbstring --enable-xml --with-iconv --with-mcrypt --with-mhash --with-openssl --enable-bcmath --enable-soap --with-xmlrpc --with-libxml-dir --enable-pcntl --enable-shmop --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-sockets --with-curl --with-curlwrappers --with-zlib --enable-zip --with-bz2 --with-gd --enable-gd-native-ttf --with-jpeg-dir --with-png-dir --with-freetype-dir --with-iconv-dir --with-readline
$ make
$ make install
--with-fpm-user=www --with-fpm-group=www这里面开启了很多扩展。如果这时候忘了开启，以后还能加上吗？答案是可以的。以后只需要进入源码的ext目录，例如忘了pdo_mysql，进入ext/pdo_mysql，使用phpize工具，像安装普通扩展一样即可生成pdo_mysql.so。
关于：--enable-safe-mode
开启的话php可以执行一下系统函数，建议关闭（可搜索受此函数影响的php函数）
#如果只需要配置某一个目录可以执行则 设置为on并指定 safe_mode_exec_dir=string目录来执行系统函数。php7编译不用加这个配置。
#本特性已自 PHP 5.3.0 起废弃并将自 PHP 5.4.0 起移除。
safe_mode = off
编译比较耗内存和CPU。等待半小时左右，编译完成：
Build complete.
Don't forget to run 'make test'.
Installing shared extensions: /usr/local/php/lib/php/extensions/no-debug-non-zts-20151012/
Installing PHP CLI binary: /usr/local/php/bin/
Installing PHP CLI man page: /usr/local/php/php/man/man1/
Installing PHP FPM binary: /usr/local/php/sbin/
Installing PHP FPM config: /usr/local/php/etc/
Installing PHP FPM man page: /usr/local/php/php/man/man8/
Installing PHP FPM status page: /usr/local/php/php/php/fpm/
Installing phpdbg binary: /usr/local/php/bin/
Installing phpdbg man page: /usr/local/php/php/man/man1/
Installing PHP CGI binary: /usr/local/php/bin/
Installing PHP CGI man page: /usr/local/php/php/man/man1/
Installing build environment: /usr/local/php/lib/php/build/
Installing header files: /usr/local/php/include/php/
Installing helper programs: /usr/local/php/bin/
program: phpize
program: php-config
Installing man pages: /usr/local/php/php/man/man1/
page: phpize.1
page: php-config.1
Installing PEAR environment: /usr/local/php/lib/php/
[PEAR] Archive_Tar - installed: 1.4.0
[PEAR] Console_Getopt - installed: 1.4.1
[PEAR] Structures_Graph- installed: 1.1.1
[PEAR] XML_Util - installed: 1.3.0
[PEAR] PEAR - installed: 1.10.1
Wrote PEAR system config file at: /usr/local/php/etc/pear.conf
You may want to add: /usr/local/php/lib/php to your php.ini include_path
/php-7.0.7/build/shtool install -c ext/phar/phar.phar /usr/local/php/bin
ln -s -f phar.phar /usr/local/php/bin/phar
Installing PDO headers: /usr/local/php/include/php/ext/pdo/
[root@e8ed9b00e80c php-7.0.7]# /usr/local/php/bin/php -m
[PHP Modules]
bcmath
bz2
Core
ctype
curl
date
dom
fileinfo
filter
gd
gettext
hash
iconv
json
libxml
mbstring
mcrypt
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
readline
Reflection
session
shmop
SimpleXML
soap
sockets
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tokenizer
xml
xmlreader
xmlrpc
xmlwriter
zip
zlib
[Zend Modules]
配置文件
需要从安装包里复制php.ini、php-fpm.conf到安装目录：
$ cp php-7.0.7/php.ini* /usr/local/php/etc/
$ cd /usr/local/php/etc/
$ cp php.ini-production php.ini
$ cp php-fpm.conf.default php-fpm.conf
$ cp php-fpm.d/www.conf.default php-fpm.d/www.conf
$ ls
pear.conf php-fpm.conf.default php.ini-development php.ini-production
配置php.ini
# 不显示错误，默认
display_errors = Off
# 在关闭display_errors后开启PHP错误日志（路径在php-fpm.conf中配置），默认
log_errors = On
# 字符集，默认
default_charset = "UTF-8"
# 文件上传大小，默认
upload_max_filesize = 2M
# 设置PHP的扩展库路径,，默认被注释了。
extension_dir = "/usr/local/php7/lib/php/extensions/no-debug-non-zts-20151012/"
# 如果不设置extension_dir，也可以直接写绝对位置：
# extension=/usr/local/php/lib/php/extensions/no-debug-non-zts-20151012/redis.so
# 设置PHP的时区
date.timezone = PRC
# 开启opcache，默认是0
[opcache]
; Determines if Zend OPCache is enabled
opcache.enable=1
配置php-fpm.conf
; 去掉里分号，方便以后重启。建议修改
; Default Value: none
; 下面的值最终目录是/usr/local/php/var/run/php-fpm.pid
; 开启后可以平滑重启php-fpm
pid = run/php-fpm.pid
; 设置错误日志的路径，可以默认值
; Note: the default prefix is /usr/local/php/var
; Default Value: log/php-fpm.log, 即/usr/local/php/var/log/php-fpm.log
error_log = /var/log/php-fpm/error.log
; Log等级，可以默认值
; Possible Values: alert, error, warning, notice, debug
; Default Value: notice
log_level = notice
; 后台运行，默认yes，可以默认值
; Default Value: yes
;daemonize = yes
; 引入www.conf文件中的配置，可以默认值
include=/usr/local/php/etc/php-fpm.d/*.conf
配置www.conf（在php-fpm.d目录下）
www.conf这是php-fpm进程服务的扩展配置文件：
; 设置用户和用户组，默认都是nobody。可以默认值保存配置文件后，检验配置是否正确的方法为:
user = nginx
group = nginx
; 设置PHP监听
; 下面是默认值，不建议使用。可以默认值
; listen = 127.0.0.1:9000
; 根据nginx.conf中的配置fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
listen = /var/run/php-fpm/php-fpm.sock
######开启慢日志。可以默认值
slowlog = /var/log/php-fpm/$pool-slow.log
request_slowlog_timeout = 10s
/usr/local/php/sbin/php-fpm -t如果出现诸如 test is successful 字样，说明配置没有问题。另外该命令也可以让我们知道php-fpm的配置文件在哪。
建立软连接：
ln -sf /usr/local/php/sbin/php-fpm /usr/bin/或者将php编译生成的bin目录添加到当前Linux系统的环境变量中:
ln -sf /usr/local/php/bin/php /usr/bin/
ln -sf /usr/local/php/bin/phpize /usr/bin/
ln -sf /usr/local/php/bin/php-config /usr/bin/
ln -sf /usr/local/php/bin/php-cig /usr/bin/
echo -e '\nexport PATH=/usr/local/php/bin:/usr/local/php/sbin:$PATH\n' >> /etc/profile && source /etc/profile
启动php-fpm
/usr/local/php/sbin/php-fpm如果提示没有www用户（www.conf里填写了www而不是nobody），则新增：
useradd www检测是否启动:
chown -R www:www /www
ps aux |grep php-fpm # 另外该命令也可以让我们知道fpm的配置文件在哪。查看php-fpm进程数：
netstat -ant |grep 9000
ps aux | grep -c php-fpmphp-fpm操作汇总：
/usr/local/php/sbin/php-fpm # php-fpm启动重启方法二：
kill -INT `cat /usr/local/php/var/run/php-fpm.pid` # php-fpm关闭
kill -USR2 `cat /usr/local/php/var/run/php-fpm.pid` #php-fpm重启
killall php-fpm如果无法平滑启动，那就终止进程id：
/usr/local/php/sbin/php-fpm &
ps aux | grep php-fpm
kill -9 1210 #1210指php-fpm进程id
二、安装Nginx
安装包下载地址： http://nginx.org/download/nginx-1.11.1.tar.gz
依赖：
# 为了支持rewrite功能，我们需要安装pcre配置编译参数
yum install pcre-devel
# 需要ssl的支持，如果不需要ssl支持，请跳过这一步
# yum install openssl*
# gzip 类库安装，按需安装
# yum install zlib zlib-devel
$ tar -zxvf nginx-1.11.1.tar.gz配置ok：
$ cd nginx-1.11.1
$ ./configure \
--prefix=/usr/local/nginx \
--with-http_stub_status_module \
--with-http_ssl_module \
--with-http_realip_module \
--with-http_sub_module \
--with-http_gzip_static_module \
--with-pcre
Configuration summary编译安装nginx
+ using system PCRE library
+ using system OpenSSL library
+ md5: using OpenSSL library
+ sha1: using OpenSSL library
+ using system zlib library
nginx path prefix: "/usr/local/nginx"
nginx binary file: "/usr/local/nginx/sbin/nginx"
nginx modules path: "/usr/local/nginx/modules"
nginx configuration prefix: "/usr/local/nginx/conf"
nginx configuration file: "/usr/local/nginx/conf/nginx.conf"
nginx pid file: "/usr/local/nginx/logs/nginx.pid"
nginx error log file: "/usr/local/nginx/logs/error.log"
nginx http access log file: "/usr/local/nginx/logs/access.log"
nginx http client request body temporary files: "client_body_temp"
nginx http proxy temporary files: "proxy_temp"
nginx http fastcgi temporary files: "fastcgi_temp"
nginx http uwsgi temporary files: "uwsgi_temp"
nginx http scgi temporary files: "scgi_temp"
make设置软连接：
make install
ln -sf /usr/local/nginx/sbin/nginx /usr/sbin检测nginx:
nginx -t显示：nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
成功了。我们重新配置下nginx.conf：
#user nobody;配置localhost:
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
# 解决虚拟主机名字过长 http://www.jb51.net/article/26412.htm
server_names_hash_bucket_size 128;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
autoindex on;# 显示目录
autoindex_exact_size on;# 显示文件大小
autoindex_localtime on;# 显示文件时间
include vhosts/*.conf;
}
vim ./vhosts/localhost.conf
server {
listen 80;
server_name localhost;
#charset utf-8;
#access_log logs/host.access.log main;
location / {
root /www/www/;
index index.php index.html index.htm;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php$ {
root /www/www/;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}启动nginx:/usr/local/nginx/sbin/nginx重启：
# 或者
nginx
/usr/local/nginx/sbin/nginx -s reload停止：
# 或者
nginx -s reload
/usr/local/nginx/sbin/nginx -s stop如果提示80端口被占用了，可以使用ps aunx | grep 80查看。一般是apache占用了。可以使用：
# 或者
nginx -s stop
chkconfig --list禁止apache启动并关闭apache服务。
chkconfig nginx on
service apache off
三、安装扩展
1、安装swoole
Swoole: PHP的异步、并行、高性能网络通信引擎：http://www.swoole.com/
wget https://github.com/swoole/swoole-src/archive/swoole-1.8.5-stable.zip
unzip swoole-1.8.5-stable.zip
cd swoole-1.8.5-stable
phpize
./configure
make && make install
2、安装redis
wget https://github.com/nicolasff/phpredis/archive/2.2.4.tar.gz
tar -zxvf 2.2.4
cd phpredis-2.2.4/
phpize
./configure
make && make install
四、信号管理
不重载配置启动新/旧工作进程
kill -HUP 旧/新版主进程号从容关闭旧/新进程
kill -QUIT 旧/新主进程号如果此时报错，提示还有进程没有结束就用下面命令先关闭旧/新工作进程，再关闭主进程号：
kill -TERM 旧/新工作进程号升级、添加或删除模块时，我们需要停掉服务器
kill -USR2 旧版程序的主进程号或进程文件名收起阅读 »
单独编译添加PHP的pdo_mysql模块
原来编译php的时候，没有把pdo_mysql相关的参数带上，安装完后才发现。再重新编译有点费时间，所以决定单独来安装。
先找需要的版本，我用的是稳定的版本。要先看看说明，特别是要注意mysql的php的版本
经过configure就可以make了
在执行：./configure 时，又出现了一个问题：
解决方法：
/usr/local/php/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so
然后在/usr/local/lib/php.ini加上一句：
先找需要的版本，我用的是稳定的版本。要先看看说明，特别是要注意mysql的php的版本
# wget http://pecl.php.net/get/PDO_MYSQL-1.0.2.tgz执行完以后，报如下错误：
# tar xzvf PDO_MYSQL-1.0.2.tgz
# cd PDO_MYSQL-1.0.2
# /usr/local/php/bin/phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
# ./configure
checking for mysql_config... not found这个错误表明系统缺省没有找到你的mysql安装目录，因此可以使用这个命令解决：
configure: error: Cannot find MySQL header files under
ln -s /usr/local/mysql/bin/mysql_config /usr/bin/mysql_config这样建立了你的实际msyql安装目录和mysql_config命令的管理
经过configure就可以make了
在执行：./configure 时，又出现了一个问题：
checking for PDO includes... checking for PDO includes...检查的时候，不能找到php_pdo_driver.h，经过检查，发现在读php-config的时候，在读以前的配置。
configure: error: Cannot find php_pdo_driver.h.
解决方法：
./configure –with-php-config=/usr/local/php/bin/php-config (根据实际的路径的来指定)在执行./configure --with-php-config=/usr/local/php/bin/php-config，又出现了一个问题：
error: mysql_query missing!?解决方法：
./configure --with-php-config=/opt/php5/bin/php-config --with-pdo-mysql=/usr/local/mysql(根据自己的实际路径，设定编译安装mysql的位置).
make && make install注意pdo_mysql的全路径，我的是：
/usr/local/php/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so
然后在/usr/local/lib/php.ini加上一句：
extension=/usr/local/php/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so重新启动apache即可看到已经加载pdo_mysql成功。 收起阅读 »
Centos6.8下编译安装Apache 2.4.25详细过程
一、下载源码安装包
二、解压安装
解决APR not found 过程如下：
在编译apr的的过程中报错如下：
解决方法如下：
在configure里面 RM='$RM -f' 这里的$RM后面一定有一个空格。 如果后面没有空格，直接连接减号，就依
然会报错。把RM='$RM'改为RM='$RM -f'
接着重新编译Apache：
解决APR-util not found过程：
编译完成后，我们再次重新编译Apache：
最后：
# cd /usr/local/src
# wget 'http://mirror.bit.edu.cn/apache//httpd/httpd-2.4.25.tar.gz'
二、解压安装
# tar zxf httpd-2.4.25.tar.gz在这过程中报错如下：
# cd httpd-2.4.25
# ./configure --prefix=/usr/local/apache --enable-so --enable-rewrite --with-mpm=worker
checking for chosen layout... Apache
checking for working mkdir -p... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
configure:
configure: Configuring Apache Portable Runtime library...
configure:
checking for APR... no
configure: error: APR not found. Please read the documentation.
解决APR not found 过程如下：
# cd /usr/local/src
# wget http://archive.apache.org/dist/apr/apr-1.5.2.tar.gz
# tar zxf apr-1.5.2.tar.gz
# ./configure --prefix=/usr/local/apr
# make && make install
在编译apr的的过程中报错如下：
configure: creating ./config.status
config.status: creating Makefile
config.status: creating include/apr.h
config.status: creating build/apr_rules.mk
config.status: creating build/pkg/pkginfo
config.status: creating apr-1-config
config.status: creating apr.pc
config.status: creating test/Makefile
config.status: creating test/internal/Makefile
config.status: creating include/arch/unix/apr_private.h
config.status: executing libtool commands
rm: cannot remove `libtoolT': No such file or directory
config.status: executing default commands
解决方法如下：
在configure里面 RM='$RM -f' 这里的$RM后面一定有一个空格。 如果后面没有空格，直接连接减号，就依
然会报错。把RM='$RM'改为RM='$RM -f'
接着重新编译Apache：
./configure --prefix=/usr/local/apache --enable-so --enable-rewrite --with-mpm=worker --with-apr=/usr/local/apr报错如下：
checking for chosen layout... Apache
checking for working mkdir -p... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
configure:
configure: Configuring Apache Portable Runtime library...
configure:
checking for APR... yes
setting CC to "gcc"
setting CPP to "gcc -E"
setting CFLAGS to " -g -O2 -pthread"
setting CPPFLAGS to " -DLINUX -D_REENTRANT -D_GNU_SOURCE"
setting LDFLAGS to " "
configure:
configure: Configuring Apache Portable Runtime Utility library...
configure:
checking for APR-util... no
configure: error: APR-util not found. Please read the documentation.
解决APR-util not found过程：
# wget 'http://archive.apache.org/dist/apr/apr-util-1.5.2.tar.gz'
# tar zxf apr-util-1.5.2.tar.gz
# cd apr-util-1.5.2
# ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr/bin/apr-1-config
# make && make install
编译完成后，我们再次重新编译Apache：
# ./configure --prefix=/usr/local/apache --enable-so --enable-rewrite --with-mpm=worker --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr-utilenable-so 允许apache支持动态模块 enable-rewrite 支持URL重定向 with-mpm=worker apache进程模型为worker 默认为prefork
最后：
# make && make install到这编译就算完成了。 收起阅读 »
Sudo本地提权漏洞安全预警
linux 系统sudo存在本地提权高危漏洞，本地攻击者可以利用此漏洞提权至root。请检查您所使用的sudo是否在影响范围之内，并及时进行升级。
影响范围
Centos 5、6、7
Redhat Enterprise Linux 5、6、7
Ubuntu 14.04、15.04、16.04、16.10、17.04、17.10
Debian wheezy、jessie、jessie、sid
SUSE Linux Enterprise Software Development Kit 12 SP1、SP2
SUSE Linux Enterprise Server for SAP 12
SUSE Linux Enterprise Server 12 SP1 、SP2
SUSE Linux Enterprise Server 12-LTSS
SUSE Linux Enterprise Desktop 12 SP1 、SP2
SUSE Linux Enterprise Server for Raspberry Pi 12 SP2
OpenSuse
修复方案
【CentOS/RHEL】
yum update
或 yum install sudo
【Ubuntu/Debian】
sudo apt update $ sudo apt upgrade
或sudo apt-get install sudo
备注：部分官方版本还未发布可用修复包，请时刻关注，官网发布后UCloud软件源也会在第一时间更新。
【修复版本】
1、Centos /Redhat
Centos /RHEL 7 :1.8.6p7-22.el7_3
Centos /RHEL 6 :1.8.6p3-28.el6_9
Centos /RHEL 5 :1.7.2p1-30.el5_11
2、Ubuntu
Ubuntu 14.04:1.8.9p5-1ubuntu1.4
Ubuntu 16.04:1.8.16-0ubuntu1.4
Ubuntu 16.10:1.8.16-0ubuntu3.2
Ubuntu 17.04:1.8.19p1-1ubuntu1.1
3、Debian
Debian wheezy:1.8.5p2-1+nmu3+deb7u3
Debian jessie:1.8.10p3-1+deb8u4
4、SUSE /OpenSuse
1.8.10p3-2.11.1
1.8.10p3-10.5.1
漏洞详情
CVE-2017-1000367：当确定tty时，Sudo没有正确解析/ proc / [pid] / stat的内容，本地攻击者可能会使用此方法来覆盖文件系统上的任何文件，从而绕过预期权限或获取root shell。
sudo版本查看方法：
Centos /RHEL /SUSE /OpenSuse：rpm -qa|grep sudo
Ubuntu /Debian：dpkg -l sudo 收起阅读 »
影响范围
Centos 5、6、7
Redhat Enterprise Linux 5、6、7
Ubuntu 14.04、15.04、16.04、16.10、17.04、17.10
Debian wheezy、jessie、jessie、sid
SUSE Linux Enterprise Software Development Kit 12 SP1、SP2
SUSE Linux Enterprise Server for SAP 12
SUSE Linux Enterprise Server 12 SP1 、SP2
SUSE Linux Enterprise Server 12-LTSS
SUSE Linux Enterprise Desktop 12 SP1 、SP2
SUSE Linux Enterprise Server for Raspberry Pi 12 SP2
OpenSuse
修复方案
【CentOS/RHEL】
yum update
或 yum install sudo
【Ubuntu/Debian】
sudo apt update $ sudo apt upgrade
或sudo apt-get install sudo
备注：部分官方版本还未发布可用修复包，请时刻关注，官网发布后UCloud软件源也会在第一时间更新。
【修复版本】
1、Centos /Redhat
Centos /RHEL 7 :1.8.6p7-22.el7_3
Centos /RHEL 6 :1.8.6p3-28.el6_9
Centos /RHEL 5 :1.7.2p1-30.el5_11
2、Ubuntu
Ubuntu 14.04:1.8.9p5-1ubuntu1.4
Ubuntu 16.04:1.8.16-0ubuntu1.4
Ubuntu 16.10:1.8.16-0ubuntu3.2
Ubuntu 17.04:1.8.19p1-1ubuntu1.1
3、Debian
Debian wheezy:1.8.5p2-1+nmu3+deb7u3
Debian jessie:1.8.10p3-1+deb8u4
4、SUSE /OpenSuse
1.8.10p3-2.11.1
1.8.10p3-10.5.1
漏洞详情
CVE-2017-1000367：当确定tty时，Sudo没有正确解析/ proc / [pid] / stat的内容，本地攻击者可能会使用此方法来覆盖文件系统上的任何文件，从而绕过预期权限或获取root shell。
sudo版本查看方法：
Centos /RHEL /SUSE /OpenSuse：rpm -qa|grep sudo
Ubuntu /Debian：dpkg -l sudo 收起阅读 »
华尔街见闻：基于腾讯云容器服务的微服务架构实践
简介
华尔街见闻的运营方上海阿牛信息科技有限公司是全球金融信息服务提供商，每天全平台为近200万用户提供资讯、数据、研究等服务。旗舰产品华尔街见闻APP长期位居各应用市场财经资讯类客户端第1位。由于将重大事件、市场的基本面变化和100多种全球资产价格紧密关联，在金融领域具有极高渗透率。首创的7x24快讯模式已经成为在中文世界理解全球市场的最快来源。也因此，该产品有技术架构复杂，需要高并发承载能力等特性。
背景
•老系统日益臃肿
原先的系统是PHP monolithic架构，功能按模块划分，日积月累，最后模块达到60+个，新人接手项目会拿到一整个系统的代码，以及需要整个系统的配置，而他可能只需要专注开发不到1/10的业务。
•伸缩性
我们的主要业务是即时资讯，资讯具有时效性，网站的访问量会呈现锯齿形分布。当遇到特大新闻如英国退欧、美国大选、法国大选等，我们要能弹性地通过增加服务资源，提高服务的容量。
•容错性
我们希望一个低优先级服务出现问题之后，不影响主要服务；一个主要服务能保证更高的可用性，就算出现问题，也要保证优雅降级。
比如在重大事件发生的时候，我们希望文章API保证不会受到影响。
•单体应用
PHP单体应用在生产环境服务的时候，所有业务都跑在一个程序里，增加了系统的脆弱性，一个隐藏的性能问题，能在服务量激增的时候成为压垮骆驼的一根稻草。
•云服务商成本
由于架构落后于需要，我们不得不用硬件弥补性能上的问题，导致云服务器成本不断增加。
•线上运维
由于没有方便的监控和运维工具，导致排查问题的效率低，使得在系统遇到问题的时候排查困难，耗时过长。
•开发新功能
开发新任务的同时，我们需要修复原有系统的性能问题。
PHP monolithic架构图
每台服务器部署相同的服务端PHP代码，由PHP-fpm解释执行，通过Nginx进行反向代理。
华尔街见闻微服务架构设计
因此，在2016年11月至2017年3月，我们采用微服务架构启动重构，尝试解决一部分上述问题，在伸缩性上能以服务为单位进行拓容，同时，这一设计会在某些方面增大我们的开发成本和运维成本。
•错误排查复杂
很显然，以前在单体应用中能直接登录服务器，查看出错日志，现在错误散落在不同的服务中，为我们的错误排查带来了困难。
•日志源增加
如何把服务的日志收集并分析。
•基础设施增加
每个服务有互相独立的MySQL、Redis，公共服务方面需要高可用的服务发现，调用链路分析，日志收集储存设施等。
技术选型
微服务架构图
每台服务器上均衡地部署服务，LB接受用户的请求，将请求转发到API gateway，API gateway向服务发现查询具体服务的IP和端口，服务执行完业务逻辑后向上返回数据。
服务框架
我们选择golang作为我们的后端开发语言。
• golang在性能和开发效率上有很好的平衡，语法上很简单，并发编程简单高效，基础库健全。
• 调试工具强大
自带一些pprof包可以profile当前程序的CPU消耗、内存占用、锁状态、channel阻塞等，非常便利我们定位问题。
• 有一些优秀的微服务框架
我们选用go-micro作为开发框架，里面包含几乎所有微服务组件，并且支持非常好的拓展性，通过接口的设计方式，让我们可以拓展一些自己的组件，如服务发现、传输协议等。
• golang在华尔街见闻已经有过比较多的应用，工程师使用golang开发几乎0学习成本。
服务拆分
拆分的原则是通过服务功能划分，尽量避免双向依赖。我们拆分出了13个服务，包括用户、内容、实时新闻、评论、搜索、商城、支付、三方代理等服务。
服务间通信
服务间使用protobuf协议对数据进行编码，使用UDP作为传输协议。
服务发现
Etcd搭建多节点高可用的服务发现。
服务保护
我们选择Hystrix作为服务保护以及服务降级的方案。
每个服务开发者，需要定义自己服务接口的并发量、超时时间以及fallback方法。
部署方案
我们选择了Kubernetes。
* Docker Swarm
这是我们最先选择的方案，因为Docker 1.12之后已经将Swarm功能集成到Docker En-gine，能以最少的配置启动Docker集群。经过简化和设计的控制台API，方便地管理集群、调整服务如控制服务的数量、CPU、内存限制等。往集群内加入机器非常简单，只需要运行一条命令即可。使用manager-worker架构，manager作为调度节点，支持高可用。
但遇到了非常致命的问题，比如频繁更新服务的时候会出现服务访问不到，某服务的负载均衡后挂载的服务IP是其它服务的，服务之间的通信有几率出现超时问题，归根结底，还是社区正在不断完善swarm，有很多不稳定的地方，网络方面没有进行优化。
* Kubernetes
这是谷歌主导的服务编排工具，它支持Docker，相比Docker Swarm来说，它的概念更多，分层更细。功能方面多于Docker Swarm，支持一些高级功能如秘钥管理、配置管理、自动拓容等。在生产环境的应用比较广泛，稳定性更高。
* 裸机部署
裸机部署是我们的一个备案，考虑到以上两个方案在当时没有具体线上实施的经验，所以如果Docker Swarm和Kubernetes都没有成功，我们直接裸机部署。
裸机部署的需要解决单机端口冲突，如果一个服务在一个服务器上最多只部署一个，那么可以通过写脚本，并划分服务器角色的方式进行部署，利用ansible可以定义user服务集群、content服务集群、comment服务集群等，通过分发二进制文件的方式让服务启动，这样的方案要考虑到服务更新、服务重启、服务删除等逻辑，同一时间只有部分节点更新，在服务未更新成功的时候流量暂时不能打到正在更新的节点。
准备工作
代码托管
由于之前使用github开发人员的代码提交在有翻墙工具的帮助下速度依然不是很理想，我们自建了Gitlab仓库，自此开发过上了幸福的生活。
容器化
swarm和kubernetes是基于docker快速创建删除服务，通过增加容器为服务拓容，缩减容器为服务缩小规模，所以所有项目必须要构建docker镜像。按项目类型划分，我们遇到3种镜像打包情况。
1. 后端项目
后端服务90%是golang项目，针对golang的镜像，我们采取将golang项目编译成可执行文件，基于最小的alpine镜像打包入docker，这里遇到过一个问题，就是alpine里缺少openssl的证书，无法支持https，我们自定义了新的基础镜像，不仅将证书文件打入镜像，同时为了线上调试方便，增加了tcpdump、strace、bash等工具，在初期调试容器间通信问题时发挥重要的作用。
2. 前端静态文件
见闻的后台以及m站基于Vue，编译后生成的静态文件打入镜像，通过nginx访问。 为了支持HTTP2，我们打入nginx镜像缺少的证书。
3. 服务端渲染
主站PC站基于nodejs、Vue实现服务端渲染，所以不仅需要依赖nodejs，而且需要利用pm2进行nodejs生命周期的管理。为了加速线上镜像构建的速度，我们利用taobao源https://registry.npm.taobao.org进行加速, 并且将一些常见的npm依赖打入了基础镜像，避免每次都需要重新下载，镜像打包从开始的3分钟缩减到1.5分钟。
三类镜像结构
持续集成
我们利用Gitlab CI配置了测试、镜像构建、镜像发布、自动部署等流程，后端服务从提交代码到测试分支到测试环境自动部署完成花费1.5分钟，前端服务平均为2.5分钟。
CI任务中的test->build->docker->deploy流程
云平台的选择
最终，我们选择了腾讯云的容器服务，主要基于以下几点考虑：
• 腾讯云的容器服务是在腾讯云的Iaas上为每个用户构建容器集群，腾讯云提供的微服务架构和持续集成与交付的应用场景基本满足了我们的述求。
• 腾讯云的容器服务是基于Kubernetes实现的，支持完全的kubernetes能力。
• 腾讯云在Kubernetes上实现了他们的存储、负载均衡等产品的插件、复用了腾讯云本身平台的监控、日志等能力。减少了我们接入和开发的成本。
服务在腾讯云的应用
我们将我们的应用重构成微服务的架构，每个微服务部署成腾讯云容器服务上的一个服务，前端接入通过一个负载均衡。后端服务间可互相访问。
服务器安全方面，内部服务器通过VPC进行网络隔离，将网络划分为生产环境、测试环境，在生产环境中又划分backend子网和data子网，设定子网之间的访问规则。
为了禁止内部服务器的外网访问，不给内部服务器分配外网IP，仅通过跳板机访问。
性能对比
利用locust模拟线上请求的比例，利用2台16核的压测机在内网对10台16C32G的机器上的服务进行压测，达到1w/s QPS以上，并且服务的负载并没达到极限，这已经是之前PHP生产环境20+台16C32G服务器能达到的QPS。
线上调用追踪
通过追踪API调用链的流向与耗时，我们可以找出性能的瓶颈。我们通过zipkin实际优化了几种情况:
• 服务调用冗余
当拉取文章列表的时候，我们需要拉取文章对应的作者信息，开始的时候我们使用拉取单个作者信息的方式，后来性能调优阶段，我们将其改为批量拉取作者列表，减少RPC的冗余。
• 服务耗时长
对于有些本身就比较耗时并且对即时性不是那么苛刻的计算服务，我们为了保证服务的响应时间，会适量地加上缓存。
监控与报警
由从外部系统表征到内部日志，我们将监控分为API健康，程序错误报警，以及服务器/容器负载。
排查问题的流程一般有两种情况，一种是用户发现问题，申报问题，开发人员跟进问题；一种是我们的监控优先发现问题，开发人员在用户反馈前跟进并修复。在报警方面，我们通过为监控系统谨慎设置报警阈值，当触发报警时，开发人员会收到邮件。
这里我们在报警的定义上有过思考，即什么样的报警算是有意义的？我们遇到过每天10几条重复的报警，通常开发人员开始时会对报警非常重视，当重复的报警一再出现，渐渐失去了对报警的关注。所以我们有解除一些不必要的报警，并且对剩余一些报警进行调查，甚至有些警报是因为监控工具本身的不准确引起的。
API健康
我们设置默认的时间区间是5分钟
• 统计API五分钟内平均QPS
• API 98%以内的延迟分布
• QPS最高的前10的API
• API的返回码的分布
程序错误报警
后端程序内接入Sentry日志报警系统，golang程序捕获panic日志以及error日志，并发送报警邮件。
服务器/容器负载
通过在服务器上运行telegraf daemon进程，收集服务器metrics并发送给influxdb，使用Grafana作为前端面板，对服务器负载以及容器的平均CPU、内存占用率进行监控。
结束语
本文介绍了华尔街见闻通过重构和服务容器的重新部署，实践微服务架构的情况。经过几个月的开发测试，我们不仅完成了线上服务从PHP到Golang的转型，更在服务的稳定性上经历了考验，支撑了几次重大新闻的高流量。
在开发流程上，搭建了完善的自动化工具，减少了人工操作的重复性和误操作概率。
在运维方面，由于监控系统对系统完整的监控，与Kubernetes健全的上线、下线、回滚、拓容功能配合，能以极快的速度处理线上问题。
收起阅读 »
华尔街见闻的运营方上海阿牛信息科技有限公司是全球金融信息服务提供商，每天全平台为近200万用户提供资讯、数据、研究等服务。旗舰产品华尔街见闻APP长期位居各应用市场财经资讯类客户端第1位。由于将重大事件、市场的基本面变化和100多种全球资产价格紧密关联，在金融领域具有极高渗透率。首创的7x24快讯模式已经成为在中文世界理解全球市场的最快来源。也因此，该产品有技术架构复杂，需要高并发承载能力等特性。
背景
•老系统日益臃肿
原先的系统是PHP monolithic架构，功能按模块划分，日积月累，最后模块达到60+个，新人接手项目会拿到一整个系统的代码，以及需要整个系统的配置，而他可能只需要专注开发不到1/10的业务。
•伸缩性
我们的主要业务是即时资讯，资讯具有时效性，网站的访问量会呈现锯齿形分布。当遇到特大新闻如英国退欧、美国大选、法国大选等，我们要能弹性地通过增加服务资源，提高服务的容量。
•容错性
我们希望一个低优先级服务出现问题之后，不影响主要服务；一个主要服务能保证更高的可用性，就算出现问题，也要保证优雅降级。
比如在重大事件发生的时候，我们希望文章API保证不会受到影响。
•单体应用
PHP单体应用在生产环境服务的时候，所有业务都跑在一个程序里，增加了系统的脆弱性，一个隐藏的性能问题，能在服务量激增的时候成为压垮骆驼的一根稻草。
•云服务商成本
由于架构落后于需要，我们不得不用硬件弥补性能上的问题，导致云服务器成本不断增加。
•线上运维
由于没有方便的监控和运维工具，导致排查问题的效率低，使得在系统遇到问题的时候排查困难，耗时过长。
•开发新功能
开发新任务的同时，我们需要修复原有系统的性能问题。
PHP monolithic架构图
每台服务器部署相同的服务端PHP代码，由PHP-fpm解释执行，通过Nginx进行反向代理。
华尔街见闻微服务架构设计
因此，在2016年11月至2017年3月，我们采用微服务架构启动重构，尝试解决一部分上述问题，在伸缩性上能以服务为单位进行拓容，同时，这一设计会在某些方面增大我们的开发成本和运维成本。
•错误排查复杂
很显然，以前在单体应用中能直接登录服务器，查看出错日志，现在错误散落在不同的服务中，为我们的错误排查带来了困难。
•日志源增加
如何把服务的日志收集并分析。
•基础设施增加
每个服务有互相独立的MySQL、Redis，公共服务方面需要高可用的服务发现，调用链路分析，日志收集储存设施等。
技术选型
微服务架构图
每台服务器上均衡地部署服务，LB接受用户的请求，将请求转发到API gateway，API gateway向服务发现查询具体服务的IP和端口，服务执行完业务逻辑后向上返回数据。
服务框架
我们选择golang作为我们的后端开发语言。
• golang在性能和开发效率上有很好的平衡，语法上很简单，并发编程简单高效，基础库健全。
• 调试工具强大
自带一些pprof包可以profile当前程序的CPU消耗、内存占用、锁状态、channel阻塞等，非常便利我们定位问题。
• 有一些优秀的微服务框架
我们选用go-micro作为开发框架，里面包含几乎所有微服务组件，并且支持非常好的拓展性，通过接口的设计方式，让我们可以拓展一些自己的组件，如服务发现、传输协议等。
• golang在华尔街见闻已经有过比较多的应用，工程师使用golang开发几乎0学习成本。
服务拆分
拆分的原则是通过服务功能划分，尽量避免双向依赖。我们拆分出了13个服务，包括用户、内容、实时新闻、评论、搜索、商城、支付、三方代理等服务。
服务间通信
服务间使用protobuf协议对数据进行编码，使用UDP作为传输协议。
服务发现
Etcd搭建多节点高可用的服务发现。
服务保护
我们选择Hystrix作为服务保护以及服务降级的方案。
每个服务开发者，需要定义自己服务接口的并发量、超时时间以及fallback方法。
部署方案
我们选择了Kubernetes。
* Docker Swarm
这是我们最先选择的方案，因为Docker 1.12之后已经将Swarm功能集成到Docker En-gine，能以最少的配置启动Docker集群。经过简化和设计的控制台API，方便地管理集群、调整服务如控制服务的数量、CPU、内存限制等。往集群内加入机器非常简单，只需要运行一条命令即可。使用manager-worker架构，manager作为调度节点，支持高可用。
但遇到了非常致命的问题，比如频繁更新服务的时候会出现服务访问不到，某服务的负载均衡后挂载的服务IP是其它服务的，服务之间的通信有几率出现超时问题，归根结底，还是社区正在不断完善swarm，有很多不稳定的地方，网络方面没有进行优化。
* Kubernetes
这是谷歌主导的服务编排工具，它支持Docker，相比Docker Swarm来说，它的概念更多，分层更细。功能方面多于Docker Swarm，支持一些高级功能如秘钥管理、配置管理、自动拓容等。在生产环境的应用比较广泛，稳定性更高。
* 裸机部署
裸机部署是我们的一个备案，考虑到以上两个方案在当时没有具体线上实施的经验，所以如果Docker Swarm和Kubernetes都没有成功，我们直接裸机部署。
裸机部署的需要解决单机端口冲突，如果一个服务在一个服务器上最多只部署一个，那么可以通过写脚本，并划分服务器角色的方式进行部署，利用ansible可以定义user服务集群、content服务集群、comment服务集群等，通过分发二进制文件的方式让服务启动，这样的方案要考虑到服务更新、服务重启、服务删除等逻辑，同一时间只有部分节点更新，在服务未更新成功的时候流量暂时不能打到正在更新的节点。
准备工作
代码托管
由于之前使用github开发人员的代码提交在有翻墙工具的帮助下速度依然不是很理想，我们自建了Gitlab仓库，自此开发过上了幸福的生活。
容器化
swarm和kubernetes是基于docker快速创建删除服务，通过增加容器为服务拓容，缩减容器为服务缩小规模，所以所有项目必须要构建docker镜像。按项目类型划分，我们遇到3种镜像打包情况。
1. 后端项目
后端服务90%是golang项目，针对golang的镜像，我们采取将golang项目编译成可执行文件，基于最小的alpine镜像打包入docker，这里遇到过一个问题，就是alpine里缺少openssl的证书，无法支持https，我们自定义了新的基础镜像，不仅将证书文件打入镜像，同时为了线上调试方便，增加了tcpdump、strace、bash等工具，在初期调试容器间通信问题时发挥重要的作用。
2. 前端静态文件
见闻的后台以及m站基于Vue，编译后生成的静态文件打入镜像，通过nginx访问。 为了支持HTTP2，我们打入nginx镜像缺少的证书。
3. 服务端渲染
主站PC站基于nodejs、Vue实现服务端渲染，所以不仅需要依赖nodejs，而且需要利用pm2进行nodejs生命周期的管理。为了加速线上镜像构建的速度，我们利用taobao源https://registry.npm.taobao.org进行加速, 并且将一些常见的npm依赖打入了基础镜像，避免每次都需要重新下载，镜像打包从开始的3分钟缩减到1.5分钟。
三类镜像结构
持续集成
我们利用Gitlab CI配置了测试、镜像构建、镜像发布、自动部署等流程，后端服务从提交代码到测试分支到测试环境自动部署完成花费1.5分钟，前端服务平均为2.5分钟。
CI任务中的test->build->docker->deploy流程
云平台的选择
最终，我们选择了腾讯云的容器服务，主要基于以下几点考虑：
• 腾讯云的容器服务是在腾讯云的Iaas上为每个用户构建容器集群，腾讯云提供的微服务架构和持续集成与交付的应用场景基本满足了我们的述求。
• 腾讯云的容器服务是基于Kubernetes实现的，支持完全的kubernetes能力。
• 腾讯云在Kubernetes上实现了他们的存储、负载均衡等产品的插件、复用了腾讯云本身平台的监控、日志等能力。减少了我们接入和开发的成本。
服务在腾讯云的应用
我们将我们的应用重构成微服务的架构，每个微服务部署成腾讯云容器服务上的一个服务，前端接入通过一个负载均衡。后端服务间可互相访问。
服务器安全方面，内部服务器通过VPC进行网络隔离，将网络划分为生产环境、测试环境，在生产环境中又划分backend子网和data子网，设定子网之间的访问规则。
为了禁止内部服务器的外网访问，不给内部服务器分配外网IP，仅通过跳板机访问。
性能对比
利用locust模拟线上请求的比例，利用2台16核的压测机在内网对10台16C32G的机器上的服务进行压测，达到1w/s QPS以上，并且服务的负载并没达到极限，这已经是之前PHP生产环境20+台16C32G服务器能达到的QPS。
线上调用追踪
通过追踪API调用链的流向与耗时，我们可以找出性能的瓶颈。我们通过zipkin实际优化了几种情况:
• 服务调用冗余
当拉取文章列表的时候，我们需要拉取文章对应的作者信息，开始的时候我们使用拉取单个作者信息的方式，后来性能调优阶段，我们将其改为批量拉取作者列表，减少RPC的冗余。
• 服务耗时长
对于有些本身就比较耗时并且对即时性不是那么苛刻的计算服务，我们为了保证服务的响应时间，会适量地加上缓存。
监控与报警
由从外部系统表征到内部日志，我们将监控分为API健康，程序错误报警，以及服务器/容器负载。
排查问题的流程一般有两种情况，一种是用户发现问题，申报问题，开发人员跟进问题；一种是我们的监控优先发现问题，开发人员在用户反馈前跟进并修复。在报警方面，我们通过为监控系统谨慎设置报警阈值，当触发报警时，开发人员会收到邮件。
这里我们在报警的定义上有过思考，即什么样的报警算是有意义的？我们遇到过每天10几条重复的报警，通常开发人员开始时会对报警非常重视，当重复的报警一再出现，渐渐失去了对报警的关注。所以我们有解除一些不必要的报警，并且对剩余一些报警进行调查，甚至有些警报是因为监控工具本身的不准确引起的。
API健康
我们设置默认的时间区间是5分钟
• 统计API五分钟内平均QPS
• API 98%以内的延迟分布
• QPS最高的前10的API
• API的返回码的分布
程序错误报警
后端程序内接入Sentry日志报警系统，golang程序捕获panic日志以及error日志，并发送报警邮件。
服务器/容器负载
通过在服务器上运行telegraf daemon进程，收集服务器metrics并发送给influxdb，使用Grafana作为前端面板，对服务器负载以及容器的平均CPU、内存占用率进行监控。
结束语
本文介绍了华尔街见闻通过重构和服务容器的重新部署，实践微服务架构的情况。经过几个月的开发测试，我们不仅完成了线上服务从PHP到Golang的转型，更在服务的稳定性上经历了考验，支撑了几次重大新闻的高流量。
在开发流程上，搭建了完善的自动化工具，减少了人工操作的重复性和误操作概率。
在运维方面，由于监控系统对系统完整的监控，与Kubernetes健全的上线、下线、回滚、拓容功能配合，能以极快的速度处理线上问题。
收起阅读 »
