容器化的 DevOps 工做流

對於 devops 來講,容器技術絕對是咱們笑傲江湖的法寶。本文經過一個小 demo 來介紹如何使用容器技術來改進咱們的 devops 工做流。html

devops 的平常工做中不免會有一些繁瑣的重複性勞動。好比管理 Azure 上的各類資源,咱們會使用 Azure CLI 工具。同時咱們也會使用 Ansible 完成一些自動化的任務。當咱們同時使用兩者的時候就會碰到一些尷尬的事情:Azure CLI 依賴的 python 版本爲 3.x,而 Ansible 的主流版本還在依賴 python 2.x。若是咱們要同時使用兩者,就須要在環境中搞一些飛機。若是團隊中的每一個成員都須要使用這樣的工具,那麼每一個人的環境中都須要這些飛機!下面是一些比較相似的問題:python

  • 一些工做流在陌生的環境中不能正確的工做
  • 在工做流中加入新的工具時,整個團隊都須要獲取並安裝這些新的工具
  • 運行 devops 工做流不能對當前的環境產生影響(應該容許在 build 環境中運行 devops 工做流)
  • 工做流的變化不會對運行環境產生任何的影響

實現這些需求的最好方式就是容器技術!經過容器把咱們的 devops 工做流和運行環境隔離開就能夠了。文本的 demo 會演示一個很是簡單的使用 Azure CLI 的工做流,咱們的目標是爲整個團隊打造一個知足以上需求的工具集(容器鏡像)。其大致步驟以下:docker

  • 建立構造容器鏡像的 Dockerfile 文件
  • 在本地構建容器鏡像並進行測試
  • 對容器鏡像不斷的升級完善
  • 把容器鏡像分享給整個團隊

構建容器鏡像

讓咱們使用 Dockerfile 來建立本身的容器鏡像。先建立目錄 cazurecli,並在目錄下建立 Dockerfile 文件:瀏覽器

$ mkdir cazurecli
$ cd cazurecli
$ touch Dockerfile

編輯 Dockerfile 文件的內容以下:bash

FROM microsoft/azure-cli:latest
CMD bash

其中的 FROM 指令用來指定 base 鏡像,這裏咱們直接使用了微軟提供的 azrue-cli 鏡像,只是把容器啓動時執行的命令經過 CMD 指令設置爲 bash。服務器

而後執行下面的命令構建容器:函數

$ docker build -t azcli .

上圖的輸出顯示容器鏡像構建成功,咱們能夠經過 azcli:latest 來引用新構建的容器鏡像。那就讓咱們啓動容器並執行 azure cli 命令:工具

$ docker run --rm -it azcli:latest

進入容器中的命令行後,嘗試經過 az account list 查看 azure 帳號信息:測試

bash-4.3# az account list

紅框中的信息是提示咱們先經過 az login 命令登陸才能查看帳號信息:ui

bash-4.3# az login

而後按照提示信息打開瀏覽器,輸入驗證碼進行登陸。在瀏覽器中登陸完成後命令行上的登陸過程也隨之完成,而後從新執行 az account list 命令:

這樣就能夠輸出你的帳號信息了。

解決 Azure CLI 的登陸問題

若是你實驗了 az login 命令,就會發現登陸的過程仍是挺繁瑣的,若是每次啓動容器都須要執行登陸操做你會怎麼想呢?確定是弱爆了!
好在咱們能夠經過 bind mount 的方式把 azure 的登陸信息保存在 host 的文件中。之後啓動容器時掛載這些登陸信息就能夠了。下面是具體的步驟。
先在用戶的家目錄中建立 .azure 目錄:

$ mkdir ${HOME}/.zaure

而後啓動一個容器並以 bind 的模式掛載 .azure 目錄:

$ docker run --rm -it --mount type=bind,source=${HOME}/.azure,target=/root/.azure azcli

在容器中進行一次登陸操做:

# az login

登陸完成後,登陸的信息被保存到了 /root/.azure 目錄中:

退出當前的容器,執行下面的命令建立一個新的容器:

$ docker run --rm -it --mount type=bind,source=${HOME}/.azure,target=/root/.azure azcli

