docker容器日志存儲多久

docker容器運行后容器日志會一直存儲，時間久后會出現日志文件過大，從而導致查詢日志困難，容器日志一般會在docker持久化目錄containers下對應不同鏡像名稱以*-json.log形式展現。Docker是一個開源的應用容器引擎，讓開發者可以打包他們的應用，以及依賴包到一個可移植的鏡像中，然后發布到任何流行的Linux或Windows操作系統的機器上，也可以實現虛擬化。容器是完全使用沙箱機制，相互之間不會有任何接口。

小編還為您整理了以下內容，可能對您也有幫助：

對docker容器產生的日志做輪轉

logrotate是Linux系統的日志輪轉程序，能夠對系統產生的日志自動管理

logrotate配置文件在/etc/logrotate.d下,創建對docker容器日志輪轉的配置文件

第一行添加要輪轉的日志的位置

daily 表示按天輪轉 還有 hourly, weekly,monthly ,yearly

weekly 指定轉儲周期為每周

monthly 指定轉儲周期為每月

rotate 轉儲次數，超過將會刪除最老的那一個

copytruncate 這個參數如果不添加的話，logrotate程序會將日志

missingok 忽略錯誤，如“日志文件無法找到”的錯誤提示

dateext 切換后的日志文件會附加上一個短橫線和YYYYMMDD格式的日期

compress 通過gzip 壓縮轉儲舊的日志

delaycompress 當前轉儲的日志文件到下一次轉儲時才壓縮

notifempty 如果日志文件為空，不執行切割

sharedscripts 只為整個日志組運行一次的腳本

prerotate/endscript 在轉儲以前需要執行的命令可以放入這個對，這兩個關鍵字必須單獨成行

postrotate/endscript 在轉儲以后需要執行的命令可以放入這個對，這兩個關鍵字必須單獨成行

size 　size當日志文件到達指定的大小時才轉儲，Size 可以指定 bytes (缺省)以及KB (sizek)或者MB (sizem).

對zabbix-agent日志進行配置，創建zabbix-agent文件即可

logrotate可以在任何時候從命令行手動調用

Docker 容器的日志大家都是怎么處理的

Docker時代的日志，步子并未跨得太大，畢竟安全第一。然而，不可否認發展的時代總有讓你意想不到的亮點。

如果你是容器中的應用，哪怕你是始亂終棄，抑或是灑脫不羈，Docker容器都會記錄下你的點點滴滴，只要你對著標準輸出標準錯誤說一句action。（Docker容器所有的標準輸出標準錯誤都會被Docker Daemon接管）

如果你是個閱盡人間無數，拳打南山，腳踢北海，四海流竄的Docker容器，你在北京的One Night，興許第二天在上海的你早已酒醒如初；第三天出差杭州的你，更是不記得昨天在上海住的是幾星級賓館。（Docker容器本身理應盡量無狀態，容器內應用持久化的日志則有狀態，頻繁遷移不宜容器日志管理）。

如果你有一部腎機，如果你繼續支持大表姐。Docker容器中的你，很容易將容器走南闖北的經歷傳至云端，以便他日傳看。（Docker容器的應用日志，如果自己發往集中的日志處理中心，則為上上策，易統一；問題是成本高，得有錢買腎機，還需統一化的標準）

Docker(5)——數據管理

docker 容器的文件系統在宿主機上存在的方式很復雜，這會帶來下面幾個問題：

為了能夠 保存（持久化） 數據以及 共享 容器間的數據，docker 引入了數據卷(volume) 機制。數據卷是存在于一個或多個容器中的特定文件或文件夾，它可以繞過默認的聯合文件系統，以正常的文件或者目錄的形式存在于宿主機上。

其生存周期于容器的生存周期。

容器中主要有 兩種 管理數據方式： 數據卷(Data Volumes) ， 數據卷容器(Data Volume Containers) 。

數據卷是一個可供容器使用的特殊目錄，它繞過文件系統，可以提供很多有用的特性：

數據卷的使用類似 linux 下對目錄或文件進行 mount 操作，目前Docker提供了 三種 不同的方式將數據從宿主機掛載到容器中，分別是

