docker pull時的錯誤:failed to register layer

錯誤訊息

有時在下docker pull時會出現如下的錯誤:

解決方案

這是因為有時docker弄亂了其工作空間,可能就是原因。您可以嘗試以下方法:

  • 停止所有(java)容器,刪除它們,刪除Java映像(或所有映像),然後重新拉動並運行。
  • 如果這沒有幫助,則也重新啟動Docker引擎。
  • 如果仍然不能解決問題,請停止docker引擎,刪除docker工作目錄,然後重新啟動docker引擎。

以我的經驗,這可以解決所有類似OP的問題。

相關討論串: Docker error when pulling Java 8 image – “failed to register layer”

docker初探

  1. 安裝docker(於centos7)
  1. 測試用指令
  • 顯示 docker 的資訊
    $ docker info

  • 顯示 docker 的版本
    $ docker version

  • 取得一個指定版本的 image

  • 如果不指定 image 版本該版本則為 latest
    $ docker pull [Image 名稱]:[Image 版本]

  • ex:
    $ docker pull hello-world
    $ docker pull ubuntu
    $ docker pull ubuntu:14.04

  • 顯示 docker 的 images 清單
    $ docker images

  • 透過 iamge 執行並產生一個新的 container
    $ docker run [Image 名稱]:[Image 版本] [執行指令]

  • ex:
    $ docker run hello-world
    $ docker run ubuntu /bin/echo “example 1 – ubuntu”
    $ docker run ubuntu:14.04 /bin/echo “example 2 – ubuntu:14.04”

*********** 我是分隔線 ***********

  • [OPTIONS]:
  • -i, –interactive (互動模式)
  • -t, –tty (配置一個終端機)
  • -d, –detach (在背景執行)

$ docker run [OPTIONS] [Image 名稱]:[Image 版本] [執行指令]

  • ex:
    $ docker run -i -t ubuntu:14.04 bash
    $ exit

  • 查看正在執行的 containers
    $ docker ps

  • 查看所有的 containers
    $ docker ps -a

  • 對正在執行的 container 下執指令

  • [OPTIONS]:

  • -i, –interactive (互動模式)

  • -t, –tty (配置一個終端機)

  • docker exec [OPTIONS] [Container ID] [執行指令]

  • ex:

  • 產生一個 container 在背景執行
    $ docker run -i -t -d ubuntu:14.04 bash

  • 查詢正在執行的 container
    $ docker ps
    $ docker exec -i -t [Container ID] bash
    $ exit

  • 總結

  • 啟動 docker container
    $ docker start [Container ID]

  • 停止 docker container
    $ docker stop [Container ID]

  • 重新啟動 docker container
    $ docker restart [Container ID]

  • ex:

  • 產生一個 container 在背景執行
    $ docker run -i -t -d ubuntu bash

$ docker ps
$ docker stop [Container ID]

$ docker ps
$ docker start [Container ID]

$ docker ps
$ docker restart [Container ID]

  • 刪除 container
    $ docker rm [Container ID]

  • ex:
    $ docker ps
    $ docker stop [Container ID]

$ docker rm [Container ID]
$ docker ps -a

  • 刪除 image

  • 刪除 image 前必需將透過該 image 所產生的 container 移除
    $ docker rmi [Image ID]

  • ex:

  • 移除 hello-world image 所產生的 container
    $ docker ps -a
    $ docker rm [Container ID]
    $ docker ps -a

  • 移除 hello-world image
    $ docker images
    $ docker rmi [Image ID]
    $ docker images


** 小技巧 **************************


  • 停止所有的 containers
    $ docker stop $(docker ps -a -q)

  • 刪除所有的 containers
    $ docker rm $(docker ps -a -q)

  • 刪除所有的 images
    $ docker rmi $(docker images -a -q)

  • 運行容器並掛載主機捲
    Docker容器不會保存它們產生的數據。該過程完成後,容器將停止運行,並且容器中的所有物品都將被移走。

如果要在容器停止後仍要存儲持久性數據,則需要啟用共享存儲卷。

對於安裝卷,請使用-v屬性以及要在其中保存數據的目錄的指定位置,然後是該數據在容器內的位置。

-v [/host/volume/location]:[/container/storage]
整個docker container run命令是:

docker container run -v [/host/volume/location]:[/container/storage] [docker_image]

docker build -t fmsdocker . –no-cache

  • docker file 寫法 / run寫法
    https://docs.docker.com/engine/reference/run/

  • entrypoint
    docker run –entrypoint=/bin/hostname test

  • ENV
    ENV HOSTNAME testhost
    export today=Wednesday
    docker run -e “deep=purple” -e today –rm alpine env

  • HEALTHCHECK
    docker run –name=test -d
    –health-cmd=‘stat /etc/passwd || exit 1’
    –health-interval=2s
    busybox sleep 1d

