不知何故，我決定寫一篇關於以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系統開始越來越流行，特別是在那個時候我發現了RedHat Linux 6，大約2000年。 當然，也有一定的軟體交付方式；根據 Wikipedia，RPM 作為主要的套件管理器已經在 1995 年的 RedHat Linux 2.0 版本中出現。 從那時起直到今天，該系統一直以 RPM 套件的形式交付，並且已經相當成功地存在和開發。
Debian家族的發行版也遵循了類似的路徑，以deb包的形式實現交付，至今仍保持不變。
軟體包管理器可讓您自行交付軟體產品、在安裝過程中對其進行配置、管理不同軟體包之間的依賴關係、在卸載過程中刪除產品並清理不必要的項目。 那些。 在大多數情況下，這就是所需要的，這就是為什麼它們持續了幾十年幾乎沒有變化。
雲端運算不僅從實體媒體還從雲端儲存庫向套件管理器添加了安裝，但從根本上來說幾乎沒有改變。
值得注意的是，目前有一些遠離 deb 並切換到 snap 包的舉措，但稍後會詳細介紹。
於是，這些既不懂DEB，又不懂RPM的新一代雲端開發者，也慢慢成長，累積了經驗，產品變得更加複雜，需要一些比FTP、bash腳本和類似的學生手藝更合理的交付方式。
這就是 Docker 的用武之地，它是一種虛擬化、資源界定和交付方法的混合體。 現在很時尚很年輕，但是是不是一切都需要它呢？ 這是靈丹妙藥嗎？
根據我的觀察，很多時候 Docker 被提出並不是一個合理的選擇，而只是因為，一方面，它在社區中被談論，而提出它的人只知道它。 另一方面，在大多數情況下，他們對良好的舊包裝系統保持沉默——它們存在並安靜地完成工作，不被注意。 在這種情況下，確實沒有其他選擇——選擇是顯而易見的——Docker。
我將嘗試分享我的實作 Docker 的經驗以及結果。
自寫腳本
最初，有 bash 腳本將 jar 檔案部署到所需的電腦。 這個過程由 Jenkins 管理。 這很成功，因為 jar 檔案本身已經是一個包含類別、資源甚至配置的組件。 如果你把所有的東西都最大限度地放進去，那麼將它擴展成腳本並不是你需要的最困難的事情
但腳本有幾個缺點：
- 腳本通常是匆忙編寫的，因此非常原始，只包含一種最佳情況。 這是因為開發人員對快速交付感興趣，而正常的腳本需要投入大量資源
- 由於上一點，腳本不包含卸載過程
- 沒有既定的升級程序
- 當新產品出現時，需要編寫新腳本
- 無依賴支持
當然，您可以編寫複雜的腳本，但是，正如我上面所寫，這是開發時間，而且是最重要的，而且正如我們所知，時間總是不夠的。
這一切顯然限制了這種部署方法的應用範圍，僅限於最簡單的系統。 是時候改變這一點了。
碼頭工人
在某個時候，新鮮出爐的中間人開始來到我們身邊，他們充滿了想法並對碼頭工人讚不絕口。 好吧，旗幟在手——讓我們開始吧！ 有兩次嘗試。 兩人都沒有成功——可以說，是因為雄心勃勃，但缺乏真正的經驗。 有必要不擇手段地強行結束嗎？ 這不太可能——團隊必須發展到所需的水平才能使用適當的工具。 另外，在使用現成的Docker映像時，我們經常會遇到網路無法正常運作（可能是Docker本身受潮的原因）或難以擴展別人的容器的情況。
我們遇到了哪些不便？
- 橋接模式下的網路問題
- 查看容器中的日誌不方便（如果沒有單獨儲存在宿主機的檔案系統中）
- ElasticSearch偶爾會在容器內奇怪的凍結，原因尚未確定，容器官方
- 有必要在容器內使用 shell - 一切都非常精簡，沒有熟悉的工具
- 收集的容器尺寸較大 - 儲存成本昂貴
- 由於容器體積較大，難以支援多版本
- 與其他方法（腳本或 deb 套件）不同，建置時間較長
另一方面，為什麼透過同一個 deb 以 jar 存檔的形式部署 Spring 服務會更糟？ 資源隔離真的有必要嗎？ 將服務塞進大大縮小的容器中而失去方便的作業系統工具是否值得？
實踐表明，實際上這是沒有必要的，deb 包在 90% 的情況下就足夠了。
好的舊 deb 什麼時候會失敗，什麼時候我們真正需要 docker？
對我們來說，這是在 python 中部署服務。 機器學習所需的大量庫未包含在操作系統的標準發行版中（並且存在錯誤的版本）、設置黑客、同一主機系統上的不同服務需要不同版本導致運送這種核混合物的唯一合理方式是碼頭工人。 事實證明，組裝一個 docker 容器的勞動強度比將其全部打包到具有依賴關係的單獨 deb 包中的想法要低，而且事實上，任何頭腦清醒的人都不會這樣做。
我們計劃使用Docker的第二點是使用藍綠部署方案來部署服務。 但在這裡我想要逐漸增加複雜性：先建置 deb 包，然後從它們建置 docker 容器。
快照包
讓我們回到快照包。 它們首次正式出現在 Ubuntu 16.04 中。 與通常的 deb 包和 rpm 包不同，snap 攜帶了所有依賴項。 一方面，這可以讓您避免庫衝突，另一方面，生成的套件的大小更大。 此外，這也會影響系統的安全性：在快照交付的情況下，所包含庫的所有變更都必須由創建套件的開發人員監控。 一般來說，並不是一切都那麼簡單，普遍的幸福也不是來自於使用它們。 但是，儘管如此，如果同一個 Docker 僅用作打包工具而不用於虛擬化，那麼這是一個完全合理的替代方案。
因此，我們現在以合理的組合使用 deb 套件和 docker 容器，也許在某些情況下我們會用 snap 套件替換它們。
只有註冊用戶才能參與調查。 ， 請。
你用什麼來送貨？
-
自寫腳本
-
手動複製到 FTP
-
deb 包
-
rpm 包
-
快照包
-
Docker 映像
-
虛擬機器鏡像
-
克隆整個硬碟
-
木偶
-
ansible
-
其他
109 位用戶投票。 32 名用戶棄權。
來源： www.habr.com