其中 volume 、 bind mount 比較常用， tmpfs mount 基本不會用.

volumes作為Docker管理宿主機文件系統的一部分 ，默認位于 /var/lib/docker/volumes 目錄中，不是宿主機已有數據，而是新建的。

docker 專門提供了 volume 子命令來操作數據卷：

先創建一個名稱為 hello 的數據卷并通過 ls 命令進行查看：

然后可以使用 inspect 命令看看數據卷hello的詳細信息

該數據卷使用的 Driver 為默認的 local ，表示數據卷使用宿主機的本地存儲;

Mountpoint 是 volumes 的掛載點，默認是本機 /var/lib/docker/volumes 下的一個目錄。

所有Container的數據都保存在了這個目錄下邊，由于沒有在創建時指定卷，所以Docker幫我們默認創建許多匿名卷。

使用 -v 選項也可以指定掛載一個本地的已有目錄到容器中去作為數據卷：

docker run -it –-name robot1 -v /var/data:/opt/mydata ros/kinetic /bin/bash

上面的命令掛載主機的 /var/data 目錄到容器的 /opt/mydata 目錄。

這個功能在測試的時候特別方便，比如用戶可以放置一些程序或數據到本地目錄中，然后在容器中使用。另外，本地目錄的路徑必須是絕對路徑，如果目錄不存在，Docker 會自動創建。

Docker 掛載數據卷的默認權限是可讀寫 rw ，用戶也可以通過 ro 標記指定為只讀：

docker run -it –-name robot1 -v /var/data:/opt/mydata:ro ros/kinetic /bin/bash

加了 :ro 之后，容器內掛載的數據卷內的數據就變成只讀的了。

除了把數據卷中的數據存儲在宿主機，docker 還允許我們通過指定 volume driver 的方式把數據卷中的數據存儲在其它的地方，比如 Azrue Storge 或 AWS 。

通過 vieux/sshfs 驅動把數據卷的存儲在云主機上，docker 默認是不安裝 vieux/sshfs 插件的，我們可以通過下面的命令進行安裝：

docker plugin install --grant-all-permissions vieux/sshfs

然后通過 vieux/sshfs 驅動創建數據卷，并指定遠程主機的登錄用戶名、密碼和數據存放目錄：

注意：確保指定的遠程主機上的掛載點 /home/nick/sshvolume 目錄是存在的，否則在啟動容器時會報錯。

最后在啟動容器時指定掛載這個數據卷：

在容器中 /world 目錄下操作的文件都存儲在遠程主機的 /home/nick/sshvolume 目錄中。進入容器 testcon 然后在 /world 目錄中創建一個文件，然后打開遠程主機的 /home/nick/sshvolume 目錄進行查看，新建的文件會出現在那里。

當使用 bind mounts 將主機上的目錄掛載到容器中時，目錄由其在主機上的完整或相對路徑引用。

bind mount 和 volume 其實都是利用宿主機的文件系統，不同之處在于volume是docker自身管理的目錄中的子目錄，所以不存在權限引發的掛載的問題，并且目錄路徑是docker自身管理的，所以也不需要在不同的服務器上指定不同的路徑，不需要關心路徑

bind mounts 可以掛載在宿主機系統的任意位置 ，但 bind mount 在不同的宿主機系統是不可移植的，比如Windows和Linux的目錄結構是不一樣的， bind mount 所指向的 host 目錄也不能一樣。這也是為什么 bind mount 不能出現在Dockerfile中的原因，因為這樣Dockerfile就不可移植了。

如果使用 Bind mounts 掛載 宿主機目錄 到 容器內非空目錄 ，那么 此容器中的非空目錄中的文件會被隱藏 ，容器訪問這個目錄時能夠訪問到的文件均來自于宿主機目錄。這也是Bind mounts模式和Volumes模式最大的行為上的不同。

掛載存儲在宿主機系統的內存中，而不會寫入宿主機的文件系統；

