linux那些事儿之我...(Linux怎么学)

学生信的那些事儿之七 - Linux基础之Shell脚本编程

沿着前面的轨迹，接下来是Linux中shell脚本的学习。这对于生信工程师后续处理大量(海量更合适些)数据是非常非常重要的，但是同样的，作为一个有点古板的人，对于"脚本"是什么意思我都死磕了好久。主要觉得有些抽象，尤其是跟生信的同事讨论项目分析部分的问题时，他们经常会说道这个词，在他们意识里这是个不言自明的术语，殊不知对外行人而言(比如我)，那简直就是无情的"知识的诅咒"。经常是我假装听懂了，然后继续讨论下面的问题，形成一个模糊的印象。

百度上的解释是：脚本（Script）是一种批处理文件的延伸，是一种纯文本保存的程序，一般来说的计算机脚本程序是确定的一系列控制计算机进行运算操作动作的组合，在其中可以实现一定的逻辑分支等。不知道你能不能看懂，反正我开始的时候真是一知半解。

鸟哥私房菜的解释是：shell script是利用 shell的功能所写的一个"程序"，这个程序是使用纯文本文件，将一些shell的语法与命令(含外部命令)写在里面，搭配正则表达式、管道命令与数据流重定向等功能，以达到我们所想要的处理的目的。不明觉厉，好像更看不懂了···

Jude的简单粗暴大白话解释是：脚本就是Linux中很多命令按照一定规则的组合，以实现某个特定的功能。Linux中有很多简单的命令，往往只是进行了简单的对话，比如 cd就是进入到某个目录，简单直接。但是如果我想进入某个目录A，然后在目录A中创建目录B，再在目录B中创建文本C呢？当然可以一步一步操作，如果想要一步到位呢，那就可以用脚本，把三个命令写在一起，一起执行。好像有点啰嗦···

或者从英语的角度去理解，脚本的对应英文是Script，而这个单词的中文释义中还有剧本的意思。剧本就好理解了啊，剧本就是导演(生信工程师)基于某个主旨(要实现的目标)按照一定的手法(规则)所写的一个故事。不管是哪个演员，都得按照剧本演。所以，学好英语对于生信也是有帮助的~

按照脚本的复杂程度可以分为：

这个无需多说，其实就是若干个简单命令的顺序排列，执行脚本后会按照命令的前后关系从前往后一一执行。

相对于简单的基本脚本，结构化的命令脚本可以施加逻辑流程控制，从而改变程序(命令)执行的顺序。基本脚本中的命令就是从上往下执行，但是结构化的命令脚本可以根据逻辑判断重复或者跳过某些命令。

常用的结构化命令(语句)有：

后面还有什么嵌套循环啊啥的，不过我觉得上面的7中命令学到家了，应该可以应付大部分在生信分析里面的应用了。

记得高中的时候，物理老师(也是班主任)在给我们讲解习题时有个有意思的套路：不管什么难题现在下面写个"答："，以示自己解决问题的决心，也是一种正向的心理暗示。脚本编写也是有套路的，不过总的来说还是比较简单。

对于简单的脚本(超级简单的那种)，直接几个命令连在一起即可，中间用"；"隔开。

对于更长更复杂的脚本，一般需要创建一个文本，并在里面编辑。这就涉及到了文本编辑器，比较常用和简单的一般有nano和vim，实在很简单，规则也容易理解，教程随手可得，不多说。

比如用vim创建了一个脚本之后，具体的语法(套路)：

ok，脚本写完了，怎么让脚本开始工作呢？这有涉及到之前讲过的环境变量和相对路径、绝对路径了。方法有三：

就这么多吧，应该有点感觉到了，剩下的就是狂练狂练了~

说说数据中心日常维护工作的那些事儿

数据中心要保持稳定的运行，需要大量的专业技术人员。一般承担重要业务的数据中心都是有人24小时值守，无人值守的数据中心一般只能承担不重要业务，完全无人管理维护的数据中心几乎没有。所以数据中心日常维护工作烦琐，但又很重要。随着人们的工作生活对数据的完全依赖，承载数据计算、运行的数据中心正发挥着越来越重要的作用，这更突显出维护工作的重要。

