經過昨天幾經的折騰後，才深深的體悟到Gitlab在Docker安裝那寫下的這段話的用意，以及到了2020也沒有更新這警告
Caution: Docker for Windows is not officially supported. There are known issues with volume permissions, and potentially other unknown issues.
本來以為到了2020，Windows 10和WSL2的使用會讓Docker更接近於實際的linux環境，但在這幾天的嘗試中，明顯的和之前用Mac時的環境不一樣。這會讓建構以container為主軸的流程變成很不容易進行。
這幾天的流程建構一直沒有好好的記註下來，最主要的原因是雖然心中有一定的藍圖，但沒有試著串連起來，也著實不確定是否可行，但今天就花一些時間將心中的想法記錄下來，就算是不可行的方案，日後也有可以調整的基準。
流程的建立是依據production的概念回推到develop上，也就是利用建置production規劃中所要走流程轉回到本機端的開發環境中。其中最主要的不外乎二個主要的流程(其實test也很重要，但先不放進來)
簡單來說，當程式碼提交到Source Control，也就是Git Repo後，開始進行建置的動作，建置完後的Artifact，也就是Container，會放入到Container Registry裡，並於之後佈署到k8s cluster中。
這份相當簡易的流程裡，若是純以Google Cloud Platform(GCP)的方式進行Production佈署，大致上會走的流程是
所以會想要在本地端複製一套和Production建置流程一致的方案。
首先想到的就是在Source Control和CI tool的選擇上，如果Remote和Local都是一樣用GitLab，那程式碼控管的部份就會一致，而GitLab自有的CI tool評價相當的高，如果是一併使用，也省掉了再學一套CI tool，如Travis CI、Circle CI或是Drone CI的複雜度。
待建置完成包成image後就要進入到Container Registry的空間中，因為最後會用GCP，自然地會放在Google Container Registry裡，但在本地端，會選擇另一個方案，也就是JFrog的Container Registry。最後，在GCP裡會進入到GKE的cluster中，而在本地端則會以kinD為主，進行測試。
這樣的規劃就是這一陣子以來花了不少時間再試本地端開發的工具和服務搭配，過程並不是很順利。其中有一部份是作業環境的關係，而一部份則是串連不熟悉的工具和服務本來就會有的學習成本。
主要的想法大致是這樣，這樣簡化的流程中仍是有很多工具、服務沒有列入，但光是這樣的流程在短時間內要配置好，也不是容易的。簡易的想法就暫時記錄到這，接下來又要回到Gitlab這。
就算是本機端的開發環境建置上不順利，最終還是要以production環境的建置為主。但就算是用gitlab雲端的服務，還是有一些要克服的障礙。尤其是建置的部份問題比較多。在現有的規劃中，會用Monorepo的方式進行程式碼規劃，Gitlab對於一個專案裡有多個app(service等)或是多種語言沒有很好的建置方案。
從.gitlab-ci.yml只能有一份來看，就很難去處理多app和跨語言的需求，討論區裡的這篇Multiple .gitlab-ci.ymls MVC，從四年前到現在，都沒有任何好的官方解法。只有在討論中連接了另一個GitHub的專案，裡面有二種方法可以解決用Gitlab來建置Monorepo所造成的問題。
這二種方法都不是很好，第一種要在commit message加上特定的關鍵字，這本身就很奇怪，而第二種方法，設定上看起來相當的複雜。從這樣的角度，我還是用之前想到的老方法，雖然設定上不會比較簡單，但做過了幾次，也比較了解如何進行，而這個方法就是多開一些建置用git repo，並以開發用的git repo為主，以類別分支出去。這和用變數的方式在本質上是相同的，但省去了還要了解和安裝gitlab-trigger-proxy的複雜度。但是否最後會用這個方法還會花些時間思考。
不論如何，主要的任務都是要利用Gitlab的建置工具完成backend的服務建置。只是在本地端沒有辦法搭建gitlab，就能只能再思考要不就全數直接上雲端，要不就保留其它的部份在本地，只有gitlab用雲端的方案。
iThome鐵人賽
看影片追技術