這張圖說明 bind mount 和 volume 其實都是利用宿主機的文件系統， Bind mounts 模式是將宿主機上的任意文件或文件夾掛載到容器，而 Volumes 本質上是將Docker服務管理的一塊區域（默認是 /var/lib/docker/volumes 下的文件夾）掛載到容器。所以 volume 不存在權限引發的掛載的問題，并且目錄路徑是docker自身管理的，所以也不需要在不同的服務器上指定不同的路徑，不需要關心路徑。

相對于 bind mount ， volume 是Docker Engine在自己的“地盤”分配了一個路徑作為掛載點，自己地盤的權限肯定是安排的明明白白。所以，以上掛載宿主機路徑的問題都解決了。

在使用 volume 作為數據卷掛載到容器時，直接用 volume 名稱代替宿主機路徑名就行：

docker run -d -v test_vol:/var/data some_image

這樣就將數據卷 test_vol 掛載到了容器內的 /var/data 目錄下。

命名的容器掛載數據卷，其它容器通過掛載這個(父容器)實現數據共享，掛載數據卷的容器，稱之為數據卷容器

可以利用數據卷容器對其中的數據卷進行備份、恢復，以實現數據的遷移。

備份

使用下面的命令來備份 mydata 數據卷容器內的數據卷：

sudo docker run --volumes-from mydata -v $(pwd):/backup –-name worker ubuntu tar cvf /backup/backup.tar /data

這個命令首先利用 Ubuntu 鏡像創建了一個容器 worker。又使用 --volumes-from mydata 參數來讓 worker 容器掛載 mydata 容器的數據卷。接下來使用 -v $(pwd):/backup 參數來掛載本地的當前目錄到 worker 容器的 /backup 目錄。

在 worker 容器啟動后，使用了 tar cvf /backup/backup.tar /data 命令來將 /data 下內容備份為容器內的 /backup/backup.tar，即宿主主機的當前目錄下的backup.tar。

恢復

如果要恢復數據到一個容器，可以按照下面的操作。首先創建一個帶有數據卷的容器 mydata2:

sudo docker run -v /data –-name mydata2 ubuntu /bin/bash

然后創建另一個新的容器，掛載 mydata2 的數據卷，并使用 tar 解壓縮備份文件到所掛載的容器卷中：

sudo docker run --volumes-from mydata2 -v $(pwd):/backup busybox tar xvf /backup/backup.tar

如果用戶需要在容器之間共享一些持續更新的數據，最簡單的方式是使用數據卷容器。數據卷容器其實就是一個普通的容器，專門用它提供數據卷供其他容器掛載。下面簡單介紹其使用方法。

首先要創建一個數據卷容器 mydata，并在其中創建一個數據卷掛載到 /data 目錄。

sudo docker run -it -v /data –-name mydata ubuntu

然后在其他容器中使用 --volumes-from 來掛載 mydata 容器中的數據卷。例如創建兩個容器 mycon1 和 mycon2，并從 mydata 容器掛載數據卷：

sudo docker run -it --volumes-from mydata –-name mycon1 ubuntu

sudo docker run -it --volumes-from mydata –-name mycon2 ubuntu

(注意，命令中沒有指定數據卷的信息，也就是說新容器中掛載數據卷的目錄和源容器中是一樣的。)

此時容器 mycon1 和 mycon2 都掛載同一個數據卷到相同的目錄 /data。三個容器任何一個在該目錄下寫入數據其他容器都能看到。

可以多次使用 --volumes-from 參數來從多個容器掛載多個數據卷。還可以從其他已經掛載了容器的容器來掛載數據卷。并且使用 --volumes-from 參數所掛載數據卷的容器自身并不需要保持在運行狀態。

但刪除掛載了數據卷的容器時，數據卷并不會被自動刪除。如果要刪除一個數據卷，必須在刪除最后一個還掛載著它的容器時顯式的使用 docker rm -v 命令來指定同時刪除關聯的容器。

如何對已經運行的容器掛載目錄？

https://blog.51cto.com/hjun169/2440799

手動修改mount掛載的json文件，狂神的那個視頻里面也有寫。

深刻理解Docker鏡像大小

https://blog.csdn.net/shlazww/article/details/47375009

理解docker的分層鏡像實現 base 鏡像共享（DockerFile）

https://blog.csdn.net/lu_1110/article/details/106533490

