Docker 的應用場景在哪裡？

12-27

雖說docker最近很火，可以實現快速部署。但是真正想要往生產環境去部署的時候，卻不知道它的具體應用場景在哪裡？

我們（AVOS Cloud）是做 BaaS，場景非常適合使用 Docker，拋出來大家一起聊下。

在我們的平台上，一台 16 核 32G 內存的虛擬機上，需要跑 500+ 個用戶的應用（每個應用的功能可以認為是一個網站 + 一系列的 RESTful API），有兩個事情很重要：

資源隔離：比如限制應用最大內存使用量，或者資源載入隔離等。
低消耗：虛擬化本身帶來的損耗需要盡量的低。

我們不可能在一台機器上開 500 個虛擬機，雖然可以在資源隔離方面做的很好，但這種虛擬化本身帶來的資源消耗太嚴重。
另一個方面，我們可以考慮使用語言級別沙箱，雖然這種「虛擬化」本身的消耗可以低到忽略不計，但是資源隔離方面絕對是噩夢，比如你打算在一個 JVM 里隔離內存的使用。

而 Docker 很好的權衡了兩者，即擁有不錯的資源隔離能力，又有很低的虛擬化開銷。

下面是我總結的一些Docker的使用場景，它為你展示了如何藉助Docker的優勢，在低開銷的情況下，打造一個一致性的環境。內容來自：八個Docker的真實應用場景
1. 簡化配置
這是Docker公司宣傳的Docker的主要使用場景。虛擬機的最大好處是能在你的硬體設施上運行各種配置不一樣的平台（軟體、系統），Docker在降低額外開銷的情況下提供了同樣的功能。它能讓你將運行環境和配置放在代碼中然後部署，同一個Docker的配置可以在不同的環境中使用，這樣就降低了硬體要求和應用環境之間耦合度。
2. 代碼流水線（Code Pipeline）管理
前一個場景對於管理代碼的流水線起到了很大的幫助。代碼從開發者的機器到最終在生產環境上的部署，需要經過很多的中間環境。而每一個中間環境都有自己微小的差別，Docker給應用提供了一個從開發到上線均一致的環境，讓代碼的流水線變得簡單不少。
3. 提高開發效率
這就帶來了一些額外的好處：Docker能提升開發者的開發效率。如果你想看一個詳細一點的例子，可以參考Aater在DevOpsDays Austin 2014 大會或者是DockerCon上的演講。

不同的開發環境中，我們都想把兩件事做好。一是我們想讓開發環境盡量貼近生產環境，二是我們想快速搭建開發環境。

理想狀態中，要達到第一個目標，我們需要將每一個服務都跑在獨立的虛擬機中以便監控生產環境中服務的運行狀態。然而，我們卻不想每次都需要網路連接，每次重新編譯的時候遠程連接上去特別麻煩。這就是Docker做的特別好的地方，開發環境的機器通常內存比較小，之前使用虛擬的時候，我們經常需要為開發環境的機器加內存，而現在Docker可以輕易的讓幾十個服務在Docker中跑起來。
4. 隔離應用
有很多種原因會讓你選擇在一個機器上運行不同的應用，比如之前提到的提高開發效率的場景等。

我們經常需要考慮兩點，一是因為要降低成本而進行伺服器整合，二是將一個整體式的應用拆分成松耦合的單個服務（譯者註：微服務架構）。如果你想了解為什麼松耦合的應用這麼重要，請參考Steve Yege的這篇論文，文中將Google和亞馬遜做了比較。
5. 整合伺服器
正如通過虛擬機來整合多個應用，Docker隔離應用的能力使得Docker可以整合多個伺服器以降低成本。由於沒有多個操作系統的內存佔用，以及能在多個實例之間共享沒有使用的內存，Docker可以比虛擬機提供更好的伺服器整合解決方案。
6. 調試能力Docker
提供了很多的工具，這些工具不一定只是針對容器，但是卻適用於容器。它們提供了很多的功能，包括可以為容器設置檢查點、設置版本和查看兩個容器之間的差別，這些特性可以幫助調試Bug。你可以在《Docker拯救世界》的文章中找到這一點的例證。
7. 多租戶環境
另外一個Docker有意思的使用場景是在多租戶的應用中，它可以避免關鍵應用的重寫。我們一個特別的關於這個場景的例子是為IoT（譯者註：物聯網）的應用開發一個快速、易用的多租戶環境。這種多租戶的基本代碼非常複雜，很難處理，重新規劃這樣一個應用不但消耗時間，也浪費金錢。

