標籤:

Docker 有什麼優勢?

docker dotcloud/docker · GitHub

1. docker 是什麼?

2. docker 跟原有的工具有何區別?

3. docker 會對伺服器端開發/部署帶來什麼變化?


2016年6月5日更新:

距離回答這個問題已經過去很長時間了,在此期間docker也一直發展。但本答案僅僅作為向新人介紹docker的入門文章的話,在大方向上還是沒問題的。

本文僅僅是個docker入門介紹文章,用比較宏大的敘事來描述docker的面貌,如果想了解更細節或者更深入的東西,還是需要去深入學習官方文檔等內容。

答案正文:

---

#難懂的docker學術式定義

Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux. Docker uses the resource isolation features of the Linux kernel such as cgroups and kernel namespaces, and a union-capable filesystem such as aufs and others to allow independent 「containers」 to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines.

Docker是一個開放源代碼軟體項目,讓應用程序布署在軟體容器下的工作可以自動化進行,藉此在Linux操作系統上,提供一個額外的軟體抽象層,以及操作系統層虛擬化的自動管理機制。Docker利用Linux核心中的資源分離機制,例如cgroups,以及Linux核心命名空間(name space),來建立獨立的軟體容器(containers)。這可以在單一Linux實體下運作,避免啟動一個虛擬機器造成的額外負擔。

——摘自維基百科

這個定義真是學院派的不能再學院派了,一般人通過這個充滿專業名詞的定義,模糊的能知道docker是可以實現簡化部署之類功能的虛擬化工具,但是並不能清楚的理解它到底牛逼在什麼地方。

##如何搞懂一個陌生的概念?

要搞明白docker的概念,只看定義是遠遠不夠的。除了直接看定義外,還可以通過其他方式來認識它,主要有三種:

  • 第一種:在長期使用docker的過程中,逐漸體會到其優勢(放到具體場景中認識)
  • 第二種:通過和一些已經熟悉的概念對比來認識(比如虛擬機)

上述兩種方法都要求掌握相當多的軟體虛擬化知識,但是對於一個從未接觸過docker,甚至對部署都不是很了解,也沒時間去研究docker的新人,應該怎麼快速理解docker的核心優勢呢?

  • 第三種:藉助於隱喻。

如果你不清楚隱喻的概念,個人有一篇文章單獨介紹:隱喻 。如果不想了解,可以將隱喻簡單理解為類比,藉助於另一個更容易認識的概念來映射新概念。

#docker的隱喻

「docker」的字面意思是「碼頭工人」,這個名字本身應該是官方深思熟慮之後的結果,這個辭彙本身就帶有很強的隱喻性質,它借用了一個在真實世界中已經成熟的體系:全球物流系統,來映射docker在軟體領域中起到的作用。

在全球物流系統中,一個非常重要的發明就是集裝箱。

##集裝箱重要在哪裡?


為了理解這件事情,可以先考察一下集裝箱出現之前的物流情況:貨物從工廠生產出來之後裝箱,然後一箱箱的搬到卡車上,然後再一箱箱卸下來,一箱箱送上火車,運送到碼頭附近的火車站,再一箱箱卸下來,裝上卡車,拉到貨輪上,再一箱一箱的裝上去…

可以看出在這個整個流程中,大量的時間,人力 ,物力全部浪費在了中間的裝卸上。在物流系統裡面,由於路程和運輸工具速度的限制,貨物真正在路上的時間是一定的,在交通技術得到改善之前,這個時間也很難去縮短。於是這部分貨物裝卸時間就成了物流系統中的瓶頸。

這個瓶頸在集裝箱出現之後得到了很大的改善。集裝箱重要在它提供了一種通用的封裝貨物的標準規格(尺寸,外形符合統一標準),這樣就產生了一些巨大的優點:只需要在運輸前一次性封裝,集裝箱就可以放上火車,卡車,拉到碼頭,直接放在貨船上;卸船之後直接再放上火車,卡車,運送到目的地。而且由於集裝箱符合統一標準,整個流程非常容易機械化,這引發了以集裝箱為中心的整個全球物流的標準化進程,從而節省了大量的時間資源和人力資源,成本迅速下降,促進了全球資源的流動與重新配置。

##docker(碼頭工人)正是借用了集裝箱的隱喻

