有一次，我決定寫一篇關於以 docker 容器和 deb 包形式交付的文章，但是當我開始寫的時候，出於某種原因，我被帶到了第一台個人電腦甚至計算器的遙遠時代。總的來說，我並沒有對 docker 和 deb 進行枯燥的比較，而是對演化這個主題有了這些想法，供大家判斷。
任何產品，無論它是什麼，都必須以某種方式到達產品伺服器，進行設定和啟動。這就是本文要討論的內容。
我會在歷史背景下進行反思，“我所看到的就是我所歌唱的”，我第一次開始編寫程式碼時所看到的以及我現在觀察到的，我們自己目前正在使用什麼以及為什麼使用。本文並不聲稱是一項成熟的研究，有些觀點被遺漏了，這只是我對過去和現在的個人看法。
所以，回到過去的美好時光......我記得的最早的傳送方式是錄音機裡的磁帶。我有一台電腦 BK-0010.01…
計算機時代
不，還有更早的時候，還有一個計算器 и .
所以，當我有 ，那麼傳輸程序的方法就是在一個盒子裡放一張普通的紙，上面寫上程序，如果需要的話，可以手動寫入計算器。如果你想玩（是的，即使是這個古老的計算器也有遊戲），你就坐下來並在計算器中輸入一個程式。自然，當計算器關閉時，該程式也就消失了。除了手寫在紙上的計算器代碼外，這些程式還發表在《無線電》和《青少年科技》雜誌上，並印刷在當時的書籍中。
下一個修改是計算器 ，它已經具有一些非揮發性資料儲存的類似功能。現在不再需要手動進入遊戲或程序，而是在使用按鈕執行一些神奇的操作後，它就會自行加載。
計算器中最大程式的大小為 105 步，MK-52 中永久記憶體的大小為 512 步。
順便說一句，如果有這些計算器的粉絲正在閱讀這篇文章 - 在撰寫本文的過程中，我發現了適用於 Android 的計算器模擬器和適用於它的程式。前進到過去！
關於 MK-52 的重點題外話 （取自維基百科）
MK-52 搭乘聯盟號 TM-7 太空船飛入太空。其目的是在機載計算機故障時用來計算著陸軌跡。
自 52 年以來，配備 Elektronika-Astro 記憶體擴充單元的 MK-1988 已作為導航運算套件的一部分提供給海軍艦艇。
第一台個人電腦
讓我們回到過去 。顯然那裡有更多的內存，並且從紙上輸入代碼不再是一種選擇（儘管起初我就是這麼做的，因為根本沒有其他媒介）。錄音機的錄音帶成為儲存和傳送軟體的主要手段。
盒式磁帶上儲存的通常是一個或兩個二進位文件，其他所有內容都包含在裡面。可靠性很低，需要保留2-3份程序副本。載入時間也不令人樂觀，愛好者嘗試了不同的頻率編碼來克服這些缺點。那時我自己還沒有涉足專業軟體開發（除了用 BASIC 編寫的簡單程式），因此很遺憾我無法詳細地告訴你裡面的一切是如何安排的。電腦只有 RAM 這一事實在很大程度上決定了資料儲存方案的簡單性。
可靠、大容量儲存媒體的出現
後來，軟碟出現了，複製過程變得更簡單，可靠性也提高了。
但只有當出現足夠大的 HDD 形式的本地儲存時，情況才會發生根本性改變。
交付類型發生了根本性的變化：出現了安裝程序來管理系統配置過程以及刪除後的清理，因為程序不是簡單地讀入內存，而是已經復製到本地存儲中，您需要能夠在必要時從中清理不必要的程序。
同時，所提供軟體的複雜性也增加。
交付的文件數量從個增加到數百和數千個，當不同的程式使用相同的資料時，庫版本的衝突和其他煩惱就開始了。
那時，存在的概念尚未向我揭示。 Linux我曾經生活在 MS-DOS 的世界裡，後來， Windows他使用 Borland Pascal 和 Delphi 編寫程式碼，偶爾也涉獵 C++。當時，許多人使用 InstallShield 來交付產品。 ，它相當成功地解決了部署和配置軟體的所有任務。
網路時代
漸漸地，軟體系統的複雜性變得越來越複雜，從單體系統和桌面應用程式到分散式系統、瘦客戶端和微服務。現在您需要配置的不只是一個程序，而是一組程序，並且以使它們協同工作。
觀念徹底改變了，網路來了，雲端服務時代開始了。到目前為止，它還處於起步階段，以網站的形式存在；沒有人真正夢想過服務。但它是應用程式開發和實際交付行業的一個轉捩點。
就我個人而言，我注意到那時開發人員的世代發生了變化（或者僅僅是在我的圈子裡），感覺所有好的舊交付方法在某一刻都被遺忘了，一切都從頭開始：所有的交付都開始透過下意識的腳本完成，他們自豪地稱之為「持續交付」。事實上，一個混亂時期已經開始，舊的東西被遺忘、不再使用，而新的東西根本不存在。
我記得當時在我工作的公司（我不說出它的名字）裡，人們不是通過 ant 進行構建（當時 maven 並不流行或根本不存在），而是簡單地在 IDE 中構建一個 jar 然後平靜地將其提交給 SVN。因此，部署包括從 SVN 取得檔案並透過 SSH 複製到所需的機器。就這麼簡單、粗暴。
同時，簡單 PHP 網站的交付方式非常原始，只需透過 FTP 將修正的檔案複製到目標機器即可。有時沒有這樣的事情——程式碼是在生產伺服器上即時編輯的，如果某處有備份就特別別緻了。
RPM 和 DEB 包
另一方面，隨著網路的發展，類UNIX系統開始越來越受歡迎；尤其是我正是在那時發現了紅帽系統。 Linux 大約在2000年左右。當然，當時也有一些軟體分發方式。根據維基百科，RPM作為主要的軟體套件管理器早在1995年就出現在Red Hat版本中。 Linux 2.0 從那時起，該系統以 RPM 軟體包的形式交付，並持續蓬勃發展。
家庭分佈 Debian 他們採取了類似的方法，以 deb 包的形式進行交付，這種方法至今仍未改變。
套件管理器可讓您自行交付軟體產品、在安裝期間配置它們、管理不同套件之間的依賴關係、刪除產品以及在卸載期間清理不必要的項目。那些。在大多數情況下，這就足夠了，這也是為什麼它們幾十年來幾乎沒有變化。
雲端運算不僅增加了從實體媒體的安裝，還增加了從雲端儲存庫到套件管理器的安裝，但從本質上講，幾乎沒有什麼變化。
值得注意的是，目前有一些嘗試擺脫 deb 並轉向 snap 包，但稍後會詳細介紹。
於是，這群既不懂 DEB 也不懂 RPM 的新一代雲端開發者也慢慢成長，累積了經驗，產品也變得越來越複雜，需要一些比 FTP、bash 腳本和類似的學生手藝更合理的交付方式。
這就是 Docker 的用武之地，它是虛擬化、資源隔離和交付方法的混合體。現在很時尚、很年輕，但凡事都需要它嗎？這是靈丹妙藥嗎？
據我觀察，很多時候人們建議使用 Docker 並不是因為它是一個合理的選擇，而僅僅是因為，一方面，它在社區中被討論，而且只有那些建議使用它的人知道它。另一方面，傳統的優良包裝系統大多保持安靜——它們存在並且默默地、不引人注意地完成它們的工作。在這種情況下，沒有其他選擇——選擇是顯而易見的——Docker。
我將嘗試分享我們如何實施 Docker 以及結果的經驗。
自寫腳本
最初，有 bash 腳本將 jar 檔案部署到所需的機器。該過程由詹金斯管理。此過程成功完成，因為 jar 檔案本身已經是一個包含類別、資源甚至配置的組件。如果你把所有東西都投入其中，那麼在劇本中把它展現出來並不是最困難的事情
但是腳本有幾個缺點：
- 劇本通常都是匆忙寫成的，因此非常原始，只包含一個最有利的場景。這是因為，開發人員對最快的交付感興趣，而正常的腳本需要大量的資源。
- 由於上一點，腳本不包含卸載程序
- 沒有建立昇級程序
- 當出現新產品時，你需要寫新腳本
- 無依賴支持
當然，您可以編寫一個複雜的腳本，但是，正如我上面所寫的，這需要時間來開發，而且並非最不重要的，而且正如我們所知，時間永遠不夠。
所有這些顯然將這種部署方法的應用範圍限制在僅限於最簡單的系統。現在是改變這種狀況的時候了。
碼頭工人
不知什麼時候，剛出道的中年人開始向我們走來，他們滿腦子都是想法，對 docker 讚不絕口。好，我們走吧！我們開始做吧！有過兩次嘗試。兩次嘗試均未成功 - 可以說，原因是野心很大但缺乏實際經驗。是否有必要用任何必要的手段來強迫它並結束它？不太可能——團隊必須發展到所需的水平才可以使用適當的工具。另外，在使用現成的Docker映像時，我們經常會遇到網路無法正常使用（可能也是Docker本身不夠成熟導致的）或是很難擴展別人的容器的情況。
我們遇到了什麼不便？
- 橋接模式下的網路問題
- 在容器中查看日誌不方便（如果沒有單獨移動到主機檔案系統）
- 容器內的ElasticSearch週期性地奇怪地凍結，原因尚不清楚，容器是官方的
- 在容器內使用外殼很不方便 - 一切都非常有限，沒有常用的工具
- 收集的容器尺寸很大——儲存成本高
- 由於容器體積較大，很難支援多版本。
- 比其他方法（腳本或 deb 套件）的建置時間更長
另一方面，為什麼透過相同的 deb 以 jar 檔案的形式部署 Spring 服務會更糟？資源隔離真的有必要嗎？將服務塞進一個大大縮小的容器中是否值得失去作業系統的便利工具？
實踐表明，實際上沒有必要這麼做；在 90％ 的情況下，deb 包就足夠了。
什麼時候舊的 deb 會失效以及什麼時候我們真正需要 docker？
對我們來說，這是用 Python 部署服務。機器學習所需的大量庫並未包含在標準作業系統交付中（並且包含的版本不正確）、設定不當、同一主機系統上不同服務需要使用不同版本等問題導致交付這種核混合物的唯一合理方式是 Docker。事實證明，組裝一個 docker 容器的勞動強度要低於將所有這些打包成帶有依賴關係的單獨 deb 包的想法，事實上，沒有一個頭腦正常的人會承擔這項工作。
計劃使用docker的第二個點是使用藍綠部署方案來部署服務。但在這裡我們希望逐漸增加複雜性：首先，建置 deb 包，然後從它們建置 docker 容器。
Snap 套件
讓我們回到Snap包裹的話題。它們最早正式出現在… Ubuntu 4月16日。與傳統的DEB和RPM軟體包不同，Snap軟體包包含了所有依賴項。雖然這避免了庫衝突，但也意味著產生的軟體包體積更大。此外，這可能會影響系統安全性：部署Snap軟體包時，建立軟體包的開發者必須管理所有對所包含庫的變更。總而言之，Snap軟體包的使用並非總是那麼簡單直接，也並非總是雙贏之選。然而，如果例如Docker僅用作打包工具而非虛擬化工具，那麼Snap軟體包則是完全合理的替代方案。
因此，我們現在合理地結合使用 deb 套件和 docker 容器，在某些情況下，我們可能會用 snap 套件替換它們。
只有註冊用戶才能參與調查。 ， 請。
您用什麼來送貨？
自寫腳本
手動複製到 FTP
deb 軟體包
rpm 包
snap 軟體包
Docker 映像
虛擬機器映像
克隆整個硬碟
木偶
ansible
其他
109 位用戶投票。 32 名用戶棄權。
來源： www.habr.com