使用Docker，可以為每一個租戶的應用層的多個實例創建隔離的環境，這不僅簡單而且成本低廉，當然這一切得益於Docker環境的啟動速度和其高效的diff命令。

你可以在這裡了解關於此場景的更多信息。
8. 快速部署
在虛擬機之前，引入新的硬體資源需要消耗幾天的時間。Docker的虛擬化技術將這個時間降到了幾分鐘，Docker只是創建一個容器進程而無需啟動操作系統，這個過程只需要秒級的時間。這正是Google和Facebook都看重的特性。

你可以在數據中心創建銷毀資源而無需擔心重新啟動帶來的開銷。通常數據中心的資源利用率只有30%，通過使用Docker並進行有效的資源分配可以提高資源的利用率。

簡單說就是PaaS，可實現方便的服務創建、刪除，做到可伸縮，意義重大。可以快速構建一個容器，很快的構建一個 PaaS 容器，對不同的環境使用不同的 Docker 容器即可。

flynn和deis是基礎Docker實現的開源PaaS，相比CloudFoundry更小、更輕。

Docker依賴Linux LXC技術，輕量容器概念，其上實際運行的程序是在宿主機上的，本身不是完整的程序系統，也正是其特別之處。

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

根據Docker佈道師Jerome Petazzoni的說法，Docker約等於LXC+AUFS（之前只支持ubuntu時）。其中LXC負責資源管理，AUFS負責鏡像管理；而LXC又包括cgroup、namespace、chroot等組件，並通過cgroup進行資源管理。所以只從資源管理這條線來看的話，Docker、LXC、CGroup三者的關係是：cgroup在最底層落實資源管理，LXC在cgroup上封裝了一層，Docker又在LXC封裝了一層。

Docker是Linux下應用容器引擎，提供一種比LXC高級的API。Docker使用Go語言開發，利用了Linux提供的LXC，AUFS，namespace和cgroup技術。實現了文件系統，資源和網路的隔離，最終目標實現類似PaaS平台的應用隔離。

LXC——Linux容器工具，容器有效地將由單個操作系統管理的資源劃分到孤立的組中，以更好地在孤立的組之間平衡有衝突的資源使用需求。與虛擬化相比，這樣既不需要指令級模擬，也不需要即時編譯。容器可以在核心 CPU 本地運行指令，而不需要任何專門的解釋機制。此外，也避免了准虛擬化（paravirtualization）和系統調用替換中的複雜性。

容器在提供隔離的同時，還通過共享這些資源節省開銷，這意味著容器比真正的虛擬化的開銷要小得多。

我們都知道Linux有一個進程號為1，名字為init的進程，系統服務的父進程都是init進程。

Docker容器中進程號為1的進程是bash，而不是init，一個運行的Linux竟然沒有init進程，簡直太不思議了。這其實得益於強大的Linux提供的LXC功能。宿主機器中運行的docker服務就是該容器中ubuntu系統的init進程。其實每個運行的容器僅僅是宿主機器中運行的一個進程而已，在容器中運行的任何程序其實也是運行在宿主機器中的一個進程。Docker通過cgroup將屬於每個容器的進程分為一組進行資源(內存，cpu，網路，硬碟)控制；通過namespace將屬於同一個容器的進程劃分為一組，使分屬於同一個容器的進程擁有獨立的進程名字和獨立分配的進程號，比如宿主機器存在一個進程號為1的進程，容器中也存在一個進程號為1的進程。

如果對同一台服務上的少數應用需要控制資源的直接使用 cgroup 是較好的選擇，可以按用戶或用戶組控制系統資源。如果服務需要指出多種環境，那麼 Docker 就是最好的。

補充（20140625）：

With the release of version 0.9 Docker.io have dropped LXC as the default execution environment, replacing it with their own libcontainer.

In other words, as of Docker 0.9, LXC is now optional.

by: Docker drops LXC as default execution environment

感謝 @Honglin Feng 提醒。