docker就像往集裝箱里裝貨物的碼頭工人那樣,它把應用打包成具有某種標準規格的集裝箱,用計算機領域的語言來說,這種按照一定規格封裝的集裝箱叫「鏡像」。其實就是將你原來的代碼添加點額外的內容,格式之類的,生產出來的一個符合某種標準的東西。

集裝箱減少了貨物的運輸工作量,那docker鏡像又有什麼相似的優勢呢?同樣可以先看看docker出現之前的應用部署是情況。

###docker出現之前的部署情況

在docker出現之前,比如說要部署一個django應用,要做哪些事情?

  • 首先得有個python環境,比如這個要部署的應用基於python3,而你機器上是python2,那ok,先裝個python3吧,一看裝起來還挺麻煩,要先裝各種依賴,還要解決一些可能的衝突,沒辦法硬著頭皮上吧。
  • 裝完python之後,因為有pip這些神奇的工具,很快就裝完django及各種需要的python庫了。咦,發現還要裝mysql,還用了redis。沒辦法,繼續下載,安裝,配置。費了九牛二虎之力終於搞完了。一天就這麼過去了。
  • 啥?你告訴我原來的伺服器不用了,要換一台伺服器?我靠,那重新來一遍吧,有了昨天的經驗,只用了大半天就搞定了。
  • 啥?你說咱們的應用做的太好,要進行推廣,需要指導其他廠商部署?我選擇狗帶,刪代碼走人

上面的描述可能有些誇張,但也絕不是罕有發生。在docker出現之前,各種安裝、配置環境正是運維人員經常做的事情之一,在重複工作上浪費了巨大的資源。

###docker出現之後

####標準的交付件

說到docker最像集裝箱的地方,關鍵就是理解它是軟體領域的一種「標準化」,這種標準化的具體產物,簡單來說就是「鏡像(image)」。

「鏡像」這個詞說實話太玄乎,當然對應的原文「image」本身也挺玄乎的。原因是它根據一些場景引申了本來的含義。

image本身是「畫像,映像」的意思,又有「現實物體的抽象描繪」的意思,而且畫像本身可以很容易的複製,後來又有了「原畫像複製品」一類的意思。

再後來直接就拿來表示光碟鏡像(很容易複製的存儲影像的東西,只不過畫像是畫在紙上,但這種影像以數字形式存在於光碟上)。

當然「鏡像」在漢語中就有「複製品」的含義,只不過加入了漢字獨有的意境,顯得玄乎,朦朧了。

在docker中鏡像是指,把你的應用按照一定的格式封裝(其實就是執行一些符合特定規的命令行)成一種具有某種標準規格的東西(就像集裝箱把你的貨物封裝起來類似)。形象的說,就是把你的應用按照一定的格式抽象的畫了個畫像。

在docker中,鏡像是無法直接運行的,我猜想這並不是技術上的原因,而是出於工程設計上的考慮。因為一般來說,一個軟體的某個具體版本只會打包成一個鏡像。如果鏡像可以配置,運行的話,在使用過程中很可能會對鏡像造成破壞。

那怎麼樣避免鏡像損壞的問題呢?就是再加一層,相當於分身術,只要本尊沒問題,分身怎麼撲街都不會真正的跪掉。多加的這一層分身,就叫容器(container),這個名字也挺形象,它就像個盒子一樣,你的應用在裡面運行,而且多了一層安全機制。你想使用服務或把你的應用跑起來的話,只需要使用鏡像新創建一個容器就可以了(也是一條命令搞定),而鏡像還放在那裡不動,沒辦法,金貴嘛。

#### Docker 究竟做了什麼簡化?

docker在部署過程中,將安裝,配置等重複的部分,由docker自動化完成。只需要在第一次部署時,構建完可用的docker鏡像(裝好集裝箱),在以後使用中,短短的幾行命令,就可以直接拉取鏡像,根據這個鏡像創建出一個容器,把服務跑起來了。所需要的僅僅是安裝了docker的伺服器,一個Dockerfile文件,以及比較流暢的網路而已。真可謂『一次構建,到處部署』。

  • 需要python3環境?直接 from python:3.x 搞定。
  • 需要遷移伺服器? 直接把應用連帶Dockerfile,備份數據拷貝到新伺服器上,幾條命令又搞定
  • 需要作為服務給別人使用?Dockerfile即是最清晰的部署文檔,維護一個官方鏡像即可,誰需要就直接拉下來幾條命令部署上就行了。

