GitLab故障排除紀錄

作為公司碩果僅存的 MIS，打開 gitlab 時如果看到 502 就會覺得噢又來了，然後一邊抱怨一邊連回伺服器處理。

呂布也救不了你

軟體業有個說法，說可以治百病的不是華佗，是呂布(reboot)
但上次 gitlab 掛點我卻發現關掉之後連整個 docker 的 container 都無法重新掛載起來，重開機不僅沒有治百病，反而還直接死給你看，那時候只有一個想法：我要趕快辭職潛逃了 XDD

追蹤問題

公司的 gitlab 是用 docker 架的，所以如果連 container 都掛載不起來，那問題實在是有點惱人，但還好，我們還有 log 可以查。

docker logs --tail 50 --follow --timestamps YOUR_CONTAINER_NAME

吐出的 log 片段如下

...26Z Initializing logdir...
...28Z Initializing datadir...
...97Z Updating CA certificates...
...09Z Installing configuration templates...
...99Z SSL Key, SSL Certificate and DHParam were not found.
...18Z Assuming that the container is running behind a HTTPS enabled load balancer.
...73Z Configuring gitlab...
...25Z envsubst: write error: No space left on device

重點應該就是最後一句啦 磁碟空間用完了。

抓兇手

下指令看了一下公司伺服器的磁碟容量，雖然不大但應該夠用(因為有在運作的服務也所剩無幾)，所以找出到底是哪個資料夾最占空間應該是目前的主要任務，畢竟要刪就要從最肥的開始刪才是最有效率的做法。

上網查了一下做法，最後整理出的指令如下

du -h --max-depth=1 | sort -hr

該指令會列出目前目錄下的資料夾佔用空間，並依大小排序，然後你就可以一層一層 cd 進去，直到找到目標位置。

最後發現的兇手位在 ./srv/docker/gitlab/gitlab/backups/ 底下。
啊這不就是 gitlab 自己的備份檔嗎!??

解決問題

繞了一大圈，最後得到的結論是不知道為什麼，gitlab 的備份機制從某天開始，忽然不會自己把過時的備份檔刪除，所以磁碟空間後來就被塞爆了。
懶惰如我，選擇把備份紀錄刪一刪，先把 gitlab 開起來再說，至於為啥備份檔忽然不會自己刪除了，之後有空再來處理囉。看要不要寫個排程來刪檔案之類的。

最後附上刪除 3 天前的所有備份檔的指令

find ./srv/docker/gitlab/gitlab/backups/*.tar -mtime +3 -exec rm -rf {} \;