Heresy 這邊有在使用 Apache + PHP 的 Docker（實際上是 php:apache 這個 Docker Image）在架設測試用的網站；而由於現在網站都是建議要使用 https，所以一開始是自己去 Let’s Encrypt（官網）申請憑證來用。不過由於他發的 SSL 憑證期限是三個月，所以就必須要定時更新才行。
為了避免之後忘了更新，其實最好是像要辦法設定成自動更新的模式。而目前，也已經有 CertBot（官網）這類的工具，可以來協助完成 SSL 的憑證設定、更新了！
這邊基本上就是紀錄一下 Heresy 自己在 Apache + PHP 的 Docker 內、設定 CertBot 的方法。
這篇算是 Heresy 這邊透過 Docker 來架設 GitLab server 的一些後續，真要說的話，應該是之前《GitLab 升級到 13 的筆記》的延伸。
GitLab 在 13.0 的時候，把「Design Management」（官方文件）開放給免費的使用者使用了。這項功能的目的，主要應該就是讓使用者可以在 issue 中上傳圖檔，方便討論。
不過，對 Heresy 這種是從 GitLab 11 升級上來的人來說，這項功能預設是不能用的。而且還會在 issue 那邊顯示警告，看起來滿煩的。 XD
Heresy 這邊在去年架設好自己的 GitLab 後，都有固定在更新，同時也在試著研究之前沒用上的功能、看看到底有沒有幫助（例如 Gitlab CI/CD）。
由於自己採用的是 Docker 的形式（Omnibus GitLab），所以其實不管是安裝、升級，都算是相對簡單的；但是在升級到前幾天推出的 GitLab 13 的時候，倒是小出包了一下…
GitLab 13 的新功能，可以參考官方的《GitLab 13.0 released with Gitaly Clusters, Epic Hierarchy on Roadmaps, and Auto Deploy to ECS》這篇介紹。
而這邊踩到的地雷，則是他把預設的網頁伺服器，從 Unicorn 改成 Puma 了。
之前有說過了，Heresy 為了自己在玩的手機遊戲《刀劍神域－記憶重組》另外弄了一個部落格來做紀錄（網址）。
而實際上，之前由於覺得遊戲內的公告由於不是照著更新時間排序、要找到哪個公告是新的實在很麻煩，所以就火大，自己試著想辦法去做公告的變更紀錄了。
搞了老半天，弄出了一個使用了兩個 Git repository 的奇怪架構系統，算是勉強做到堪用的程度了～
目前的成品是：https://kheresy.github.io/SAOMD-AA/changelog.html
而實際在運作的專案則是 https://gitlab.com/kheresy/saomd-announcement
目前 Google 和微軟都有提供線上翻譯的服務，甚至很多網站也會直接把翻譯的功能掛進去。
像是 Twitter 其實就有掛了 Google 翻譯的連結，使用者可已在不離開頁面的情況下，看到翻譯的結果。
但是根據自己的經驗，其實 Google 翻譯在把日文翻譯成中文的時候，其實結果實在很難說是夠好…很多時候，看著翻譯的結果，常常會覺得不但文法詭異到一個極致，就算想自己重新拼湊、也還是無法理解它的意思。
而這次在《DeepL 翻譯器新增中文日文，更接近真人流暢語意的翻譯品質》這篇文章看到的 DeepL，感覺則是提供較好的翻譯結果了！
Docker（官網）這種比虛擬機器更輕量化的「容器」虛擬化技術，基本上算是這幾年來一個滿重要的技術。透過 Docker，他可以將需要的環境打包、建構出類似虛擬機器，但是更小、更彈性的可移植環境，在需要自動佈署的環境上，應該算是很實用的一種技術。（參考介紹、參考介紹）
不過由於工作的領域不同，所以 Heresy 其實之前都沒有去碰這一個技術；真的開始接觸到，是之前試著使用 Docker 來架設 GitLab Server 的時候開始的。
後來，Heresy 也很認真地開始搞整個 GitLab CI/CD 的架構，試著透過 GitLab 的系統來做一些程式開發的自動化建置、測試。最初，考慮到環境的熟系程度，Heresy 都是直接使用作業系統的 shell 來作為 gitlab-runner 的 executor。
Heresy 今年把新的 GitLab Server 架好後，就開始玩 CI/CD（Continuous Integration and Deployment）的功能、試著透過這個架構，來做一定程度的自動化了。
除了目前 C++ 專案的自動建置腳本已經算是完成了，其他一些特別的工作，也開始試著用 GitLab CI/CD 來玩，所以這段期間對這東西還算玩得滿認真的。
而從開始些 C++ 專案的跨平台建置開始，其實 Heresy 就覺得 GitLab CI/CD 的架構，有一點很討厭，就是他是基於「stage」來控制流程的，前面的 stage 沒有全部結束的話，後面的 stage 就不會進行。
所以如果整個 pipeline 有 build 和 test 兩個 stage 的情況下，就會變成要所有的 build 都完成，才能進行測試。
感謝網友提醒，根據官方《Cache vs artifacts》的說法，看來 Heresy 這邊把 build 階段產生的檔案透過 cache 傳遞到 test 階段，應該是嚴重的誤解／誤用了。 XD
之前在《GitLab 簡單的 C++ 專案腳本範例》和《GitLab 的 C++ CI/CD 腳本：使用 PowerShell》這兩篇文章，有分享了 Heresy 這邊目前 GitLab CI/CD 的腳本寫法了。
而當時也有提到，在 build 階段到 test 階段，Heresy 沒有玩出比較正規的檔案傳遞方法。
最近 Heresy 又開始測試這部分的東西。理論上，要在不同的 job 間傳遞檔案，是要透過在 .gitlab-ci.yml 裡面加上 cache（官網）來做。
在有加入 cache 的狀況下，GitLab Runner 會在 job 開始、透過 git 取得檔案後，就試著把 cahce 的檔案抓下來；而當腳本執行完後，則會再把 cache 指定的檔案打包，放到 Gitlab-runner 上。
Heresy 目前加上 cache 後的 .gitlab-ci.yml 大致上會像下面這樣：