Docker 最近確實很火。一個簡單的例子，你可以用docker把資料庫的數據與資料庫程序本身分離開：用一個container A作為數據存儲，然後另一個container B運行資料庫。當你想升級資料庫時，用新的container C替換掉container B即可，只需一分鐘就可以搞定。

可以參考一下我寫的blog： Containerize your database volume with Tutum MySQL Images

另外我們有在做公有雲的docker hosting, 上面有很多已經做好的Image(叫jumpstart)，直接使用即可。你可以註冊一個帳號(http://tutum.co)，對個人用戶完全免費，讓你體驗一下docker的魅力，相信會使你對docker的應用場景有進一步的了解

深入淺出系列

深入淺出Docker（一）：Docker核心技術預覽
深入淺出Docker（二）：Docker命令行探秘
深入淺出Docker（三）：Docker開源之路
深入淺出Docker（四）：Docker的集成測試部署之道
深入淺出Docker（五）：基於Fig搭建開發環境

源碼分析系列

Docker源碼分析(一)：Docker架構
Docker源碼分析(二)：Docker Client創建與命令執行
Docker源碼分析(三)：Docker Daemon啟動
Docker源碼分析(四)：Docker Daemon之NewDaemon實現
Docker源碼分析(五)：Docker Server的創建
Docker源碼分析（六）：Docker Daemon網路

奉送一份由阿里雲調研的：《2016中國容器技術調研報告全景解讀》，文中可以看到容器技術目前主要應用的場景依次是：Web應用，API服務，測試應用，以下是正文

經過容器技術的發展，以及國內各家公司的積極實踐，國內用戶對於容器技術的接受度有所提升，近87% 的用戶表示考慮使用容器技術，這相比較於四個月前的調研結果，接受比例有了明顯增加

容器服務部署速度快，開發、測試更敏捷、提高系統利用率，降低資源成本的核心優勢，依然是用戶選擇它的主要原因

但與此同時，缺乏Docker相關經驗、缺乏生產環境成功案例和成熟經驗是困擾絕大部分觀望用戶的問題，這還需要業界同行持續不斷的共同努力

同時絕大多數用戶將Docker技術和雲戰略結合在一起，70% 將容器用於公共雲, 45% 考慮容器用於混合雲

阿里雲容器服務團隊抽樣調研了國內的雲計算使用者，對於您判斷容器技術在國內的認知度有很大的參考價值

以下是問卷的詳細報告：

本次調研人數超過2600人，其中，開發和運維工程師佔了樣本的一半，開發和運維主管超過20%

調研對象所在公司規模大多數在1-99人，大型企業約佔調研樣本的3%

調研對象所處行業可以看出，互聯網公司仍然佔據半壁江山

熟悉Docker和不了解Docker的用戶比例約為7:3，與六月份國內的調研結果相差不大，正在使用容器技術的公司超過23%

近87%的用戶表示，接下來六個月會考慮使用容器技術。相比較6月份的調研結果，這個比例增加約7%

容器技術部署速度快，開發、測試更敏捷；提高系統利用率，降低資源成本；

這兩個突出優勢，依然為用戶考慮容器技術的最主要原因

同時，跨環境可移植性、提供更好的微服務，應用運維標準化，支持不同語言應用也是用戶選擇容器服務的重要理由

與容器技術特點相符合，目前主要應用的場景依次是：Web應用，API服務，測試應用

關於用戶使用容器技術的挑戰，缺乏Docker相關經驗、缺乏生產環境成功案例和成熟經驗，仍然是影響容器技術擴散的主要原因

用戶偏向於選擇Docker Engine的版本，其中1.12接近六成，每個docker版本發布都會新增一些新的功能，國內用戶對於docker版本的跟進也較為積極

這個也說明國內用戶中Docker新用戶居多，還在一個快速接受期

國內超過一半的用戶仍然選擇自己管理集群，使用docker的方式還比較初級，偏向於手工管理

關於docker 的存儲選擇上，多數用戶選擇本地磁碟或者nfs

較多用戶選擇通過Host模式、通過bridge模式和Docker overlay網路搭建網路

在評估或使用容器技術用戶中，絕大部分用戶選擇CentOS系統作為容器的宿主機，Ubuntu次之，而其他操作系統的佔比較少。我們也期待隨著Windows 2016的發布，Windows平台上能提供對容器的更多支持

關於如何管理Docker的鏡像，更多的用戶選擇使用阿里雲Docker Registry進行管理，選擇使用Docker Hub和搭建私有Docker Registry的也較多

關於構建和製作Docker鏡像，大多數用戶選擇本地構建鏡像，並上傳倉庫

用戶主要在公共雲部署容器方案或在自有數據中心部署容器方案來結合Docker和雲計算

用戶在選擇使用容器技術的時候，最多考慮的是Docker容器的相關資源限制設置和最小化Capability

相比於自建容器集群，雲廠商容器服務已經能滿足較多的用戶需求

總結：

容器技術爆髮式增長，中國市場開始起步，容器技術前景廣闊但依然有很多阻礙因素

為了推動Docker技術在國內發展，阿里雲在雲棲大會上宣布和Docker公司戰略合作

阿里雲將為Docker Hub提供中國運營的基礎服務，這將普惠國內開發者；阿里云為Docker Engine商用版以及Docker Datacenter提供銷售和支持服務，將推動Docker技術在企業落地。同時Docker官方支持阿里雲作為雲平台，Docker用戶在阿里雲上可以有更好的用戶體驗和性能

阿里雲容器服務團隊正在和大家一起推進Docker在國內的發展，可在這裡關注我們： https://www.aliyun.com/product/containerservice

版權公告：本調研歸屬為阿里雲及雲棲社區，轉載請註明出處。未經允許，不可商用。如發現違規違法使用，保留追究法律責任的權利。

作為docker的重度使用者，我從普通開發者(系統，運維，後端服務方向)的角度介紹下自己遇到過的幾種使用場景：

無痛嘗試新事物

這應該是最早讓我感受到docker的便利性的使用場景了。

以前，如果想嘗試新的編程語言/資料庫/命令行工具，會先找找apt的源里有沒有相應的包，沒有的話再看看是否有PPA源可以用，再沒有就只能嘗試從源碼編譯，編譯成功前可能還要經歷一遍安裝編譯工具鏈，依賴庫等過程，而這個過程中遇到下代碼被牆，依賴庫版本太老/太新等麻煩也不少見。

現在，我會先上http://hub.docker.com搜索相關的docker 鏡像，有的話按照文檔直接跑個docker run的命令就好了。比如前兩天為了跟一份scala的入門文檔，需要先安裝一套scala開發環境，可我的開發機上連jdk都沒有，好在有人build了一個scala開發環境的鏡像，我只需要一條命令docker run -it --rm williamyeh/scala就得到了一個scala的REPL。

使用docker打包/發布各種服務

這應該是docker最廣為人知的使用場景了，目前我們team的幾乎所有服務都是跑在容器里的，比如：salt-master.

salt-master是saltstack的中心控制節點，saltstack是用Python寫的一套伺服器集群管理工具，通過salt-master可以批量完成對所管轄機器的配置下發，信息收集，遠程命令執行等任務。salt-master節點上除了需要安裝salt的相關包以外，還需要安裝完成各項任務用的salt formula,各服務的配置信息等。

我們有多個環境的集群需要管理，安全起見，每個集群各自部署一套salt-master。之前部署一套salt-master的流程是：找一台虛擬機，裝上salt的相關package，git clone各個依賴的salt formula，手工填上各項包括各種服務密碼在內的配置。需要更新配置或salt formula的時候，都是運維人員連上該節點手動修改文件或執行git pull等命令。

實際上，按照之前的辦法，部署或更新一個salt-master節點是比較繁瑣，容易出錯的。後來我們換到了用docker部署，通過Dockerfile定義安裝salt-master及其依賴包和配置項的過程，並將Dockerfile，配置等信息用git管理起來。任何人需要修改salt-master的時候只要修改這個git repo的內容就可以了，完成代碼審閱後，會通過jenkins自動build一個新的鏡像。更新線上salt-master的時候，運維人員只需要執行docker pull,docker rm -f, docker run三個命令即可。

使用docker image打包各種命令行工具

一般關於docker的介紹中，大多是將其描述為打通」開發-測試-發布」整個pipeline的神器，似乎docker最主要的用途是發布服務類軟體。但實際上，即使是命令行工具，使用docker鏡像發布也能帶來很大的便利性。

比如之前我們的環境裡邊遇到了docker在使用devicemapper方面的一個bug，為了定位到問題所在，我試圖用systemtap來跟蹤docker daemon的一些系統調用和代碼路徑，但systemtap依賴項眾多，在每一台出問題的伺服器上都裝一遍這些包顯然是不現實的，更何況像kernel debug info這種包公司內部乃至國內的一些mirror上都沒有，還需要翻牆從官方源下載。但好在我們的所有伺服器都是標準化配置的，kernel，libc等基礎組件版本都一樣。我只需要製作一個sytemtap的鏡像，就可以在任何一台伺服器上用systemtap進行debug了。case解決後，清理辦法也簡單，刪掉啟動的相關容器及下載的鏡像就好了。

現在，每開始一個新的項目，無論是服務類還是工具類，除了init一個git repo外，我的另一個習慣就是寫一份Dockerfile和一份usage.sh腳本，這樣，當我需要向我的夥伴介紹這個項目時，我只需要build一份鏡像，推送到我們的private registry，然後發郵件告訴他們「請嘗試用命令docker run --rm & usage查看使用簡介」。

搭建開發環境

答主之前做openstack相關的開發(當然現在也會做一些)，有過openstack開發經驗的同學應該清楚搭建一份openstack的開發環境對初學者而言還是挺難的，沒記錯的話，當初入職的時候光是搭建穩定的開發環境就花了我差不多三個星期的時間。

上半年我給我們的openstack版本中的每一項服務都做了一份docker鏡像，搭配docker-compose和兩個bash腳本，成功實現了十分鐘內在兩台裸虛擬機(ubuntu 14.04,不帶docker-engine)上搭建一套完整的openstack開發環境(一個控制節點，一個計算節點)。

使用docker build完成單元測試

以前用jenkins做自動化測試的時候，經常擔心項目間的環境依賴會互相衝突。但現在依託於docker的隔離性，這個問題不復存在。只要寫一份Dockerfile，通過docker build的過程完成依賴安裝，pep8檢查，單元測試等步驟，build成功則表示測試通過，否則表示測試失敗，開發者可以在測試過程中執行幾乎所有命令。

實際上，已經出現了基於這個思路的持續交付平台，比如：https://github.com/drone/drone

不算 VM，只是一種 namespace 的資源隔離。可以用來做更好的應用部署，配合 link 功能 SOA 不要太爽。

我們現在基於 docker 做的 engine 比較類似於 google 的 borg，純粹的 PaaS 對我來講已經沒有難度了……怎麼樣通過一個平台滿足 SOA 大數據演算法等各類需求正是我們目前要解決的。

Docker 毫無疑問的是部署應用的未來。我們正在使用DaoCloud，感覺很不錯。

1.就我個人所知，早在14年國內有一些公司，開始嘗試docker，當時畢竟docker是一個新事物，很多新特性方面的優點，並沒有被大大的利用起來，這個也可以理解。那時docker對一些企業的價值在於計算的輕量級，也就是對於一些計算型的任務，通過docker的形式來分發，部署快，隔離性好，這樣的任務包括：消息傳遞，圖像處理等。

2.14下半年到15年初，docker的價值被更大化，應用的運行，服務的託管，外界的接受度也變高，國內也出現了一些startup公司，比如DaoCloud（http://www.daocloud.io）,雲雀(http://www.alauda.cn)等。但這些僅僅是這些公司的第一步，後續緊跟的更多的是基於代碼與鏡像之間的CI/CD,縮減開發測試發布的流程，這方面的實踐逐漸成熟。

3.微服務架構的興起。微服務會對現階段的軟體架構有一些衝擊，同樣也是軟體系統設計方法論的內容。這些方面國外討論的葯多一些，相信這一點也會近年來多家公司發力的地方

應用場景本身沒有變化，還是應用託管和自動部署，部署後的彈性資源調度。當前paas層調度的方案或調度的計算單元主要有虛擬機層面，容器層面，中間件層面。

docker是基於容器層面的調度，可以理解為一種更加輕量的虛擬機，即能夠更好的滿足快速部署和資源調度的性能速度，又能夠滿足資源直接的隔離。

Docker for Data Science at Trulia 和一點感悟 - Hello陳然! - 知乎專欄

我們在Trulia Data Science Team 裡面推行了Docker。一方面是搭建API做SOA，另一方面也在幫助每一個Data Scientist 都可以直接從最開始演算法分析、開發一直做到部署，而不需要其他的Engineer幫助，加快迭代速度。

----
陳然_Ran的微博

我是把docker和vagrant結合起來使用，作為我們團隊的日常統一的開發環境。
可以參考我的一篇blog：Dev with Vagrant and Docker ? 悟道集
----- 2014.07.08

兩年多過去了，docker火的不像話了，各大公司開始用docker來做各種微服務。我再來補充一個場景，那就是威客方向：項目整體切分為多個微服務子系統，通過API通信，就可以把子系統外包出去，用docker交付，就可以非常方便的集成部署了。

八個Docker的真實應用場景

docker相當於輕量級的vm：容器本身的開銷低，啟動速度快，但隔離/控制弱，無法虛擬其它OS
特點是在一個物理機的OS里能同時虛擬巨多個本OS的運行環境（要求應用本身占的資源（主要是內存）不多）

所以，它最適合有大量小型（資源要求低、負荷也低）但需要互相隔離的應用的單位
比每個應用都採用獨立物理機省，比每個應用都採用獨立虛擬機也省

Docker源於PaaS，故PaaS的應用場景即是Docker的應用場景。

我認為docker的出現對於linux開發者是重大利好，我們都知道在linux上面做開發，配置環境變數異常繁瑣，尤其是在設置交叉編譯環境的時候。

舉個例子比如我要設置mips的編譯環境，而我宿主機是debian.有些優秀的工具只存在於gentoo平台，而gentoo又不好安裝，我們使用docker只要從docker hub上面pull下鏡像，就可以完美使用，這使得開發人員效率最大化。

推薦一篇，講docker在大數據上的應用Hadoop on Docker

在我學習Docker過程中遇到各種各樣問題，把一些在實踐中遇到的經典問題分享，希望對真實的應用場景有幫助！
1. redis，elasticsearch k8s配置service的域名報主機找不到，配置ip可以？是否是代碼封裝有問題？

需要運行kubernetes的DNS插件或kube-dns服務。

順便介紹一下K8s的DNS

SkyDNS：
SkyDNS本來是和Kubernetes沒有任何關係的項目，只不過Kubernetes 1.3版本以前的域名服務用的插件是基於SkyDNS的。
Kube-dns：
Kubernetes 1.3之後新增的服務，用來替代過去的域名服務插件。

- 介紹SkyDNS的文章
etcd 和 skydns|木洛七
這是一篇很老的文章，裡面提到的Etcd和Etcd-fs的內容隨便看一下就好，已經全部過時，不過Skydns的使用部分還適用，並且整體概念介紹還是比較清楚。

- Skydns詳細說明還是看官方文檔吧
GitHub - skynetservices/skydns: DNS service discovery for etcd

介紹Kube-dns的文章：
kubernetes DNS——kube-dns命令
這篇文章認為kube-dns在kube的功能已完勝skydns，不過skydns可以用『-nameservers』指定一個外部DNS，當搜索的域名不是內網服務的時候，會到這個外部DNS查詢，在kube-dns里我沒發現等效的參數。有發現這個功能如何實現的同學麻煩告知~

2. 在docker環境跑會出現同步配置文件或者jar衝突，但是在物理機上不報錯？想知道大概出現這種情況的原理是怎麼樣的？

鏡像可能存在有多餘的jar包，但是怎麼進去的需要具體分析

3. k8s集群怎麼樣監控node是否正常？

Node是屬於IaaS層的資源，在k8s管理的範圍之外。
可以採用普通的IaaS層監控工具解決，比如：Zabbix Nagios Prometheus …
K8s本身提供了PaaS層以上的監控能力，比如檢查容器健康狀態的Probe功能

4. docker 網路怎麼樣固定IP？

單節點的情況 docker run 命令可以用『--ip』參數指定容器IP
跨節點的情況，是否能夠指定IP以及如何指定IP與選擇的跨節點通信方案有關，比如Weave是可以指定容器IP地址的，Flannel則不行。

5. 如何讓docker 容器啟動的時候，啟動tomcat 服務？

在Dockerfile中通過CMD或ENTRYPOINT指定，比如：
CMD [「bin/catalina run」]
ENTRYPOINT [「bin/catalina run」]

這篇文章對Dockerfile的寫法介紹還比較好：
Docker學習筆記（3）-- 如何使用Dockerfile構建鏡像

6. 希望視頻中利用一個完整的小項目來延時整個流程(比如：wordpress等)

很難找到一個能夠覆蓋k8s全面功能但是又不至於太複雜的例子
比如wordpress搭建的例子在之後介紹k8s的volume部分會用到，但是它其實只會用到k8s當中很小的一部分功能。

7. 希望搭建一個mysql集群的例子

官方的mysql鏡像『https://hub.docker.com/r/_/mysql』可以掛載自定義配置文件，因此實現mysql的方式和主機上差不多，主要就是配置正確。
把資料庫放到docker運行一般只會在測試的時候用到，實際的運用中一般不會用docker作mysql的生產環境，也不會用於做集群。

8. 在win7下配vagrant總是報錯，在cygwin那一步，能給一個在win7下準備環境的說明文檔么？

Win7使用Vagrant時候Cygwin不是必須的，甚至可以說是完全沒必要的。
找了一篇比較簡單的Vagrant安裝的文章：
http://jingyan.baidu.com/article/f0e83a25a8fdb022e591012d.html
在網上找文章時候發現了一篇比較有意思的Vagrant用法，也推薦給大家：
https://codefalling.com/2016/01/24/unix-env-in-windows-with-vagrant/

9. etcd 集群基於 dns 方式時，首先要有個 dns 伺服器；而 k8s 服務發現機制也會用到 dns，如何能使兩者共用 dns 伺服器？dns 伺服器單點如何解決？

可以共用。
在 /etc/resolv.conf 配置多個DNS就可以了。
如果非要在DNS服務端做高可用，可以考慮：
- HAProxy負載均衡
- 虛擬IP

10. k8s初學者，對提到的2本參考書，如何與課程相互滲透？

《Kubernetes權威指南》使用的Kuberentes版本比較舊，其中內容很多已經不適用了。建議直接看《Kubernetes實戰》，這本書的大部分內容在課程的kubernetes視頻部分都會講到，可以先看視頻得到一個k8s的直觀印象，對理解書里的命令會有幫助。或者先看書了解概念再通過視頻觀看這些概念的演示。

11. 有哪些主流PaaS？

Swarmkit
Kuberenetes -&> Openshift
Mesos + Marathon
Rancher

12. 從對外服務視角來看，k8s完成一次服務調度的具體流程？

HTTP API -&> kubeapiserver -&> Etcd
-&> kubeschedule (Pod)
-&> kubecontroller (Pod/Deployment/Job/Service)
-&> kubelet -&> docker

13. Docker需要學到什麼程度（指容器基礎，不包括swarm）？

如果不是對Docker有定製化或者二次開發的需求。將市面上任意一本Docker入門書籍學習完就足夠日常使用了。

14. 如何進一步學習CoreOS？

《CoreOS實踐之路》書中的大部分內容現在還是適用的，除了Rkt的部分已經發生了很大的變化，Kubernetes部分針對的是1.0版本與當前版本有到一定差異，以及書中Etcd採用的是2.x版本（最新3.x版本的使用方法與2.x完全兼容，只是額外提供了新版本的API）。

Rkt &<- nsspawn &<- ns/cg
&<- phone &<- kvm
&<- …
Docker &<- RunC &<- ns/cg
&<- RunV &<- hpyer &<- kvm/xen
Etcd 2.x(HTTP) &<- 3.x(Probuf)

15. 我司準備使用docker, 我現在的任務是要將傳統的流程改造為docker化的流程，目前我的想法還是先跑單個docker應用，在逐步轉換成集群應用。我個人是這麼想的，不知能否改進
1）開發人員 push代碼到gitlab上
2）jenkins從docker私服(harbor)上pull我定製好的基礎鏡像。進入容器，然後從gitlab上pull代碼到容器中，我們是java應用，在容器中進行編譯，最終會編譯為一個單獨fatjar, 使用jetty運行. 這樣代碼也在容器裡面了。
3）將構建好的鏡像推送到遠程的機器上，移除以前的容器，啟動新的容器。

我的問題是：
1）不知道我設想的流程是否符合docker的最佳實踐
2）假設我的流程無大的問題。我從 harbor 上pull了基礎鏡像，在容器中打包編譯後可能文件就有個10多M（200M=150M+10M+20M），然後我將這個鏡像推送到各個伺服器。總感覺鏡像有點大，這樣速度很慢。
3）我們現在有多套環境，dev test preprod prod，是否要針對不同的環境構造出不同的鏡像。有無更好的多環境方案。

1.符合Docker推薦的構建和發布方式。
2.內網情況拉取鏡像基本可以達到幾MB/s，每次拉取幾十MB一般是可以接受的
採用虛擬機方式部署同樣要傳這麼大一個包到伺服器上去，這個是繞不過的。
3.
不同的環境構造出不同的鏡像
在一個包中包含所有環境配置，通過啟動參數選擇（比如springboot的工程）
採用中心化的配置管理（例如spring-configure）

16. kubenetes master節點有什麼高可用的方案？

這個目前確實還沒做過，查了一下官方文檔這方面的內容，發現解釋得比較含糊，推薦一篇相對比較靠譜的文章：
Kubernetes高級實踐：Master高可用方案設計和踩過的那些坑
這篇是基於HAProxy和Keeplived實現Kubeapiserver的高可用和負載均衡本身高可用的，考慮比較完備，關鍵還是在這兩個服務的配置。

17. kubernetes有什麼服務自動發現的框架？

Kubernete本身只用Etcd作存儲，和服務自發現無關。
如果是K8s上運行的其他服務需要自發現優先推薦 Etcd / Consul，其次是 Zookeeper

18. 相對來說calico和flannel相比那個更適合使用到beta或者生產環境中？

兩個方案目前都已經比較穩定，都可以用於生產環境。
Flannel配置比較簡單，出錯時候也相對比較容易定位。
Calico的傳輸效率更高，配置和維護相對複雜。

19. docker0的地址必須要和flannel0的地址在同一個地址段內么？為什麼？

需要在同一網段，因為docker0到flannel0的路由是通過路由表的默認網關方式實現的。
eth0(in-container) - docker0 - flannel0 &<-&> flannel0 - docker0 - eth0(in-container)
參考這篇文章：
DockOne技術分享（十八）：一篇文章帶你了解Flannel

這個問題歡迎大家提供更詳細的解釋，網路原理方面我不是特別熟悉。

20. 能不能介紹一下flannel,calio,weave等各網路模型的特點與區別？生產中建議用哪種？

建議是Flannel或Calico，除非在需要固定每個容器IP的時候可以用Weave。
這方面同樣希望有對網路比較了解的同學能補充。

我對Weave只使用早期版本，當前情況不太了解了，不過從最近看到過的一些測試數據，Weave依然是各種Overlay工具中效率很低的一種。

21. K8S和Mesos能集成在一起使用嗎？

可以，有這個官方項目：
Kubernetes - Kubernetes on Mesos
這個效果以前我的同事測過，可以用，但是在壓力測試中的表現比單獨使用kubernetes的集群差距很大。這種用法在實際生產上使用的應該不多，Kubernetes文檔的介紹僅有這篇，Mesos的文檔里完全沒提這回事。

22. docker和openstack集成，有沒有什麼要注意的?

OpenStack之前嘗試和docker集成的幾個項目（nova-docker/magnum/...）最後似乎都沒有做起來，目前比較熱門的消息是OpenStack的核心貢獻者正在將OpenStack與Kubernetes更好的集成起來：
OpenStack 宣布用 Kubernetes 重寫底層編排引擎
這次看起來比較靠譜。

正在學習的一門Docker實戰課：
從理論到生產環境實戰：掌握Docker大規模部署和管理，有興趣的可以去看下

我在之前的公司主要把docker作為每日集成測試的容器，當容器帶-r參數運行，會在指定任務完成後刪除自身，通過-v參數可以將測試結果共享到host（測試機器）上，這樣可以大量，快速完成測試環境和代碼部署，基本上是秒開啊！作paas的也有，把docker當中一個小型虛擬機器使用。