到這裡你可能已經發現了,docker鏡像成為了一種像集裝箱那樣的標準貨件。它不像傳統的軟體交付方式那樣,只把代碼以及說明文檔之類的給你就完了,而是直接給你一個標準docker貨件,它可能是Dockerfile,或者直接就是鏡像,這個標準件不僅包括了代碼本身,還包括了代碼運行的OS等各種整體環境。

於是,誰想用我的服務,直接拉取鏡像,實例化一個容器就可以了,能直接提供你所要的服務,不再像之前那樣有繁複的安裝過程————這些都有人給你做過了。

#### 當然docker的優點不止於此

就像集裝箱帶來的「標準化」,這種標準化不僅是指集裝箱本身,而且是指包括運輸器械,物流管理方法等在內的,整個領域的標準化和效率的提高。也就是說基於一件核心事物的「標準化」,可以做更多的事情,比如集裝箱的機械自動搬運,再遠的比如自行車上的螺絲,輪胎等都有全球通用的標準。

docker也是類似的,一旦這種軟體標準建立起來之後,就可以基於標準件和相應的管理方式帶來更多的改變。隨便舉一些例子:

##### 統一的管理服務

使用docker部署的應用,都會在docker的管理範圍之內。這也是docker的另一個非常大的優點,它提供了一種隔離的空間,把伺服器上的零散的部署應用集中起來進行管理。

舉個例子,比如我一個伺服器上部署了n多服務,有mysql,redis,rabbitmq,其他還有一堆應用。有一天我伺服器突然斷電重啟了,那些沒有設置自動重啟的應用,那些重啟出問題的應用,那些你甚至都不知道隱藏在某個角落裡的重要應用沒啟動成功….

然而使用docker,一眼就可以看出那些應用正常啟動了,那些應用又出問題了。接下來只用有條不紊的處理就ok了。

#####持續交付上的應用
持續交付有一些超出範圍,自己去尋找答案吧

##### 彈性計算

也就是根據需要,動態地添加新的應用服務,在不需要時收回伺服器資源,docker的標準化讓這種彈性能力得到了更好的應用。

# 最後,關於docker的一個誤解

很多人說docker改變了運維世界,這句話是從群體統計角度來說的,像mysql,python這樣被大規模使用的應用,docker化之後對整個群體所節省的時間,是非常巨大的。

所以有人可能會問,我只有一台伺服器,也不太可能會遷移。我的python服務,mysql服務,只需要部署一次,就可以在以後重複使用了。那這樣docker對於我來說還有優勢嗎?畢竟docker也是有學習成本的。

如果你確信你的應用都是一次性的,而且只提供給自己使用,那麼docker在這種場景下的優勢不是特別明顯:即便是docker,最初的構建也是需要有人做的,這和直接在機器上部署一次的工作量差不多。也就是說,docker並不能把部署的工作「減少為0」,比較好的情況下是「基本減少為1」。

但是,你真的真的確信,你所做的工作只是一次性的嗎?


前兩天,debian 從 8 全新升級到 9(不喜歡 dist-upgrade),要重裝 owncloud (debian 9 已經移除 apt源了),打開 owncloud 的安裝文檔,真他媽的瑣碎,要搭建個高可用的 owncloud 起碼還要費我兩三個小時,於是打開 http://hub.docker.com 立馬就找到了一個 owncloud 的 image,我掃了一眼特性,比 owncloud 官方推薦的標準配置強不少:

  • Streamlined Letamp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;#x27;s Encrypt functionality built right in
    • This will fetch valid, trusted and free SSL certs for your domain and install them into the image!
    • Hurray for green lock icons!
  • Superfast
    • Uses PHP7 with APCu and Zend OpCache for maximum performance
  • Now with image version tags corresponding to OwnCloud release versions
    • So you won"t get unexpectedly upgraded and you can safely stay on an OC version you know is working for you
  • Built in (optional) MySQL database server (faster than sqlite default)
    • Or specify your own pre-existing database server during setup
  • Web GUI driven initial setup of user/password/database
  • Based on Arch Linux ensuring everything is cutting edge up to date
  • SSL (HTTPS) encryption works out-of-the-box
    • Tweaked for maximum security while maintaining compatibility
  • Optionally enable automatic SSL certificate regeneration at runtime for maximum security
    • Or easily incorporate your own SSL certificates
  • In-browser document viewing and editing ready (.odt, .doc, and .docx)
  • In-browser media viewing ready (pretty much everything I think)
  • Comes complete with all of the official ownCloud apps pre-installed:
    • Bookmarks
    • Calendar
    • Contacts
    • Documents
    • Gallery
  • Or install your own 3rd party apps

