本篇文章是一個技術探討文,探討 Docker 是如何使用硬碟空間以及當維運人員發現空間不足時應該要如何清理系統上的空間。
Docker 的便利使用方式使得開發人員可以非常簡的透過的 Container 的概念來運行各式各樣的應用程式,這中間牽扯包含 Image 的建置,抓取以及透過其產生出一個運行的 Container。
隨者時間愈用愈久,系統內可用的空間也會愈來愈少,這時候可以透過 docker system df 來觀看一下目前系統上的空間資訊,主要包含下列四種類型,而每個類型也會包含目前使用量以及可以回收的量有多少
1. Images
2. Containers
3. Local Volumes
4. Build Cache(只有 docker 18.09 後使用 buildkit 才會有)
當 Contaienr 被創建時, /var/lib/docker 底下會有很多檔案以及資料夾都被創建出來,譬如
- /var/lib/docker/containers/ID (資料夾):如果 container 使用的是預設的 logging driver,則 log 檔案都會以 JSON 的格式存放於這個資料夾底下。
所以要注意,當 contaienr 有太多 log 時,其會透過這個方式影響節點檔案系統的容量
- /var/lid/docker/overlay2 (資料夾): 這邊包含了 containers 本身的 read-write layer 的檔案,大部分 Linux 發行版預設都會使用 overlay2 來管理。此外 contaienr 內如果有存放任何額外檔案於系統中,實際上都會放這節點上的這個資料夾內。
接下來作者透過一個實際的範例,讓一個全新的 contaienr 內透過 dd 指令來產生一些檔案,並且觀察上述資料夾的變化以及 docker system df 的結果,最後介紹 docker prune 以及 docker rm 針對 contaienr 的處理。
關於 image 的部分,除了常規使用的 Image 外,還有
1. Dangling images: 不再被參考使用的 image,譬如 ID/Tag 都是 None 的
這邊可以透過 docker image ls -f dangling=true 的指令
文章後半部分還有介紹 docker volume 以及 build cache 的部分,這篇文章非常推薦大家閱讀,除了基本使用外還會介紹底層 docker 實際上用到的資料夾,有了這些概念未來對於如何清除 docker 環境就會更有概念,知道要刪除哪些資料夾以及為什麼要刪除。
https://betterprogramming.pub/docker-tips-clean-up-your-local-machine-35f370a01a78
「linux /var」的推薦目錄:
- 關於linux /var 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於linux /var 在 Kewang 的資訊進化論 Facebook 的精選貼文
- 關於linux /var 在 What goes in /var? - linux - Stack Overflow 的評價
- 關於linux /var 在 Linux Directories Explained - including /etc /home /var /proc /usr 的評價
- 關於linux /var 在 Why are process management files on Linux stored under /var ... 的評價
linux /var 在 Kewang 的資訊進化論 Facebook 的精選貼文
這一系列文總共有三篇,這是第二篇。
上一篇解決了 social network 抓取 head tag 裡面的 title, og data 等問題,但其實還有 search engine 要解決,因為 social network 只看 head,但 search engine 除了 head 以外也會看 body,所以這篇要來解決 body 一模一樣的問題。
傳統的 web 開發方式通常是一條龍開發 (你就是那條龍!),後端取得資料庫的內容,然後組成 HTML 之後丟到瀏覽器上顯示。現代的 web 開發方式通常就是一個前端配一個後端,後端專注於把資料送給前端,前端專注於取得資料後在瀏覽器上面顯示漂漂亮亮的。而傳統方式稱為 server side rendering (SSR),現代方式就稱為 client side rendering (CSR)。兩者開發方式各有優缺,蠻多文章有提過,這裡也就不另外說明了。
比較簡單判斷 CSR/SSR 的方式可以直接在你想知道的網頁,按下 Ctrl+u (Windows, Linux) 打開原始碼,看看實際上顯示的內容跟原始碼是不是差異過大。如果網頁內容很豐富,但原始碼才十幾二十行而已,那可以很粗略的說這是 CSR,如果基本上一致那就可以說是 SSR。
而 search engine 就是靠著原始碼把網頁內容做索引,所以如果谷歌大神到 CSR 的網站爬網頁內容,最後爬到的 body 當然都是同一份內容,這樣子對於 SEO 上是不合格的,所以這裡就要分享一下 Funliday-旅遊規劃 是如何處理這塊的。
第一種方式,可以用 VAR 這三套前端框架各自支援的 SSR 方案來處理,像是 Nuxt.js, Next.js, Angular Universal,這些內容已經有許多前輩分享,這裡就不另外說明了。但要注意一點,就是導入這類的解決方案通常會影響到原本的開發模式,像是 webpack 跟 bootstrapping 的方式就一定會動到,小編是建議對框架真的很熟悉之後,再來用這方式會比較好。
第二種方式,就是這次的重頭戲 prerender 了。prerender 也不是什麼魔法,就是一句話「讓爬蟲看到它應該要看的內容」。如圖所示,當 Nginx 收到 request 之後,發現 user agent 是 googlebot 就轉送到 prerender service,如果是一般 request 就直接丟到後面原本的 web server。
而 prerender service 接到 request 之後,就執行 headless chrome (用程式控制沒介面的 Google Chrome),把原本的網頁用 CSR 處理完之後,再把 HTML 的完整資料傳回給 googlebot,這樣子就達到「讓爬蟲看到它應該要看的內容」的功能了。原本的程式完全不用改,只要在 Nginx 做處理就可以了,也是負擔相對較小的方式。
另外,用了 prerender 之後,原本第一篇為了 title, og data 所做的調整也可以拿掉了。因為 CSR 本來就可以改 title, og data,所以避免重複做一樣的事,app.get("*") 這個 route 裡面關於 metadata 的功能也可以直接刪掉了。
那為什麼還會有第三篇?因為 Funliday 實際在應用 prerender.io 似乎有些問題,所以我們就改成自己寫 prerender 了,原因下回說明。
* Prerender.io:https://prerender.io
#prerender #funliday
linux /var 在 Linux Directories Explained - including /etc /home /var /proc /usr 的推薦與評價
![影片讀取中](/images/youtube.png)
If you are new to Linux then the directory structure can be confusing, but within a few minutes you can understand the essentials. ... <看更多>
linux /var 在 Why are process management files on Linux stored under /var ... 的推薦與評價
Because the /var/run is the blessed directory by FHS standard, for a software's run time data. The /var/run directory was "deprecated", ... ... <看更多>
linux /var 在 What goes in /var? - linux - Stack Overflow 的推薦與評價
... <看更多>