Gitlab CI/CD 之 自動化佈署，製作自動化上線計畫書

-

前言

大家好上次講到在使用 Gitlab CI/CD 自動化佈署前，使用 Docker Compose 撰寫佈署計畫書，今天我們要將目標轉移到 Gitlab 我們要撰寫自動化上線佈署計畫書，我們之後還會講一套更完整的佈署流程，今天只是讓各位體驗，自動化佈署上線的快感

調整 CI/CD 變數

首先我們先稍微調整 CI/CD 的變數，在這裡讓我稍微偷懶一下，我們 development 主機、staging 主機及 production 主機，所使用的變數都先用 DEV 開頭，因為我們主機只有一台，如果各位有想再開而外變數練習，也是可以的

撰寫 CI/CD 腳本

接下來我們開始撰寫 CI/CD 自動化佈署計畫書

image: mcr.microsoft.com/dotnet/sdk:6.0


stages:

    - deploy


.deploy:

    tags:

        - shell

    variables:

        SERVER_PRIVATE_KEY: ""

        SERVER_USER_NAME: ""

        SERVER_URL: ""

        SERVER_PORT: ""

        SERVER_ENV: ""

    before_script:

        - eval $(ssh-agent -s)

        - ssh-add <(echo "$SERVER_PRIVATE_KEY")

        - echo $DOCKER_REGISTRY_PASSWORD | docker login -u $DOCKER_REGISTRY_USERNAME --password-stdin

    script:

        - ssh -o StrictHostKeyChecking=no $SERVER_USER_NAME@$SERVER_URL "

            mkdir -p ~/DotNetCoreWebApiCiAndCdCourse"

        - scp -o StrictHostKeyChecking=no ./docker-compose.yml $SERVER_USER_NAME@$SERVER_URL:~/DotNetCoreWebApiCiAndCdCourse

        - ssh -o StrictHostKeyChecking=no $SERVER_USER_NAME@$SERVER_URL "

            export COMPOSE_PROJECT_NAME=$SERVER_ENV

            export SERVER_ENV=$SERVER_ENV

            export SERVER_PORT=$SERVER_PORT


            cd ~/DotNetCoreWebApiCiAndCdCourse &&

            docker compose up --build -d"


deploy-to-development:

    stage: deploy

    tags:

        - shell

    variables:

        SERVER_PRIVATE_KEY: $DEV_SERVER_PRIVATE_KEY

        SERVER_USER_NAME: $DEV_SERVER_USER_NAME

        SERVER_URL: $DEV_SERVER_URL

        SERVER_PORT: 8080

        SERVER_ENV: development

    extends: .deploy

    

deploy-to-staging:

    stage: deploy

    tags:

        - shell

    variables:

        SERVER_PRIVATE_KEY: $DEV_SERVER_PRIVATE_KEY

        SERVER_USER_NAME: $DEV_SERVER_USER_NAME

        SERVER_URL: $DEV_SERVER_URL

        SERVER_PORT: 8081

        SERVER_ENV: staging

    extends: .deploy

    needs:

        - deploy-to-development


deploy-to-production:

    stage: deploy

    tags:

        - shell

    variables:

        SERVER_PRIVATE_KEY: $DEV_SERVER_PRIVATE_KEY

        SERVER_USER_NAME: $DEV_SERVER_USER_NAME

        SERVER_URL: $DEV_SERVER_URL

        SERVER_PORT: 80

        SERVER_ENV: production

    extends: .deploy

    needs:

        - deploy-to-staging

檢查 CI/CD 自動上線狀況

接下來我們將我們寫好的自動化佈署計畫書，將他上板上去 Giblab，讓他運行 CI/CD，在下面 'deploy-to-development' 這個 Job 運行成功

繼續往下看到 'deploy-to-staging' 這個 Job 也成功運行

在最後我們看到 'deploy-to-production' 這個 Job 也成功運行

檢查 Docker 運作

我們連去伺服器，檢查 Docker 運作狀況，輸入以下指令

dockerr ps -a

可以看到 Docker 所起的 Container 上線都沒有問題

檢查後端連線狀態

輸入後端 Api 網址，查看 8080 port，可以看到 Api 運作正常

再來查看 8081 port，也可以看到 Api 運作正常

最後查看正式機 80 port，可看見 Api 也運作正常

最後補充

最後我們來補充講解一些變數，可以看到我 CI/CD 的 .devploy 這個繼承 Job，裡面有開了一些 export 的變數

SERVER_ENV: 我想各位應該都懂，也就是 Server 環境定義

SERVER_PORT: 我想各位應該都懂，也就是 Server 連接埠定義

COMPOSE_PROJECT_NAME: 我想這個各位應該不太懂這個在做甚麼的，這個是 Docker 自有的環境變數，他的功能是依據專案，取幫你起一個 Container Name，由於我們不想有衝突，所以我們必須在每個階段，設定不同的名稱，這樣才不會有衝突