HEALTHCHECK –interval=5s –timeout=3s
CMD curl ${HOSTNAME}:1111/admin/getServerStats?auser=admin&apswd=pass.123 || exit 1

直播相關教學文章庫

  • 直播點播錄播
  • 直播原理介紹
  • 視訊編解碼
  • 推流介紹
  • 串流格式介紹
  • 播放器介紹

*直播軟體比較

  • 直播品質關鍵
  • SRS-Bench: 搭建直播服务器以后需要对直播性能进行测试,srs-bench 针对特定业务性能测试并发推流来解决

編碼與封裝

前言

要說到影片的編碼與封裝,就要先聊聊影片是怎麼產生的。相信大家小時後都有看過翻頁動畫吧,就是由很多張圖片組成的書,在快速翻書時就可以看到一幅連續的動畫,如下圖:
翻頁動畫
影片的原理也是如此,一張張的照片,經過快速的連續切換,就成為了動態影片。但是這樣子的原始影片大小非常的可觀,若影像的每個畫素的三個顏色RGB各需要一個位元組儲存,每一個畫素需要3位元組,解析度1280×720的影像的大小為2.76M位元組,若每秒FPS為25偵,所需的位元率會達到553Mb/s。這種大小不論是儲存或用網路傳輸都是有困難的,因此編碼壓縮勢在必行。

資料壓縮的難題

音檔和視訊有著完全不同的編碼方式和壓縮理論,音訊編碼的難點在於延時敏感、卡頓敏感、噪聲抑制(Denoise)、回聲消除(AEC)、靜音檢測(VAD)、混音演算法等…每個項目都有各別的演算法去深究如何優化音訊的擷取。

而視訊壓縮編碼的難點則在於編碼效率和編碼複雜度的平衡。例如H.265較H.264在相同的位元率之下有更好的畫質呈現、更小的檔案大小,但相較起來,編碼的複雜度約增加了近十倍。但在實際的應用當中,大多數狀況的編碼端及解碼端的電腦資源不固定,因此在編碼複雜度和編碼效率中取得平衡則是很重要的事。

H264和H265的比較圖
264vs265
來源: H.264和H.265(HEVC)深度解析及對比

影片壓縮衡量單位

位元速率

網路影音多媒體包括音視頻在單位時間內的資料傳輸率時通常使用碼流位元速率來表示,代表每秒傳輸或處理的位元量(資料流量),單位 Mbps (Mb/s) 。
亦可說是所需的最低下載速度,下載速度越低,需越高的壓縮,尤其是破壞性壓縮,故位元速率會影響到影片品質。

  • 相同解析度下,位元率越高,每秒包含的資訊越多,檔案越大、壓縮比越小,影音品質越佳,越吃頻寬及電腦的運算能力,配備不夠好者可能會很卡。
  • 使用較低的位元速率輸出,在靜止畫面差異較小,動態畫面容易產生色塊,畫質低落,整體較不清晰。

我們可以從位元速率去推算最終整個串流檔案的大小,完整的影片則包括『視頻』及『音頻』兩個軌道,其公式如下:

