資訊專欄INFORMATION COLUMN
該過程中用到的技術棧git gitlab shell
需要提前準備的內容
一個項目myweb
本機安裝Git
一個Gitlab倉庫
docker私有倉庫
gitlab runner(Gitlab-runner)
公司的代碼一般都保存在私有化部署的Gitlab，要使用Gitlab的CI/CD，需要Gitlab版本>8.0.0
CI/CD雖然不難，但配置過程中有很多坑，而且有些要了解的概念也比較多，可以分成多個步驟，逐一攻破。
gitlab-runner需要提前進行安裝和注冊，詳情
進入Gitlab->CICD->Runner 當前可用的runner有
如圖所示，該項目可用的runner
左邊runner僅可以為當前項目使用，但需要激活一下。
右邊為共享的runner, 可以直接使用
.gitlab-ci.yml中以tags和runner的tags關聯(lián)
首先在項目的根目錄下新建.gitlab-ci.yml，然后在該文件中配置pipeline的任務，這些任務將會跑在gitlab-runner中。
一個最簡單的.gitlab-ci.yml文件，其中CI_COMMIT_BRANCH、GITLAB_USER_LOGIN是一些gitlab定義好的變量，可以直接使用，你也可以定義自己的變量
image: "node" stages: - BuildImage before_script: - echo "before_script" - echo "This job deploys something from the $CI_COMMIT_BRANCH branch." - echo "Hello, $GITLAB_USER_LOGIN!" build: tags: - test stage: BuildImage image: "node" script: - node -v 復制代碼
推送Git倉庫
git add .gitlab-ci.yml git commit -m "commit ci" git push 復制代碼
進入gitlab-> CI/CD頁面，可以看到一個pipeline狀態(tài)是stuck，這是因為沒有Gitlab-runner。
修改.gitlab-ci.yml，僅展示部分
build: # tags,代表要使用的runner,這里改成uaek-c1 tags: - uaek-c1 stage: BuildImage image: "node" script: - node -v 復制代碼
提交代碼，進入CI/CD頁面看到新增了一條pipeline執(zhí)行完成
點擊新的記錄，可以看到對應的Stage，點擊當前任務
可以看到Gitlab-runner執(zhí)行.gitlab-ci.yml的具體信息。
到目前為止，已經看到了.gitlab-ci.yml觸發(fā)到執(zhí)行的過程，接下來，看看針對這個項目怎樣去具體跑CI
構建Docker鏡像參考詳情
(1)、根目錄中添加配置文件Dockerfile
FROM node:10-alpine as builder WORKDIR /data/myweb COPY . . RUN npm install --registry=https://registry.npm.taobao.org --no-package-lock --no-save RUN yarn publish:prod FROM nginx:alpine as myweb RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ && echo "Asia/Shanghai" > /etc/timezone WORKDIR /data/production COPY ./nginx /etc/nginx/conf.d COPY --from=builder /data/myweb/build /data/production EXPOSE 80, 443 復制代碼
(2)、在項目根目錄中新建nginx/default.conf，我們用外掛的nginx配置文件覆蓋原來Nginx鏡像中的配置文件
server { listen 80; listen [::]:80; server_name localhost; location / { root /data/production; index index.html; try_files $uri /index.html; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } } 復制代碼# 定義全局變量,鏡像名稱，命名空間，鏡像拉取的密碼的變量名 variables: IMAGE_HUB: "lvpf/myweb" DOCKER_HUB_URL: "hub.docker.com/r/lvpf/myweb" # 這里打印一些變量，僅僅為了展示，看下這些gitlab預設的變量值，可以去掉 before_script: - echo "VARIABLE CI_COMMIT_SHA IS $CI_COMMIT_SHA!" - echo "VARIABLE CI_COMMIT_TAG IS $CI_COMMIT_TAG!" - echo "VARIABLE CI_PROJECT_DIR IS $CI_PROJECT_DIR!" # stages順序運行, 同一個stage的所有job并行 stages: - BuildImage # 任務1，構建docker鏡像 docker-image-master: # 使用的Gitlab Runner標簽 tags: - uaek-c1 # 任務名稱 stage: BuildImage # 由于當前runner為k8s構建的，所以這里執(zhí)行docker構建和上傳需要通過kaniko鏡像，具體可以看下面參考文檔（） image: gcr.io/kaniko-project/executor script: # 首先我們需要為我們的鏡像生成一個tag，規(guī)則是：如果有 git tag，就使用 git tag，如果沒有的話，就使用 git commit sha - IMAGE_TAG=$CI_COMMIT_SHA && if [[ -n "$CI_COMMIT_TAG" ]]; then IMAGE_TAG=$CI_COMMIT_TAG; fi - echo $IMAGE_HUB:$IMAGE_TAG - mkdir -p /kaniko/.docker - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $DOCKER_HUB_URL:$IMAGE_TAG # 使用 only 來限制這個 job 什么情況下會運行，下面的設置標識只有新的 tag 被創(chuàng)建時才觸發(fā)CI，如果去掉，每次推送分支都會觸發(fā)CI only: - tags 復制代碼一般公司安全性考慮，不會將鏡像推送到hub，公司內網一般也不通，要考慮自建私有鏡像倉庫
gitlab-runner可以使用的宿主機類型很多，包括云主機、docker、k8s等，構建鏡像的解決方式略有不同，可以參考文檔
其中一些涉及密碼的變量，可以通過Gitlab->Setting->CI/CD->Variables來設置，直接在.gitlab-ci.yml中使用
作者：前端中后臺
鏈接：https://juejin.cn/post/6967570299336261646
來源：稀土掘金
著作權歸作者所有。商業(yè)轉載請聯(lián)系作者獲得授權，非商業(yè)轉載請注明出處。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/127954.html
摘要：什么是持續(xù)集成持續(xù)集成，簡稱指的是，頻繁地一天多次將代碼集成到主干。如圖什么是一次其實相當于一次構建任務，里面可以包含多個流程，如安裝依賴運行測試編譯部署測試服務器部署生產服務器等流程。參考鏈接用進行持續(xù)集成 什么是持續(xù)集成 ? 持續(xù)集成（Continuous integration，簡稱CI）指的是，頻繁地（一天多次）將代碼集成到主干。 GitLab CI 什么是 GitLab CI...
摘要：所以在此給大家分享一下不使用構建工具實現項目自動化打包發(fā)布的思路。對于一個前端項目來說，自動化的構建是很有必要的，同時我們也可以通過實現更多的功能比如代碼檢測，單元測試等等。另外這種思路同樣適用于其他項目等前端項目，等移動端項目。 今天這篇文章的目的是在rn項目的構建，并不會涉及到rn框架或者使用的講解，說起構建，特別是前端構建大家應該很快會想到webpack、Grunt、 Gulp等...
一、什么是CI/CDCI 持續(xù)集成CD 持續(xù)交付CI/CD就是在開發(fā)階段，通過自動化發(fā)布，來頻繁部署應用的一種方式二、為什么要配置CI/CD想象一下，一個項目的發(fā)布如果手動部署，需要的操作有：單元測試打包文件上傳服務器等等如果每個過程都需要手動執(zhí)行，每次都要保證不出錯，這個已經很繁瑣了。而現在大的前端項目多達10+的人開發(fā)，而且人員流動大。如果每個人都這么發(fā)布，快速迭代就容易出錯。這時候就需要CI...
摘要：只要的項目有提交，相關就根據來決定是否跑自動部署的命令。項目的自動部署添加執(zhí)行的注冊命令，按照說明進行參數配置。至此，和服務都已經自動部署完成。 準備工作 說明 公司最近準備了一臺新的開發(fā)服務器，正好用以實踐docker的基本應用。docker的好處不再贅述，詳情可參考阮一峰的這篇入門。（關于Docker最好的中文介紹，沒有之一）。 公司目前主要使用了EggJs + ReactJS的技...
摘要：本文的目的最主要是備忘其次是分享療效并不能讓你一下子掌握這只是一個比較完整的解決方案其他基礎知識自行補充基調首先這不是屠龍刀不要奢望一篇文章可以走遍天下這里只是提供一個具體的落地方案一個具體的技術選型階段代碼倉庫關于代碼倉庫本文選取的方案是 本文的目的:最主要是備忘, 其次是分享 療效: 并不能讓你一下子掌握CI/CD, 這只是一個比較完整的解決方案,其他基礎知識,自行補充. 基調...
閱讀 484·2024-11-07 18:25
閱讀 130851·2024-02-01 10:43
閱讀 961·2024-01-31 14:58
閱讀 925·2024-01-31 14:54
閱讀 83048·2024-01-29 17:11
閱讀 3310·2024-01-25 14:55
閱讀 2086·2023-06-02 13:36
閱讀 3206·2023-05-23 10:26
