行業內各巨頭的自動化運維架構都各種功能,各種酷炫,讓人可望不可及。
如下圖,現在行業內各巨頭自動化運維架構的最終樣子大家都知道了,但是如何根據自己團隊當前的情況一步步向這個目標演進?
筆者所在團隊,三個半開發,要維護幾十臺云機器,部署了十來個應用,這些應用 90% 都是遺留系統。
應用系統的編譯打包基本在程序員自己的電腦上。分支管理也清一色的 dev 分支開發,測試通過后,再合并到 master 分支。
生產環境的應用配置要登錄上具體的機器看才知道,更不用說配置中心及配置版本化了。對了,連基本的機器級別的基礎監控都沒有。
我平時的工作是 50% 業務開發,50% 運維。面對這么多問題,我就想,如何在低成本情況下實現自動化運維。
本文就是總結我在這方面一些經驗和實踐,希望對讀者有幫助。
別說話,先上監控和告警
事情有輕重緩急,監控和告警是我覺得一開始就要做的,即使業務開發被拖慢。只有知道了當前的情況,你才好做下一步計劃。
現在市面上監控系統很多:Zabbix、Open-Falcon、Prometheus,但是最終我選擇了 Prometheus。
原因有如下幾點:
它是拉模式的。
它方便使用文本方式來配置,有利于配置版本化。
插件多,想要監控什么,基本都會有現成的插件。
以上三者,我基本都要重新學,我為什么不學一個 Google SRE 書上推薦的呢?
之前我們已經介紹過,人少機器多,所以安裝 Prometheus 的過程也必須要自動化,同時版本化。我使用的是 Ansible + Git 實現。
最終樣子如下:
這里需要簡單介紹一下:
Prometheus Server 負責監控數據收集和存儲。
Prometheus Alert manager 負責根據告警規則進行告警,可集成很多告警通道。
node-exporter[1] 的作用就是從機器讀取指標,然后暴露一個 http 服務,Prometheus 就是從這個服務中收集監控指標。當然 Prometheus 官方還有各種各樣的 exporter。
使用 Ansible 作為部署工具的一個好處是太多現成的 role 了,安裝 Prometheus 時,我使用的是現成的:prometheus-ansble[2]。
有了監控數據后,我們就可以對數據進行可視化,Grafana 和 Prometheus 集成得非常好,所以我們又部署了 Grafana:
在 Grafana 上查看 nodex-exporter 收集的數據的效果圖大概如下:
可是,我們不可能 24 小時盯著屏幕看 CPU 負載有沒有超吧?這時候就要上告警了,Promehtues 默認集成了 N 多告警渠道,可惜沒有集成釘釘。
但也沒有關系,有好心的同學開源了釘釘集成 Prometheus 告警的組件:prometheus-webhook-dingtalk[3]。
接著,我們告警也上了:
完成以上工作后,我們基礎監控的架子就完成了,這為我們后期上 Redis 監控、JVM 監控等更上層的監控做好了準備。
配置版本化要從娃娃抓起
在搭建監控系統的過程中,我們已經將配置抽離出來,放到一個單獨的代碼倉庫進行管理。以后所有部署,我們都會將配置和部署邏輯分離。
關于如何使用 Ansible 進行配置管理,可以參考這篇文章:How to Manage Multistage Environments with Ansible[4] 。
我們就是使用這種方式來組織環境變量的。
├── environments/ # Parent directory for our environment-specific directories│ ││ ├── dev/ # Contains all files specific to the dev environment│ │ ├── group_vars/ # dev specific group_vars files│ │ │ ├── all│ │ │ ├── db│ │ │ └── web│ │ └── hosts # Contains only the hosts in the dev environment│ ││ ├── prod/ # Contains all files specific to the prod environment│ │ ├── group_vars/ # prod specific group_vars files│ │ │ ├── all│ │ │ ├── db│ │ │ └── web│ │ └── hosts # Contains only the hosts in the prod environment│ ││ └── stage/ # Contains all files specific to the stage environment│ ├── group_vars/ # stage specific group_vars files│ │ ├── all│ │ ├── db│ │ └── web│ └── hosts # Contains only the hosts in the stage environment│
現階段,我們所有的配置都以文本的方式存儲,將來要切換成使用 Consul 做配置中心,也非常的方便,因為 Ansible 2.0 以上的版本已經原生集成了Consul:consul_module[5]。
Tips:Ansible 的配置變量是有層次的,這為我們的配置管理提供了非常大的靈活性。
Jenkins 化:將打包交給 Jenkins
我們要將所有項目的打包工作交給 Jenkins。當然,現實中我們是先將一些項目放到 Jenkins 上打包,然后逐步將項目放上 Jenkins。
首先我們要有 Jenkins,搭建 Jenkins 同樣有現成的 Ansible 腳本:ansible-role-jenkins[6]。
注意了,在網上看到的大多文章告訴你 Jenkins 都是需要手工安裝插件的,而我們使用的這個 ansible-role-jenkins 實現了自動安裝插件,你只需要加一個配置變量 jenkins_plugins 就可以了。
官方例子如下:
---- hosts: all vars: jenkins_plugins: - blueocean - ghprb - greenballs - workflow-aggregator jenkins_plugin_timeout: 120 pre_tasks: - include_tasks: java-8.yml roles: - geerlingguy.java - ansible-role-jenkins
搭建好 Jenkins 后,就要集成 Gitlab 了。我們原來就有 Gitlab ,所以不需要重新搭建。
最終 Jenkins 搭建成以下這個樣子:
關于 Jenkins master 與 Jenkins agent 的連接方式,由于網絡環境各不相同,網上也有很多種方式,大家自行選擇適合的方式。
現在我們需要告訴 Jenkins 如何對我們的業務代碼進行編譯打包,有兩種方法:
界面上設置
使用 Jenkinsfile:類似于 Dockerfile 的一種文本文件,具體介紹:Using a Jenkinsfile[7]
我毫不猶豫地選擇了第二種,因為一是利于版本化;二是靈活。
Jenkinsfile 類似這樣:
pipeline { agent any stages { stage('Build') { steps { sh './gradlew clean build' archiveArtifacts artifacts: '**/target/*.jar', fingerprint: true } } }}
那么 Jenkinsfile 放哪里呢?答案是和業務代碼放在一起,類似這樣每個工程各自管理自己的 Jenkinsfile:
這時,我們就可以在 Jenkins 上創建一個 pipleline Job了。關于分支管理,我們人少,所以,建議所有項目統一在 master 分支進行開發并發布。
讓 Jenkins 幫助我們執行 Ansible
之前我們都是在程序員的電腦執行 Ansible 的,現在我們要把這項工作交給 Jenkins。
具體操作:
在 Jenkins 安裝 Ansible 插件[8]
在 Jenkinsfile 中執行
withCredentials([sshUserPrivateKey(keyFileVariable:"deploy_private",credentialsId:"deploy"),file(credentialsId: 'vault_password', variable: 'vault_password')]) { ansiblePlaybook vaultCredentialsId: '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 是 Jenkins ansible 插件提供的 pipeline 語法,類似手工執行:ansible-playbook 。
withCredentials 是 Credentials Binding[9] 插件的語法,用于引用一些敏感信息,比如執行 Ansible 時需要的 ssh key 及 Ansible Vault 密碼。
一些敏感配置變量,我們使用 Ansible Vault[10] 技術加密。
Ansible 腳本應該放哪?
我們已經知道各個項目各自負責自己的自動化構建,所以 Jenkinfile 就放到各自項目中。
那項目的部署呢?同樣的道理,我們覺得也應該由各個項目自行負責,所以我們的每個要進行部署的項目下都會有一個 Ansible 目錄,用于存放 Ansible 腳本。
類似這樣:
但是,怎么用呢?我們會在打包階段將 Ansible 目錄進行 zip 打包,到真正部署時,再解壓執行里面的 playbook。
快速為所有的項目生成 Ansible 腳本及Jenkinsfile
上面,我們將一個項目進行 Jenkins 化和 Ansible 化,但是我們還有很多項目需要進行同樣的動作。
考慮到這是體力活,而且以后我們還會經常做這樣事,所以我決定使用 cookiecutter[11] 技術自動生成 Jenkinsfile 及 Ansible 腳本,創建一個項目,像這樣:
小結
總結下來,我們小團隊的自動化運維實施的順序大概為:
上基礎監控
上 Gitlab
上 Jenkins,并集成 Gitlab
使用 Jenkins 實現自動編譯打包
使用 Jenkins 執行 Ansible
以上只是一個架子,基于這個“架子”,就可以向那些大廠高大上的架構進行演進了,比如:
CMDB 的建設:我們使用 ansible-cmdb[12] 根據 inventory 自動生成當前所有機器的情況。
發布管理:Jenkins 上可以對發布的每個階段進行定制。藍綠發布等發布方式可以通過修改 Ansible 腳本和 Inventory 實現。
自動擴縮容:通過配置 Prometheus 告警規則,調用相應 webhook 就可以實現。
ChatOps:ChatOps 實戰[13]。
以上就是我關于自動化運維的一些實踐,但是還在演進的路上,希望能與大家交流。
-
監控系統
+關注
關注
21文章
3904瀏覽量
174420 -
自動化
+關注
關注
29文章
5562瀏覽量
79239 -
機器
+關注
關注
0文章
780瀏覽量
40711
原文標題:超實用:小團隊如何從零搭建一個自動化運維體系?
文章出處:【微信號:magedu-Linux,微信公眾號:馬哥Linux運維】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論