把docker鏡像當作桌面系統來用

01-28

本文作者：zasdfgbnm
本文鏈接： 2017/12/28/把docker鏡像當作桌面系統來用/

近些年來，Docker由於提供了一套非常方便地創建並運行應用容器的方法，而在全球掀起了一股容器化的熱潮。容器通過將軟體及其所需要的運行環境一同打包帶走，從而將人們從依賴的苦海中拯救出來。雖然Docker設計的初衷並不是操作系統容器，更不是一個直接運行在裸機上的操作系統，但是docker這套強大的工具也會給我們管理操作系統帶來巨大的便利。

為什麼要用Docker鏡像當作桌面系統？這就要從普通桌面系統的不方便之處說起。通常我們都擁有不止一台電腦，我們希望這些電腦能夠保持一致。這裡所說的「一致」，用一個例子來講，就是我在一台電腦上編輯了一半的文件，不需要認為拷貝到另一台電腦上，而是直接打開電腦就能編輯。如果這個文件只是一個純文本文件，或者一個Microsoft Word文檔，那麼實現這個一致性非常簡單：把文件扔到Dropbox之類的雲同步盤就好。然而對於專業用戶來講，這種一致性的保持並非單純的扔到Dropbox裡面那麼簡單：比如說你最近忙於一個項目，這個項目要用到若干編程語言，然後在電腦里裝了一堆庫，一堆工具軟體，有圖形界面的，也有命令行的。在工作的過程中，你有可能不斷安裝新的工具，或者決定棄用某個之前計劃使用的庫或者工具。要讓你的工作在你的若干台電腦上都能工作，就要一直維護不同機器的環境的一致性：在一台機器上安裝的工具，要在所有機器上重新安裝一遍。在一台機器上升級了的庫，要在所有機器上都升級，稍微有所差池，就有可能出現某個腳本/程序在一台機器上跑的好好的，在另一台機器上卻無法運行的問題。

docker哲學

不熟悉docker的讀者可以戳這裡來了解docker。Docker的使用非常簡單：我們通過寫一個Dockerfile，在Dockerfile中寫入相應的命令來安裝以及配置我們想要的庫跟工具。不熟悉docker的讀者可以看一下下面這個抄來的Dockerfile的例子，來了解一下Dockerfile長啥樣子：

FROM ubuntunMAINTAINER Kimbro StakennRUN apt-get install -y software-properties-common pythonnRUN add-apt-repository ppa:chris-lea/node.jsnRUN echo "deb http://us.archive.ubuntu.com/ubuntu/ precise universe" >> /etc/apt/sources.listnRUN apt-get updatenRUN apt-get install -y nodejsn#RUN apt-get install -y nodejs=0.6.12~dfsg1-1ubuntu1nRUN mkdir /var/wwwnADD app.js /var/www/app.jsnCMD ["/usr/bin/node", "/var/www/app.js"]n

有了Dockerfile，只需要docker build一條命令就可以創建一個docker鏡像。同時Docker公司提供一個叫做DockerHub的服務，可以免費託管公開鏡像。只需要使用docker push就可以直接把鏡像上傳到DockerHub。在不同的電腦上只需要docker pull就可以從DockerHub獲取最新版的鏡像。DockerHub還支持自動構建，通過把DockerHub帳號跟GitHub帳號關聯起來，就可以讓DockerHub在GitHub上面的Dockerfile出現更改的時候自動重新生成鏡像。

本文開頭所說的這種一致性的維護，docker實際上已經在給我們提供答案了：我們通過構建一個docker鏡像，讓這個鏡像包含著我們項目所需要的所有的一切。這樣的話，我們開發，測試，部署等等一切任務，都可以在先用docker run來開啟一個容器，然後在容裡面進行所有的工作。當我們決定修改運行環境，比如引入新的庫的時候，就在Dockerfile中進行相應的修改，重新生成鏡像，然後在不同的機器上用docker pull來更新一下就好。這種使用哲學，通過一個中心化了的倉庫，非常優雅地解決了不同機器上環境一致的問題。美中不足的是，並不是所有的程序都能在容器里運行的，也並不是所有的程序都方便在容器里運行的。如果你用到了圖形界面的程序，或者說是一些系統級別的程序，那麼在容器裡面使用這些程序會麻煩很多，有的甚至根本無法實現。於是自然地就會想到，如果我們能夠在每次開機的時候，直接把某個docker生成的鏡像掛載起來當根目錄來使用，就可以讓這個鏡像直接在裸機上（而不是在容器中）運行，來做我們的日常桌面系統了。

