国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

關于Docker Swarm,你可能需要了解更多實踐經驗

bitkylin / 3350人閱讀

摘要:雖然可以使用相同的方式部署應用到云端,使用外部負載均衡器,但動態添加或者減少負載均衡節點依舊是痛點。這對使用外部負載均衡器幫助巨大。

數人云今天帶來的本篇文章將分享Docker在應用程序生命周期每個階段中所扮演的角色,以及遷移到Swarm集群時需要考慮的問題。

利用Docker來開發

Docker讓工作更輕松。如需要一個部署安裝MySQL數據庫,或者安裝Ghost,又或者Redis數據庫,PostgreSQL,Ruby等。實際上這些都已經被Docker化容器化和鏡像化。

只需要一條命令即可運行:

docker run name_of_programe_you_need

下載(鏡像)—使用完—丟掉,沒有其他程序搞亂本地開發環境。

擴展現有的容器十分簡單,只要擁有足夠的Docker基礎知識,就能判定從網上下載的Docker鏡像是否是有用的鏡像。

Docker是開發人員的利器,添加到開發環境中好處無需多言。

若熟悉Docker,? 會經常使用Docker-compose一條命令來啟動整個開發環境棧。

例如,很常見的Docker-compose文件是這樣:

version: "2"  
services:  
  web:
    build: .
    command: npm run dev
    ports: 
      - 8080:80

  redis:
    image: redis

  database:
    image: postgres

然后運行:

docker-compose up # --build if you want to rebuild

PostgreSQL訪問地址:postgresql://database

Redis訪問地址: http://redis

這是一種極為簡便的方法,整個開發環境棧用幾行代碼描述(development stack as a code),并且內置版本控制功能。下面來講下生產環境。

生產環境要求

生產環境非同一般。這里例舉中等負載量的服務器要求——

可用性: 必須所有的時間點上,服務都是可用的,盡可能減少宕機時間。

性能: 服務器需要處理大量的訪客請求,故而性能也很重要。

易于部署和回滾。

收集日志和指標。

負載均衡: 如果有某些服務或者服務器失敗了,我們期望網站可以正常訪問。

