【51CTO.com快譯】自從.NET技術(shù)已經(jīng)能夠在Linux上運(yùn)行(如同在Windows和macOS上那樣)以來，全世界的Linux容器和microservices（微服務(wù)）都向.NET開發(fā)者開放了。由于.NET擁有著超大量的開發(fā)者群體，長期的成功開發(fā)案例和令人印象深刻的性能參數(shù)，它為全世界的Linux容器向著原本以Windows為中心的開發(fā)者陣營的擴(kuò)展，提供了一個很好的機(jī)會。

雖然在Linux容器里運(yùn)行.NET代碼時(shí)，有一些不容錯過的運(yùn)行方面的細(xì)微差別，而這似乎顯得有點(diǎn)冒進(jìn)，但我還是會脫口而出那句“去吧，皮卡丘！”這可比要把一些代碼推到鏡像里去完成可容易多了。畢竟，一切都能快速實(shí)現(xiàn)，而且是恰到好處地，不是嗎？

當(dāng)然，讓你的.NET代碼能運(yùn)行在Linux容器中可并不是一個微不足道的事，正如一個古老的諺語所言：“讓它先工作起來，然后再讓它能快速地工作。”

快速，在我們這里是指其在構(gòu)建、啟動鏡像以及鏡像內(nèi)代碼的性能等方面所花費(fèi)的時(shí)間。本文將涉及前兩個部分——構(gòu)建和啟動鏡像的時(shí)間。我們將從一個簡單的.NET程序開始，來運(yùn)行基于容器的應(yīng)用，然后觀察鏡像隨其變小的進(jìn)化，并導(dǎo)致構(gòu)建和加載時(shí)間的縮短。

至于代碼優(yōu)化則是另外一方面的話題了，市面上有很多書可供您參考。

橫空出世且如此鮮活!
試想一個非常簡單的例子：微服務(wù)僅給出一個HTTP 類型的“Hello world”響應(yīng)。也就是說，您將瀏覽器指向一個URL，并獲得包含有主機(jī)名的一個非常簡單的響應(yīng)。記住這是一個簡單的例子，我登錄到了Linux虛擬機(jī)(VM)里，從其repo（請參見https://github.com/donschenck/dotnet_docker_msa）中這些下載代碼。

就像面對任何新技術(shù)的開發(fā)者那樣，在這種情況下，我想盡快在Linux容器中啟動并運(yùn)行該應(yīng)用程序。因此我迅速地構(gòu)造了一個Dockerfile（請參見repo中的Dockerfile.attempt1）并使用如下命令構(gòu)建了一個鏡像：

docker build -t attempt1 -f Dockerfile.attempt1 .

在構(gòu)建成功完成后，我當(dāng)然是興奮的。而當(dāng)我能用如下命令在容器中運(yùn)行鏡像時(shí)，我甚至有些激動了：

docker run -d -p 5000:5000 --name attempt1 attempt1

我將瀏覽器指向正確的URL，它也是我虛擬機(jī)的IP地址。請看下面的截圖：

一些數(shù)字
我在第一次構(gòu)建該鏡像的時(shí)候花了高達(dá)95秒的時(shí)間，其原因在于需要下載一整個490 MB大小的且安裝了.NET SDK的紅帽子企業(yè)版（Red Hat Enterprise Linux，RHEL）的鏡像。這也導(dǎo)致了整個鏡像的大小為659 MB。

公平地說，后續(xù)的構(gòu)建將會更快些，因?yàn)閐ocker格式的容器鏡像，現(xiàn)在已經(jīng)存在我的機(jī)器上且可用了。此后，我又改變了其源代碼，并再次運(yùn)行了構(gòu)建過程，這次只花了大約50秒的時(shí)間，并產(chǎn)生了相同大小為659 MB的鏡像。

其實(shí)鏡像的大小還是很重要的。雖然您的機(jī)器上所使用的存儲空間現(xiàn)如今已經(jīng)是比較便宜的了，但它仍然是一種有限的商品。特別是在您定期使用容器的時(shí)侯，那些過期且被遺忘的鏡像很容易就“靜靜”地是待在那里占用消耗了空間。因此您很容易在不小心之間就很快地填滿了磁盤的空間。

那么，如何才能讓鏡像變得更小呢?

刪除一些不需要的部分
將一個簡單的命令行選項(xiàng)添加到dotnet restore命令中，是會有所幫助的。我使用的是：dotnet restore --no-cache (請參見Dockerfile.attempt2)來消除任何緩存，它將鏡像的大小降至608.6 MB，也就是縮減了50.6 MB，即省下了百分之七以上的空間。但我對此并不滿意，肯定還有更多的辦法。