隨便裝一下 owncloud糊弄一下的話,很快,但想弄的穩定高效,不是專業sa,每項都要費我不少時間去查閱文檔,真不想在這些事情上費時間。看完這些毫不猶豫的把 image 拉下來,設置下內外埠映射和文件夾映射,一條命令就跑起來了,感覺真爽。

以前在大公司,要什麼環境發封郵件就行了,後來在小公司,不得不充當半個 SA才感覺事情之繁瑣細緻。舉個例子,搭建 svn server,可能你覺得簡單,不就是 apt-get subversion 然後 supervisor 裡面配置個 svnserve 的服務就行了么?好,接下來要給 svn 換成 https 的模式可能你就覺得有點煩了,apt-get 下來還有一堆許可權和模塊要配置,起碼半小時,不過還好;如果更進一步,需要針對 ssd 優化 svn 倉庫的存儲方式,還有每天定時增量備份,每周定期全量備份,備份內容要保存到遠程目錄,加密壓縮,定期刪除老的備份保留最近兩個月數據,然後支持多倉庫,自動同步許可權配置併合並更新,有個小網頁可以註冊svn帳號(需要管理員密碼才能操作),可以複位忘記密碼的,所有帳號操作有記錄,你可能真的要吐血了。

這種環境我搭了四遍,每次都是隔了半年以上忘記的差不多了,又重頭開始塔的,第一次完整搭建下來廢了我兩天。本來偷懶沒記筆記,想著搞一次,結果半年後第二次又來一遍,好多東西忘記了,仍然費了我一個整天,還好我這次學乖了記了筆記,第三次第四次半天就搞定了。

現在你再讓我搭建一遍我真的想想都怕,後來我搭建了一個乾淨的 svn虛擬機 image,但是接近1個G,壓縮以後也好幾百兆,十分累贅,不便於保存和傳遞,現在好了,製作一個 docker 映像,交給別人用,根本不用啰嗦半天,一條命令,前面配置了那麼多的功能,一下就啟動起來了。

在我半個 SA生涯里,https + svn 只能算煩,不能算複雜,比較複雜的還有整套 qemu-kvm 的虛擬化環境,linux 物理機上從零搭建起一套類似 vmware 的可視化虛擬環境,可以在網頁上點點創建虛擬機,設置虛擬網路,支持網頁版 VNC,可以頁面上打開虛擬機終端屏幕進行操作系統安裝,就像騰訊雲阿里雲一樣,還有一些自動腳本可以用 libvirt 操作虛擬機做一些自動備份遷移的事情。配這麼一套環境要想弄得完善,各種網路和系統參數優化到位,從頭到尾接近一百多個步驟,這玩意兒,我配第一次挺開心,覺得自己從頭到尾弄了一套完全免費的 vmware,結果後面又接著配了倆三次,配一次吐一升血。

除此之外還有各種 mongodb 集群啦,分散式文件系統啊,有了docker以後,都是一句話就搞定的事情。現在覺得 docker 就是來拯救大家的時間的,能夠將 SA的經驗標準化並固定下來,特別中小團隊,上了docker省下你一兩個 sa來一點問題都沒有。


1. Docker是一個對Linux cgroup, namespace....包裝並提供便利借口的的一個開源項目,使其看起來可以更像「虛擬機」

2. 實現更輕量級的虛擬化,方便快速部署

3. 感覺 對開發的影響不大,但對於部署來說,是場革命。可以極大的減少部署的時間成本和人力成本


Docker有不少有趣的功能,通過本教程系列相信你會更好地理解它們。Docker特性主要包括以下幾點,具體參考:http://dockerone.com/article/101

  • 速度飛快以及優雅的隔離框架
  • 物美價廉
  • CPU/內存的低消耗
  • 快速開/關機
  • 跨雲計算基礎架構


給個標準答案,不用謝:

1)標準化應用發布,docker容器包含了運行環境和可執行程序,可以跨平台和主機使用;

