【有獎討論】DOCKER進(jìn)化帶來的討論！�。�

niao5929

oracle本身的解決方案也在往虛擬化方向發(fā)展，如何評價回復(fù) 20# gaoyp27


   

gaoyp27

抱歉，表述不清，我的看法是docker暫時不適合數(shù)據(jù)庫，因為如果docker因為不知原因中斷，那么結(jié)果就是數(shù)據(jù)的丟失。oracle的數(shù)據(jù)庫虛擬化沒有使用過，不好去評價。

   

gaoyp27

回復(fù) 21# niao5929
抱歉，表述不清，我的看法是docker暫時不適合數(shù)據(jù)庫，因為如果docker因為不知原因中斷，那么結(jié)果就是數(shù)據(jù)的丟失。oracle的數(shù)據(jù)庫虛擬化沒有使用過，不好去評價。


   

niao5929

目前ORACLE不建議數(shù)據(jù)庫使用虛擬環(huán)境。真正的企業(yè)級應(yīng)用依然是在物理機上部署的。個人感覺目前DOCKER更適合做應(yīng)用服務(wù)器內(nèi)容。企業(yè)級應(yīng)用其實進(jìn)化很慢的，很多時候企業(yè)級應(yīng)用受到應(yīng)用系統(tǒng)前臺、后臺軟件等許多因素的制約，不是個人PC說升級就升級的。呵呵回復(fù) 23# gaoyp27


   

wq4113

1、作為未來DEVOPS的運維人員，您覺得DOCKER的技術(shù)有哪些？
     Docker 的容器利用了LXC，管理利用了namespaces 來做權(quán)限的控制和隔離，cgroups 來進(jìn)行資源的配置，并且還通過aufs 來進(jìn)一步提高文件系統(tǒng)的資源利用率。
2、和傳統(tǒng)操作系統(tǒng)比DOCKER對您的應(yīng)用會有那些改變？
     簡化配置、代碼流水線（Code Pipeline）管理、提高開發(fā)效率、隔離應(yīng)用、調(diào)試能力、多租戶環(huán)境、快速部署。
3、是否所有的系統(tǒng)都適合遷移到DOCKER環(huán)境中？
     會變化的應(yīng)用，如自研的Web服務(wù)是首選。Docker的核心價值在于快速簡單的持續(xù)交付，一個應(yīng)用如果萬年不變，放Docker附加值少了一大半。但是互聯(lián)網(wǎng)大潮轟轟烈烈，迭代越來越快。如果您的應(yīng)用每周上線，每日上線，可以試試Docker。需要知道Docker不是包治百病，適合的業(yè)務(wù)跑docker；需要有成熟的管理工具和私有DockerHub；生產(chǎn)環(huán)境關(guān)心的主要是監(jiān)控、日志、變更、擴容，這些問題都需要在頭腦里知道怎么解決。
4、DOCKER化之后，規(guī)模集群如何更好的避免傳統(tǒng)HA帶來的資源浪費？
     HA相較于容器較重，沒有容器集群所擁有的資源自動伸縮能力。      
5、DOCKER化和SDN之間如何更好的結(jié)合，避免DOCKER化之后網(wǎng)絡(luò)技術(shù)成為應(yīng)用開發(fā)瓶頸?
     網(wǎng)絡(luò)的確是個問題，可以嘗試使用集群編排工具管理。

開源將軍

占坑圍觀學(xué)習(xí)思考中

niao5929

Gnu/Linux確實變得越來越好了，盡管有時看起來很混亂，你也不知道圍繞Linux而產(chǎn)生的新技術(shù)到底哪個更好，不過在社區(qū)環(huán)境下的自然進(jìn)化選擇總能體現(xiàn)趨同性。所以，被進(jìn)化保留下來的部分都是值得學(xué)習(xí)和掌握的�。。�

hiyachen