這種做法，除了在保持一致性方面帶來的便利以外，還有一些其他的好處：

整個系統保存在雲端，本地的內容僅僅是雲端的一份緩存而已，這樣就完全沒有必要定期對系統進行備份了。
你的系統是如何從零開始一步一步配置成你想要的樣子的，所有的一切都清晰地展現在Dockerfile裡面。Dockerfile就是你最好的筆記。
完全不用擔心系統長時間使用產生一些殘餘的垃圾文件、或者某些系統中某些程序的數據出現損壞，因為每次開機，我們用的都是一個全新的系統。
要裝一台新機器，並不需要從頭安裝操作系統，只要從DockerHub拉取鏡像拿來用就好，安裝系統這個過程變得極其方便。
系統更新的過程實際上就是根據Dockerfile從最新的軟體倉庫重新從頭安裝生成docker鏡像的過程，不會出現某些更新遇到文件衝突或者依賴無法處理，需要人為干預才能完成的問題。

docker存儲驅動的工作原理

Docker的存儲驅動官方有介紹其工作原理，這裡只是簡單概括一下。Docker使用了層的概念，docker在構建鏡像的時候，會逐行執行我們的Dockerfile中的每一行，每執行一行的時候，docker就會創建出一個新的層來存放新的內容。當我們執行docker pull或者docker push的時候，docker實際上傳跟下載的是這些層之間的增量。每當執行docker run，docker就會把這些下載下來的層組合到一起，組合成一個完整的鏡像，然後新建一個讀寫層，所有運行過程中的寫入都會被寫入到讀寫層中，而鏡像本身則是保持只讀，不會被更改。「層」這個概念具體實現起來，根據docker目錄（通常為/var/lib/docker這個目錄）所在的文件系統的不同而不同，具體的實現在docker中被稱為graph driver，docker自帶的graph driver包括aufs、 overlay、btrfs、zfs、devicemapper等。這些graph driver大多使用了寫時複製的技術，這樣在把各個層組合在一起的過程不需要重新拷貝一份數據，實際的拷貝是在寫入的時候發生的。

由於筆者使用的是btrfs，所以本文就以btrfs為例子來介紹怎麼讓系統啟動到docker鏡像上去。btrfs是一個寫時複製的系統，由於docker的鏡像是由一個一個的層疊在一起組成的，docker在使用btrfs的時候，每往上疊一層，docker就會創建一個原來層的快照，然後把新層的內容寫到快照裡面去。然後docker會在從鏡像創建容器的時候，給鏡像的最頂層做個快照，把這個快照當作容器讀寫層來用。

啟動到docker鏡像中去

明白了docker存儲驅動的工作原理，還需要知道Linux的啟動過程才能達成我們的目標。Linux在啟動的時候，一般會讓啟動器給內核裝載一個內存檔initramfs，然後內核完成簡單的早期初始化以後，就會解壓內存檔的內容到根目錄/，然後啟動內存檔中的init程序（一般為/init），這個init程序會進行進一步的初始化（比如說載入文件系統的驅動，對文件系統進行fsck等），這一步初始化完成了以後，這個init程序就會根據內核選項中的root、rootflags等內容掛載真正的根目錄，然後通過switch_root程序啟動真正根目錄中的init程序，這個init程序則會完成最後的初始化工作，比如掛載fstab、載入圖形界面等等。很多發行版都提供製作initramfs的工具，比如archlinux的mkinitcpio，這些工具通常都是模塊化的，允許用戶自己添加hook。

