不知何故，我决定写一篇关于以 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偶尔会在容器内奇怪的冻结，原因尚未确定，容器官方
- 有必要在容器内使用外壳 - 一切都非常精简，没有常用的工具
- 收集的容器尺寸较大 - 存储成本昂贵
- 由于容器体积较大，难以支持多版本
- 与其他方法（脚本或 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 名用户弃权。
来源： habr.com