Docker作為一個準生產的解決方案,實際上被非常多的人低估了。約一年前,PvP Center(https://beta.pvpc.eu/)過程中,因Docker文件系統問題,也經歷了一些失敗(目前,我使用Overlay2文件系統,問題不復存在),現在回頭想一下,這是很好的決定。

生產部署是使用原始Docker命令還是 Docker-compose

若遇到這個問題,配置好Ansible自動下載新版本的應用,然后自動部署到容器即可(Ansible配置文件:https://rock-it.pl/managing-m... )。
接下來查看列表——

性能:Docker進程,是正常的內核進程,不會產生顯著的資源開銷。

易于部署: 一鍵部署。因Ansible要檢查多個判斷條件, 不僅僅是是判斷容器的版本,所以需要花費一點時間。

回滾: 所有的容器鏡像都使用不同的標簽后,保存在容器倉庫中。對數據庫遷移做了向后兼容,回滾會很容易。

但以上的做法也會產生問題:

1、不能滿足一些非常規要求(在要求部署應用的時候服務器零宕機) 因為要維護后端動態的負載均衡節點,不能輕易的擴容到多臺服務器上。

2、需要極聰明的手段和方法才能整合 持續集成/持續部署系統(CI/CD)。

3、如果分別存放特定應用程序,滿足部署依賴在不同的架構倉庫內 。當配置文件發生變化時,回滾變得非常困難。

堅持了這種做法一段時間,沒有任何問題,但是總感覺缺失了什么東西,因為快速部署以及配置文件需要太多修改, Ansible部署也刺激到了我(太慢了)。但是,真正促使往Docker Swarm遷移的決定性原因是——擴容到一臺服務器以的特性。雖然可以使用相同的方式部署應用到云端,使用外部負載均衡器,但動態添加或者減少負載均衡節點依舊是痛點。把特定應用的配置文件從Ansible中移除,轉而把這些配置文件發到應用倉庫中。

Docker Swarm

Docker Swarm設計的目的是方便地使用Docker命令來管理多臺服務器之間的容器調度,是相當前沿的新功能新特性(從Docker 1.12版本開始)。

要點:允許同時連接到多臺運行Docker的服務器上。

比較簡單:對比Kubernetes,Docker Swarm上手更快。

高可用 – 集群中有二種不同類型的節點: Master節點和Worker節點。

其中的一個Master節點是Leader, 如果當前Leader宕機不可用,其他健康的Master中的一臺會自動成為Leader 。如果Worker節點宕機不可用,宕機節點上的容器實例會被重新調度到其他健康的Worker節點上。

聲明式配置:只需明確發布什么應用以及多少份實例副本,調度系統會自動調度發布這些應用實例,并且遵循指定的限制條件等。

滾動更新:Swarm保存了發布容器時候的配置。 若新了配置文件,容器也會批量更新,所以服務會是一直是可用的。

內置服務發現和負載均衡 :與Docker-compose 實現的負載均衡類似。可以通過參考服務名,容器跑在哪里哪臺服務器上已經完全不重要,這些負載均衡節點都會接收前端導過來的流量,默認是輪詢策略。

Overlay網絡:如果容器暴露了一個服務端口,這個服務端口在集群內都可以被訪問。這對使用外部負載均衡器幫助巨大。

在什么時候才應該考慮使用Docker Swarm

在考慮使用Docker Swarm前,先過一遍下面5個問題——

應用是否需要擴容到兩臺以上的服務器上?多臺服務器總是比單臺服務器復雜,或者只是想購買更高配置的單臺服務器(譯者注: 縱向擴展)?

應用是否有高可用的要求?

應用容器化后是否真的是無狀態化的?在Swarm下跑容器不應該使用存儲卷,雖然理論上是可以使用存儲卷,但是在測試使用的時候,它依舊不是穩定可靠的。可以考慮把多媒體文件移到亞馬遜S3上,而把數據庫運行在Docker Swarm之外。

是否有集成日志系統,例如ELK (這個適用于所有分布式系統)。

是否需要已經存在于其他更成熟解決方案(如Kubernetes)中的高級功能和特性? 謹記,熟悉Kubernetes比熟悉Docker Swarm要難得多。

生產環境使用Docker Swarm經驗

截止目前,應用跑在Swarm上面已經有六個月的時間,從Docker-compose遷移到Swarm花去一周的時間(包括學習如何遷移等)。需要調整配置文件,以便讓應用容器完全是無狀態的,使用外部集中式日志和指標收集。高峰時,共運行了35個節點。對集群的管理十分方便。

例如:

docker service scale name_of_service=30 or docker service update --env-add SECRET_ENV=youdontneedtoknowit name_of_service

截屏如下:


部署流程如下圖:

在Deploy區域內,使用最新Docker-compose v3版的語法和Docker stack deploy命令。把發布應用容器的配置文件存儲為VCS這項工作變得前所未有的簡單。無需要手工修改任何配置,輕松地部署應用容器到Swarm集群。

配置文件例子:

version: "3" 
services: 
  web:
    image: registry.gitlab.com/example/example  # you need to use external image
    command: npm run prod
    ports:
      - 80:80
    deploy:
      replicas: 6
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure

整個部署命令只有一行:docker stack deploy application . 當然,這里使用了Gitlab.com 的流程,結果如下圖所示:

可以在Web界面上進行回滾操作,甚至在手機上執行回滾操作。

結語

以上都是個人對Docker Swarm的觀點。之前考慮過使用其他選項,但如果想讓應用容器化,進而伸縮擴容到多臺服務器上,目前這種方法是最好的選擇。

原文作者:Jakub Ska?ecki
原文鏈接: https://rock-it.pl/my-experie...

歡迎關注數人云微信公眾號,如有后續文章,我們會在第一時間進行跟進

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/26903.html

相關文章

  • 生產環境中使用Docker Swarm的一些建議

    摘要:譯者按實踐中會發現,生產環境中使用單個節點是遠遠不夠的,搭建集群勢在必行。集群的網絡通信服務發現,負載均衡以及容器間通信非常可靠。負載均衡也是由提供的。 譯者按: 實踐中會發現,生產環境中使用單個Docker節點是遠遠不夠的,搭建Docker集群勢在必行。然而,面對Kubernetes, Mesos以及Swarm等眾多容器集群系統,我們該如何選擇呢?它們之中,Swarm是Docker原...

    loonggg 評論0 收藏0
  • 老肖有話說:如期而至的Swarm新工具Crane開源解讀

    摘要:更多技術棧的包容數人云技術團隊為了幫助廣大技術愛好者對新版本有快速直觀的感受,制作了一款基于最新特性的容器管理工具,具備一定容器開發經驗的開發者可以通過它在第一時間體驗的新特性。可以說,數人云是在技術能否持續下去的爭論中發布的工具。 showImg(https://segmentfault.com/img/bVD5g2?w=900&h=500);中秋節前, 數人云技術團隊推出了一...

    andot 評論0 收藏0
  • 數人云容器管理工具 Crane 現已開源

    摘要:指導員明伯伯數人云工程師手記相關閱讀基于的集群管理開發實踐服務發現,負載均衡和 這是一個容器信息臃腫的時代。 Docker 鯨魚鼓著圓圓的肚子在西雅圖開了一場名為 DockerCon2016 的大會,全球 4000 人參加, 8 大看點留下對容器生態的更多暢想。 數人云一直專注于以企業級的 Mesos +容器技術棧,出于對容器新技術的熱愛,我們在社區版的工具上小試牛刀,距 Docker...

    NeverSayNever 評論0 收藏0
  • Docker Swarm在生產環境中的進階指南

    摘要:應該如何解決本文將給出若干提示,如何在生產環境中使用。路由匹配服務發現負載均衡跨容器通訊非常可靠。在單個端口上運行一個服務,節點的任意主機都可以訪問,負載均衡完全在后臺實現。 上周數人云給大家分享了——《你可能需要的關于Docker Swarm的經驗分享》今天給大家帶來這位作者大大的后續文章——《Docker Swarm在生產環境中的進階指南》 當在本地開發環境中使用Docker,或者...

    galaxy_robot 評論0 收藏0
  • Docker Swarm集群初探

    摘要:既然要組集群那就涉及諸如的資源調度管理等等一系列問題。目前涉及集群的三個主要的技術無外乎三種。從本文開始作者將會一一實踐這幾種主要的集群技術,話不多說,現在開始。完全運行于內存中,體積小,啟動快。 showImg(https://segmentfault.com/img/remote/1460000015723680); 前言 相信Docker技術大家都有所了解,單個Docker能發...

    MingjunYang 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<