2)節約時間,快速部署和啟動,VM啟動一般是分鐘級,docker容器啟動是秒級;

3)方便構建基於SOA架構或微服務架構的系統,通過服務編排,更好的松耦合;

4)節約成本,以前一個虛擬機至少需要幾個G的磁碟空間,docker容器可以減少到MB級;

5)方便持續集成,通過與代碼進行關聯使持續集成非常方便;

6)可以作為集群系統的輕量主機或節點,在IaaS平台上,已經出現了CaaS,通過容器替代原來的主機。

再透露一些信息,以便對docker了解更多一些,國內做docker容器的公司現在不多,都有免費試用的服務,如果你感興趣可以一家一家去玩玩兒,精靈雲、道雲、時速雲、靈雀雲等,這四家我都已經玩兒了一遍。


Docker最大的優勢是其定義的鏡像(image)製作和分發機制,以及基於鏡像衍生出來的一套軟體生態:

  1. 簡單的Dockerfile語法,飛快的鏡像製作速度,讓稍懂命令行的開發者能很快上手製作自己的鏡像。
  2. 鏡像繼承(FROM &)和鏡像中心(docker registry),使得鏡像復用異常奇松。
  3. 基於鏡像的發布,讓發布過程原子化。以前一次升降級=拉代碼包+更新配置+殺進程+起進程,換一種語言意味著換一種發布流程。基於鏡像的升降級=拉鏡像+停容器+起容器,和語言幾乎無關。
  4. http://hub.docker.com 上各種鏡像讓各路開發者只需要通過一條命令`docker run`即可輕鬆嘗試新的技術。

反倒是鏡像的運行時-容器(container),還存在很多不完美的地方,使得企業級應用的容器化部署之路遠沒有官方宣稱的「ship and run"那麼簡單,讓很多其他容器技術試圖取而代之或佔領細分市場(如rkt, hyper,mesos container等),這些技術雖在容器運行時層面各有側重,但不變的是他們都會強調兼容docker 鏡像。


樓上回答的很好了。

關於部署,我再補充一句:

  • 傳統的部署模式是:安裝(包管理工具或者源碼包編譯)-&>配置-&>運行;

  • Docker的部署模式是:複製-&>運行。


docker:運維大神! 舉起手來, 把你在那黑盒子里所乾的事情統統坦白!

rooter: 好吧,這是一份 Dockerfile...


1.容器技術對比虛擬化技術,容器比虛擬化更輕量級,對資源的消耗小很多。容器操作也更快捷,啟動和停止都要比虛擬機快。但Docker容器需要與主機共享操作系統內核,不能像虛擬機那樣運行獨立的內核。

2.Docker的發展得益於為使用者提供了更好的容器操作介面。包括一系列的容器,鏡像,網路等管理工具,可以讓用戶簡單的創建和使用容器。

3.Docker支持將應用打包進一個可以移植的容器中,重新定義了應用開發,測試,部署上線的過程,核心理念就是 Build once, Run anywhere。典型應用場景是開發運維上提供持續集成和持續部署的服務。

只看理論很難理解,實驗樓有在線的Docker環境,實操體驗下就清楚了。

Docker - 動手實戰學Docker


1. 從技術上說,容器技術有10幾年的歷史,Docker也有5,6年的歷史了,容器/Docker所依賴的Linux內核Cgroup和Namespace技術,歷史更悠久,因此容器的技術可靠性是完全可以信賴的。

2. Docker版本更新較快,版本迭代頻繁,而且docker沒有長期穩定版LTS的支持,所以在生產場景中使用,難免會踩到Docker的Bug,所以如果要在實際生產環境中大規模使用,需要有對Docker本身的維護能力。

3. Docker和VM相比,虛擬化層次不同,導致Docker的隔離性要比VM弱,在多租戶環境中有安全隔離的問題,另外在單宿主機上,容器之間的資源競爭也可能導致業務會受到影響,需要對容器的資源隔離,特別是cgroup的隔離有較為精細的運維。


1. 軟體構建方面的優勢

讓我們來對比下傳統的構建模式和docker的構建模式:

生命周期傳統DockerBuildmakefile、rpm、maven、tgzdocker buildShipscp、freedom、pspdocker pushRunbash、freedom,pspdocker run從中可以看到傳統的運維模式特點:割裂,個性化,而docker則統一,一致,這對於運維人員來說,可以說是一個接近革命性的