檔案大小(MB為單位) = (音訊編位元速率(KBit為單位)/8 + 視訊編位元速率(KBit為單位)/8)× 影片總長度(秒為單位

而音檔的位元速率公式如下:

位元速率(Bit Per Second) = 取樣率(Hz) x 採用位數 x 聲道數

通常,影片位元速率會受到FPS(每秒幀數)、解析度(指輸出的影像尺寸)、編碼方式(有VBR、CBR、ABR三種)、壓縮演算法(如:H.264、H.265和VP9)影響,音檔則受到取樣率、採用位數(指單次取樣儲存時所占大小,例如電話就是3kHZ取樣的7位聲音,而CD是44.1kHZ取樣的16位聲音)以及聲道數影響,以上幾項的選擇目標是達到位元速率的最小化播放畫質最佳化之間的理想的平衡。

下面針對上面提到的幾個名詞做解釋:

FPS

FPS是Frames Per Second的縮寫,是指每秒鐘重新整理的圖片的幀數,也可以理解為圖形處理器每秒鐘能夠重新整理幾次。越高的幀速率可以得到更流暢、更逼真的動畫。每秒鐘幀數(FPS)越多,所顯示的動作就會越流暢。

解析度

編碼方式

壓縮演算法

影像壓縮原理

資料壓縮是透過去除資料中的冗餘資訊而達成。就視訊資料而言,資料中的冗餘資訊可以分成四類:

  1. 時間上的冗餘資訊(temporal redundancy)
    在視訊資料中,相鄰的影格(frame)與影格之間通常有很強的關連性,這樣的關連性即為時間上的冗餘資訊。

  2. 空間上的冗餘資訊(spatial redundancy)
    在同一張影格之中,相鄰的像素之間通常有很強的關連性,這樣的關連性即為空間上的冗餘資訊。

  3. 統計上的冗餘資訊(statistical redundancy)
    統計上的冗餘資訊指的是欲編碼的符號(symbol)的機率分布是不均勻(non-uniform)的。

  4. 感知上的冗餘資訊(perceptual redundancy)
    感知上的冗餘資訊是指在人在觀看視訊時,人眼無法察覺的資訊。

影音服務介紹

網路串流服務介紹

近年來影音相關的服務越來越火紅,許多的社交軟體都用直播影片來取代舊有的圖文內容。雖然網路影音服務在2000年左右就已經出現,但由於當時的移動設備和網路頻寬的限制,使得網路影音的發展受到很多限制。而在2013年後網路直播開始爆發,進入了直播影片的年代,一開始的網路直播以PC為主,而在移動設備普及後,各種社群媒體的APP更是紛紛支援直播串流功能。因為直播串流的普及、電腦設備及網路速度的進步下,也新興了如了Youtuber、實況主、直播主等這種專門經營此區塊的行業,可謂是非常火紅且受到矚目的一個領域。近年來,通信行業也更多的走向網路化,通訊軟體如Line、Facetime等,漸漸取代了過去的電話、簡訊。最近因5G和IoT的發展,未來應有更多的領域會走向網際網路化。

所有網路影音相關的服務,大致分為『點播』、『直播』和『錄播』。

  1. 所謂點播,其英文為Video On Demand,簡稱VOD。其中Demand意為需求,從字面上理解點播,指的是使用者點選想要看的影片,並將該影片使用實時串流的方式播放出來。相關的服務如:Netflix、Apple TV、HBO等…
    Video On Demand

  2. 直播的英文為Live broadcast,則是直播音視頻會以媒體流的形式推到服務器上(推流)。如果有觀眾收看直播,服務器收到用戶的請求後,會把視頻傳輸到網站、APP、客戶端的播放器,即時播放串流影片。相關的服務平台有Youtube、Facebook Live、Twitch等…
    Live broadcast

  3. 錄播: 一個完整的錄播系統包含了錄製剪輯、直播推送、影片處理等核心功能,配備了相關的軟體和硬體。能夠按照標準產出比較高質量的影片內容,較多使用在線上教學系統上。
    Live record

直播服務的原理

而這30天的系列文章,我們主要會著重在直播的研究,一個完整的直播服務會牽涉到非常多面項領域的技術,從視頻/音頻處理,圖形處理,視頻/音頻壓縮,CDN分發,即時通訊等技術等,每個項目都有很深的技術背景,都需要以年來計算的去鑽研,因此許多部份只會提及基本概念(但光概念就有一大堆艱深知識了…XD…推薦這個系列文,把許多概念知識都整理的很清楚: 30天之即時網路影音開發攻略(小白本))

本系列文主要介紹的重點會放在開源串流伺服器SRS的架設與影片品質調校上(以及相關必要知識)的介紹。

一般來說,一個影片的直播流程要經過以下環節:
採集影像 —> 影像處理 —> 編碼 —> 封裝 —> 推流 —> 串流伺服器 —> 拉流 —> 解封裝 —> 解碼 —> 播放
各個環節都有相關的技術或現成可使用的軟體,如下圖為以SRS伺服器的流程為例:
直播流程

其中,上述的事情發生在三個端點: 直播主的電腦、串流伺服器、觀眾的電腦,各個事件發生的地點如下圖:
直播流程

  1. 採集: 從系統的採集設備中獲取原始音視頻數據,將其輸出到下一個環節。一個影片的採集涉及兩方面數據的採集:音頻採集和影像採集,它們分別對應兩種完全不同的輸入源和數據格式。

  2. 編碼與封裝: 對於視訊資料而言,視訊編碼的最主要目的是資料壓縮。因為動態影像的畫素形式,資料量極為巨大,儲存空間和傳輸頻寬完全無法滿足儲存和傳輸的需求。舉例來說,若影像的每個畫素的三個顏色RGB各需要一個位元組儲存,每一個畫素需要3位元組,解析度1280×720的影像的大小為2.76M位元組,若每秒FPS為25偵,所需的位元率會達到553Mb/s。這樣的資料量無論是儲存或傳輸都不可能,因此編碼非常重要,編碼性能、編碼速度和編碼壓縮比會直接影響整個流媒體傳輸的用戶體驗和傳輸成本。這一部份之後會有各別的文章去介紹。

視訊資訊之所以存在大量可以被壓縮的空間,是因為其中本身就存在大量的資料冗餘。其主要型別有:

  1. 時間冗餘:視訊相鄰的兩幀之間內容相似,存在運動關係
  2. 空間冗餘:視訊的某一幀內部的相鄰畫素存在相似性
  3. 編碼冗餘:視訊中不同資料出現的概率不同
  4. 視覺冗餘:觀眾的視覺系統對視訊中不同的部分敏感度不同
    來源: https://www.itread01.com/content/1547220622.html
  1. 推流: 推流是影響整個直播串流能不能順暢播放的最根本因素,若是步驟2的影片編碼的編碼器效能不好、網路速度不夠,或者編碼的壓縮品質不佳,那麼後面的串流服務再怎麼好,使用者的影片觀看體驗和順暢度也不會好。因此步驟2的編碼,會連帶影響到步驟3的推流的順暢度。因此,像一些推流軟體如OBS,會自動偵測直播主的電腦配備和網路頻寬,去選擇適合的影片壓縮位元率(影響影片的品質)、編碼格式(VP9、MPEG或H.264)、編碼工具(如Quick Sync H.264或x264),以及設定適合的buffer,來達到讓推流能夠順暢的目的。
    現有推流最廣泛被使用的通訊協定為RTMP(Real Time Messaging Protocol),大部份的推流軟體都使用這個協定去做推流。
    FME推流介面
    圖片: FME推流介面

  2. 串流伺服器: 主要的工作為接收推流、轉發給拉流客戶端。現在的直播服務由於需要支援行動設備,隨著flash從網頁裡被淘汰,網頁端多已不能支持rtmp流協定的播放。但因推流的協定仍多為RTMP,因此大多需要經過轉碼的動作,轉為HLS或HTTP-FLV的格式,以支援行動端的播放。這部份伺服器的轉碼工作也會影響到直播的延遲時間。
    所謂『延遲』(latency)就是從直播端到播放端的時間差,造成延遲的原因有很多,因使用網路傳輸,影像串流需要經過編解碼並即時於使用者端播放。考量到網路狀況可能不穩定,又需顧及影片播放的順暢性,客戶端播放器的緩衝設定以及其解碼的速度,也是造成延遲的一大主因。不同傳輸方式其搭配的容器格式亦會影響到延遲的時間,一般來說RTMP的延遲時間約為0.3-1秒間,HTTP-FLV約1-3秒,而HLS則需要至少10秒以上的延遲(以最佳狀況來說)。
    目前市面上較受歡迎的串流伺服器有:
    *FMS: FMS是adobe的流媒體服務器,RTMP協議就是adobe提出來的,FMS一定是重量級的產品。
    *WOWZA: 由Wowza Media Systems開發的串流媒體服務器軟體
    *SRS: 本系列文主要探討的串流伺服器,產品定位是商用互動式社群直播伺服器叢集,支持K8S。
    *NGINX RTMP: 現在非常火紅並且被廣泛使用的開源伺服器
    *CRTMPD: 使用單線程異步socket,在當時處於領先水平,但是當NGINX出現後就漸漸淡出大眾視野了

  3. 拉流: 拉流是指伺服器已有直播內容,根據協議類型(如RTMP、RTP、RTSP、HTTP等),與伺服器建立連接並接收數據,進行拉取的過程。因為RTMP的協定較容易被防火牆檔掉,因此主要移動端的播放都採用HTTP的網路協定去做拉流,包括常見的HTTP-FLV與HLS。

  4. 解碼與播放: 其實所有的串流都會包括音視頻兩個部份,在解碼時會分別解碼音頻和視頻,並且將兩個搭配起來。在這邊播放會遇到的挑戰,很重要的部份就是buffer的設製,buffer會影響到三個點:『首屏』、『延遲』、『卡頓』。首屏指的是點擊畫面後到第一個畫面出來的時間、延遲是指與直播端的時間差、而卡頓則是影片播放時畫面不順暢的次數或時間。一般來說,若觀看端的buffer時間較長,從點擊到看到第一個畫面的時間也會較長、總延遲時間也會變長,但可以在網路狀況較不穩定下仍能維持一定的播放品質。另外若buffer設定的過短,機器的解碼的速度在電腦lag時短暫趕不上,就有可能會出現跳屏的狀況(ex: 從1秒直接跳到3秒),因此這部份也需要經過仔細的調校和設定。

各種傳輸協定比較表

RTMP HTTP-FLV HLS
延遲 0.3-1s 2-3s
傳輸協議 TCP HTTP
瀏覽器支持 N Y
數據分段 連續流 連續流

一般來說,在架設串流伺服器時,應考量用途和需求,去決定要使用那一種直播協議,每一種格式都有其優缺點,這邊有相關的比較文章:RTMP、HTTP-FLV、HLS,你了解常見的三大直播協議嗎

參考資料