容器技術

1.?Docker持續部署圖文詳解

http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=208550161&idx=1&sn=e1bdb3d219c110c79850f43c0fe1d297&key=c76941211a49ab5870652c78bff255aa29b56abb1fbd503a3584dea04af2275000a4e796fee253975115f33b11f203b1&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=8v85tN1QS3hxebVAhDtc6ukXMi3rJa9OXz2dz1W%2FcTgAoFG2PtOeCtCciSf9%2B3eh

要點: 本文演示了如果基于 docker 實現持續部署的過程. 主要最新的代碼提交到 git, 自動會部署到線上, 這一切不是多數工程師一直向往的嗎? 當然 demo 很簡單, 真正用到線上還有很多工作, 比如自動化測試和分級發布等等, 不管怎么說, 文章提供了一種思路, 讓我們從docker 的視角看待問題, 我人為這也是 docker 最最核心的競爭力所在.

2.?Google宣布成立CNCF基金會，Kubernetes 1.0正式發布

http://dockone.io/article/518#rd?sukey=fc78a68049a14bb2cffbb7d4a2dbc0f2d82571c618cbc68358353b2e71c270c4941a93cd7eef75de40b89599d925b74f

要點: kubernetes 終于發布了1.0版本了, 意味著 kubernetes 宣稱可以支持生產環境了, 不過 kubernetes發展太快了, 郵件組中每天有數千封郵件討論 kubernetes 的相關問題, 要想用的化, 還是需要等功能逐漸穩定了之后吧.

3.?剖析Docker文件系統：Aufs與Devicemapper

http://www.infoq.com/cn/articles/analysis-of-docker-file-system-aufs-and-devicemapper

要點: 這不是一篇新文章, 如果稍微了解 docker 的話, 相信大家對 docker 依賴的 cgroup 和 namespace 技術比較容易理解, 但是cgroup 和 namespace 技術在比較早的 linux 內核版本中其實已經支持的比較好了, 為什么 docker 還要依賴比較高(linux 3.8以上)的 linux 內核版本呢? 主要是因為 docker 的分層特性. 為了減少存儲空間, docker 鏡像采用層次化結構, 高層次鏡像可以共享低層鏡像的文件, 同時要支持容器之間隔離, 容器中進程的文件寫入不能被其他容器看到. 為了實現這個目標, docker 依賴于特殊文件系統的特性. 目前Docker支持Aufs，Devicemapper，Btrfs和Vfs四種文件系統, 這篇文章就是幫助我們理解 docker 是如何依賴 aufs 和 devicemapper 的. 但是這些文件系統都依賴相對高版本的 linux 內核,??其實我覺得在一定的限制條件下, 通過 mount 系統調用, 把依賴的底層鏡像文件 mount 到高層鏡像中, 也可以實現類似的功能, 擺脫這些文件系統對高版本內核的要求.

4.?深入理解docker ulimit

http://weibo.com/p/1001603867707551442110

要點: 文章中遇到的問題主要是與系統的啟動順序有關, 相信大家對 ulimit 都不陌生了, 但是如何正確的讓 ulimt 生效并且理解其中的原理特別是針對 docker 中的鏡像? 這篇文件就是非常好的選擇.

服務化和資源管理技術

1.?服務發現：六問四專家

http://dockone.io/article/509#rd?sukey=fc78a68049a14bb2ec54365a6d6daeeca437e166a69146795e4d90ba4e6f478903992e78ee8445b80b88edf61080b189

要點:?服務發現系統是實現服務化的核心組件之一, 這篇文章介紹了4位云計算專家回答關于服務發現的技術和選型的問題.

2.?春晚微信紅包，是怎么扛住一百億次請求的？

http://mp.weixin.qq.com/s?__biz=MzAxNDU2MTU5MA==&mid=208037085&idx=1&sn=fb093eecec51c525f1cd3685645cef1a&scene=1&key=c76941211a49ab5817b68e29bbf4969884639ef6cfe7486665a07e2cfbadde27b5eae0e54d9ae6741692adabb0af824d&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=8v85tN1QS3hxebVAhDtc6ukXMi3rJa9OXz2dz1W%2FcTgAoFG2PtOeCtCciSf9%2B3eh