docker查看日志命令

如何查看docker日志，讓我們一起了解一下？

通過docker logs可以查看容器的日志命令。高效的監控和日志管理對保持生產系統持續穩定的運行以及排查問題至關重要。在微服務架構中，由于容器的數量眾多以及快速變化的特性使得記錄日志和監控變得越來越重要。

docker查看日志的幾個方式：

1、docker logs --tail=1000 容器名稱 （查看容器前多少行的日志）（推薦）

2、docker 容器啟動后,可以進入以下位置查看日志（/var/lib/docker/containers/容器ID/容器ID-json.log）（進入容器內部查看日志）

3、#查看compose所有容器的運行日志

docker-compose -f docker-compose-app.yml logs -f

4、#查看compose下某個容器的運行日志

docker-compose -f docker-compose-app. yml logs -f服務名>

5、# 也可以把compose的容器日志輸出到日志文件里去，然后用tail -f隨時查看

docker-compose -f docker-compose-app. yml logs -f >> myDockerCompose.log &

具體操作如下：

docker attach [options] 容器會連接到正在運行的容器，然后將容器的標準輸入、輸出和錯誤流信息附在本地打印出來。命令中options的取值有三種：--detach-keys,--no-stdin,--sig-proxy。

該命令只是進入容器終端，不會啟動新的進程。所以當你同時使用多個窗口進入該容器，所有的窗口都會同步顯示。如果一個窗口阻塞，那么其他窗口也就無法再進行操作。

使用ctrl+c可以直接斷開連接，但是這樣會導致容器退出，而且還stop了。如果想在脫離容器終端時，容器依然運行。就需要使用--sig-proxy這個參數。例如：

$ docker attach --sig-proxy=false mytest

注意： 當使用docker attach連接到容器的標準輸入輸出時，docker使用大約1MB的內存緩沖區來最大化應用程序的吞吐量。如果此緩沖區填滿，那么輸出或寫入的速度將會受到影響。因此查看應用日志，可以使用docker logs命令。

docker日志存儲位置，設置docker容器日志大小

在Linux系統中docker啟動后日志存儲在 /var/lib/docker/containers/容器ID/ 目錄中，啟動一個容器后，容器ID目錄中會生成如下文件：

每個容器的日志默認都會以 json-file 的格式存儲于 /var/lib/docker/containers/<容器id>/<容器id>-json.log 下，不過并不建議去這里直接讀取內容，因為容器的日志則可以通過 docker logs 命令來訪問，而且可以像 tail -f 一樣，使用 docker logs -f 來實時查看。如果使用 Docker Compose，則可以通過 docker-compose logs <服務名> 來查看。

從上面可以知道docker容器日志存儲在文件中，容器銷毀后 /var/lib/docker/containers/<容器id>/ 目錄會被自動刪除，所以容器日志也被一并刪除。如果容器一直運行并且一直產生日志，容器日志會導致磁盤空間爆滿，如何解決這個問題？

新建 /etc/docker/daemon.json ，若有就不用新建了。添加log-dirver和log-opts參數，如下：

設置完成之后，需要刪除容器，并重新啟動容器，我們可以看到 /var/lib/docker/containers/<容器id>/hostconfig.json 文件的變化如下：

設置 log-opts 之前：

設置 log-opts 之后：

在k8s集群中docker容器日志 /var/lib/docker/containers/容器ID/ 目錄的文件如下：

與docker容器目錄相比少了一些文件：hostname、hosts、resolv.conf、resolv.conf.hash

k8s通過 sandbox(pause容器，關于pause容器的介紹可以查閱資料) 關聯了這些文件，通過查看 cat config.v2.json 可以發現如下配置：

使用命令 cat /var/lib/docker/containers/<容器id>/hostconfig.json 查看 hostconfig.json 的內容，發現有如下設置：

查看 /etc/docker/daemon.json 發現有如下配置：

下面列出了一個容器的日志文件達到設置值的情況：

參考文檔：

Docker 日志都在哪里？怎么收集？

Docker容器日志查看與清理

Docker日志收集

Docker的應用為我們帶來便利的同時，日志集中化問題就越來越有必要性了。

