GitLab CI/CD課程32

Promote to Staging (Multi-Stage Demo — Part 2)

前篇調整的部分只是透過提取PORT號為變數

其實整體還是舊有的PIPELINE(只佈署到DEV)

這邊直接複製DEV佈署的部分為STAGING

但是改名稱為STAGING

首先開頭先宣告STAGING的位置(雖然這邊是跟DEV一樣):

接著再進一步區分stages:

接著可能安插一個測試Job在佈署完DEV後 →run_functional_tests

在此情境下的docker-compose.yaml造成的問題

如上圖,在Staging階段的down指令

很可能反而會關閉到DEV階段up的Container

因為對應到的Container為docker-compose.yaml內的:

這邊簡單頗析docker-compose相關運作:

首先其啟動的container名稱是:

對應方式如下:

<project_name>_<service_name>_<index>,其中project_name預設等於當下目錄名

如上解析,所以在現在狀況,需要依據不同階段的佈署

透過不同目錄(造成不同Container名稱)來啟動對應階段的Container

一個簡單的方法要用到的東西是:

LINK

使用上述變數(COMPOSE_PROJECT_NAME)

就可以取代預設去認當下目錄名稱的部分

然後把上述pipeline程式commit但是先手動停止跑pipeline

目前Pipeline內容為:

Run pipeline access applications

這邊再微調程式碼裡的index.xml內容:

上述Code連同前面的Pipeline Code commit後,pipeline自動執行

這是因為舊的Container沒有移除,還占據著3000 PORT

所以這邊要先手動停止舊的DEV Container:

直接重跑Pipeline:

看到容器:

開一下防火牆:

都能看到貓貓:

Fail functional tests to skip promoting to staging

也就是DEV佈署後的測試失敗,我們應該禁止佈署到staging階段

故意改成錯誤的指令

然後看看commit後結果會不會跑staging的佈署

當前會失敗的Pipeline為:

記得改IP跟host才能用

參考課程(reference)