要點: 文章介紹了春晚微信發紅包的后臺架構設計演化過程, 面臨春晚這樣的重大事件, 確保服務穩定高效的處理海量用戶的爆發請求, 需要高技術含量的架構來支持.

3.?SAMI：來自三星的基于Docker和Mesos的容器解決方案

http://dockone.io/article/506#rd?sukey=fc78a68049a14bb21f2b8921ff7ae6050597f20823385f7d3195a08acdfd4c5eac7b23ecaf88865b0b33043173416e2e

要點: 這篇文章介紹了 SAMI 基于 mesos 和 docker 搭建的持續集成+持續部署的解決方案,?所有工作配置都存放在Git中,?把應用軟件打包成Docker鏡像，便于快速部署. 在配置管理方面, 大搜索也采用類似的機制, 所有配置文件都寫入 svn, 但是帶來的一個問題是不同的機房或者不同的環境, 對應的配置可能是不一樣的, 所以我們目前采用的是模板機制, 服務部署時, 按照當前環境和模板生成對應的配置文件. 但是這也就帶來了模塊和環境的維護成本, 由于全靠人工維護, 也比較容易出錯(比如新增了一個物理機房), 還沒有想到更好的解決方法, 不知道 SAMI 是怎么解決這個問題的, 文章沒有提.

4.?微服務架構成功之路

http://www.infoq.com/cn/news/2015/07/success-of-microservices#rd

要點: 前兩期也分享過微服務相關的文章, 我覺得這篇文章寫的比較有深意, 是否微服務不關鍵, 關鍵是"這些小型、跨職能的微服務團隊看起來像是小型開源項目一樣。大家一起工作，不怕與別人分享自己的觀點；每個人都熱衷于構建高質量軟件，由于團隊規模足夠小并且聚焦，因此可以構建出模塊化軟件。他們是開發者、測試、運維，一切工作都有著相同的目標，而這正是DevOps與微服務的真諦之所在。"

服務調度技術

1.?Uber容錯設計與多機房容災方案

http://weibo.com/p/1001643867507730568365

要點: 本文介紹了 uber 在容災方面的技術, 基本上也是單點故障容災, 單個交換機容災, 單個機房容災這樣來考慮的, 容災一方面要快速服務故障, 另一方面要保證遇到災難時能夠有效的降級, 防止過載進而產生雪崩效益, 也就是 fail fast 的策略.

DevOps 技術

1.?從DO分離走向DO合作

http://mp.weixin.qq.com/s?__biz=MzA4NjAzMjEyOA==&mid=207411309&idx=1&sn=f6bd2c4673578e6f36233a12136ae291&scene=1&key=c76941211a49ab587b58892192ba6e5fae8eb999381453382fda8f1dd87bb5806bf231eb397b8566ac69a0771b9fa1bb&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=kjAQbpqrv1k4JEUjLZ%2Bgsq8ZccHlxm%2BubjZn4ZwoLErY4m9JeX4u1OeaHs9uG3An

要點: 文章中列舉了很多導致研發和運維分裂的因素, 其實很多因素我們或多或少的也遇到過. 術業有專攻, 要想實現1+1>2, 就要擁抱彼此，互相合作，因為衡量我們標準只有一個，“用戶說好，那才是真的好”，其他的還真的都是在扯淡。

2.?騰訊游戲運維服務建設之“版本服務”

http://mp.weixin.qq.com/s?__biz=MjM5MDM2MzU3OQ==&mid=207205820&idx=1&sn=ad541ea2cd292cd155ffab227d98d593&scene=1&key=c76941211a49ab585aee8a71ed7ee251a51d7b306512f03597bb9af743659717417c6c0049edf0a5b399cdb6d618deec&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=u0DR%2Fa6EsWkHwAtGB0LLszVOEACFomaqkQSZelRgiq5nc0BQWQuJRRJrduOcvbBs

要點: 本文介紹了騰訊游戲部門在新版本發布前后需要關注的內容, 運維人員不僅在版本發布后關注程序運行的狀態和效果, 在開發過程中就會關注軟件的質量和缺陷了, 并且推動開發人員去改善.

3.?現代告警平臺的設計是模塊化的

http://segmentfault.com/a/1190000003012335

