业界巨头的自动化运维架构，功能多样，功能炫酷，让人望尘莫及。如下图，大家都知道业界巨头的自动化运维架构最终的样子，但是如何根据自己团队的现状，一步步朝着这个目标演进呢？作者团队三个半开发人员，维护着几十台云机，部署了十几个应用。这些应用程序中有90%是遗留系统。应用系统的编译和打包基本上是在程序员自己的电脑上完成的。分支管理也是在dev分支开发，测试通过后合并到master分支。生产环境的应用配置只有登录特定的机器才能知道，更不用说配置中心和配置版本控制了。顺便说一句，基本机器级别没有基本监控。我平时的工作是50%业务开发，50%运维。面对这么多问题，我就想着如何低成本的实现自动化运维。这篇文章就是总结一下我在这方面的一些经验和实践，希望对读者有所帮助。不说了，先从监控告警说起。事情有优先级。监控告警是我认为一开始就应该做的，即使业务发展放缓。只有了解了当前的情况，才能制定下一步的计划。市面上有很多监控系统：Zabbix、Open-Falcon、Prometheus，但最后我选择了Prometheus。这有几个原因：它是拉模式。使用文本配置方便，有利于配置版本控制。插件很多，想监控什么，基本都有现成的插件。上面三本我基本都要重新学，为什么不学一本谷歌SRE的书推荐呢？我们之前已经介绍过，人少机器多，所以安装Prometheus的过程也必须自动化和版本化。我正在使用Ansible+Git实现。最终的样子如下：这里简单介绍一下：PrometheusServer负责监控数据的收集和存储。PrometheusAlertmanager负责根据告警规则进行告警，可以集成多个告警通道。node-exporter[1]的作用是从机器上读取指标，然后暴露一个http服务，Prometheus从中收集监控指标。当然，Prometheus官方有各种出口商。使用Ansible作为部署工具的好处之一是现成的角色太多了。安装Prometheus时，我使用的是现成的：prometheus-ansble[2]。有了监控数据之后，我们就可以把数据可视化了。Grafana和Prometheus集成的很好，所以我们又部署了Grafana：nodex-exporter采集的数据在Grafana上的渲染大致如下：但是，我们不可能24小时盯着屏幕看CPU负载已经超过了吗？这时，警报即将发出。Promehtues默认集成了N多报警通道，可惜钉钉没有集成。不过没关系，好??心的同学开源了钉钉集成的Prometheus告警组件：prometheus-webhook-dingtalk[3]。然后，我们也报警：完成以上工作后，我们的基础监控架子就搭建完成了，为我们后面的Redis监控、JVM监控等更高层的监控做准备。配置版本控制应该从婴儿开始。在搭建监控系统的过程中，我们已经将配置抽取出来，放到单独的代码仓库中进行管理。对于所有未来的部署，我们将分离配置和部署逻辑。关于如何使用Ansible进行配置管理，可以参考这篇文章：HowtoManageMultistageEnvironmentswithAnsible[4]。这就是我们组织环境变量的方式。......──hosts#Containsonlythehostsintheprodenvironment││└──stage/#Containsallfilesspecifictothestageenvironment│├──group_vars/#stagespecificgroup_varsfiles││├──all││├──db││└──web│└──hosts#Containsonlythehostsinthestageenvironment│now在这个阶段，我们所有的配置都是以文本格式存储的。以后改用Consul作为配置中心会很方便，因为Ansible2.0以上的版本已经原生集成了Consul：consul_module[5]。Tips：Ansible的配置变量是分层的，这为我们的配置管理提供了极大的灵活性。Jenkinsization：把打包交给Jenkins我们想把所有项目的打包交给Jenkins。当然在现实中，我们是先把一些项目打包到Jenkins上，然后再逐步把项目放到Jenkins上。首先，我们需要詹金斯。还有一个现成的用于构建Jenkins的Ansible脚本：ansible-role-jenkins[6]。注意，你在网上看到的大部分文章都告诉你Jenkins需要手动安装插件，而我们使用的ansible-role-jenkins实现了插件的自动安装。你只需要添加一个配置变量jenkins_plugins。官方示例如下：----hosts:allvars:jenkins_plugins:-blueocean-ghprb-greenballs-workflow-aggregatorjenkins_plugin_timeout:120pre_tasks:-include_tasks:java-8.ymlroles:-geerlingguy.java-ansible-role-jenkins后搭建Jenkins，即将集成Gitlab。我们已经有了Gitlab，所以不需要重建。最终Jenkins搭建如下：关于Jenkinsmaster和Jenkinsagent的连接方式，由于网络环境不同，网上有很多方式，大家可以自行选择合适的方式。现在我们需要告诉Jenkins如何编译和打包我们的业务代码。方法有两种：界面上useJenkinsfile：类似于Dockerfile的文本文件，具体介绍：UsingaJenkinsfile[7]我毫不犹豫的选择了第二种，因为一种有利于版本控制；另一个是灵活性。Jenkinsfile看起来像这样：pipeline{agentanystages{stage('Build'){steps{sh'./gradlewcleanbuild'archiveArtifactsartifacts:'**/target/*.jar',fingerprint:true}}}}所以放在哪里詹金斯文件？答案是和业务代码放在一起，像这样，每个项目管理自己的Jenkinsfile：此时，我们可以在Jenkins上创建一个piplelinejob。关于分支管理，我们人少，所以建议所有项目都在master分支开发发布。让Jenkins帮助我们运行Ansible之前我们都是在程序员的电脑上运行Ansible，现在我们要把这个工作交给Jenkins。具体操作：在Jenkins中安装Ansible插件[8]在Jenkins文件中执行withCredentials([sshUserPrivateKey(keyFileVariable:"deploy_private",credentialsId:"deploy"),file(credentialsId:'vault_password',variable:'vault_password')]){ansiblePlaybookvaultCredentialsId:'vault_password',inventory:"environments/prod",playbook:"playbook.yaml",extraVars:[ansible_ssh_private_key_file:[value:"${deploy_private}",hidden:true],build_number:[value:"${params.build_number}",hidden:false]]}这里需要说明一下：ansiblePlaybook是Jenkinsansible插件提供的管道语法，类似于手动执行：ansible-playbook。withCredentials是CredentialsBinding[9]插件的语法，用来引用一些敏感信息，比如执行Ansible需要的sshkey和AnsibleVault密码。一些敏感的配置变量使用AnsibleVault[10]技术进行加密。Ansible脚本应该放在哪里？我们已经知道每个项目负责自己的自动化构建，所以把Jenkinfile放在自己的项目中。项目部署情况如何？同样的道理，我们觉得每个项目都应该对自己负责，所以我们每个要部署的项目都会有一个Ansible目录，用来存放Ansible脚本。像这样：但是，如何使用它？我们在打包阶段会对Ansible目录进行zip打包，真正部署的时候再解压并执行里面的playbook。为所有项目快速生成Ansible脚本和Jenkinsfiles上面，我们已经对一个项目进行了Jenkinsized和Ansibleized，但是我们还有很多项目需要执行相同的操作。考虑到这是手工活，以后我们会经常做这样的事情，所以决定使用cookiecutter[11]技术自动生成Jenkinsfile和Ansible脚本，创建一个项目是这样的：维度实现顺序大致如下如下：在Jenkins上对Gitlab进行基础监控，并集成Gitlab使用Jenkins实现自动编译打包使用Jenkins执行Ansible以上只是一个架子。进化了，例如：CMDB构建：我们使用ansible-cmdb[12]根据库存自动生成所有机器的当前情况。发布管理：发布的每个阶段都可以在Jenkins上自定义。蓝绿发布等发布方式可以通过修改Ansible脚本和Inventory来实现。自动扩缩容：可以通过配置Prometheus告警规则，调用相应的webhook来实现。ChatOps：ChatOps实战[13]。以上是我在自动化运维方面的一些实践，但还在进化的路上，希望与大家多多交流。相关链接：[1]https://github.com/prometheus/node_exporter[2]https://github.com/ernestas-poskus/ansible-prometheus[3]https://github.com/timonwong/prometheus-webhook-dingtalk[4]https://www.digitalocean.com/community/tutorials/how-to-manage-multistage-environments-with-ansible[5]http://docs.ansible.com/ansible/latest/modules/consul_module.html[6]https://github.com/geerlingguy/ansible-role-jenkins[7]https://jenkins.io/doc/book/pipeline/jenkinsfile/[8]https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin[9]https://jenkins.io/doc/pipeline/steps/credentials-binding/[10]http://docs.ansible.com/ansible/2.5/user_guide/vault.html[11]https://github.com/audreyr/cookiecutter[12]https://github.com/fboender/ansible-cmdb[13]https://showme.codes/2017-10-08/chatops-in-action/
