搭建企業私有Docker Registry實戰分享

jopen 9年前發布 | 44K 次閱讀 Docker

實戰聊天運維ChatOps

什么是ChatOps

ChatOps這個概念最初是由Github團隊提出，簡單來說，是基于對話驅動的開發方式。實際做法是：把你的工具帶到您的溝通過程中，并使用一個聊天機器人編寫定制化的腳本，使團隊可以自動執行相應任務和協同工作，使運維工作更透明更高效。

因此，實施ChatOps需要兩個重要組成部分：聊天室和機器人。聊天室也就是我們常說的團隊協作平臺，比較知名的有：

  • Flowdock，知名團隊協作平臺，目前我們在使用它。

  • Slack，國外著名的團隊協作平臺，界面美觀。

  • HipChat，國外著名的團隊協作平臺，界面簡潔。

  • Zulip，Dropbox旗下的group chat平臺，已開源。

  • Teambition，國內知名的團隊協作工具，具有文檔管理功能。
    • </ul>
    這里是一篇比較Slack、Flowdock和HipChat的文章：
    http://www.slant.co/topics/135 ... wdock。

    機器人選取了由Github團隊開發的，當下最廣泛使用 Hubot。它是基于Node.js+CoffeeScript編寫的，支持眾多協作平臺，如果沒有你在用的，自己寫adapter也很簡單。除此之外，還有一些機器人：

    • lita，Ruby寫的robot。

    • Errbot，Python寫的robot。
      • </ul>
      團隊中的任何一個人，只要在Flowdock這樣的協作平臺上，像聊天一樣，輸入相應指令，比如hubot show registry status，收到這條指令的Hubot就會根據后臺定制的腳本，自動把相應信息通過一條聊天信息返回給你。

      為什么要使用ChatOps

      ChatOps的實施使運維工作更加透明，更加簡潔。這樣的好處很多：

      • 把過去團隊成員在各自工具中輸入命令的這個黑匣子過程前端化、透明化了。團隊每個成員都能隨時了解其他成員的一舉一動，打造真正的無死角透明團隊。

      • 非常有利于新人的培養。顯然，能夠直觀看到團隊的微觀運作，對于剛入職的新手來說，比任何培訓的效果都更好。
        • </ul>

        目前是如何利用ChatOps

        我們公司目前內部署了私有Docker Registry，我們希望監控它的運行和使用情況，并且能夠快速地對一些可預知的問題進行處理。通過Flowdock+Hubot（Hubot運行在Docker容器里）就能實現這點：

        • 通過Hubot監控Registry是否正常運行。主要使用了Sensu來做Registry的health check。一旦發現Registry沒有正常運行，hubot就會發送一條信息到flowdock里，使用@team來通知團隊。然后團隊的成員可以使 用hubot指令hubot fetch registry error cause，讓hubot幫我們調查并返回出錯的原因。根據出錯原因，再使用hubot指令進行應急處理。

        • 通過Hubot定時發Registry運行情況到Flowdock Inbox里。通過Sensu作為服務監控，收集Registry本身一些運行數據，包括CPU，內存等，發送到Graphite，生成時序統計圖，發布到flowdock上。

        • 通 過Hubot實時獲取Registry的使用情況。首先Registry進行了notification配置，Registry使用元信息會被發送到定制 的收集服務（Notification analysis service）中去。通過分析這些使用元信息，獲取不同Registry鏡像的pull/push數量，由Notification analysis service提供相應的聚合搜索API。調用這些API，可以獲取每小時、每天的Registry使用情況（json），將這些信息發送給相應的 GraphOps平臺，就能生成相應的圖像，發布到flowdock上。我們目前比較常用的指令，就是hubot graph me registry usage since 24 hours，hubot立刻會返回最近24小時內Registry的使用情況，包括pull/push的數量等。
          • </ul>

          對于ChatOps未來計劃

          • 目前hubot對于我們的Registry的運維還比較基礎，將來我們希望通過增 強hubot的運維能力（添加自動化腳本），來提高Registry的負載能力。例如通過hubot監測到Registry運行負載劇增，然后使用 hubot實施auto scaling來保證Registry運行穩定。

          • hubot可以作為連接和協同眾多獨立的微服務的一種橋梁， 擴展的便利性尤為重要，而目前手動編寫自定義的腳本不是特別方便。我們計劃在企業內開發一套圖形化擴展hubot的平臺，集成企業內常用的各種服務，包括 代碼管理服務（SVN、Git）、通知服務（郵件、Flowdock）和部署服務（企業私有云）。對于特有應用的服務，可以提供自定義腳本擴展。
            • </ul>

            使用Rancher實現Docker容器集群環境的部署和管理

            為什么使用Rancher

            我們需要一個平臺來 管理生產環境中的容器，Rancher是一個開源項目，使用起來非常簡單，容易上手，一方面Rancher提供UI，可視化創建開關容器，另一方面，當時 我們對docker-compose已有一定的了解，Rancher是支持標準化docker-compose.yml的。除此以外，Rancher實現 了跨主機的overlay network。基于以上考慮，我們采用Rancher，基本上滿足我們對于容器部署管理的需求。

            準備環境

            • 安裝Rancher的Server，其名為rancher/server的docker image，主要用于提供用戶界面、追蹤集群中容器狀態、meta data和容器的調度、處理API請求等。

            • 給 Rancher添加host，即在host上運行rancher/agent 這個docker image。Rancher的environment對應一個overlay network，把多個主機加入到一個environment中，Rancher根據資源和端口，自主調配容器在哪個主機上運行，每個容器將獲得一個 IP（10.42.0.0/16），容器之間是網絡聯通的。
              • </ul>

              Rancher進行部署

              • Rancher根據docker-compose.yml來部署容器，一個 docker-compose.yml定義的container cluster，在Rancher里，被稱為Stack。一個environment可以起多個Stack。對于docker compose中的link， Rancher有自己的Distributed DNS Service discovery的功能，根據link，生成service name對應IP的DNS record。Rancher也支持Docker volume, 并且提供其快照和備份的功能。我們通常還配有一個私有Registry，這樣部署的時候Rancher可以從私有Registry去pull image.

              • 與docker-compse.yml一起工作的有rancher-compose.yml，在rancher-compose.yml中定義service scale，即一個service的container數量。例如

                db:
scale: 2
                </li>

              • Rancher內置的load balancer，我們用來做流量的路由。例如，在docker-compose.yml中，有如下定義

                lb:
image: rancher/load-balancer-service
labels:
io.rancher.loadbalancer.target.service1: example.com:443/service1=3000
io.rancher.loadbalancer.target.service2: example.com:80/service2=5000
service1:
...
service2:
...

                意思是我們定義了一個lb的service，是rancher/load-balancer-service的image，labels中的內容則配置 lb的路由規則，即訪問example.com:443/service1，流量會被分發到service1，而example.com:80 /service2，流量被分發到service2。我們常常在一個envrionment中，指定一臺host，專門用于運行lb。然后，云服務上配置 DNS，使域名綁定到這個主機的IP。這樣無論如何部署，總可以很順利地通過域名來訪問這些服務。 </li>

              • 容器編排scheduling的功 能。Rancher允許用戶給每個host定義label，比如我們常常給專門來運行load balance的主機定義一個label是for=lb，如果要lb這個service一定在此主機上運行，那么可以在docker- compose.yml中這樣定義：

                lb:
labels:
io.rancher.scheduler.affinity:host_label: for=lb
                </li> </ul>
                Rancher有更多高級的scheduling規則編寫的功能，包括否定，軟指定等。
                io.rancher.scheduler.affinity:host_label_ne: for=lb指service一定不能在for=lb的host上運行。
                io.rancher.scheduler.affinity:host_label_soft: for=lb指service在條件允許的情況下盡量在for=lb的host上運行。

                • 可以從用戶界面上部署容器，Rancher自動生成docker-compose.yml，并且提供Service之間相互link的拓撲圖，如圖

                  搭建企業私有Docker Registry實戰分享
                  </li>

                • Rancher有rancher-compose命令行工具，方便容器部署自動化，與其他流程進行整合。
                  • </ul>

                  生產環境使用Rancher

                  • 發布新的image，可以用Rancher upgrade的功能，實現無縫更新。本質上Rancher啟動新的service，然后切換link到新的service。如果需要回滾，則可以很方便的切換回之前的service。

                  • Rancher對于主機和容器進行實時監控，通過用戶界面可以查看cpu和memory的使用情況。

                  • Service Health Check，是基于HAProxy開發的對于service狀態的監控。
                    • </ul>

                    目前發現的缺點

                    • 缺乏自主修復的功能。如果有些host無法和Rancher Server連接，Rancher無法重新調配container。
                      • </ul>

                      團隊

                      • 惠普企業RnD部門，從事DevOps及Docker的研究和相關工具的研發，開源社區貢獻者。

                      • 成員：李文權、林箐、王春陽。
                        • </ul>

                        Q&A

                        Q：目前有沒有嘗到監控Register運行和使用情況的好處，或者在維護私有Register有沒有遇到過什么問題？

                        A：能夠實時監控Registry，就能觀察用戶的行為，當我們在負載量很大的時候，能夠有效保持Registry穩定運行。維護私有的Registry的問題，就是要跟進官方的更新，看看是否也需要同步。
                        Q：Rancher 實際上是基于Docker的開源PaaS，基于容器技術的開源PaaS很多，比如Deis、Flynn等，但是Rancher跟這些項目不同的地方是，它 盡可能的和Docker生態圈工具兼容。請問當初為什么會選擇Rancher，在你看來，Rancher最吸引你的地方是什么？

                        A：Rancher的UI比較方便于上手和使用。而且Rancher的概念也更接近Docker compose，目前官方的文檔也比較齊全。
                        Q：Flowdock+Hubot這種方式下的監控是否必須用Sensu，是否支持采用zabbix作監控，Zabbix的遠程腳本可以實現一些自動重啟等等操作?

                        A：Sensu不是必須的，你可以使用你熟悉的監控服務，比如Zabbix。
                        Q：Flowdock+Hubot在一些安全性要求比較高的生產環境上是否可用，其發布的命令采用什么方式連接到容器\虛擬機或者主機上？要不要建立SSH免密碼連接之類的操作？

                        A：Hubot是拉取Flowdock的信息，所以Hubot可以部署在公司防火墻內。目前Hubot使用docker remote API來控制虛擬機上的容器。
                        Q：請教一下，Rancher可以理解為Compose的增強版嗎，特別是可視化部分？

                        Rancher自己有一套rancher-compose，提供load balance和auto scaling，可以算是Compose的增強版。可視化部分，是Rancher的一個Feature。
                        Q：Rancher的lb是用的HAProxy么？

                        A：是的。
                        Q：有沒有做過橫向比較，Kubernetes和Swarm+Compose，Rancher+Compose，在這幾種選擇間做過比較，或者說為什么最終選擇了Rancher？

                        A：最初是選擇Swarm+Compose，但是由于那個時候的Swarm不太穩定，有bug，集群管理工作不起來。Rancher部署方便，操作簡單，所以就用了它。
                        Q：Rancher的網絡具體是怎么做的呢？

                        A：據目前了解，是overlay模式。各主機之間采用IPsec Tunneling來實現通信，使用udp的500和4500端口。啟動時在各個主機部署容器之前啟動一個Network Agent管理容器網絡。具體可以參看文檔：docs.rancher.com
                        Q：rancher master如何實現的高可用？之前看了文檔搭建之后，cpu等監控圖無法顯示了

                        A：通過rancher-compose提供load balance和auto scaling實現高可用。監控圖無法顯示也是我們遇到的問題，目前正在解決。
                        Q：從描述看Rancher的網絡類似于weave吧，給每個容器分配固定IP，對集群規模比較大的或者IP地址段受限的似乎不太夠用？

                        A：從我們目前的經驗來看，的確有這樣的限制，如果有大規模集群的需求下，需要重新評估Rancher來管理和部署。
                        Q： Hubot是不是也支持非容器方式的部署，比如部署在虛擬機上？

                        A：可以，可以參照 https://hubot.github.com。
                        Q：Hubot使用docker remote API是否采用了安全策略，另外Docker Registry采用了何種安全策略？

                        A：Remote API使用了TLS驗證。目前我們的private registry使用了LDAP+token作為安全認證。
                        Q：在部署方面很重要的是動態伸縮和灰度發布，在這兩方面你們是怎么考慮的？Rancher在這兩個方面有支持嗎？

                        A：通過rancher-compose提供load balance和auto scaling實現動態伸縮。其他方面，還沒有考慮過。
                        Q：Rancher的管理數據是不是都放在了MySQL里面？MySQL需要搭建在物理機上嗎？

                        A：MySQL是rancher server自己提供的，無需手工部署。
                        Q：Rancher能支持云存儲嗎？

                        A：最新版本的Rancher對Docker volume插件有了支持，可以通過它來實現Container的數據存儲管理。
                        Q：請問你們實踐或了解到的基于Rancher的集群規模有多大？

                        A：目前我們的使用規模比較小，還沒有這方面的準確數據。
                        Q：從介紹看整個系統是搭建在OpenStack上的，采用Swift作為存儲，那Docker的部署是不是采用的nova-docker呢？容器是部署在物理機上還是虛機上的，如果是虛擬機采用的是哪種hypervisor，性能方面如何，有沒有做過相關的壓測？

                        A：Docker是部署在KVM的虛擬機上，使用的企業私有云平臺，目前沒有做過性能測試。
                        Q：Rancher 實際應用中有哪些要特別注意的問題，麻煩分享下？

                        A：Rancher版本更新快，較低的版本會有很多bug。
                        Q：有考慮過升級問題么？比如Registry從v1升級到v2？或者docker 升級到1.9？

                        A：目前我們使用的就是v2，使用rancher upgrade來升級。 升級Docker的成本較大，目前還沒有相關最佳實踐。
                        Q： Rancher中文資料多嘛，有推薦嘛？

                        A：目前我們看的都是官方英文文檔，這樣能看到最新的信息，中文文檔沒有關注。
                        ===========================================================
                        以上內容根據2015年11月24日晚微信群分享內容整理。 分享人： 李文權，去年開始參與關于OpenStack的項目forj，這是一個持續集成和分發的開源平臺。負責搭建公司內部使用的Docker Registry，跟Docker社區成員一起貢獻了OpenStack Swift作為Registry V2的代碼。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信： liyingjiesx，進群參與，您有想聽的話題可以給我們留言。

                        來自：http://dockone.io/article/852

 本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！