雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
在目前DevOps的趨勢下，持續內建（CI）和持續部署（CD）使得項目建構和釋出更加的快捷頻繁可靠，那麼如何快速搭建CI/CD流水線就至關重要，本次分享如何使用Ansible、Docker、GitLab Runner快速打造CI/CD工作流。
GitLab内置的CI/CD工具GitLab Runner
公司使用GitLab來管理代碼，GitLab在生态環境上提供gitlab-runner來實作CI/CD。
安裝搭建：下載下傳rpm包安裝，使用gitlab-runner指令注冊到GitLab上，并使用Docker執行器。gitlab-runner start啟動gitlab-runner服務。
使用：在項目根目錄下，建立檔案.gitlab-ci.yml，導入z_qz/cicd/templates/Maven.gitlab-ci.yml：
z_qz/cicd項目檔案結構：
Demo項目以Maven打包為例。
Demo有兩個流水線：build和deploy，并引入需要的操作步驟檔案：
在before-script.yml裡聲明了一些函數：
function maven_build() {
echo "maven build"
mvn clean package -U -Dmaven.test.skip=true
}
function gradle_build() {
echo "gradle build"
}
function download_docker_files() {
echo "download Dockerfile"
echo "download entrypoint.sh"
}
function docker_build() {
echo "[start] get docker args"
docker build --build-arg JAR_PATH=${JAR_PATH} --build-arg JAR_FILE=${JAR_FILE} --no-cache -t ${DOCKER_IMAGE} .
docker push ${DOCKER_IMAGE}
echo "[end] done"
}
function download_ansible_roles() {
echo "download site.yml"
echo "download ansible roles.tgz"
}
function notice() {
# 通知
msg="${message:-'太懶了，什麼都沒留下'}"
curl 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=企業微信機器人' \
-H 'Content-Type: application/json' \
-d "{
\"msgtype\": \"text\",
\"text\": {
\"content\": \"${msg}\"
}
}"
}
before_script:
- *function 在maven_build.yml檔案裡實作Maven和Docker打包，并上傳Docker鏡像到Harbor上：
打包階段： 當環境變量YPSX_STAGE == BUILD才會觸發build流水線，并且根據variables傳遞過來的JDK_VERSION來啟動Maven容器，進行maven package，docker build操作。
在deploy.yml檔案裡實作部署應用到目标機器上：
image: ansible:2.9.7
stage: deploy
tags:
deploy
only:
variables:
- $YPSX_STAGE == "DEPLOY"
script:
- notice # 通知： 誰釋出環境下的應用
- download_ansible_roles
- echo "$SSH_PRIVATE_KEY" >> ~/.ssh/id_rsa
- chmod 600 ~/.ssh/id_rsa
- ansible-playbook -i /etc/ansible/${ENV}_hosts -e hosts=${APP_NAME} -e DOCKER_IMAGE=${DOCKER_IMAGE} -e APP_NAME=${APP_NAME} \
-e JAR_FILE=${JAR_FILE} -e SPRING_PROFILES_ACTIVE=${SPRING_PROFILES_ACTIVE} -t java site.yaml SSH_PRIVATE_KEY變量參數在項目組裡配置（可作用于組下面所有項目）：
組-> settings->CI/CD -> Variables
一些安全系數要求高的參數，可以在這邊設定，像Harbor賬戶密碼。
Docker&Harbor（私有Hub）
在maven package生成JAR檔案，然後Docker将jar檔案打包成應用鏡像，上傳到Harbor。
在Dockerfile裡用了ARG，從docker build --build-arg裡擷取參數進行JAR檔案路徑和JAR檔案替換，docker build找到JAR檔案路徑，拷貝JAR到鏡像，制作應用鏡像。
這邊使用Harbor，使用docker-compose指令，就能安裝啟動，非常友善，以及提供鏡像清理。
Ansible自動化運維工具
Ansible通過SSH管理目标機器，機器資訊（inventory）使用該格式/etc/ansible/{env}_hosts管理各個環境機器。
使用ansible roles管理釋出過程：
check檢查Agent和Logspout容器是否存在（docker_container_info new in ansible 2.8）：
install_agent和install_logspout是應用安裝前的初始化：
install_app安裝更新APP，優雅關閉，檢查服務狀态，銷毀應用容器，啟動應用容器，檢查應用是否啟動成功：
釋出系統
前端使用antd-pro。
後端使用Golang Gin開發審批流程和批次釋出等。
通過調用GitLab API建立Pipeline觸發流水線。
--header "Content-Type: application/json" \
--data '{ "ref": "test", "variables": [{"key": "YPSX_STAGE", "value":"BUILD"}, {"key": "JDK_VERSION", "value": "11"}] }' \
"https://gitlab.example.com/api/v4/projects/99/pipeline" 在Variables裡傳遞：
還可以指定build流水線的鏡像，這邊傳遞JDK_VERSION=11。
鏡像将使用Maven：3.6.3-jdk-11。
在沒有Web管理系統前，我們可以騷氣地操作，git tag dev_xxx針對目前的tag代碼，打包、釋出到dev環境：
Q&A
Q：有對照過Jenkins，Drone等其他CI/CD工具嗎，出于什麼考慮最後選擇gitlab-runner，未來有考慮過Kubernetes這方面的內建嗎？
A：gitlab-runner，Jenkins，Drone都屬于配置即操作的工具，因為使用GitLab來管理代碼，gitlab-runner又很好貼近GitLab，維護成本也不高，類似Jenkins的Node，安裝注冊，就能拿來用。 正在引入Kubernetes中。
Q：從鏡像到部署到Kubernetes，是通過什麼實作的，kubectl還是鏡像更新觸發？在這個過程中能不能調整一些deployment的配置，比如resource.cpu.request或者Ingress的一些配置？
A：這邊，現在沒有使用Kubernetes（二季度将引入Kubernetes），隻将應用Docker鏡像，釋出到目标機器上，如果引入Kubernetes，将開發調用Kubernetes的API server接口，傳遞yaml配置檔案。
Q：對于項目是如何進行部署檢測的？對tag進行監聽嗎？
A：在項目根目錄下添加配置檔案.gitlab-ci.yml，有only和except數組，支援branch，tag，環境變量，MR，檔案變動（像README.md）。
Q：相比Jenkins如何？
A：輕量些，GitLab就是Server端，gitlab-runner就是節點。不需要配置git clone。
Q：産品代碼疊代送出中，如何差別正常的合并代碼、以及建構請求呢
A：建構請求時，是讓開發選擇要釋出的分支，進行打包釋出。
Q：gitlab-ci.yml放在根目錄下， 是否會增加維護成本。這些檔案的改動是業務研發修改，還是專人維護呢？
A：.gitlab-ci.yml四行代碼，就這四行固定，加到項目腳手架裡，沒有維護成本，通過include cicd項目，運維在cicd項目裡進行維護打包和釋出操作代碼，對業務代碼，零影響。
Q：請問自動化測試準備怎麼加入呢？
A：釋出成功後，調用自動化測試平台API。
Q：針對GitLab Runner是要驅動整個産品的研發去觸發CI/CD吧，對于不懂Docker及Kubernetes yaml文法的同僚，怎麼讓他們接受新的釋出體系及使用呢？
A：.gitlab-ci.yml的文法是運維寫好的，開發隻要在頁面上點選釋出，釋出系統觸發。
Q：請問有沒有高并發拉取鏡像的問題？有沒有遇到過在高并發下GitLab性能下降的問題？
A：Harbor（機器配置偏低）遇到過高并發拉取問題，在一次大量遷移的時候，沒有按批次操作，平常開發釋出，Harbor完全可以勝任，高并發下對GitLab影響不大，GitLab主要還是觸發gitlab-runner去運作打包和釋出，gitlab-runner機器配置稍微高些，因為除了Java的Maven和Gradle，我這邊還将Node打包也內建在這個項目裡。
Q：詳細介紹一下灰階釋出是怎麼做的吧，例如兩次發版資料庫結構不一緻，是如何做釋出和復原的，流量怎麼分發到新舊版的？
A：釋出前，更新資料庫結構版本，先執行資料庫結構變更（淩晨）；
復原：将資料庫結構復原，應用retry上一次釋出記錄；流量通過網關配置。
Q：公司目前就20來個開發，适合自己搞這套嗎？
A：如果你們還在手動釋出的話，建議你們使用gitlab-runner，可以使用git tag方式，釋出，我們也是一步一步走過來的，先前沒有釋出系統，開發使用打tag方式釋出，這個沒有限制看開發個人，後面開發了套釋出系統，在上面做了工作流管理。
Q：釋出系統權限怎麼控制的？
A：分應用開發和應用Onwer，RBAC。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-06-03
本文作者：Andy_Lee
本文來自：“
dockone”，了解相關資訊可以關注“dockone”