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

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

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

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

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

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

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

docker build -t attempt1 -f Dockerfile.attempt1 .

在構建成功完成后，我當然是興奮的。而當我能用如下命令在容器中運行鏡像時，我甚至有些激動了：

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

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

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

公平地說，后續的構建將會更快些，因為docker格式的容器鏡像，現在已經存在我的機器上且可用了。此后，我又改變了其源代碼，并再次運行了構建過程，這次只花了大約50秒的時間，并產生了相同大小為659 MB的鏡像。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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