centos运维，docker容器技术与运维

老铁们，大家好，相信还有很多朋友对于centos运维和docker容器技术与运维的相关问题不太懂，没关系，今天就由我来为大家分享分享centos运维以及docker容器技术与运维的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！

Debian、Ubuntu和CentOS,哪一个发行版的运维成本最低

首先来说，CentOS、Ubuntu、Debian都是当下主流的Linux发行版本。如果站在服务器端来说，CentOS应用最为广泛；站在家用来说，Ubuntu应用较为广泛；Debian用的比例并不是太多。

从运维成本上考虑，建议各位选择CentOS，它的运维成本最低，主要体现在以下几方面：

1、市场占有率

因为CentOS是最接近RHEL的企业级操作系统，包资源丰富，CentOS在国内市场占有率最高，包括现在各大云计算平台推荐的镜像也是CentOS。

2、系统稳定性上

Ubuntu最大的特点就是更新频繁，它的内核较其它发行版本来说都要新，但是这也会带来一些问题，比如说：

太新的内核会导致部分老版软件兼容性差，Linux上不少软件和包都很古老；

Ubuntu更新频繁，但事实上服务器系统讲究的是稳定，过于频繁的更新可能会导致系统不稳定。

而CentOS则以稳定为主，更新频率上没有Ubuntu高。另外Ubuntu更注重的是桌面系统，在服务器端并不实用。

3、人力上

掌握CentOS的人占绝大部分，而Ubuntu和Debian更多的是用来“尝鲜”的。大家可以看看各大招聘网站上面对于Linux运维的要求是CentOS必须要会，而对于Ubuntu和Debian则没有要求。

4、技术支持上

CentOS的背后是红帽，而Ubuntu是由创始人和社区维护的，没有大公司的背书。从实力上说，CentOS在这三者里最好。

综上，从运维成本上考虑，CentOS无论是在品牌背书还是稳定性、占有率上，都是排在前列。

Linux运维工程师主要学点什么

linux最先要学的是Linux基础知识，学完基础知识才算入门，之后还要学习综合架构、Shell编程、数据库、云计算以及网络安全方面的知识，以下是linux基础部分要学习的内容：

1.计算机硬件、组成原理、操作系统基础、Linux起源、核心介绍及Linux安装实战入门

2. Xshell远程网络连接Linux、基础优化、远程连接网络基础、Xshell连接故障排错、核心基础命令讲解

3. Linux系统核心通配符体系、三剑客（grep,sed,awk）核心正则表达式精讲及企业级案例实战模拟精讲

4. Bash核心符号、快捷键、通配符详解

5. Linux目录、FHS\挂载、文件属性、核心目录精讲

6. Linux文件及目录管理核心知识和命令精讲（第二关）

7. Linux企业级基础优化（工作中可直接使用

8. Linux文件及目录权限精讲及多个企业案例模拟

9. Linux重要核心命令回顾与深入精讲（第三关）

为什么运维普遍反对使用 CentOS 7

客观的因素

我赞同题主关于“懒惰”的描述，但是这并不是某一个体或者某一公司的问题，而且这不是一个技术问题。这是一个非常普遍的管理问题：

·你不是一个人在战斗，你在团队中。

·团队是由各式各样的人组成的，各类人的比例和社会上基本相同。

·就是有很大一部分人只是混口饭吃，多一事不如少一事。（比如很多答案都提到了“谁背黑锅”这个问题）

对于这种社会规律，要么你就接受，要么你就通过改进生产工具来提高劳动生产率引发小范围“工业革命”（其实就是DevOps的思路），抱怨现象是没有意义的。有一个提到DevOps的答案是匿名+反讽，但是我支持字面的意思：you can you up。一个人能扛下来运维团队的工作，没有领导会反对，那时候混日子那部分人态度会转变，有了失业的压力。

主观的因素

技术本身是有优劣的，题主对“最新”+“稳定”的分析是有逻辑的，但是管理一个团队的目标是产出高。招不到10个同样追求极致的人，招20个一般的也能有一样多的产出，但是质量会降低到这20个人的平均水平。9.9×10< 8.0×20大家都会算。只要把握好平衡，不要出现劣币驱逐良币的状况，团队就能维持下去。这是一个人为的平衡。

DevOps

最后回归说技术，一个人扛下运维团队的工作是绝对做得到的。代价是程序本身要提高自动化能力和设计整体容错恢复机制。如果说“业务运维的存在，是替开发的懒惰在擦屁股。”，一样有道理。但是，上面提到的“运维懒惰”和“开发懒惰”是两个层次的事情。开发作为制造者，有能力破局。运维没有能力去改进系统的功能。系统里任何不满意的地方，归根结底都是开发没做好，不要怨别人，先改变自己。

然后，运维大爷反对用centos7的原因，归根结底应该只有一个：他对centos7不熟，所以在这个版本上做事就没那么爽，没那么快，没那么习惯，没那么顺手。对于运维来说，选择的往往并不是最新最稳定版本，而是自己最熟悉最顺手的版本。真相往往就这么简单。

学习新版本需要成本，而他负担不起这个成本，就不愿意换新版本。自己不熟，一下子又学不会，又不愿意被懂新版本的员工替换掉，自然，就只能要求你用旧版本了。一个非常新的版本，往往是难以招到合适的足够熟悉的运维的，所以，实际生产系统对新版本的采纳往往要更为滞后。更多的运维学会并且熟悉了一个版本之后，这个版本才能流行。至于其他的说法什么的，升级需要折腾什么的。。。归根结底还是不熟，熟到一定程度，升级改脚本都不是问题，拿钱就得干活，不可能一套脚本混一辈子不升级。问题是你得找到对新版本足够熟的运维，这并不总是能实现的。要么这个运维很爱学习一直跟进新版本，要么你们经常更换运维，出个新版本就换个对新版本最熟悉的运维。

如果两者都不是，锅自然就甩给开发了。