要點: 面對眾多的開源收集和監控平臺, 比如 ELK,?Nagios，Zabbix等等, 作者認為很多開源平臺都在追求大而全,?實際上我們更需要的是一對小二精的組件拼裝成一個個性化的解決方案. 文章中包含了作者演講的視頻. 我也比較贊同作者的觀點, 畢竟在 IAAS 層, 不同公司面臨的硬件和基礎環境差異比較大, 一套"大而全"的系統往往不能解決全部問題, 而且為了使用這套"大而全"的系統還不得不同時運行多套小系統來滿足差異化需求.

4.?運維的本質—可視化

https://mp.weixin.qq.com/s?__biz=MzA4NjAzMjEyOA==&mid=207471771&idx=1&sn=b5d8f23abe978741bb4eed21c83764ca&scene=1&key=0acd51d81cb052bc8ade672f7509f4d9e67d13540a2f70117683c3fcbec6fda017ace2135f040cbfbb78c24326297e79&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=l2e4Y2LaqzrQir65a4ET7YS1SPJ1yNhVPzcrjPULWd%2Bwequ0%2BjoCS%2BTrVeh3aeQV

要點:?沒有比“可視化”更好的一個詞能概括運維的本質，而“可視化”又應該分成兩部分：可視化的服務交付和可視化的服務度量! ?我們做架構的同學往往對可視化不是很重視, 認為這是錦上添花的東西, 有更好, 沒有也無所謂. 但是從上半年 beehive 開始建設 dashboard 的過程中發現, 可視化是實現運維自動化的利器. 沒有可視化, 就無法談及運維自動化, 一方面因為自動化運維策略的制定來源于可視化的數據分析, 另一方面沒有可視化的自動化運維, 我們也不敢使用, 因為看不到當前狀態, 誰知道是正常還是異常呢.

?

工具集合

1.?YouCompleteMe

http://blog.marchtea.com/archives/161#rd?sukey=fc78a68049a14bb2ba33c15948d34749e1eb616df07efe977573d59996ea9b63dc82be61d5771f948f5d8f01a917acd7

要點: ycm 應該是目前為止 vim 里最好用的自動補全插件了, 基于 llvm 通過實時編譯來實現 c++程序的語義解析. 遺憾的是, 目前在 gcc 3.4.5上無法編譯 llvm, 而且 llvm 發布的 prebuild 包里也沒有 redhat 的版本, 需要自行編譯. 如果大家使用 gcc 4.8.2 可以用一下試試.

2.?最佳日志實踐

http://www.bitstech.net/2014/01/07/log-best-practice/#rd?sukey=fc78a68049a14bb2b83589ac2af50619681535af567aee4d789810d67c3957ffaa91805bca31f9ce78e5437b84f98f61

要點: 又是一篇關于日志的文章, 每次線上追查問題, 都被大量無效的日志折磨著, 所以每次看到寫關于日志的文章, 都忍不住想轉一下. 如何輸出日志, 輸出哪些內容, 都是非常有講究的, 這些日志將成為我們日后追查問題的利器, 如果組織的不好, 就會給我們定位問題帶來很大的阻礙. 除了日志內容之外, 選一個功能靈活, 性能優異的日志庫也是非常重要的, 我期望的日志庫具備的功能有: 日志文件按照時間和大小兩個維度進行切割; 所有日志文件的 size 有一個 quota 可以限制, 超出之后自動刪除最舊的文件; 日志的配置可以在運行時修改而不需要重啟服務; 不同級別的日志輸出到同一個文件里; 日志的輸出具有異步的語義, 不會因為磁盤故障而阻塞服務(特別是對于無狀態的服務). 目前看來似乎只有 log4cplus 滿足我的需求.

3. 像 shell 的-x 參數一樣追蹤 python 的執行過程

http://pymotw.com/2/trace/

要點: python 雖然比 shell 強大的多, 但是調試起來不太方便, 尤其是很多情況下只有運行起來之后才會發現錯誤. 使用 python 的 trace 模塊可以讓 python 像 shell 的-x 參數一樣打印腳本執行過程, 方便調試

4.?15個對開發人員有用的Chrome擴展插件

http://info.9iphp.com/15-chrome-extensions-for-developers/

要點: 一些常用的 chrome 插件, 即使不做 web 開發, 像 JSONView 這樣的插件也非常有幫助.

?

轉載于:https://www.cnblogs.com/zhengran/p/4676323.html

總結

以上是生活随笔為你收集整理的我关注的一周技术动态2015.7.26的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。