Docker在運維上的優勢可以類比Java語言:(當然我認為docker和jvm的思想是一致的,只是虛擬化的層次不同)

  • Java可以一次編譯到處運行,Docker實現了一次構建(鏡像),到處運行(整個應用及其依賴)。
  • Java的JVM屏蔽了不同OS的差異,Docker的Daemon屏蔽了不同OS發行版,不同機器的環境差異;

對開發人員

  • 解決了開發環境搭建的問題

對運維人員

  • 環境變更避免多打一的瓶頸
  • 研發交付完整的運行棧,自動化程度更高

2.鏡像啟動快速以及鏡像size小帶來的優勢

由於docker的鏡像相對於虛擬機鏡像來說小的出奇,而且啟動速度非常快(基本上秒級的啟動速度),這讓應用的容量伸縮變得很容易,結合微服務架構,可以讓原有的物理資源利用率提高。

  • 比如原有一個SOA的應用需要綁定100個service,但是其中被調用頻繁的service其實也就那麼10個,而由於這10個service的存在,其他90個service也在同一個應用中被啟動著,白白損失了一定的內存資源,由於這10個service啟部署在100台物理機,則一共啟動了1000個services,其中900各十分空閑,但是仍損耗一定資源。

  • 經過微服務,把原有的100個service每一個service拆分成了一個應用,其中90個應用只需要啟動1個實例即可應付所有請求,而10個頻繁的service則啟動了100個實例,則一共啟動了 90 + 100 = 190個service,在這種情況下,對內存和cpu的利用率明顯提高了,而且開發甚至都不需要知道自己的service被部署到了哪裡


docker就是lxc的一個封裝

並帶有git類似的鏡像版本控制

可以非常方便的運行容器和釋放

可以很方便的連接宿主機器容器

最主要的是方便。一個容器環境commit之後導出image,部署到另外一台機器的成本是0


關於docker有什麼優勢的回答,大家都已經寫了很多了,在這兒就不贅述了。

問了我們豈安科技的運維筋斗雲老師,他提出了一些自己的看法:

不可否認docker確實有很多的優勢,目前廣泛被廣大程序員稱道的是輕便,快捷。但是隨著 docker 部署的增多,也發現了一些單純使用 docker 的弊端,例如命令行操作比較繁瑣,需要記的參數較多等。但是這些弊端並不是不可解決的,很多人會安裝Marathon來使用,所以在此介紹一下讓docker優勢更明顯的工具——Marathon。並附上詳細的部署教程。

以下:

基本概念

Mesos:Mesos 採用與 Linux Kernel 相同的機制,只是運行在不同的抽象層次上。Mesos Kernel 利用資源管理和調度的 API 在整個數據中心或雲環境中運行和提供引用(例如, Hadoop、 Spark、Kafaka、Elastic Search)。

ZooKeeper:ZooKeeper 是一個分散式的,開放源碼的分散式應用程序協調服務,是 Google的Chubby 一個開源的實現,是 Hadoop 和 HBase 的重要組件。它是一個為分散式應用提供一致性服務的軟體,提供的功能包括:配置維護、名字服務、分散式同步、組服務等。

Marathon:Marathon 是一個 Mesos 框架,能夠支持運行長服務,比如 Web 應用等。它是集群的分散式 Init.d,能夠原樣運行任何 Linux 二進位發布版本,如 Tomcat、Play 等等。它也是一種私有的 PaSS,實現服務的發現,為部署提供提供 REST API 服務,有授權和 SSL、配置約束,通過 HAProxy 實現服務發現和負載平衡。

部署

為了部署的方便 全部使用 docker 部署。

master搭建

三台 mesos master 伺服器

ip地址分別是 10.100.0.21,10.100.0.22,10.100.0.23

需要在master上分別部署 mesos mater , zookeeper , marathon

需要在10.100.0.21 上執行下列命令 :

marathon

docker run -d -e MARATHON_HOSTNAME=10.100.0.21 -e MARATHON_HTTPS_ADDRESS=10.100.0.21 -e MARATHON_HTTP_ADDRESS=10.100.0.21 -e MARATHON_MASTER=zk://10.100.0.22:2181,10.100.0.23:2181,10.100.0.21:2
181/mesos -e MARATHON_ZK=zk://10.100.0.22:2181,10.100.0.23:2181,10.100.0.21:2181/marathon --name marathon --net host --restart=always mesoscloud/marathon