1、作為未來DEVOPS的運維人員，您覺得DOCKER的技術(shù)有哪些？
  開發(fā)／交付／運行／運維一體化�？焖賳�動、鏡像分層aufs
  Docker是一個開源的應(yīng)用容器引擎，讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個可移植的容器中，然后發(fā)布到任何流行的Linux機器上，也可以實現(xiàn)虛擬化。容器是完全使用沙箱機制，相互之間不會有任何接口。
基于LXC的高級容器引擎。
Docker讓應(yīng)用程序布署在軟件容器下的工作可以自動化進(jìn)行，借此在Linux操作系統(tǒng)上，提供一個額外的軟件抽象層，以及操作系統(tǒng)層虛擬化的自動管理機制。Docker利用Linux核心中的資源分離機制，例如cgroups，以及Linux核心命名空間（name space），來建立獨立的軟件容器（containers）。這可以在單一Linux實體下運作，避免啟動一個虛擬機器造成的額外負(fù)擔(dān)。
    Docker使用標(biāo)準(zhǔn)的交付件（預(yù)裝了安裝一些標(biāo)準(zhǔn)服務(wù)的鏡像）放在容器中運行。即在第一次部署時，構(gòu)建完可用的docker鏡像。以后使用的過程中，可以直接拉取鏡像，根據(jù)這個鏡像創(chuàng)建出一個容器，把服務(wù)運行起來。通過一個Dockerfile文件，實現(xiàn)『一次構(gòu)建，到處部署』的Docker特有功能。
    Docker自身已經(jīng)提供許多安全機制。如cgroup的內(nèi)存、進(jìn)程資源限制，namespace的資源隔離。另外可以使用SELinux等工具來增強容器安全。
2、和傳統(tǒng)操作系統(tǒng)比DOCKER對您的應(yīng)用會有那些改變？
   構(gòu)建標(biāo)準(zhǔn)化的運行環(huán)境，現(xiàn)有的方案大多是在一個baseOS上運行一套puppet/chef，或者一個image文件，其缺點是前者需要base OS許多前提條件，后者幾乎不可以修改(因為copy on write 的文件格式在運行時rootfs是read only的)。并且后者文件體積大，環(huán)境管理和版本控制本身也是一個問題。
    PaaS環(huán)境是不言而喻的，其設(shè)計之初和dotcloud的案例都是將其作為PaaS產(chǎn)品的環(huán)境基礎(chǔ)
    因為其標(biāo)準(zhǔn)化構(gòu)建方法(buildfile)和良好的REST API，自動測試和持續(xù)集成/部署能夠很好的集成進(jìn)來
    因為LXC輕量級的特點，其啟動快，而且docker能夠只加載每個container變化的部分，這樣資源占用小，能夠在單機環(huán)境下與KVM之類的虛擬化方案相比能夠更加快速和占用更少資源

3、是否所有的系統(tǒng)都適合遷移到DOCKER環(huán)境中？
  不是的，體現(xiàn)在以下的局限性。
    Docker是基于Linux 64bit的，無法在32bit的linux/Windows/unix環(huán)境下使用
    LXC是基于cgroup等linux kernel功能的，因此container的guest系統(tǒng)只能是linux base的
    隔離性相比KVM之類的虛擬化方案還是有些欠缺，所有container公用一部分的運行庫
    網(wǎng)絡(luò)管理相對簡單，主要是基于namespace隔離
    cgroup的cpu和cpuset提供的cpu功能相比KVM的等虛擬化方案相比難以度量(所以dotcloud主要是按內(nèi)存收費)
    docker對disk的管理比較有限
    container隨著用戶進(jìn)程的停止而銷毀，container中的log等用戶數(shù)據(jù)不便收集

  
4、DOCKER化之后，規(guī)模集群如何更好的避免傳統(tǒng)HA帶來的資源浪費？
  鏡像分層技術(shù)。
