上次寫完 遷移 gitlab 資料到全新容器 ，我有在微博裡說過這裡如果有關聯過 ci ，可能會出現一些小問題，比如：原本好好的pipeline顯示執行中，但是沒日誌響應、專案的ci頁面打不開，顯示500錯誤。
再次檢視備份與恢復 的文件，發現 gitlab 在恢復備份過程中，對於下面的檔案是不會進行備份和恢復操作的。
而被恢復的資料庫中包含雙因子加密驗證的資料，其中的乙個解密因子被儲存在了gitlab-secrets.json中，如果你不進行手動合併操作，那麼你的新gitlab應用中涉及到需要雙因子解密的資料將都不可用，而gitlab在**中也沒有對這類情況作一些額外操作，就導致頁面報 500 錯誤，顯示不可訪問。
一年前有人已經在官方社群中進行了反饋，但是暫時還沒有進行解決。
解決方式有兩種。
第一種是你手動備份這幾個檔案，然後在新的應用中進行還原操作，這裡除了要注意進行操作的時候，gitlab要處於停止服務狀態，沒有什麼額外的問題。
但是如果你想得到乙個更少歷史負擔、更少陳舊配置的全新應用，可能接下來的第二種解決方式會更適合你。
第二種方式則是在資料庫中清理掉這些需要雙因子解密的資料，避免gitlab在執行過程**現異常情況，進而報錯拒絕服務。
如果你是裸機安裝，那麼直接執行gitlab-rails console就可以進去rails 控制台了。
如果你修復是在 docker 容器中執行的gitlab則需要使用-it引數，使用互動式終端後，再執行上面的操作，比如：
docker exec -it gitlab /bin/bash 1
docker
exec
-it
gitlab
/bin
/bash
然後在執行下面的命令：
gitlab-rails console 1
gitlab
-rails
console
等待控制台繼續可互動輸入內容的時候，輸入下面的命令，清理掉這些不可解密使用的變數。
p = project.find_by_full_path('project-group/project-name') p.variables.each(&:destroy) 1
2 p=
project
.find_by_full_path
('project-group/project-name'
) p
.variables
.each(&
:destroy
)
當你看到一段顯示正常的 json 資料返回之後，再次重新整理不能進行設定 ci 變數的頁面。
將之前「卡住」的pipeline取消，再次觸發執行，你會發現一切又都正常了。
在全新部署 gitlab 的時候，可能會出現執行任務失敗，直接報錯fragment error。
但是如果仔細思考一下，會發現有的事情還是挺有意思的：
如果你也在構建一套對外的工具軟體，上面的思路或許也可以借鑑其中一二。
說些題外話，有的時候，人們出於本能會躲開麻煩和折騰的事情，只要它們還沒有變成不得不去解決的「麻煩」。但是如果有一天你選擇去面對它們，去解決它們，那麼你在某一方面的知識水平、技能積累就將會大幅的提高。
比如我一直覺得重新配置一台新的家用伺服器很麻煩，從系統設計到入網規劃、再到上面跑什麼樣的虛擬化方案，具體資源分配如何設計….
但是真的當我重新配置了一台新的伺服器後，我發現許多問題，我之前已經解決過了，把已有的經驗稍微更新一下，就可以快速拿到我想要的結果。而且新的伺服器的出現，讓我有了許多冗餘的「算力」和「儲存」空間，我可以再一次將我的自動化流程方案進行公升級改造，進一步提高效率、擴充套件我折騰的邊界。
共勉。—eof
gitlab遷移公升級
一 遷移步驟 1.首先安裝最新版本gitlab gitlab7.2安裝 2.停止舊版本gitlab服務 3.將舊的專案檔案完整匯入新的gitlab bundle exec rake gitlab import repos rails env production bundle exec rake g...
Gitlab遷移小記
本來用家裡退休的筆記本，利用ddns，搭建了乙個gitlab自己玩，最近剛好拿到乙個digitalocean的優惠，就把想把它遷移到digitalocean的機器上了 畢竟原本的功耗帶來的成本還是不低的，一天大概要跑一度電，也許更多，那乙個月下來也要30多的開銷了。不過好處就是效能相對vps來說，絕...
gitlab倉庫遷移
遇到乙個情況，需要將兩個gitlab倉庫合併。好在都是使用的ldap賬戶登陸，使用者賬戶不需要遷移。實際的使用情況下，需要遷移的主要部分為分組及分組下專案。gitlab的api還是很給力的，能夠獲取所有這些資訊，並利用這些資訊進行新建。獲取資訊使用get方法，修改資訊使用put方法，新建使用post...