-----內容簡介-------------

1.DevOps介紹

1.1什麼是DevOps

1.2DevOps原理

1.3 DevOps實踐

1.4 微服務的概念

2.怎麼實現DevOps

2.1從軟體開發角度看

2.2DevOps的支持

2.3 工具的合理選擇

-----------------------------

雲計算是開發和運維的屌絲們對IT的逆襲。原來運維人員的具體分工多處在底層，但在雲時代，開發運維一體化使得運維人員變得尤為重要。

一、DevOps介紹

1、什麼是DevOps

DevOps是一種開發、測試、運營、維護部門之間溝通、協作與整合的軟體過程、方法與系統。DevOps將開發、運維2個概念整合在一起， 是開發、質量管控、運營三個方面整合在一起，強調的是各個部門打破壁壘，開發運維的一體化，互相支持，最終加速開發周期。DevOps的優點：

1）消除開發和運維之間的壁壘

傳統開發完了之後，代碼交給運維團隊，會出現各種牆。

2）快速迭代和快速部署

傳統部署希望開發做更好，開發則希望功能做好儘快發布。傳統的方式很難做到快速迭代和快速部署；快速開發改了一些代碼、參數，很常見，傳統方式是沒法處理的。

為什麼需要DevOps？最主要原因是原來開發完成後就交給運維人員，兩個團隊之間貌似有一堵牆，各干各的活。這種開發一般是一兩個月搞出一個版本，像金融銀行這樣的傳統行業，有時一季、半年出一個版本就很不錯了。但在互聯網時代，需要快速的創新、快速的迭代，一天可能就要推出多少個版本，那這裡就需要用到DevOps的方法。DevOps主要追求的就是速度、節奏，起源於敏捷。

業務敏捷：業務提需求到開發，整個環節要快速，業務的敏捷性是快速開發的一個環節，一些概念互動，業務快速整合及開發，一些工具如Scrum、Sprints、Stories，業務敏捷=業務人員+開發人員。

IT敏捷：持續的迭代、部署，把運維也考慮進來了，it自動化來實現,IT敏捷=開發人員+運維。

2、Devops原理

1）協同合作

運維與開發未能成功促進團隊合作仍然是DevOps取得成功的重大障礙

2）打通壁壘

破開發團隊和運維團隊之間的文化壁壘是最具挑戰的任務

3）端到端的合作

4）基礎設施及代碼

還有一個很重要的一個概念那就是Infrastructure as code。傳統系統部署，從伺服器開始裝操作系統、裝應用、升級補丁、網路配置等事都是由運維人員來操作，一旦離開就會出現問題。但在不久的將來這些工作都會被程序來實現，因為機器實現可拓展性、可靠性、重複性、一致性、能夠審計、能夠記錄、安全等，也會比人做的好。而且在雲裡面正確操作，比傳統IT安全很多。基礎設施及代碼特徵：

· 可擴展性：負載上來以後，不需要人工來擴展伺服器，手動配置都不具備好的擴展

· 可靠性

·可重複性、可複製

·環境的一致性：這次用的一套，下次用到生產絕對一樣

· 可審計

4）支持業務和技術靈活性

5）自動化一切

6）測試一切

7）測試和監控一切

3、Devops實踐

1）基礎設施即代碼

Infrastructure as code，是一個基礎架構的部署服務。如果要開一些機器，全套架構，從網路，從伺服器，這是一個真正文件，比如說Packages是什麼，升級一下相關操作系統，重要的原文件放在什麼地方等。通過這個方式整個一套基礎設施在雲里運行，包括底層架構、網路架構，虛機上運行，裝什麼系統、裝什麼應用、裝什麼伺服器都可以進行。

2）IT自動化

「運維的未來是，讓研發人員能夠藉助工具、自動化和流程，並且讓他們能夠在運維干預極少的情況下部署和運營服務，從而實現自助服務。每個角色都應該努力使工作實現自動化。」——《運維的未來》