mesos-master

HOST_IP=10.100.0.21
docker run -d --name mesos-master1 --net="host" -p 5050:5050 -e "MESOS_HOSTNAME=${HOST_IP}" -e "MESOS_IP=${HOST_IP}" -e "MESOS_ZK=zk://${HOST_IP}:2181/mesos" -e "MESOS_PORT=5050" -e
"MESOS_LOG_DIR=/var/log/mesos" -e "MESOS_QUORUM=1" -e "MESOS_REGISTRY=in_memory" -e "MESOS_WORK_DIR=/var/lib/mesos" mesoscloud/mesos-master

zookeeper

docker run -d -e MYID=1 -e SERVERS=10.100.0.21,10.100.0.22,10.100.0.23 --name zookeeper --restart=always --net=host mesoscloud/zookeeper

需要在10.100.0.22 上執行下列命令

marathon

docker run -d -e MARATHON_HOSTNAME=10.100.0.22 -e MARATHON_HTTPS_ADDRESS=10.100.0.22 -e MARATHON_HTTP_ADDRESS=10.100.0.22 -e MARATHON_MASTER=zk://10.100.0.22:2181,10.100.0.23:2181,10.100.0.21:2
181/mesos -e MARATHON_ZK=zk://10.100.0.22:2181,10.100.0.23:2181,10.100.0.21:2181/marathon --name marathon --net host --restart=always mesoscloud/marathon

mesos-master

HOST_IP=10.100.0.22
docker run -d --name mesos-master1 --net="host" -p 5050:5050 -e "MESOS_HOSTNAME=${HOST_IP}" -e "MESOS_IP=${HOST_IP}" -e "MESOS_ZK=zk://${HOST_IP}:2181/mesos" -e "MESOS_PORT=5050" -e
"MESOS_LOG_DIR=/var/log/mesos" -e "MESOS_QUORUM=1" -e "MESOS_REGISTRY=in_memory" -e "MESOS_WORK_DIR=/var/lib/mesos" mesoscloud/mesos-master

zookeeper

docker run -d -e MYID=2 -e SERVERS=10.100.0.21,10.100.0.22,10.100.0.23 --name zookeeper --restart=always --net=host mesoscloud/zookeeper

需要在10.100.0.23 上執行下列命令

marathon

docker run -d -e MARATHON_HOSTNAME=10.100.0.23 -e MARATHON_HTTPS_ADDRESS=10.100.0.23 -e MARATHON_HTTP_ADDRESS=10.100.0.23 -e MARATHON_MASTER=zk://10.100.0.22:2181,10.100.0.23:2181,10.100.0.21:2
181/mesos -e MARATHON_ZK=zk://10.100.0.22:2181,10.100.0.23:2181,10.100.0.21:2181/marathon --name marathon --net host --restart=always mesoscloud/marathon

mesos-master

HOST_IP=10.100.0.23
docker run -d --name mesos-master1 --net="host" -p 5050:5050 -e "MESOS_HOSTNAME=${HOST_IP}" -e "MESOS_IP=${HOST_IP}" -e "MESOS_ZK=zk://${HOST_IP}:2181/mesos" -e "MESOS_PORT=5050" -e
"MESOS_LOG_DIR=/var/log/mesos" -e "MESOS_QUORUM=1" -e "MESOS_REGISTRY=in_memory" -e "MESOS_WORK_DIR=/var/lib/mesos" mesoscloud/mesos-master

zookeeper

docker run -d -e MYID=3 -e SERVERS=10.100.0.21,10.100.0.22,10.100.0.23 --name zookeeper --restart=always --net=host mesoscloud/zookeeper

這樣 mesos 的 master 就搭建完成。

slave伺服器搭建

下面是 mesos 的 slave 伺服器 模擬4台

ip 地址是10.100.0.24 10.100.0.25 10.100.0.26 10.100.0.28

在10.100.0.24上運行下面的命令

docker run -d --net=host --pid=host --privileged=true --name=ms1 -v /usr/bin/docker:/usr/bin/docker -v /dev:/dev -v /var/run/docker.sock:/var/run/docker.sock -v
/var/log/mesos:/var/log/mesos -v /tmp/mesos:/tmp/mesos -e MESOS_HOSTNAME=10.100.0.24 -e MESOS_IP=10.100.0.24 -e MESOS_MASTER=zk://10.100.0.21:2181,10.100.0.22:2181,10.100.0.23:2181/mes
os -e MESOS_CONTAINERIZERS=docker,mesos mesoscloud/mesos-slave