在構(gòu)建鏡像前先構(gòu)建應(yīng)用程序
我意識到：當(dāng)我每次在一個容器里運(yùn)行鏡像的時(shí)候，應(yīng)用程序都會構(gòu)建.NET的應(yīng)用。雖然這花去的1.6秒顯然不是什么一個大塊的時(shí)間，但是我還是覺得這有些浪費(fèi)。我通過在dotnet和retore之間插入命令build，并在構(gòu)建容器鏡像之前先構(gòu)建其應(yīng)用程序，這將會使得容器的啟動要快得多。這個結(jié)果顯示在Dockerfile.attempt3中。當(dāng)然，這是以消耗存儲空間為代價(jià)的，其鏡像的大小升至為610.2 MB了。不過，dotnet build是無論如何都必須運(yùn)行的，我們不妨現(xiàn)在多花點(diǎn)時(shí)間，而以后每次啟動容器之后都能因此獲益了。

Dotnet的發(fā)布
接下來，我們的焦點(diǎn)轉(zhuǎn)移到一個問題上：既然容器是一個運(yùn)行環(huán)境，那么為什么不使用dotnet publish命令使得在其被推入鏡像之前就發(fā)布代碼呢？如果我這樣做了的話，我就不需要在自己的容器里預(yù)先安裝好.NET了。畢竟，發(fā)布是允許您構(gòu)建一個單獨(dú)的(或“獨(dú)立”)應(yīng)用程序，而該應(yīng)用程序可以在任何地方運(yùn)行。這才是dotnet publish 的真正用途！而這將是鏡像大小和啟動時(shí)間上的巨大的成功。
 

我修改了project.json文件，用以支持發(fā)布。其間，我刪除掉了用以告訴編譯器去構(gòu)建一個平臺那段命令行（實(shí)際上是將它注釋掉了）。您可以在下面的截屏上看到：

接下來，我通過使用發(fā)布命令發(fā)布了代碼：dotnet publish -c Release -r rheh.7.2-x64。此舉將所有已編譯的部分，包括所有運(yùn)行時(shí)所必要的部分，都放到了一個我可以復(fù)制到鏡像的文件夾里。當(dāng)然，它可以變得更好一些：由于我不需要.NET 的預(yù)安裝，所以我可以使用一個沒有.NET的RHEL基本版本。而之所以這樣做，是因?yàn)榇伺e肯定會節(jié)省更多的空間。
為了將各個部分推到鏡像之中，我使用了以下是Dockerfile （請參見repo中的Dockerfile.attempt4）：

值得注意的是：兩個yum install命令將會安裝一些能使得.NET需要在RHEL之上的先決條件。目前尚無繞過這個問題的辦法。但是，畢竟也不是什么大不了的。我運(yùn)行了docker build，結(jié)果生成的鏡像大小居然是694.6 MB！這到底發(fā)生了什么事呢？

誰會需要緩存呢?
原來，兩個yum install指令也為未來的yum install命令構(gòu)建了緩存。所以如果我能在每個命令之后立即清除緩存的話，就會好很多。以下就是我的第五次迭代Dockerfile，請參見Dockerfile.attempt5：

我們將運(yùn)行了docker build與這個Dockerfile所產(chǎn)生的鏡像文件大小相比較，可以看到，這次只有293.7 MB, 比第一次的嘗試結(jié)果少了55%以上。此處該有鼓聲。

該堆積的是命令而不是杯子
反映在文件Dockerfile中的, 我最后的修改是堆積式的yum install命令,如下:

可見，由此產(chǎn)生的鏡像大小為257.5 MB，相比我的第一次嘗試，結(jié)果可是少了60%以上。最后，請讓我以如下圖表的形式來和您重溫這次所提及的各次嘗試：

總結(jié)
當(dāng)我們探索新技術(shù)和新模式時(shí)，我們必須小心，不要把我們早期的結(jié)果與我們最佳實(shí)踐與努力相混淆。雖然早期的成功會帶來了興奮和鼓勵，但它也可能使我們停下前進(jìn)的腳步。我們應(yīng)該勤奮、不斷嘗試并且總對改進(jìn)建議保持開放的心態(tài)。

【原標(biāo)題】The Evolution of a Linux Container (作者: Don Schenck)
原文鏈接：https://dzone.com/articles/the-evolution-of-a-linux-container
 

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】