在收集之前，我們先來簡單了解下docker日志處理的機制。當啟動一個容器的時候，它其實是docker daemon的一個子進程，docker daemon可以拿到你容器里面進程的標準輸出，拿到標準輸出后，它會通過自身的一個LogDriver模塊來處理，LogDriver支持的方式很多，可以寫到本地的文件（默認方式），可以發送到syslog等，見下圖：

目前，常見的收集方式有下面幾種：

在日志收集的過程中，需要特別考慮性能的問題。試想一下，當容器的流量比較大的時候，勢必日志也會隨著大量地產生，這時就會有個問題，日志收集agent必然會跟容器搶占宿主機的資源，為了避免這個問題，在收集選型的時候就需要注意：

綜上所屬，最佳實踐就是采用 旁路模式 來收集，并且使用容器方式來運行并限定使用的資源；最終采用了 logspout+Fluentd 的方案（架構圖見下），采用的理由如下：

logspout通過docker.sock監聽本地容器的啟動，通過docker API獲取到這個新容器的日志流，并將這個日志流通過udp的協議發送給fluentd處理，fluentd處理完成后發送給后續的日志系統。

最后，受阿里云fluentd-pilot的影響，我將官方的logspout進行一些小的修改， 請見 ：

下面個出個docker-compose.yml, 通過docker-compose up就可以運行了；

fluent的簡單配置：

最后，可以通過查看fluent的log來查看格式化的容器日志；

微服務基礎服務之docker篇

什么是docker

Docker 最初是 dotCloud 公司創始人 Solomon Hykes 在法國期間發起的一個公司內部項目，它是基于 dotCloud 公司多年云服務技術的一次革新，并于 2013 年 3 月以 Apache 2.0 授權協議開源，主要項目代碼在 GitHub 上進行維護。Docker 項目后來還加入了 Linux 基金會，并成立推動 開放容器聯盟（OCI）。

Docker 使用 Google 公司推出的 Go 語言 進行開發實現，基于 Linux 內核的 cgroup，namespace，以及 AUFS 類的 Union FS 等技術，對進程進行封裝隔離，屬于 操作系統層面的虛擬化技術。由于隔離的進程于宿主和其它的隔離的進程，因此也稱其為容器。最初實現是基于 LXC，從 0.7 版本以后開始去除 LXC，轉而使用自行開發的 libcontainer，從 1.11 開始，則進一步演進為使用 runC 和 containerd。

Docker 在容器的基礎上，進行了進一步的封裝，從文件系統、網絡互聯到進程隔離等等，極大的簡化了容器的創建和維護。使得 Docker 技術比虛擬機技術更為輕便、快捷。

下面的圖片比較了 Docker 和傳統虛擬化方式的不同之處。傳統虛擬機技術是虛擬出一套硬件后，在其上運行一個完整操作系統，在該系統上再運行所需應用進程；而容器內的應用進程直接運行于宿主的內核，容器內沒有自己的內核，而且也沒有進行硬件虛擬。因此容器要比傳統虛擬機更為輕便。



傳統虛擬化



Docker

為什么要用docker

對開發和運維（DevOps）人員來說，最希望的就是一次創建或配置，可以在任意地方正常運行。

使用 Docker 可以通過定制應用鏡像來實現持續集成、持續交付、部署。開發人員可以通過 Dockerfile 來進行鏡像構建，并結合 持續集成(Continuous Integration) 系統進行集成測試，而運維人員則可以直接在生產環境中快速部署該鏡像，甚至結合 持續部署(Continuous Delivery/Deployment) 系統進行自動部署。

而且使用 Dockerfile 使鏡像構建透明化，不僅僅開發團隊可以理解應用運行環境，也方便運維團隊理解應用運行所需條件，幫助更好的生產環境中部署該鏡像。

特性容器虛擬機 啟動秒級分鐘級 硬盤使用一般為MB一般為GB 性能接近原生弱于 系統支持量單機支持上千個容器一般幾十個

基本概念