說到自動化，感覺又是槽點滿滿，也許有人和我一樣都經歷過為了自動化而自動化的尷尬，在大公司里，不乏專門做自動化工具的團隊，每年出一套工具，「緊跟時代潮流」，然後被迫使用這些自動化工具的團隊怨聲載道；但是有經驗的開發、測試或者運維工程師一定能體會到，「自動化」對於DevOps來說，是剛需。

3）持續集成

4）版本控制集成

5）應用和架構的版本管理

6）監控和日誌

4、微服務的概念

微服務今年最火，啟動的一年，原來很多服務都在一個線程裡面，微服務把功能都做成一個服務，傳統的方式，在一個應用中。

1）開發流程的區別

傳統：整體的應用分成好多步驟，大家各自開發組裝一個應用，通過複製整體應用在多個伺服器來擴展。

微服務：微服務將每個功能集成在一個獨立的服務，通過將未伺服器按需複製分布在多個伺服器來擴展，和SOA有個區別，SOA集成的內容較多，服務做的比較大，05,06年SOA火了，顆粒度的問題，微服務將顆粒度降低的比較細，到具體的功能。

·面向微服務的架構

·目的單一原生小組

·僅通過APIs連接

微服務，是支撐DevOps方法的手段，傳統開發是在一個伺服器裡面，把各種元素裝在一起組合成一個程序，但微服務是每一個服務是一個單獨的單元，可以部署在不同的伺服器上，通過SOA的方法，把它連接起來，再提供整個功能。

微服務如何做開發？傳統開發者分成很多團隊，整個工作常用程序，做好後涉及到整個建造、編輯、退出、測試，直到部署。微服務是由一個個團隊組成，每團隊有自己的服務，做好後，可以獨立的進行測試、開發、部署，然後整個應用組合到一起。張俠表示，開發運維一體化、微服務和Container是同等的，把它們組合起來，加上雲的手段才成為可能。DevOps不光是一個簡單的技術手段，實際上是一個方法理念。

二、怎麼實現DevOps

1、從軟體開發角度看

2、DevOps的支持

3、工具的合理選擇

同樣對於DevOps來說，工具是必要條件，但工具不是充要條件，如果沉迷於各種工具的堆砌，那麼可能跑偏，下面是我們經常會提到的一些工具：

代碼管理（SCM）：GitHub、GitLab、BitBucket、SubVersion

構建工具：Ant、Gradle、maven

自動部署：Capistrano、CodeDeploy

持續集成（CI）：Travis、Jenkins

配置管理：Ansible、Chef、Puppet、SaltStack

容器：Docker、LXC、第三方廠商如AWS

編排：Kubernetes、Core、Apache Mesos

服務註冊與發現：Zookeeper、etcd、Consul

腳本語言：python、ruby、shell

日誌管理：ELK、Logentries

系統監控：Datadog、Graphite、Ganglia、Nagios

性能監控：AppDynamics、New Relic、Splunk

壓力測試：JMeter、Blaze Meter、loader.io

應用伺服器：Tomcat、JBoss、IIS

Web伺服器：Apache、Nginx

資料庫：MySQL、Oracle、PostgreSQL等關係型資料庫；mongoDB、redis等NoSQL資料庫

項目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker

面對茫茫「工具海」，傳統運維團隊在日漸式微，而構建工具的團隊日益壯大起來，這些工具包括持續集成環境和持續交付等等。運維能力應該逐漸延伸到構建和維護基礎設施服務、配置管理、日誌管理、容器管理以及監控等多方面。我的建議是，不選別人認為對的，只選最適合自己的。

1）應用管理的服務

2）基於模板的快速部署

3）AWS代碼服務

4）託管的源碼控制服務

Github雲實現的版本，可以自動擴展，管理雲中的代碼庫，接近開發和測試

使用都是常見的git的常見命令和庫

5）自動交付和發布的服務

6）代碼部署自動化服務

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！