GitLab 遷移之後的事情
上次寫完ofollow,noindex" target="_blank"> 遷移 GitLab 資料到全新容器 ，我有在微博裡說過這裡如果有關聯過 CI ，可能會出現一些小問題，比如：原本好好的pipeline顯示執行中，但是沒日誌響應 、專案的CI頁面打不開，顯示500錯誤 。
問題原因
再次檢視備份與恢復 的文件，發現 GitLab 在恢復備份過程中，對於下面的檔案是不會進行備份和恢復操作的。
/etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /home/git/gitlab/config/secrets.yml
而被恢復的資料庫中包含雙因子加密驗證的資料，其中的一個解密因子被儲存在了gitlab-secrets.json
中，如果你不進行手動合併操作，那麼你的新GitLab
應用中涉及到需要雙因子解密的資料將都不可用，而GitLab
在程式碼中也沒有對這類情況作一些額外操作，就導致頁面報 500 錯誤，顯示不可訪問。
一年前有人已經在官方社群中進行了反饋 ，但是暫時還沒有進行解決。
如何解決
解決方式有兩種。
第一種是你手動備份這幾個檔案，然後在新的應用中進行還原操作，這裡除了要注意進行操作的時候，GitLab
要處於停止服務狀態，沒有什麼額外的問題。
但是如果你想得到一個更少歷史負擔、更少陳舊配置的全新應用，可能接下來的第二種解決方式會更適合你。
第二種方式則是在資料庫中清理掉這些需要雙因子解密的資料，避免GitLab
在執行過程中出現異常情況，進而報錯拒絕服務。
如何操作
如果你是裸機安裝，那麼直接執行gitlab-rails console
就可以進去Rails 控制檯
了。
如果你修復是在 Docker 容器中執行的GitLab
則需要使用-it
引數，使用互動式終端後，再執行上面的操作，比如：
docker exec -it gitlab /bin/bash
然後在執行下面的命令：
gitlab-rails console
等待控制檯繼續可互動輸入內容的時候，輸入下面的命令，清理掉這些不可解密使用的變數。
p = Project.find_by_full_path('project-group/project-name')
p.variables.each(&:destroy)
當你看到一段顯示正常的 JSON 資料返回之後，再次重新整理不能進行設定 CI 變數的頁面。
將之前“卡住”的Pipeline
取消，再次觸發執行，你會發現一切又都正常了。
額外的問題
在全新部署 GitLab 的時候，可能會出現執行任務失敗，直接報錯fragment error
。
遇到這個問題，大概率是從Amazon S3
下載的檔案出錯了，建議重新下載：https://docs.gitlab.com/runner/install/linux-manually.html
。
這裡其實和官方使用滾動更新有關，官方下載頁面沒有提供檔案校驗和來讓使用者進行下載檔案確認，所以你無法保證你下載的問題是正確的，只能靠下載完畢執行看行為是否正常。
最後
本篇作為上一篇文章的補足，寫的簡短了些，應該看著沒有之前的長篇大論爽快。
但是如果仔細思考一下，會發現有的事情還是挺有意思的：
- 防禦性程式設計：不信任任何外部裝置，除非它已經被加入信任列表
- 核心資料使用：不使用明文儲存任何核心資料，涉及兩臺機器，互動的資料使用雙因子進行加密，杜絕中間人攻擊
- 敏捷開發：優先完成 MVP 功能，涉及遷移資料這種低頻功能開發優先順序降低
- 社群建設：專人跟進專屬模組，收集反饋，給出臨時解決方案，透露未來的規劃，增強客戶對軟體的信心
如果你也在構建一套對外的工具軟體，上面的思路或許也可以借鑑其中一二。
說些題外話，有的時候，人們出於本能會躲開麻煩和折騰的事情，只要它們還沒有變成不得不 去解決的“麻煩”。但是如果有一天你選擇去面對它們，去解決它們，那麼你在某一方面的知識水平、技能積累就將會大幅的提高。
比如我一直覺得重新配置一臺新的家用伺服器很麻煩，從系統設計到入網規劃、再到上面跑什麼樣的虛擬化方案，具體資源分配如何設計….
但是真的當我重新配置了一臺新的伺服器後，我發現許多問題，我之前已經解決過了，把已有的經驗稍微更新一下，就可以快速拿到我想要的結果。而且新的伺服器的出現，讓我有了許多冗餘的“算力”和“儲存”空間，我可以再一次將我的自動化流程方案進行升級改造，進一步提高效率、擴充套件我折騰的邊界。
共勉。
—EOF