摘要:所以我們選一個(gè)倉庫倉庫比較多,我這里選用,都行,根據(jù)需求自行選擇訪問端口,然后就沒有然后了功能沒有那么強(qiáng)大,不過占用資源少,速度快,我們穩(wěn)定運(yùn)行了幾年了。
kubernetes集群三步安裝 CI 概述 用一個(gè)可描述的配置定義整個(gè)工作流
程序員是很懶的動(dòng)物,所以想各種辦法解決重復(fù)勞動(dòng)的問題,如果你的工作流中還在重復(fù)一些事,那么可能就得想想如何優(yōu)化了
持續(xù)集成就是可以幫助我們解決重復(fù)的代碼構(gòu)建,自動(dòng)化測試,發(fā)布等重復(fù)勞動(dòng),通過簡單一個(gè)提交代碼的動(dòng)作,解決接下來要做的很多事。
容器技術(shù)使這一切變得更完美。
典型的一個(gè)場景:
我們寫一個(gè)前端的工程,假設(shè)是基于vue.js的框架開發(fā)的,提交代碼之后希望跑一跑測試用例,然后build壓縮一個(gè)到dist目錄里,再把這個(gè)目錄的靜態(tài)文件用nginx代理一下。
最后打成docker鏡像放到鏡像倉庫。 甚至還可以增加一個(gè)在線上運(yùn)行起來的流程。
現(xiàn)在告訴你,只需要一個(gè)git push動(dòng)作,接下來所有的事CI工具會幫你解決!這樣的系統(tǒng)如果你還沒用上的話,那請問還在等什么。接下來會系統(tǒng)的向大家介紹這一切。
代碼倉庫管理首先SVN這種渣渣軟件就該盡早淘汰,沒啥好說的,有g(shù)it真的沒有SVN存在的必要了我覺得。
所以我們選一個(gè)git倉庫,git倉庫比較多,我這里選用gogs,gitea gitlab都行,根據(jù)需求自行選擇
docker run -d --name gogs-time -v /etc/localtime:/etc/localtime -e TZ=Asia/Shanghai --publish 8022:22 --publish 3000:3000 --volume /data/gogs:/data gogs:latest
訪問3000端口,然后就沒有然后了
gogs功能沒有那么強(qiáng)大,不過占用資源少,速度快,我們穩(wěn)定運(yùn)行了幾年了。缺點(diǎn)就是API不夠全。
當(dāng)你用過drone之后。。。
裝:
version: "2" services: drone-server: image: drone/drone:0.7 ports: - 80:8000 volumes: - /var/lib/drone:/var/lib/drone/ restart: always environment: - DRONE_OPEN=true - DOCKER_API_VERSION=1.24 - DRONE_HOST=10.1.86.206 - DRONE_GOGS=true - DRONE_GOGS_URL=http://10.1.86.207:3000/ # 代碼倉庫地址 - DRONE_SECRET=ok drone-agent: image: drone/drone:0.7 command: agent restart: always depends_on: - drone-server volumes: - /var/run/docker.sock:/var/run/docker.sock environment: - DOCKER_API_VERSION=1.24 - DRONE_SERVER=ws://drone-server:8000/ws/broker - DRONE_SECRET=ok
docker-compose up -d 然后你懂的,也沒有然后了
用gogs賬戶登錄drone即可
每個(gè)步驟就是個(gè)容器,每個(gè)插件也是個(gè)容器,各種組合,簡直就是活字印刷術(shù)
怎么使用這種初級膚淺的內(nèi)容我就不贅述了,但是有很多坑的地方:
裝drone的機(jī)器能用aufs盡量用,device mapper有些插件是跑不了的,如一些docker in docker的插件,這不算是drone的毛病,只能說docker對 docker in docker支持不夠好
centos對aufs支持不夠好,如果想用centos支持aufs,那你可得折騰折騰了,社區(qū)方案在此:https://github.com/sealyun/ke...
最推薦的是drone的機(jī)器內(nèi)核升級到4.9以上,然后docker使用overlay2存儲驅(qū)動(dòng),高版本內(nèi)核跑容器筆者也實(shí)踐過比較長的時(shí)間了,比低內(nèi)核穩(wěn)定很多
安裝方式2,在k8s上安裝:
helm install stable/drone使用篇
首先在你的代碼倉庫主目錄下新建三個(gè)文件:
.drone.yml : 描述構(gòu)建與部署的流程(狹義),流程配置文件(廣義)CI/CD無本質(zhì)區(qū)別
Dockerfile : 告訴你的應(yīng)用如何打包成鏡像,當(dāng)然如果不是容器化交付可以不需要
k8s yaml配置文件 or docker-compose文件 or chart包 :告訴你的應(yīng)用如何部署
其他 :如kube-config等
用gogs賬戶密碼登錄到drone頁面上之后同步下項(xiàng)目就可以看到項(xiàng)目列表,打開開關(guān)就可以關(guān)聯(lián)到git倉庫,比較簡單,自行探索
pipeline: backend: # 一個(gè)步驟的名稱,可以隨便全名 image: golang # 每個(gè)步驟的本質(zhì)都是基于這個(gè)鏡像去啟動(dòng)一個(gè)容器 commands: # 在這個(gè)容器中執(zhí)行一些命令 - go get - go build - go test frontend: image: node:6 commands: - npm install - npm test publish: image: plugins/docker repo: octocat/hello-world tags: [ 1, 1.1, latest ] registry: index.docker.io notify: image: plugins/slack channel: developers username: drone
各步驟啟動(dòng)的容器共享workdir這個(gè)卷, 這樣build步驟的結(jié)果產(chǎn)物就可以在publish這個(gè)容器中使用
結(jié)合Dockerfile看:
# docker build --rm -t drone/drone . FROM drone/ca-certs EXPOSE 8000 9000 80 443 ENV DATABASE_DRIVER=sqlite3 ENV DATABASE_CONFIG=/var/lib/drone/drone.sqlite ENV GODEBUG=netdns=go ENV XDG_CACHE_HOME /var/lib/drone ADD release/drone-server /bin/ # 因?yàn)楣ぷ髂夸浌蚕恚跃涂梢栽趐ublish時(shí)使用到 build時(shí)的產(chǎn)物,這樣構(gòu)建和發(fā)布就可以分離 ENTRYPOINT ["/bin/drone-server"]
上面說到構(gòu)建與發(fā)布分離,很有用,如構(gòu)建golang代碼時(shí)我們需要go環(huán)境,但是線上或者運(yùn)行時(shí)其實(shí)只需要一個(gè)可執(zhí)行文件即可,
所以Dockerfile里就可以不用FROM一個(gè)golang的基礎(chǔ)鏡像,讓你的鏡像更小。又比如java構(gòu)建時(shí)需要maven,而線上運(yùn)行時(shí)不需要,
所以也是可以分離。
用drone時(shí)要發(fā)揮想象,千萬不要用死了,上面每句話都需要仔細(xì)讀一遍,細(xì)細(xì)理解。再總結(jié)一下關(guān)鍵點(diǎn):
drone自身是不管每個(gè)步驟是什么功能的,只傻瓜式幫你起容器,跑完正常就執(zhí)行下個(gè)步驟,失敗就終止。
編譯,提交到鏡像倉庫,部署,通知等功能都是由鏡像的功能,容器的功能決定的 drone里叫插件,插件本質(zhì)就是鏡像,有一丟丟小區(qū)別后面說
這意味著你想干啥就弄啥鏡像,如編譯時(shí)需要maven,那去做個(gè)maven鏡像,部署時(shí)需要對接k8s,那么搞個(gè)有kubectl客戶端的鏡像;要物理機(jī)部署那么搞個(gè)
ansible的鏡像,等等,發(fā)揮想象,靈活使用。
有時(shí)我們希望CI出來的docker鏡像tag與git的tag一致,這樣的好處就是知道運(yùn)行的是哪個(gè)版本的代碼,升級等等都很方便,不過每次都去修改pipeline
文件顯然很煩,那么drone就可以有很多環(huán)境變量來幫助我們解決這個(gè)問題:
pipeline: build: image: golang:1.9.2 commands: - go build -o test --ldflags "-linkmode external -extldflags "-static"" when: event: [push, tag, deployment] publish: image: plugins/docker repo: fanux/test tags: ${DRONE_TAG=latest} dockerfile: Dockerfile insecure: true when: event: [push, tag, deployment]
這個(gè)例子${DRONE_TAG=latest} 如果git tag事件觸發(fā)了pipeline那就把git tag當(dāng)鏡像tag,否則就用latest,這樣我們自己研發(fā)過程中就
可以一直用latest迭代,覺得版本差不多了,打個(gè)tag,生成一個(gè)可以給測試人員測試的鏡像,非常優(yōu)雅,不需要改什么東西,不容易出錯(cuò)
同理還有很多其它的環(huán)境變量可以用,如git的commitID 分支信息等等, 這里可以查
對接k8s實(shí)踐首先得有個(gè)k8s集群,那么首選:kubernetes集群三步安裝 廣告,無視就好。。。
有了上面的鋪墊,對接k8s就相當(dāng)簡單了:搞個(gè)kubectl的鏡像嵌入流程中即可:
把項(xiàng)目的k8s yaml文件放到代碼中,然后pipelie里直接apply
publish: image: plugins/docker # 鏡像倉庫,執(zhí)行Dockerfile插件 tags: - ${DRONE_TAG=latest} insecure: true # 照抄 deploy: image: kubectl:test # 這個(gè)鏡像自己去打即可 commands: - cat test.yaml - ls - rm -rf /root/.kube && cp -r .kube /root # k8s 的kubeconfig文件,可以有多個(gè),部署到哪個(gè)集群就拷貝哪個(gè)kubeconfig文件 - kubectl delete -f test.yaml || true - kubectl apply -f test.yaml
不過最佳實(shí)踐還有幾個(gè)細(xì)節(jié):
k8s 的kubeconfig文件同樣放在了代碼目錄(這個(gè)不太安全,不過倉庫私有還好,還可以利用drone的secret,不細(xì)展開)
k8s 部署的yaml文件里的鏡像怎么配置? 每次都修改test.yaml多不爽
如果多個(gè)集群yaml配置有區(qū)別怎么辦?寫多個(gè)yaml?造成混亂,非常不優(yōu)雅
所以我們引入chart, 用helm進(jìn)行部署:
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: test namespace: {{ .Values.namespace }} spec: replicas: {{ .Values.replicaCount }} template: metadata: labels: name: test spec: serviceAccountName: test containers: - name: test image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" # deployment的yaml文件是模板,創(chuàng)建時(shí)再傳參進(jìn)來渲染 imagePullPolicy: {{ .Values.image.pullPolicy }} ....
注意,有了模板之后,我們部署v1版本和v2版本時(shí)就不需要改動(dòng)yaml文件,這樣降低出錯(cuò)風(fēng)險(xiǎn),pipeline執(zhí)行時(shí)把環(huán)境變量傳進(jìn)來,完美解決
這樣git tag 鏡像tag與yaml里鏡像配置實(shí)現(xiàn)了完全的統(tǒng)一:
deploy_dev: # 部署到開發(fā)環(huán)境 image: helm:v2.8.1 commands: - mkdir -p /root/.kube && cp -r .kube/config-test101.194 /root/.kube - helm delete test --purge || true - helm install --name test --set image.tag=${DRONE_TAG=latest} Chart when: event: deployment environment: deploy_dev deploy_test: # 部署到測試環(huán)境 image: helm:v2.8.1 commands: - mkdir -p /root/.kube && cp -r .kube/config-test101.84 /root/.kube # 兩個(gè)環(huán)境使用不同的kubeconfig - helm delete test --purge || true - helm install --name test --set image.tag=${DRONE_TAG=latest} Chart # 把git tag傳給helm,這樣運(yùn)行的鏡像就是publish時(shí)構(gòu)建的鏡像,tag一致 when: event: deployment environment: deploy_test
以上,優(yōu)雅的解決了上面問題
細(xì)節(jié):event可以是git的事件也可以是手動(dòng)處罰的事件,類型是deployment時(shí)就是手動(dòng)觸發(fā)的,drone支持命令行觸發(fā)
我們進(jìn)行了二次開發(fā),讓drone可以在頁面上觸發(fā)對應(yīng)的事件
原理篇drone上開通一個(gè)倉庫時(shí),會給倉庫設(shè)置一個(gè)webhook,在項(xiàng)目設(shè)置里可以看到,這樣git的事件就可以通知到drone,drone根據(jù)事件去拉取代碼走流程
pipeline基本原理理解原理對使用這個(gè)系統(tǒng)非常重要,否則就會把一個(gè)東西用死。
pipeline就負(fù)責(zé)起容器而已,容器干啥的系統(tǒng)不關(guān)心,用戶決定 這句話本文不止強(qiáng)調(diào)過一次,非常重要多讀幾遍
插件原理鏡像即插件,也就是可能現(xiàn)有很多鏡像都能直接當(dāng)作插件嵌入到drone流程中。
有個(gè)小區(qū)別是,你會發(fā)現(xiàn)drone有些插件還帶一些參數(shù),這就是比普通的鏡像多做了一丟丟事,如publish時(shí)打docker的鏡像:
publish: image: plugins/docker repo: octocat/hello-world tags: [ 1, 1.1, latest ] registry: index.docker.io
你會發(fā)現(xiàn)它有 repo tags什么的參數(shù),其實(shí)drone處理時(shí)非常簡單,就是把這些參數(shù)轉(zhuǎn)化成環(huán)境變量傳給容器了,
然后容器去處理這些參數(shù)。
本質(zhì)就是做了這個(gè)事情:
docker run --rm -e PLUGIN_TAG=latest -e PLUGIN_REPO=octocat/hello-world -e DRONE_COMMIT_SHA=d8dbe4d94f15fe89232e0402c6e8a0ddf21af3ab -v $(pwd):$(pwd) -w $(pwd) --privileged plugins/docker --dry-run
那我們自定義一個(gè)插件就簡單了,只要寫個(gè)腳本能處理特定環(huán)境變量即可,如一個(gè)curl的插件:
pipeline: webhook: image: foo/webhook url: http://foo.com method: post body: | hello world
寫個(gè)腳本
#!/bin/sh curl -X ${PLUGIN_METHOD} # 處理一個(gè)幾個(gè)環(huán)境變量 -d ${PLUGIN_BODY} ${PLUGIN_URL}
FROM alpine ADD script.sh /bin/ RUN chmod +x /bin/script.sh RUN apk -Uuv add curl ca-certificates ENTRYPOINT /bin/script.sh
docker build -t foo/webhook . docker push foo/webhook
打成docker鏡像,大功告成
所以大部分情況我們會很懶的什么也不寫,直接在容器里執(zhí)行命令就是了,同樣是一個(gè)curl的需求,不寫插件的話
pipeline: webhook: image: busybox # 直接用busybox command: - curl -X POST -d 123 http://foo.com 完事,插件都懶得開發(fā)了
值得注意的是一些復(fù)雜功能還是需要開發(fā)插件的,如publish鏡像時(shí)用的插件。關(guān)于該插件我想補(bǔ)充一句
它是docker里面起了一個(gè)docker engine,用docker內(nèi)的docker engine進(jìn)行打鏡像的
所以devicemapper存儲驅(qū)動(dòng)是支持不了的。請升級內(nèi)核用overlay2,或者ubuntu用aufs
鏡像倉庫:harbor
制品庫:nexus 做maven倉庫,yum倉庫放二進(jìn)制文件等非常合適,強(qiáng)烈推薦
總結(jié)要實(shí)現(xiàn)高效的自動(dòng)化,everything as code很重要,很多人喜歡在界面上點(diǎn)點(diǎn)點(diǎn) 填很多參數(shù)上線,其實(shí)是一種很容易出錯(cuò)的方式
不一定能提高效率。 你們項(xiàng)目如何構(gòu)建,如何發(fā)布,如何部署都應(yīng)該是代碼,沒有二義性,把人做的事讓程序做,最終人僅是觸發(fā)而已。
個(gè)人見解,探討可加QQ群:98488045
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/32735.html
摘要:集成測試完成后,由運(yùn)維同學(xué)從發(fā)起一個(gè)到分支,此時(shí)會會運(yùn)行單元測試,構(gòu)建鏡像,并發(fā)布到預(yù)發(fā)布環(huán)境測試人員在預(yù)發(fā)布環(huán)境下再次驗(yàn)證功能,團(tuán)隊(duì)做上線前的其他準(zhǔn)備工作運(yùn)維同學(xué)合并,將為本次發(fā)布的代碼及鏡像自動(dòng)打上版本號并書寫,同時(shí)發(fā)布到生產(chǎn)環(huán)境。 云原生 (Cloud Native) 是伴隨的容器技術(shù)發(fā)展出現(xiàn)的的一個(gè)詞,最早出自 Pivotal 公司(即開發(fā)了 Spring 的公司)的一本技術(shù)小...
摘要:集成測試完成后,由運(yùn)維同學(xué)從發(fā)起一個(gè)到分支,此時(shí)會會運(yùn)行單元測試,構(gòu)建鏡像,并發(fā)布到預(yù)發(fā)布環(huán)境測試人員在預(yù)發(fā)布環(huán)境下再次驗(yàn)證功能,團(tuán)隊(duì)做上線前的其他準(zhǔn)備工作運(yùn)維同學(xué)合并,將為本次發(fā)布的代碼及鏡像自動(dòng)打上版本號并書寫,同時(shí)發(fā)布到生產(chǎn)環(huán)境。 云原生 (Cloud Native) 是伴隨的容器技術(shù)發(fā)展出現(xiàn)的的一個(gè)詞,最早出自 Pivotal 公司(即開發(fā)了 Spring 的公司)的一本技術(shù)小...
摘要:內(nèi)部長期使用來管理代碼。審核通過并且成功后,觸發(fā)靜態(tài)測試單元測試鏡像構(gòu)建鏡像部署集成測試等測試通過后,創(chuàng)建一個(gè)從到的,由負(fù)責(zé)人進(jìn)行審核。從圖中我們可以看到,部分是一個(gè)單元測試,預(yù)發(fā)布部署,集成測試,,提交代碼的循環(huán)過程。UCloud內(nèi)部長期使用 Gitlab 來管理代碼。雖然Gitlab作為一套開源平臺已很優(yōu)秀,但我們對于其能為CI/CD提供的敏捷性并不十分滿意,內(nèi)部實(shí)踐中的代碼發(fā)布周期仍需...
摘要:在貓屎氤氳的霧氣里角仰望天花板,手機(jī)微信提醒這次構(gòu)建成功或失敗,并附帶污言穢語。這時(shí)他可以開始往工位走,坐下時(shí),微信又會提醒本次部署到成功或失敗。與企業(yè)微信的集成在決定使用之前,需要知道的是,是一個(gè)高度依賴社區(qū)的項(xiàng)目。 前言 相信我,一切事情的發(fā)生都是趕鴨子上架,沒有例外。人類所有偉大的變革都是迫不得已,可又是那么順其自然。比如容器(docker)技術(shù)的誕生,比如箭在弦上的創(chuàng)業(yè),比如野...
摘要:容器云將支持應(yīng)用的一鍵式部署交付,提供負(fù)載均衡,私有域名綁定,性能監(jiān)控等應(yīng)用生命周期管理服務(wù)。本容器云平臺,對接持續(xù)集成發(fā)布系統(tǒng)。 前言 在移動(dòng)互聯(lián)網(wǎng)時(shí)代,新的技術(shù)需要新技術(shù)支持環(huán)境、新的軟件交付流程和IT架構(gòu),從而實(shí)現(xiàn)架構(gòu)平臺化,交付持續(xù)化,業(yè)務(wù)服務(wù)化。容器將成為新一代應(yīng)用的標(biāo)準(zhǔn)交付件,容器云將幫助企業(yè)用戶構(gòu)建研發(fā)流程和云平臺基礎(chǔ)設(shè)施。縮短應(yīng)用向云端交付的周期,降低運(yùn)營門檻。加速向互...
閱讀 2582·2021-11-18 10:02
閱讀 1715·2021-09-30 10:00
閱讀 5333·2021-09-22 15:27
閱讀 1215·2019-08-30 15:54
閱讀 3677·2019-08-29 11:13
閱讀 2953·2019-08-29 11:05
閱讀 3329·2019-08-29 11:01
閱讀 576·2019-08-26 13:52