我們都知道，操作系統分為內核和用戶空間。對于 Linux 而言，內核啟動后，會掛載 root 文件系統為其提供用戶空間支持。而 Docker 鏡像（Image），就相當于是一個 root 文件系統。比如官方鏡像 ubuntu:18.04 就包含了完整的一套 Ubuntu 18.04 最小系統的 root 文件系統。

Docker 鏡像是一個特殊的文件系統，除了提供容器運行時所需的程序、庫、資源、配置等文件外，還包含了一些為運行時準備的一些配置參數（如匿名卷、環境變量、用戶等）。鏡像不包含任何動態數據，其內容在構建之后也不會被改變。

鏡像（Image）和容器（Container）的關系，就像是面向對象程序設計中的 類 和 實例 一樣，鏡像是靜態的定義，容器是鏡像運行時的實體。容器可以被創建、啟動、停止、刪除、暫停等。

前面講過鏡像使用的是分層存儲，容器也是如此。每一個容器運行時，是以鏡像為基礎層，在其上創建一個當前容器的存儲層，我們可以稱這個為容器運行時讀寫而準備的存儲層為容器存儲層。

按照 Docker 最佳實踐的要求，容器不應該向其存儲層內寫入任何數據，容器存儲層要保持無狀態化。所有的文件寫入操作，都應該使用 數據卷（Volume）、或者綁定宿主目錄，在這些位置的讀寫會跳過容器存儲層，直接對宿主（或網絡存儲）發生讀寫，其性能和穩定性更高。

數據卷的生存周期于容器，容器消亡，數據卷不會消亡。因此，使用數據卷后，容器刪除或者重新運行之后，數據卻不會丟失。

鏡像構建完成后，可以很容易的在當前宿主機上運行，但是，如果需要在其它服務器上使用這個鏡像，我們就需要一個集中的存儲、分發鏡像的服務，Docker Registry 就是這樣的服務。

一個 Docker Registry 中可以包含多個倉庫（Repository）；每個倉庫可以包含多個標簽（Tag）；每個標簽對應一個鏡像。

通常，一個倉庫會包含同一個軟件不同版本的鏡像，而標簽就常用于對應該軟件的各個版本。我們可以通過 <倉庫名>:<標簽> 的格式來指定具體是這個軟件哪個版本的鏡像。如果不給出標簽，將以 latest 作為默認標簽。

Centos安裝docker18

常用的docker命令

常用的docker鏡像

redis

mysql

細說kubernetes - 為什么是pod？

k8s作為現在最火的容器編排調度平臺，好用我也就不必多說了。當我們初識k8s的時候一個新的概念就到了我們眼前，那就是pod。我們在使用了之后也就漸漸的接受了pod這個東西，但是你有沒有想過，為什么是pod？k8s為什么會有這樣的設計？今天我們就來細細說說這個pod

首先我們來回憶看看k8s的架構圖是什么樣子的

從架構圖中我們可以看到，整個k8s的設計架構有以下幾個要點：

當然其他組件都非常重要，這個我們以后再說，我們今天就來看看主角“pod”

一開始用的時候我就好奇為什么k8s要弄出一個pod，因為我們一開始使用的是docker，操作的是docker容器，構建的也是docker鏡像，為什么不直接調度docker容器就好了，這樣粒度不是更加細致，調度也會更加方便嗎？

我們在使用k8s之前也使用過docker-compose，從另一個角度說，這也是一種容器的管理，看起來也挺好的。

下面我們就來說說pod

從上面的圖你大概可以感受到pod在k8s中其實是一個什么樣的角色。

我們如果使用虛擬機，那么上面就會有一系列的服務這些服務可能會有一些依賴，而這樣的依賴就好像在服務器中運行的一個個進程組，往往其中也有著相關的依賴，而pod中的容器也是一樣的道理，其中也會有類似這樣的依賴，為了更好的描述和管理這樣的依賴，于是就有了pod。

其實這樣的理念往往可以類比出很多這樣的設計。

一定會有這樣的關系嗎？我的感覺是，在現代技術服務的開發的過程中，這樣的關系是不可避免的。我下面來舉幾個例子。

我們知道 java 的 web 應用往往需要部署在tomcat這樣的容器之中，在 springboot 還沒有出現以前，需要自己啟動一個 tomcat 容器，然后將需要部署的應用打包部署到容器中去。