AUFS有所有Union FS的特性，把多個目錄，合并成同一個目錄，并可以為每個需要合并的目錄指定相應(yīng)的權(quán)限，實時的添加、刪除、修改已經(jīng)被mount好的目錄。而且，他還能在多個可寫的branch/dir間進(jìn)行負(fù)載均衡。

上面的例子，我們已經(jīng)看到AUFS的mount的示例了。下面我們來看一看被union的目錄（分支）的相關(guān)權(quán)限：

    rw表示可寫可讀read-write。
    ro表示read-only，如果你不指權(quán)限，那么除了第一個外ro是默認(rèn)值，對于ro分支，其永遠(yuǎn)不會收到寫操作，也不會收到查找whiteout的操作。
    rr表示real-read-only，與read-only不同的是，rr標(biāo)記的是天生就是只讀的分支，這樣，AUFS可以提高性能，比如不再設(shè)置inotify來檢查文件變動通知。

權(quán)限中，我們看到了一個術(shù)語：whiteout，下面我來解釋一下這個術(shù)語。

一般來說ro的分支都會有wh的屬性，比如 “[dir]=ro+wh”。所謂whiteout的意思，如果在union中刪除的某個文件，實際上是位于一個readonly的分支（目錄）上，那么，在mount的union這個目錄中你將看不到這個文件，但是read-only這個層上我們無法做任何的修改，所以，我們就需要對這個readonly目錄里的文件作whiteout。AUFS的whiteout的實現(xiàn)是通過在上層的可寫的目錄下建立對應(yīng)的whiteout隱藏文件來實現(xiàn)的。

5、DOCKER化和SDN之間如何更好的結(jié)合，避免DOCKER化之后網(wǎng)絡(luò)技術(shù)成為應(yīng)用開發(fā)瓶頸?
目前Docker網(wǎng)絡(luò)跨宿主機是不通的，公知連通技術(shù)皆屬于內(nèi)網(wǎng)“廣播找人”（同一宿主機內(nèi)），跨宿主機則用封包連通，屬于物理網(wǎng)絡(luò)技術(shù)，距云網(wǎng)絡(luò)虛擬化彈性規(guī)模及SDN動態(tài)可編程需求相去甚遠(yuǎn)，所連通的Docker網(wǎng)絡(luò)不具備動態(tài)規(guī)模彈性與提供服務(wù)所必需的可編程性，不能充分利用容器作為高效CPU虛擬化技術(shù)釋放的資源效率提升。另外正因為容器的CPU虛擬化高效率也造成網(wǎng)絡(luò)通信身份，主要是MAC地址，容量大規(guī)模提升，物理網(wǎng)絡(luò)技術(shù)“廣播找人”做法將使網(wǎng)絡(luò)設(shè)備，主要是柜頂交換機（ToR Switch）和邊緣交換機不堪重負(fù)。公知連通Docker技術(shù)絲毫未考慮因而也不解決MAC地址爆炸廣播域無控擴張這些新問題。也許有人會說：“不怕，買高端ToR就行，Offload邊緣流量到高大上ToR去做SDN連通“。這種思路大概適用并止于虛擬機網(wǎng)絡(luò)規(guī)模，目前工業(yè)界尚無有效offload容器網(wǎng)絡(luò)流量至ToR的解決方案，即便未來某天有人終于發(fā)現(xiàn)了高效技術(shù)offload容器流量到ToR上去連通，于是為了連通Docker需要買高大上ToR，那么容器帶來的CPU虛擬化生產(chǎn)率提高不就被昂貴的高大上ToR給吸走了嗎，我還要容器干嘛呢？

fenyun689

學(xué)習(xí)了
docker不適合數(shù)據(jù)庫。

niao5929

docker在編排器配合下將比傳統(tǒng)的集群更有優(yōu)勢。想知道目前編排器是否提供軟件化的負(fù)載均衡組件功能。集群環(huán)境里負(fù)載均衡組件將是必須組件之一。DOCKER在這方面是否需要進(jìn)行功能強化