timBaiii 程式教學

前言 上次我們對 Docker 架構進行了講解，今天我們來講解 Docker 的好處，他到底可以幫助我們什麼事情 ? 為什麼 Docker 如此受人喜歡 ? 現在就來講述 Docker 有什麼好處 跨平台 Docker 可以確保在不同的作業系統是可運作的，可減少機器運作的問題 版本控制 打包 Docker Image 這個過程，是可進行版本控制的，達到 Docker Image 版本化和可共享 自動化建構 Docker 可以簡化佈署流程，透過 Dockerfile 即可定義佈署流程，自動化建構打包過程 建立乾淨測試環境 Docker 在建構環境時，可以讓我們建構乾淨的測試環境，讓我們可以在乾淨的環境上，進行測試 容器化 Docker 當每起一個容器時，容器跟容器之間是互相隔離互不干擾

前言 上次我們針對 Docker 這樣容器化技術做了一點介紹，今天我們要來講解 Docker 架構，你是否發現在每次程式上伺服器的流程很麻煩呢 ? 是否發現你寫的程式在別的作業系統不能用呢 ? 如果你遇到這些問題，Docker 都可以幫助你解決這些問題 Docker 架構 在 Docker 這個容器架構，是可以跨平台的，我們可以將我們做好的 Docker Image，上傳到 Docker Hub 上，透過不同的作業系統進行拉取，以便我們快速進行佈署，可以看到有如下圖，在 Linux 上我們安裝上 Docker Engine，在上面建置我們容器，容器裡面擁有著 Docker Image，而在 Windows 系統，也同樣掛載 Docker Engine，在上面建置我們容器，容器裡面擁有著 Docker Image，在 Mac 作業系統也是同樣的動作 結語 可以看到 Docker 是這麼如此方便，不但可以跨平台作業，可以節省佈署所花費的時間，可以建立乾淨環境，使用最少的資源，幫助我們解決佈署會遇到的事情

前言 大家好我們今天要來教 Docker 這項技術，什麼是 Docker ? Docker 可以幫助我們做什麼事情 ?          Docker 是一項容器化技術，他可以降低我們在佈署 App 時，讓我們可以有效的分配作業系統資源，降低佈署作業成本，現在讓我們來了解 Docker 要解決的問題 傳統佈署遇見問題 首先我們先來看傳統我們在佈署應用程式時，所遇見的問題，我們來看我們下圖的系統架構，有一台 Host 主機，上面掛著作業系統，而作業系統上面掛著三個應用程式，這時候問題出現，當其中有一個應用程式出現問題，可能連帶影響其他應用程式也跟著出現問題 傳統主機模式 接下來來看到為了解決一台主機掛載多個應用程式，在傳統上會分成三台主機，上面掛載不同的應用程式，當如果有一個應用程式掛掉時，也不會影響其他主機，但是這樣個資源是高的 VM 模式 接下來來看到為了解決多台主機所耗費的資源，在後來我們改了 VM 模式，可以看到有如下圖，在一台 Host 主機，上面掛載作業系統，在作業系統上面我們掛載一個叫做 Hypervisor，這個東西提供了虛擬化的技術，在這上面我們掛載 VM，在 VM 在上面我們掛載作業系統，而在作業系統掛載我們的應用程式，可以看到雖然我們可以不須像傳統模式一樣，花費的硬體資源這麼高，當如果有一個應用程式出現錯誤時，也不會影響其他應用程式，達到隔離與保護的效過，但是我們每次在佈署一個應用程式時，都在起一個 VM 去做前置作業，在硬體資源上也是滿高的 容器模式 隨著時代的演進，技術的成長，現在擁有了容器模式，有如下圖我們一樣會有一台 Host 主機，在這主機安裝作業系統，上面會掛載一個東西叫做 Docker Engine，而在 Docker Engine 上我們會掛載不同的容器，而在容器上面會掛載不同的應用程式，然而當如果有一個應用程式出現錯誤時，也不會影響其他應用程式，每個容器是互相隔離的 三個模式資源比較 在傳統模式因為要耗費很多主機資源，所以傳統模式是最高的，而在 VM 模式情況下，所耗費的資源是中，在容器模式運作下所耗費的資源是最低的 容器化技術 接下來...

前言 上次我們講到 CI/CD 中的 when 使用，今天我們要來傳授一套必殺技，我們要把過去所學的全部融合再一起，相信各位都準備好了，將 Gitlab 從枷鎖中解放出來吧，讓我們來詠唱「武裝完全支配術」 「System Call. Connect Armament. Search Archived Memory. Extract Core Image. Connect Resource. Materialize Primary Shape. Append Maximal Solidity.」 設置 CI/CD 管制流程 在開始寫 CI/CD 自動化佈署腳本前，我們先定義好 CI/CD 設置流程，在這裡先做個簡單有些完整性的五個階段，在下面我們一一說明在五個階段的用處 unit-tests: 在第一個階段我們先做單元測試，確定我們的程式沒有問題 build-docker-Image: 在第二個階段，在單元測試做好後，我們開始打包 Docker Image，將我們的程式打包上傳 Docker Hub deploy-docker-development: 在第三個階段，當我們打包好 Docker Image 後，我們開始進行佈署開發機 deploy-to-string: 在第四個階段，當我們佈署好開發機後，我們緊接著佈署 demo 機 deploy-to-production: 在第五個階段，當開發機與 demo 機沒有問題的時候，我們在這裡有設置一個按鈕，按下按鈕開始佈署正式機，完成上線 撰寫 CI/CD 佈署計畫腳本 接下來我們開始撰寫 CI/CD 佈署計劃書，我們將上面五個工作階段結合起來，我們在 develop 這個分支，在有 push 的時候，擁有單元測試、打包 Docker Image、佈署開發機、佈署 demo 機 而在 main 這個分支，在有 push 的時候，擁有單元測試、打包 Docker Image、佈署正式機，現在我們開始強化撰寫 CI/CD 佈署計劃書 Enhance Armament !!! image: mcr.microsoft.com/dotnet/sdk:6.0 stages:   ...

前言 上次教到如何使用 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   ...

前言 上次我們做了一次使用 Docker、Docker Compose 與 Gitlab CI/CD 做一次自動化佈署上線，今天我們要來再來教一個 Gitlab CI/CD 中的 environment 這個 script 怎麼使用 environment 作用 environment 是可以讓我們定義我們佈署的環境有哪些，定義好環境後 Gitlab 讓的 UI 會儲存你定義的環境，讓我們可以更方便去連線我們的主機，如下圖按下 Operate -> Environments，這裡就可以讓我們新增環境，但是一個一個新增不會覺得很不方便呢 ? 我們今天用 CI/CD 腳本方式，讓他可以自動新增這些環境，是不是很方便呢 ? environment 定義 environment 在我們的工作去定義環境，可以看到以下範例，我們寫進 environment 去定義我們的環境，name 是定義我們環境名稱，url 也就是我們連線網址 deploy-to-development:     stage: deploy     environment:         name: example service name         url: https://www.example.com.tw 練習時間 接下來我們來開始撰寫 CI/CD，讓我們的環境可以自動定義好，不須再而外改來改去，我們使用上次的腳本稍微加個東西 在這裡我們在 .deploy 這個繼承工作，加了一個 SERVICE_NAME 這個 variables，用來準備定義環境名稱，並且加上 environment 這個 script，用來準備定義每個環境，每個 deploy 類的工作也跟著使用 SERVICE_NAME 這個變數定義環境名稱 image: mcr.microsoft.com/dotnet/sdk:6.0 stages:     - deploy .deploy: ...

前言 大家好上次講到在使用 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 | ...