在以前你可能會想著，將 javaweb 打包一個war，然后編寫一個 dockerfile 將 war 包cp到 tomcat 中的 webapp 目錄中。但是這樣帶來的就是每次更新發布的時候，鏡像會很大，因為每次構建都會有一個基礎的tomcat鏡像。

而在k8s使用的時候，會有的設計的是，將tomcat作為一個不變的鏡像（它也不應該改變）而把 war 包作為另外一個容器，而這樣個容器同時掛載同一個目錄，將 webapp 掛載的目錄與 war包掛載的目錄相同來達到目的，然后將他們放到同一個 pod 中。

類似的操作還有： https://kubernetes.io/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/ 里面說的就是前端靜態頁面和 nginx 的關系。

下面引用官網設計理念中的一句話：“ 比如你運行一個操作系統發行版的軟件倉庫，一個Nginx容器用來發布軟件，另一個容器專門用來從源倉庫做同步，這兩個容器的鏡像不太可能是一個團隊開發的，但是他們一塊兒工作才能提供一個微服務；這種情況下，不同的團隊各自開發構建自己的容器鏡像，在部署的時候組合成一個微服務對外提供服務。 ”

在使用 docker 部署項目的時候會遇到一個問題就是日志持久化的問題，因為 docker 容器如果被刪除的話，其中的文件也會被刪除，那么我們的日志文件同時也會被刪除，也就是說我們必須要將日志持久化。

最常見的方式是，將日志存儲的目錄掛載到宿主機上，這樣容器被刪除的時候日志不會被刪除。

而在k8s中常見的日志處理架構是怎么樣的呢？

https://kubernetes.io/zh/docs/concepts/cluster-administration/logging/

使用的是 sidecar，這個是什么呢？其實就是一個輔助性質的容器，同時與主容器放在同一個 pod 中，讀取主容器掛載出來的日志目錄。其實后續還可以做更多的操作，比如日志發送es等等。

總之我們可以看到，在一個pod中的容器關系是非常密切的，他們可以擁有同一個目錄，甚至可以擁有同一個網絡，可以擁有相互的服務，這樣的關系我聽過的名詞叫做“超親密關系”。就類似一對夫妻之間的關系了。

因為在現在的多說應用中，已經幾乎做不到一個人頂天立地了，總是會有各種各樣的依賴，依賴一些組件，依賴一些工具，依賴一些網絡服務等等，一個進程組有很多的進程互相幫助來最終實現功能一樣。

這樣的關系太過常見，于是k8s就將它設計為了pod。

如果你已經對docker的實現比較熟悉，其實pod的實現并不復雜。（如果對docker實現不熟悉可以翻看之前的博客）

其實pod是一個邏輯上的概念，其實pod做的事情很簡單：

其實k8s做的就是初始化一個infra的容器（這是一個很小的容器），利用這個容器去搶先占用需要使用的 Namespace ，然后在將用戶指定的容器加載進來，同時使用的就是相同的 Namespace 了。（如果有 InitContainer 會優先按順序初始化它，圖上就不做說明了）

這樣共享網絡應該是沒有問題了，那么要共享Volume也很簡單。pod 只需要將 Volume 目錄掛載到宿主機，讓內部的容器掛載這個目錄就可以了。

再來說說pod還有哪些功能，這些功能也是k8s為什么設計pod的原因之一

通過Probe：LivenessProbe或者ReadinessProbe，可以探測應用是否處于健康狀態，如果不健康做出相關的反應。

這就好比k8s可以定期的幫你監控、維持一整個應用的健康。

其實在我們看來，很多時候服務掛了，需要重啟，需要做高可用，那么nginx呢？tomcat呢？也是一樣的。所以pod的健康能保證整個服務的全部健康使用。

我們可以通過給Pod增加kubernetes.io/ingress-bandwidth和kubernetes.io/egress-bandwidth這兩個annotation來Pod的網絡帶寬。