讓系統啟動到docker鏡像所需要的知識已經完備了。思路也清晰了：通過給initramfs中添加hook，讓initramfs中的init在掛載root之前從docker本地緩存中的鏡像中創建出一個快照作為讀寫層，然後把這個讀寫層當作真正的root來掛載。具體操作上，在啟動管理器裡面寫啟動項的內核選項的時候，root就寫/var/lib/docker所在的分區，而rootflags裡面至少要有一項subvol=XXXXX，其中XXXXX是我們打算創建的讀寫層的位置。然後重中之重則是，寫一個hook，這個hook乾的事情是：找到想要的docker鏡像對應的btrfs子卷，給這個子卷創建一個快照，命名為XXXXX（跟內核選項中的名字保持一致）。這樣的話，在Linux把控制權交給initramfs中的init程序以後，init程序會先去從docker緩存中的子卷創造出XXXXX快照，然後把XXXXX快照當作root來掛載以及進行接下來的操作。如果讀者跟筆者一樣使用Arch Linux的話，那麼所有的這些工作筆者已經做了，讀者可以直接拿來用。

筆者的源碼位於GitHub： https://github.com/zasdfgbnm/mkinitcpio-docker-hooks ，同時讀者也可以直接從AUR中搜索mkinitcpio-docker-hooks來安裝筆者的hook。下面就來介紹一下這個hook的使用方法。

mkinitcpio-docker-hooks的使用

mkinitcpio-docker-hooks的使用流程大概分為如下幾步：

確保你的/var/lib/docker位於某個btrfs分區中
準備一個適合在裸機上啟動的docker鏡像
然後在這個鏡像中安裝並配置mkinitcpio-docker-hooks
準備內核跟initramfs
準備top layer的內容
設置啟動管理器

docker鏡像的準備

要想啟動到docker鏡像中去，首先你得有一個適合在裸機上啟動的docker鏡像。很多docker鏡像，為了減小鏡像的大小，是不會附帶只有裸機上才能用到的軟體包（比如dhcpcd）的，所以讀者可能需要在Dockerfile中手動安裝這些軟體包，對於Arch Linux來講，只需要安裝base組就可以了。由於接下來要安裝mkinitcpio-docker-hooks，這裡推薦使用一個已經內置yaourt的鏡像，筆者使用的是自己的archlinux-yaourt鏡像zasdfgbnm/archlinux-yaourt。所以，Dockerfile的開頭看起來是這個樣子的：

FROM zasdfgbnm/archlinux-yaourtnUSER rootnRUN pacman -Syu --noconfirm basen

作為示例，這裡就不安裝base之外的其他軟體了，讀者請自己根據需要安裝其他軟體。

安裝並配置mkinitcpio-docker-hooks

mkinitcpio-docker-hooks的安裝是在docker裡面而不是當前運行在裸機上的系統中進行的。之所以要把這個軟體包安裝在docker鏡像裡面，很重要的原因是因為Linux內核不提供ABI的穩定性，所以內核模塊跟內核的版本必須嚴格對應，不然模塊是無法載入的。為了保持這種一致性，我們採取的措施是，在docker裡面安裝mkinitcpio-docker-hooks，在docker中生成initramfs，並且在啟動的時候用鏡像裡面的內核啟動，就可以確保內核、initramfs中的模塊、啟動到鏡像以後的/lib/modules三者保持一致。安裝過程在Dockerfile中的寫法如下：

RUN sudo -u user yaourt -S --noconfirm mkinitcpio-docker-hooksn

安裝完了mkinitcpio-docker-hooks以後還需要配置，配置文件在/etc/docker-btrfs.json，初始內容如下：

{n "docker_image": "archlinux/base",n "docker_tag": "latest"n}n

我們需要做的就是把這兩個變數的值替換為我們想要的值，比如說這裡我打算把我的docker鏡像的名字叫做「sample_image」。同時，我們還需要在/etc/mkinitcpio.conf中添加docker-btrfs這個hook。

綜上，可以在Dockerfile中使用如下命令來配置：

RUN sed -i s/archlinux/base/sample_image/g /etc/docker-btrfs.jsonnRUN perl -i -p -e s/(?<=^HOOKS=()(.*)(?=))/$1 docker-btrfs/g /etc/mkinitcpio.confn