当一个数据中心建成投产后，维护工作就开始了，一直到数据中心的生命周期结束。一般我们可以将数据中心的维护工作分为四大类：一是日常检查类;二是应用变更、部署类;三是软、硬件升级类;四是突发故障处理类，下面就来详细说一说这些维护工作，让大家对维护工作有个了解。

日常检查

“千里之堤，溃于蚁穴”。任何的故障在出现之前都可能会有所表现，小的隐患不消除，可能导致重大的故障出现，所以数据中心日常的例行检查工作枯燥，但也很重要，可以及时发现一些运行中的隐患。根据数据中心承载业务重要性的不同，要对数据中心里的所有运行的设备进行例行检查。一些数据中心设备厂商提供了检查软件，比如网管软件，安全防护软件等。可以利用这些软件对数据中心网络进行检查，看日志是否有异常告警，网络是否出现过短时中断，端口是否出现UP/DOWN等。通过网络探测软件看网络质量如何。检查服务器应用服务是否正常，CPU内存等利用率是否正常。对应用业务进行检查，比如如果有搜索业务，就可以通过服务器进行单词搜索，看搜索的结果和延迟是否在正常的范围之内。这些检查每日都要重复检查，一旦有异常及时处理与消除，必要时将重要业务切换到备用环境中，然后排除后再切回。

对数据中心的机房环境也要进行检查，环境的温度、湿度、灰尘是否合乎要求。空调、供电系统进行运行良好，设备运行是否过热，地板、天窗、消防、监控都是检查的部分。不合理的地方要及时进行整改，而不应该偷懒。经常到一些数据中心，就会发现值班维护人员很多都抱着电脑在浏览网页，打游戏。对于日常检查应付一下，甚至根本不去检查，只要没有出现故障，就打游戏消耗时间，这样数据中心出现故障是迟早的事。一旦出现故障就毛手毛脚，甚至哪个业务走的哪个设备，哪个端口哪个网线都不清楚，本来一个小故障可能因为不熟悉导致大故障，因此日常检查绝不能应付，虽然需要不断重复，但却很重要，在持续的检查过程中，将会对数据中心的理解越来越深，这样每次检查都会有新的发现，在检查中进行学习。

应用变更

数据中心承载的业务不会是一成不变的，随着业务的多样化，经常要对业务进行调整，包括服务器和网络的设置。因此要对服务器和网络设备操作很熟悉，主要需要掌握Linux服务器命令和网络协议。要根据应用的需要，做出变更。这时就对维护人员提出了更高的要求，不仅是对数据中心原有业务要非常熟悉，还要对新上的应用业务有正确的理解，这样才能在不影响原有业务的基础上做调整。这样的应用变更每个月可能都要做几次，是数据中心维护人员的必修课，突显了一个技术人员的基本技能水平。这时要对设备操作命令比较熟悉，懂得如何实现业务，要经常和设备厂商的技术人员打交道，通过交流尽快掌握设备操作方法。同时，由于设备厂商对应用业务缺乏了解，这就需要维护人员在应用业务和设备具体实现之间做好协调，处理。以最快的时间和最小的代价完成应用业务部署。

软硬件升级

数据中心的设备一般运行周期是五年，不断地有设备需要逐渐淘汰进行更换，也有一些设备因为存在软件缺陷需要升级，因此软硬件升级也是维护工作的一部分，尤其是软硬件出现故障时，就必须要进行更换。有时为了不影响业务，往往还需要设备厂商提供软件补丁来解决问题。数据中心的设备成百上千，出现软硬件故障很正常，所以要不断地进行软硬件升级，这类工作往往都要在业务量最少的'凌晨之后进行，维护人员通宵熬夜是常有的事，维护人员要有一个良好的身体素质，否则会吃不消。软硬件升级时需要做好回退机制，以防升级出现问题时无法回退，业务长时间无法恢复。当接手数据中心维护工作就会发现，怎么会有那么多的升级，几乎每个月都要有升级操作，熬夜升级工作成了维护人员的家常便饭。

突发故障

没有任何一个数据中心是不出故障的，在数据中心运行的过程中都会出现这样那样的问题。这时就显示出维护人员的高技能水平，根据统计百分之八十的故障都是人为故障，所以维护人员的水平高低往往决定了一个数据中心运行的稳定程度。另外对于突发故障，高水平的维护人员可以静下心来冷静分析故障的触发原因，迅速找到解决的方法，如果在短时间内找不到解决方法，也可以通过切换到备用设备上先恢复业务，再进行分析。这时拥有高水平的维护人员对于一个数据中心至关重要，在关键时刻就能派上用场。

