Docker

因為剛換了一份具有挑戰性的新工作，有好一陣子沒有發文了，雖然手上有幾個在進行的學習或者project，但進度都還沒到可以發表文章的程度。剛好最近工作上有一個之前沒碰過的問題，花了一些時間做處理，因此在這邊簡單地記錄一下。 問題敘述 在某個上班日的下午，筆者突然收到來自前端工程師的訊息，在跑CI process時GitLab Runner好像出了問題，導致pipeline fail了。經查詢後，發現是該Runner所在的VM disk 容量已達99.9%，已經不能夠再pull任何的image下來了。 GitLab Runner在執行CICD job時，會pull許多暫時的image來完成任務。在敝公司的每一台Runner中，都有一個固定於每日凌晨執行的cronjob來清除這些job產生出來的image、volume以及build cache等。因此在一開始，筆者懷疑cronjob是否根本沒有如期執行，從而往system log去查看，想確認cronjob執行的狀況。 不料，cronjob的確有在指定的時間執行。但僅從system log並沒有辦法得知更詳細的資訊——例如執行前的硬體容量多少？執行後多少？如果cronjob確實有做容量的清除，那麼硬碟滿載的情況下大都在一天中的何時發生？SRE該如何即時得知這些訊息？ 可以從以上資訊得知，Gitlab Runner所在的虛擬機缺乏監控設施，導致我們沒有辦法即時、有效地獲得系統狀況，進而做出適合的判斷與解決方案。因此，建立系統的可觀測性便是開始解決問題的第一步。 建立系統可觀測性：收集系統指標 敝公司的其他專案使用Prometheus + Grafana作為主要監控工具之一，又筆者只需要監控Linux中的系統指標，Prometheus已有現成的exporter可以做使用。綜合考量下，筆者在每一台Runner起了node_exporter的container以收集host-level的metrics，再使用Grafana去收集這些指標，繪製成可視化圖表。 在這邊提一個小題外話，筆者先前也有自己實作過host-level的metrics exporter，只不過當時單純地認為，如果使用container部署這個服務，那麼觀察的指標不就只限於container裡面了嗎？事實上，在萬物皆檔案(Everything is a file)的Linux當中，我們可以在/proc、/sys等目錄找到CPU、Memory、Disk相關的資訊，因此如果想觀察host的指標，就只需要把host的檔案目錄掛載到container中就可以了！ node_exporter的官方GitHub中就給了docker-compose.yaml的最佳範例： --- version: '3.8' services: node_exporter: image: quay.io/prometheus/node-exporter:latest container_name: node_exporter command: - '--path.rootfs=/host' network_mode: host pid: host restart: unless-stopped volumes: - '/:/host:ro,rslave' 在監控與告警皆架設完成後（這部分其實還有一些細碎的小東西可以談，例如告警的閾值怎麼設？要監控哪些指標？因為怕偏離重點，先暫且不提），筆者發現，在上班時間，每一台Runner的硬碟佔用量已達全部容量的70~80%，約是400多GB左右，那自然是撐不到在半夜執行的cronjob。此外，即便筆者手動執行完docker system prune -a -f這個可以清除unused container、image以及building cache的指令，也只清除了80G左右的容量。 基本上，每一台Runner所在的虛擬機就只有裝Runner這個應用程式，而且部署方式還是container，怎麼會佔用快要400GB的容量呢？ 最後，透過資深同事的幫助，以下列指令發現這龐大的體積來源來自於Docker下面的overlay2資料夾。光是這個資料夾就佔用了300多GB。 du -ch --max-depth=1 /datadrive/docker/ Docker v25後才修復的bug 難道是連docker system prune都沒有辦法清理overlay嗎？錯了，docker system prune這個指令就是拿來清除任何暫停的container、沒有在使用的network, images, build cache。之所以會沒辦法完全清除，是因為這是Docker v25以前的一個bug（剛好敝公司使用的版本是v24…）...