現在，我們有了一個完整的示例Dockerfile了：

FROM zasdfgbnm/archlinux-yaourtnUSER rootnRUN pacman -Syu --noconfirm basenRUN sudo -u user yaourt -S --noconfirm mkinitcpio-docker-hooksnRUN sed -i s/archlinux/base/sample_image/g /etc/docker-btrfs.jsonnRUN perl -i -p -e s/(?<=^HOOKS=()(.*)(?=))/$1 docker-btrfs/g /etc/mkinitcpio.confn

只需要通過docker build . -t sample_image就可以構建自己的鏡像了。

準備內核跟initramfs

鏡像生成好了以後，下一步就是準備內核跟構建initramfs了。注意這一步操作盡量在你打算用來啟動docker鏡像的機器上進行，因為mkinitcpio會自動根據機器把相應的內核模塊放入initramfs中去，如果在別的機器上進行的話，那就可能會有一些驅動沒有被自動裝入initramfs中。如前所述，這一步的工作是在docker容器中進行的。首先運行容器並開啟一個shell：

docker run -v $(pwd):/workspace -w /workspace -it sample_image bashn

然後在容器中執行如下命令：

mkinitcpio -p linuxncp /boot/* .nexitn

然後就可以在當前目錄下看到準備好的initramfs-linux-fallback.img、initramfs-linux.img以及vmlinuz-linux了。

準備top layer的內容

Top layer是mkinitcpio-docker-hooks引入的新概念，它指的是某個驅動器中的某個目錄，這個目錄會在啟動的時候讀寫層創建之後，真正的root掛載之前，通過busybox的cp -a命令整個拷貝到讀寫層裡面去。為什麼需要top layer呢？因為我們需要在多台機器上啟動同一個鏡像，而不同機器上的往往會根據需要配置不同的配置文件，比如/etc/fstab以及/etc/X11/xorg.conf。另外，DockerHub免費賬戶上的鏡像都是公開的，/etc/passwd、/etc/shadow等的私密性文件也不適合放在鏡像裡面存儲。

準備top layer的內容，實際上就是找一個文件夾，把需要單獨配置的文件，按照從根目錄算起的相對路徑存放在這個文件夾裡面。比如說如果你想給某台機器單獨配置/etc/fstab，那麼你就應該在top layer的目錄中添加etc/fstab這個文件。這裡推薦的具體的操作流程是：首先通過docker run -v $(pwd):/workspace -w /workspace -it sample_image bash進入容器中的shell，然後在其中做各種配置，比如useradd ...，完了以後把新生成的配置文件拷貝到top layer的文件夾中去

設置啟動管理器

設置好了top layer以後，我們基本上可以算是萬事具備只差東風了。我們只需要簡單設置一下啟動管理器就可以啟動我們的系統了。這裡以refind為例子，這裡假設我們的所有東西放在一個label為「linux」的btrfs分區中，docker目錄（也就是你系統啟動以後會掛載到/var/lib/docker的目錄）存放在這個分區根目錄下的一個叫做「docker」的子卷中，而內核、initramfs以及top layer都是位於分區根目錄下的「boot_docker」文件夾中，而我們希望創建的讀寫層名字叫做「docker_rwlayer」，那麼相應的refind.conf中的菜單項的代碼如下：

menuentry archlinux-docker {n icon EFI/refind/icons/os_arch.pngn volume linuxn loader boot_docker/vmlinuz-linuxn initrd boot_docker/initramfs-linux.imgn options "root=LABEL=linux rootflags=subvol=docker_rwlayer rw docker_path=docker toplayer=LABEL=linux toplayer_path=boot_docker"n}n

其中內核選項中，我們通過root來指定docker目錄所在的分區，rootflags中的subvol來指定讀寫層的位置，docker_path來指定docker目錄在root中的相對位置；通過toplayer來指定top layer目錄所在的分區，toplayerflags來指定top layer所在分區的掛載選項，toplayer_path來指定top layer的目錄在toplayer分區中的相對位置。