在10.100.0.25上運行下面的命令

docker run -d --net=host --pid=host --privileged=true --name=ms1 -v /usr/bin/docker:/usr/bin/docker -v /dev:/dev -v /var/run/docker.sock:/var/run/docker.sock -v
/var/log/mesos:/var/log/mesos -v /tmp/mesos:/tmp/mesos -e MESOS_HOSTNAME=10.100.0.25 -e MESOS_IP=10.100.0.25 -e MESOS_MASTER=zk://10.100.0.21:2181,10.100.0.22:2181,10.100.0.23:2181/mes
os -e MESOS_CONTAINERIZERS=docker,mesos mesoscloud/mesos-slave

在10.100.0.26上運行下面的命令

docker run -d --net=host --pid=host --privileged=true --name=ms1 -v /usr/bin/docker:/usr/bin/docker -v /dev:/dev -v /var/run/docker.sock:/var/run/docker.sock -v
/var/log/mesos:/var/log/mesos -v /tmp/mesos:/tmp/mesos -e MESOS_HOSTNAME=10.100.0.26 -e MESOS_IP=10.100.0.26 -e MESOS_MASTER=zk://10.100.0.21:2181,10.100.0.22:2181,10.100.0.23:2181/mes
os -e MESOS_CONTAINERIZERS=docker,mesos mesoscloud/mesos-slave

在10.100.0.28上運行下面的命令

docker run -d --net=host --pid=host --privileged=true --name=ms1 -v /usr/bin/docker:/usr/bin/docker -v /dev:/dev -v /var/run/docker.sock:/var/run/docker.sock -v
/var/log/mesos:/var/log/mesos -v /tmp/mesos:/tmp/mesos -e MESOS_HOSTNAME=10.100.0.28 -e MESOS_IP=10.100.0.28 -e MESOS_MASTER=zk://10.100.0.21:2181,10.100.0.22:2181,10.100.0.23:2181/mes
os -e MESOS_CONTAINERIZERS=docker,mesos mesoscloud/mesos-slave

以上,搭建完成

希望我們的回答對更好的使用docker有幫助

更多乾貨歡迎關注豈安科技微信公眾號:bigsec


說點個人體會,linux許可權管理比較麻煩,為了共享文件很多目錄許可權是755,如此一來隨意允許普通用戶ssh並不安全。docker可以一對一地mount地址,然後伺服器建一些賬戶但不對外分配密碼,使得非管理員無法ssh,這樣很多時候用755和777兩種許可權即可解決絕大多數問題。

此外,相比於虛擬機與虛擬化,docker對硬體的利用率極高,而且每個服務依舊是獨立的。


作為一個開發者,我就不說運維那些事情。

Docker 解決開發的環境一致性問題 和 依賴組建版本問題。


我再補充一句。

Docker還處於快速地發展之中。每過一個月,再看看Docker,你都會驚喜的發現它在好多方面又已經變得不同了。這也是Docker的一大優勢:一個活躍的、快速進化的社區。在使用過程中,你可能會碰到一些問題。但面對這些問題,要麼你能很容易地找到回答,要麼,會在不久的將來得到解決。

推薦另外一個問題中我的回答:如何評價Docker最新版本1.6? - Linux 運維

以及這篇文章:Docker 1.6新體驗


看看Docker到底解決了什麼問題


docker應該是針對一個比較固定的環境進行配置 比如你在一大堆初始化的Ubuntu中部署一個軟體 但是如果你要把軟體部署到Centos那麼還要再去封裝一次 這是我的理解


對於樓上回答的疑問:

傳統模式有配置環節,Docker沒有,何解?不同環境配置多少有不同的地方。


只想強調一個新手認識誤區,docker用的linux kernel仍然是宿主機上的kernel!


推薦閱讀:

在雲環境中的應用部署方式上,Docker會不會取代KVM、Xen之類的虛擬機技術?
docker在web開發中得使用流程是怎樣的?
DaoCloud是一家什麼樣的公司?
Docker 的應用場景在哪裡?

TAG:Docker |