虽然这些工作看起来有些平常，但千万别小看它们。数据中心维护工作实际上非常重要，关乎着整个数据中心业务的正常运行。目前市场上这类专业人才非常抢手，尤其对于具有较深故障排查水平的人才比较缺乏。只有重视数据中心的维护工作，才能给数据中心一个平安。

程序员应知应会之自动化运维那些事儿

对于一个开发人员来讲，可能运维并不是自己的职责所在。但是作为一名开发人员，却不能不了解自动化运维的整个流程。因为对于一个信息系统而言，开发和运维本质是一体的，尤其对于一些小公司来讲，可能运维人员本身就是开发人员抽空兼任的。

而自动化运维，本质上是介于开发和运维之间的，是运维和开发的交集，甚至很多时候都要写不少代码。因此，任何一个开发人员，都需要有自动化运维的相关知识。

一个了解好的开发人员，即使自己不做运维相关的工作，也能够知道自己在将项目交付给运维人员的时候，哪些东西是重要的，那些是必须配置的等等。然而在实际工作中，往往开发人员会给运维人员留下一些坑，一些只有他自己知道，而运维人员不知道的东西。导致运维人员自己试了很多次发现不行的时候，找到开发人员，开发人员研究了一下才会告诉他，在某某环境中必须用哪个端口之类的。这样不仅白白浪费了运维人员的时间，也增加了很多沟通的工作量。

反过来也是如此，一些现场的问题如果运维人员不能现场给出问题的定位。对于开发人员来讲是非常难以复现的。比如之前有某家企业，运维人员在客户现场发现问题。费了很大力气从客气的内网里面把日志导出来，发给开发人员，结果开发人员仔细研究了日志之后，发现是网不通的问题。开发人员显然是不可能知道为啥网不通的，搞不好是压根没连网线。

所以今天我们来聊一聊，对于一个程序员来讲，需要了解的自动化运维的那些事。

一、自动化运维的概念

随着信息时代的持续发展，初期的几台服务器已经发展成为了庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求。一个运维人员手工配置几台服务器还可能。配置几百上千台服务器那就累死了，还容易出错。那么就需要对运维工作进行标准化、自动化、架构优化、过程优化等。从面降低运维服务成本。其中，自动化最开始作为代替人工操作为出发点的诉求被广泛研究和应用。

所谓自动化运维，即在最少的人工干预下，结合运用脚本与第三方工具，保证业务系统7*24小时高效稳定运行。这是所有业务系统运维的终极目标。

按照运维的发展成熟度来看，运维大致可分为三个阶段：

（1）依靠纯手工，重复地进行软件的部署与运维；

（2）通过编写脚本，方便地进行软件的部署与运维；

（3）借助第三方工具，高效地进行软件的部署与运维；

二、自动化运维需要解决的问题

自动化运维通常来讲，需要解决以下几个问题：自动部署配置、风险事前预警、故障事中解决、和故障事后管理。

三、自动化运维的常用工具

自动化运维常用的工具包括以下几种：

1、Ansible

ansible是基于Python开发的自动化运维工具，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。

ansible具有如下一些特性：

(1)模块化：调用特定的模块，完成特殊的任务。

(2)Paramiko(python对ssh的实现)，PyYaml，jinja2(模块语言)三个关键模块。

(3)支持自定义模块，可使用任何编程语言写模块。

(4)基于python语言实现。

(5)部署简单，基于python和SSH(默认已安装)，agentless，无需代理不依赖KPI(无需SSL)。

(6)安全，基于OpenSSH

(7)幂等性：一个任务执行一次和执行n遍效果一样，不因重复执行带来意外情况。

(8)支持playbook编排任务，YAML格式，编排任务，支持丰富的数据结构。

(9)较强大的多层解决方案role。

2、Chef

Chef是一个功能强大的自动化工具，可以部署，修复和更新以及管理服务器和应用程序到任何环境。

Chef主要分为三个部分 Chef Server、Workstation以及 Chef Client。用户在 Workstation上编写 Cookbook。然后，通过 knife命令上传到 Chef Server。最后，在 Chef Client上面实施安装和部署工作。所以，对于 Cookbook地编写在整个自动化部署中起到了重要的作用。