而後再執行一次 az account list 命令試試,此次就不須要登陸了!
注意:即使這樣也不是一勞永逸的,默認的登陸信息過時時間爲兩週,到時候你須要再次進行登陸。

添加自定義的工做流

對於一名 devops 工程師來講,咱們在 azure 上的操做可能是一些枯燥的重複動做。
好比:

  • Start/Stop/Deallocate/Restart 數量衆多的虛機
  • 檢查大量的虛機狀態
  • 拿到 IP 地址後查出對應的主機名稱等等

其實咱們能夠把這樣的功能進行封裝,從而簡化具體的操做。下面咱們舉個簡單的例子,就是把查詢 ResourceGroup 和虛機的操做封裝成 bash 中的函數。先在 cazurecli 目錄下建立 scripts 目錄:

$ mkdir scripts

而後在 scripts 目錄下建立 search.sh 文件:

$ touch scripts/search.sh

編輯 search.sh 文件的內容以下:

#!/bin/bash

# search for Resource Group by name
function search-group () {
    query=$1
    az group list --query "[?name | contains(@,'$query')].{ResourceGroup:name}" -o table
}

# search for VM by name
function search-vms () {
    query=$1
    az vm list --query "[?name | contains(@,'$query')].{ResourceGroup:resourceGroup,Name:name}" -o table
}

在這段腳本中咱們定義了兩個函數,分別是經過名稱來查詢 ResourceGroup 和虛機(要了解相關的查詢語法,請參考 az 命令)。
下面咱們把 search.sh 腳本集成到容器的鏡像中,並把腳本中的函數導入到 bash,編輯 Dockerfile 以下:

FROM microsoft/azure-cli:latest
COPY scripts/ scripts/
RUN echo -e "\
; for f in /scripts/*; \
do chmod a+x \${f}; source \${f}; \
done;" >> ~/.bashrc

CMD bash

用新的 Dockerfile 從新構建容器鏡像:

$ docker build -t azcli .

建立容器並嘗試使用 search-group 和 search-vms 函數:

$ docker run --rm -it --mount type=bind,source=${HOME}/.azure,target=/root/.azure azcli
bash-4.3# search-group learnrg
bash-4.3# search-vms testdesktop

這樣用起來是否是簡便不少了!若是咱們把經常使用的操做都寫成腳本封裝起來,是否是就可以打造一系列的自動化工做流了!

把鏡像放在 docker hub 上進行共享

demo 雖小,但咱們仍是要完成一個完整的用例的最後一步,就是在整個團隊中分享上面建立的容器化工做流。具體的作法大概有兩種:

  • 經過 dockerhub 等第三方平臺分享容器鏡像
  • 在公司內搭建內部使用的鏡像管理平臺

兩種方式都很方便,喜歡第二種方式的朋友能夠參考筆者的博文《局域網內部署 Docker Registry》。這裏只簡單的介紹一下 dockerhub 的用法。首先你須要去 dockerhub 的官網註冊一個帳號,註冊後建立一個 repository,好比筆者的用戶名爲 ljfpower,新建立的 repository 名稱爲 azcli。而後須要在本地經過 docker login 命令進行登陸。登陸後爲本地的容器鏡像建立一個 tag,好比:

$ docker tag azcli ljfpower/azcli

最後一步即是把這個 tag 標識的容器鏡像推送到 dockerhub 上去:

$ docker push ljfpower/azcli:latest

推送完成後你會在 dockerhub 上看到你的鏡像:

簡單起見筆者使用的是公有鏡像,也就是任何人均可如下載使用該鏡像。因此你只須要一條 pull 命令就能夠享受別人分享的工做流了:

$ docker pull ljfpower/azcli

總結

咱們打造了一個工具包,並把它容器化了。所以任何的團隊成員均可以經過容器在本身的環境中無差異的運行這些工做流。
這就是生產力呀!由於沒人會再抱怨:"這個工具配置起來好惡心","爲何在個人機器上運行不了 xxx" ...
同時,若是須要,你能夠在任何環境中運行這些工做流,好比構建產品的服務器上,由於運行這些工做流並不須要安裝額外的工具(python、azure cli 等)。
本文的名字起的很大而 demo 很小,權當拋磚引玉了!

參考:
Dockerize DevOps Workflows

相關文章
相關標籤/搜索