為什么我提到了這個功能呢？因為在實際的業務開發過程中經常會使用一些網絡插件，這些網絡插件在流量的控制上非常有用，有的時候我們會根據網絡流量來做一系列的操作，用戶的突然增長導致的流量劇增是否要擴容等等...而這樣的監控和對于pod來說無疑會更加方便，而不需要管pod內部的容器的流量。

重啟的策略，這個也算是一個功能吧

官網：一個Pod（就像一群鯨魚，或者一個豌豆夾）。

我覺得 Pod 更證明了一種設計模式“組合”，在有的時候會，組合的合理，就會方便很多東西，比如設計了一堆組件，組合在一起；ps畫圖的時候方塊更圓組合在一起，就可以一起多復制幾個組合。

當然我們在認識到為什么要這樣設計 Pod 的同時需要意識到，我們應該將什么樣的容器組合放置在同一個 Pod 之中才比較合適。遵循一定的“容器設計模式”進行編排，調度的時候才會更加得心應手。

docker | 定時清理docker容器日志

使用linux的crontab命令每天晚上2點定期執行腳本清空容器日志

0 0 2 * * ? /opt/docker-sh/clean_docker_log.sh

將日志輸出到Docker容器外

我們可以利用 docker logs 命令查看 Docker 容器內部應用程序運行時所產生的日志，可以免除首先進入 Docker 容器，再打開應用程序的日志文件的過程。docker logs 會監控容器中操作系統的標準輸出設備（STDOUT），一旦 STDOUT 有數據產生，就會將這些數據傳輸到另一個“設備”中，該 Docker 的被稱為“日志驅動（Logging Driver）”

例如，我們有一個容器實例 ID 為 “da6743d61e1a” ，隨后我們使用 docker logs 命令，查看 da6743d61e1a 容器的日志

此時，Docker 日志也在同步輸出，輸出的日志類似下面這樣。

Docker 是怎樣做到的呢？或者說，所謂的 Docker 日志驅動，到底做了些什么事情？

我們使用 docker info 命令，可以看到 Docker 容器的相關信息，其中有一項 Logging Driver 的字段。

通過輸入以上命令，將得到Docker 當前所設置的日志驅動類型：journald

其實，Docker 已為我們提供了大量的日志驅動類型。

通過 --log-opt 參數為 json-file 日志驅動添加了兩個選項，max-size=10m 表示 JSON 文件最大為 10MB（超過 10MB 就會自動生成新文件），max-file=3 表示 JSON 文件最多為3個（超過3個就會自動刪除多余的舊文件）

除了在啟動 Docker 容器時，可指定日志驅動以外，還可以通過修改 Docker 配置文件來指定日志驅動。

打開配置文件 /etc/sysconfig/docker ，找到以下配置片段：

可以看出，默認的日志驅動為 journald，把它修改為 syslog

然后重啟 docker

以上眾多日志驅動類型中，較為常用 的是 Syslog，因為 Syslog 是 Linux 的日志系統，很多日志分析工具都可以從 Syslog 中獲取日志，比如流行的 ELK(Elasticsearch、Logstash、Kibana)日志中心。Logstash 用于收集日志，Syslog 中寫入的日志可轉發到 Logstash 中，隨后將日志存入 Elasticsearch 中，最后可通過 Kibana 來查詢日志。

接下來咱們的目標是將 Docker 容器中輸出的日志寫入 Syslog，那么后面需要做的就是將 Syslog 接入 ELK 了。

默認，Linux 操作系統已經安裝了 Syslog 軟件包，但它叫 Rsyslog。實際上，Rsyslog 是 Syslog 標準的一種實現，還有一種叫 Syslog-ng 的第三方實現。雖然 Syslog-ng 的功能較為強大，但我們還是選擇使用 Rsyslog，因為操作系統已經預裝了，我們無須單獨安裝，可以通過以下命令查看 Rsyslog 是否已安裝。

如果要開啟 Rsyslog 服務，我們必須對 Rsyslog 進行配置，打開文件 vi /etc/rsyslog.conf

在 rsyslog.conf 文件中有一段配置，我們需要手工去開啟

重啟 Rsyslog 服務，否則配置無法生效

此時，我們可以查看本地是否對外開啟了 514 端口

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com