Chef Server包含所有配置数据，并存储描述Chef-Client中每个Nodes的Recipe，Cookbook和元数据。配置详细信息通过Chef-Client提供给Nodes。所做的任何更改都必须通过Chef Server进行部署。在推送更改之前，它通过使用授权密钥来验证Nodes和Workstations是否与服务器配对，然后允许Workstations和Nodes之间进行通信。

Workstations用于与Chef-server进行交互，还用于与Chef-nodes进行交互。它还用于创建Cookbook。Workstations是所有交互发生的地方，在这里创建，测试和部署Cookbook，并在Workstations中测试代码。

Chef命令行工具是创建，测试和部署Cookbook的地方，并通过此策略将其上载到Chef Server。

Knife用于与ChefNodes进行交互。

Test Kitchen用于验证Chef代码

Chef-Repo是一个通过Chef命令行工具在其中创建，测试和维护Cookbook的存储库。

Nodes由Chef管理，每个Nodes通过在其上安装Chef-Client进行配置。 ChefNodes是一台机器，例如物理云，云主机等。

Chef-Client负责注册和认证Nodes，构建Nodes对象以及配置Nodes。Chef-Client在每个Nodes上本地运行以配置该Nodes。

Cookbook是Chef框架的重要基础功能之一。在 Chef Server对目标机器做安装部署的时候，是通过 Runlist。而 Runlist里面又包含了一个一个具体的 Cookbook，所以，最终对一个目标机器的部署任务就落到了 Cookbook上。而对于 Cookbook来说，其中包含了多个组件，我们可以将 Cookbook简单地理解成一个容器或者可以理解为一个包，里面包含了 recipes、files、templates、libraries、metadata等信息。这些信息用于配置我们的目标机器。

3、Puppet

puppet是一种Linux、Unix平台的集中配置管理系统，所谓配置管理系统，就是管理其里面诸如文件、用户、进程、软件包等资源。它可以运行在一台服务器端，每个客户端通过SSL证书连接到服务端，得到本机器的配置列表，然后根据列表来完成配置工作，所以如果硬件性能比较高，维护管理上千上万台机器是非常轻松的，前提是客户端的配置、服务器路径、软件需要保持一致。

客户端Puppet会调用本地facter，facter探测出该主机的常用变量，例如主机名、内存大小、IP地址等。然后Puppetd把这些信息发送到Puppet服务端；

Puppet服务端检测到客户端的主机名，然后会检测manifest中对应的node配置，并对这段内容进行解析，facter发送过来的信息可以作为变量进行处理；

Puppet服务器匹配Puppet客户端相关联的代码才能进行解析，其他的代码不解析，解析分为几个过程，首先是语法检查，然后会生成一个中间的伪代码，之后再把伪代码发给Puppet客户端；

Puppet客户端接收到伪代码之后就会执行，执行完后会将执行的结果发送给Puppet服务器；

Puppet服务端再把客户端的执行结果写入日志。

4、Saltstack

SaltStack是基于python开发的一套C/S自动化运维工具。部署轻松，扩展性好，很容易管理上万台服务器，速度够快。与服务器之间的交流,以毫秒为单位。SaltStack提供了一个动态基础设施通信总线用于编排,远程执行、配置管理等等。它的底层使用ZeroMQ消息队列pub/sub方式通信，使用SSL证书签发的方式进行认证管理，传输采用AES加密。

在saltstack架构中服务器端叫Master，客户端叫Minion。

在Master和Minion端都是以守护进程的模式运行，一直监听配置文件里面定义的ret_port(接受minion请求)和publish_port(发布消息)的端口。当Minion运行时会自动连接到配置文件里面定义的Master地址ret_port端口进行连接认证。

saltstack除了传统的C/S架构外，其实还有一种叫做masterless的架构，其不需要单独安装一台 master服务器，只需要在每台机器上安装 Minion端，然后采用本机只负责对本机的配置管理机制服务的模式。

saltstack提供如下一些功能：

（1）远程执行：（批量执行命令）在master上执行命令时，会在所有的minion上执行。

（2）配置管理/状态管理：（描述想到达到的状态，saltstack就会去执行）

（3）云管理(cloud)：用于管理云主机

（4）事件驱动：被动执行，当达到某个值会自动触发

这四种自动化运维工具的比较如下，现在主流的基本上ansible和saltstack用的多一些：