科技新知
發佈Docker Swarm App的選擇 - CI/CD系統的參與
一段時間前，筆者就討論了一些Docker打包的程式的文章，也討論了一些Docker Cluster環境下的選擇。現在也是時候，可以分享一些對於發佈環境的可選空間。
CI/CD系統
CI/CD 全稱是continuous integration (CI) 和 continuous delivery (CD)，字面上代表的持續地集成和發佈，實體上就是某台伺服器自動發佈APP。因為使用到Docker Cluster，不論前述什麼選擇 (前文連結 請點這裏)，都會有多個node(節點)的出現。要發佈App，總不能一個個node逐個登入設定。所以我們需要一些CI/CD工具，把這個過程都自動化。
在筆者的認知上，CI/CD系統，由兩個部份組成，一個是取得Source Code(程式原始碼)的過程，一個是編譯或發佈Source Code的過程。Gitlab，Github，BitBucket等大型的代碼庫供應商，它們天生為了保存Source Code而提供服務的。不少CI/CD系統都可以跟它們整合，它們提供了存取Source Code的部份，剩下你只要能提供編譯或發佈的伺服器就好。
如果作為小型開發團隊，很少會有意願去自己花錢養一個編譯或發佈的伺服器。(極端地，如果我就是一人團隊，我用自己電腦編譯和發佈就好，伺服器能做的，我自己也能做。)好消息的是，Github提供了一個叫Github Action的CI/CD系統，即使你沒有自己的編譯專用的伺服器，Github Action也可以用Docker Image，提供一個臨時的編譯程序，用完就刪掉。詳細功能還請各位先查看官方教學，筆者也暫時只能零星使用經驗，無法給出有意思的架構。
如果對智慧財產權有高度重視，Source Code不能存放在公開的伺服器，那麼Gitlab Enterprise Edtion則是一個好選擇。運用Gitlab ee，你可以用自己的機器，造一個純本地的庫存伺服器。更強的是，它內建也有CI/CD系統，只要你有間置的伺服器，就可以作為編譯使用。筆者也是從這個方向著手，架設了自己的Gitlab Runner(Gitlab CI/CD系統)。在這裏，就分享一下與Docker Swarm整理的概念。
對於前述兩種選擇，GitLab Runner都可以做得到
- 底層程式打包成Image並運行在Swarm mode上，每次發佈的是App Binary(執行檔或核心檔案)。
- 把App直接打包成Image，並運行在Swarm mode上，每次發佈的是App Image。
CI/CD - 打包底層程式成為Image
在這個選擇下，其實就跟傳統自動化發佈的做法類似，只是發佈時，要多個node報行更新指令。如果你使用的底層程式原本就有支援多版本並行，這樣更新時就不用太操心rollback(回滾?)等操作。若系統不支援多版本並行，為求簡化，若遇到要rollback的情況，重跑過去舊的CI/CD操作也是一個做法。當然，我們也可以經過一些備份的操作，來保存被代替的程式，若在發佈過程中出問題，也可以手動重來，不過整件事就越來越複雜。
筆者發佈的基本思路是
- 使用docker image，編譯和打包App Binary。
- 使docker image做編譯的好處是，你可以比較放心地假設每次編譯時，你的編譯環境都是乾淨的。
- 傳送上述的結果至生產環境可以取用的地方。
- 跳入生產環境執行更新指令
這裏有些隱藏的管理成本，如果你生產環境中有多個node，最後那幾行指令就要多抄幾次。
CI/CD - 打包App成為Image
在這個選擇下，對比傳統自動化發佈的做法，現在要多做一步，就是要包裝自己的Image。不過好處是docker swarm有提供監測工具，在發佈過程每個分身會逐個更新，前一個分身更新成功後才會到下一個分身更新。而且 rollback等的操作，你可以靠docker做到。即是要手動rollback，也可以透過更正docker tags來達到，所以整體上來說沒有比傳統的麻煩。
筆者發佈的基本思路是
- 編譯App Binary。
- 打包成docker image。
- 經docker上傳image。
- 跳入生產環境執行更新指令。
對比傳統自動化發佈的做法，最後的更新指令，只要執行一次就可以。當然，原本在Docker Swarm中要管理的事還是要好好管理。
CI/CD - 備註事項
雖然CI/CD可以幫忙簡化更新的過程，但實際操作會比上述的例子複雜一些。因為通常對非技術型的外界用戶來說，一個Web App會包含很多不同的功能。上述的例仔，在實際情況下可能需要拆解成很多微服務來進行。所以對管理上還是有相當的挑戰。