留言

發佈留言

此網誌的熱門文章

yarn 專案版號管理指令

-
圖片
前言 yarn 是由 facebook 開發的一款套件管理工具，用來管理 node.js 套件版本，今天來學習如何使用 yarn 升級 package.json 版號管理，可以對一個專案版號管理更加制式化 major 目標升級版號 指令 yarn version --new-version major 範例 v1.0.0 ->  v2.0.0 minor 目標升級版號 指令 yarn version --new-version minor 範例 v1.0.0 -> v1.1.0 patch 目標升級版號 指令 yarn version --new-version patch 範例 v1.0.0 -> v1.0.1 premajor 目標升級版號 指令 yarn version --new-version premajor 範例 v1.0.0 -> v2.0.0-0 preminor 目標升級版號 指令 yarn version --new-version preminor 範例 v1.0.0 -> v1.1.0-0 prepatch 目標升級版號 指令 yarn version --new-version prepatch 範例 v1.0.0 -> v1.0.1-0 prerelease 目標升級版號 指令 yarn version --new-version prerelease 範例 v1.0.0 -> v1.0.1-0 若再一次的話 v1.0.1-0 -> v1.0.1-1
閱讀更多

Gitlab CI/CD 之 when

-
圖片
前言 上次教到如何使用 environment 去自動設置我們環境那些，今天我們要教 CI/CD 中的 when，通常在自動化佈署上線流程，並不會一路像前幾次一樣，先佈署到測試機，再佈署 demo 機，最後佈署到正式機，我們在佈署正式機的時候，通常會做一個防呆，比如說做成一個指令集，或者是按鈕等等，以避免出嚴重大錯 when 作用 when 是可以幫助我們在自動化佈署時，可以定義那些工作，是可以不要這麼早，就有所動作，等到我們比較確定的時候，比如說我們按下按鈕，這個工作才會開始運作，所以也可以讓我們做個半自動化，而不是全自動化 when 定義 when 這個 script 在 Gitlab CI/CD 底下提供了一些語法，以下是在 Gitlab 官網所到的，在文章的最地下，會提供相關網址 在我個人比較常使用的是 manual 這個語法，他可以在工作前，提供一個按鈕，讓我們手動按下去，才執行工作，有如以下範例 image: mcr.microsoft.com/dotnet/sdk:6.0 stages:     - deploy deploy:     stage: deploy     when: manual     script:          - echo 'deploy service' 練習時間 接下來我們開始使用這個 when 語法，在我們 deploy-to-production 這個工作加上 when 這個語法，讓我們正式機不要這麼快馬上上線 image: mcr.microsoft.com/dotnet/sdk:6.0 stages:     - deploy .deploy:     tags:         - shell   ...
閱讀更多

Gitlab CI/CD 什麼是 CI/CD

-
圖片
前言 什麼是 CI/CD ? CI/CD 可以幫助我們做到什麼事情? 為什麼要有 CI/CD ?         在傳統程式上線流程，例如可能要透過 FTP  上傳至伺服器，接著去修改環境變數，然後測試程式是否運作正常，然後伺服器重新開機就上線了。         在近代程式上線流程，例如說會有個像 Gitlab、GitHub 或者是 Jenkins，會有程式碼版控系統，把程式碼上傳上去至平台上，然後可能還跑一些測試，然後開啟 FTP，將程式碼上傳至伺服器，修改環境變數，然後就上線。         在現在程式上線流程，一樣會有個像 Gitlab、Jenkins 這樣的平台，然後我們將我們寫好的程式功能，上傳到平台上，接著我們會寫一些自動化測試的功能及自動化佈署的功能腳本，然後這些平台會去讀取我們撰寫好的腳本，去跑測試，以及佈署，可以幫助我們簡化許多佈署流程，整個佈署流程有如以下圖 什麼是 CI ? CI(Continuous Integration) 是指持續整合，也就是在工程師，在撰寫程式新功能，或者修正 Bug，上傳到 GitLab 平台，然後如果功能沒有問題打包 Docker Image，在這過程叫持續整合。 什麼是 CD ? CD(Continuous Delivery/Deployment) 是指時序交付或是持續佈署，在程式碼寫完沒問題，要佈署到伺服器，這個過程叫做時序佈署，那為什麼還會有持續交付，那是因為通常會準備是少兩個或三個環境，來進行模擬上線，測試系統功能是否正常，如果在 development 主機及 staging 主機有問題時，在重新修補功能，然後再次模擬上線及測試系統功能，在最後一切沒有問題時，佈署近正式主機，以達成上線功能。 以持續交付的話，有如上圖在不斷有新功能佈署到 development 和 staging 主機的這過程，可叫持續交付 以持續佈署的話，有如上圖不斷佈署至 development 、staging 和 production，這整個大框架叫持續佈署
閱讀更多